Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add trapezoidal speed trajectory generator #527

Merged
merged 6 commits into from
Jan 14, 2021

Conversation

PeterBowman
Copy link
Member

@PeterBowman PeterBowman commented Jan 12, 2021

The TrapezoidalSpeedTrajectoryGenerator class is added for use by GazeboYarpControlBoardDriver. It is meant to generate a trapezoidal profile capped at the provided reference speed and using fixed acceleration in both ramps. The signature of TrajectoryGenerator::initTrajectory has been expanded to accomodate said reference acceleration value. This generator is also capable of appending new trajectories to ongoing joint motion, that is, whenever a setpoint is updated (e.g. by issuing a positionMove command while a previous one has not yet completed), last computed joint velocity is used to calculate the initial motion of the new trajectory.

In order to configure a control board to use this new generator, set the TRAJECTORY_GENERATION::trajectory_type property to trapezoidal_speed.

Additional changes:

  • GazeboYarpControlBoardDriver has learned to fetch reference speed and acceleration data from initial configuration via TRAJECTORY_GENERATION::refSpeed and TRAJECTORY_GENERATION::refAcceleration properties, respectively. Existing code has been factored out and conveniently improved in a new setTrajectoryReferences method.
  • Previous defaults have been preserved, except for now using 0.01 m/s² as max acceleration for prismatic joints.
  • The control board no longer silently falls back to minimum_jerk if an unsupported value was passed to TRAJECTORY_GENERATION::trajectory_type; an error is reported instead.
  • The code that initializes trajectory_type from config has been slightly simplified and now reports its value in a yDebug line.
  • Added IDE-related stuff to .gitignore (Eclipse & VS Code).


if (instant <= m_ta) // first ramp
{
step = 0.5 * m_acceleration * std::pow(period, 2.0) * (2 * m_tick + 1) + m_v0 * period;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: I think (not 100% sure to be honest) that std::pow(period, 2) should use the simple period*period while specifying the exponent as double will take another more expensive overload.

}
else if (instant > m_tb) // second ramp
{
step = m_acceleration * (m_tf * period - 0.5 * std::pow(period, 2.0) * (2 * m_tick + 1));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@traversaro traversaro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot @PeterBowman ! This is a nice addition, thanks.

I add some minor comments inline, furthermore could you update the CHANGELOG? Thanks!

The code that initializes trajectory_type from config has been slightly simplified and now reports is value in a yDebug line.

I would prefer actually to get rid of most of the yDebug outputs, or at least put it under an option, but indeed as you did it know for sure is consistent with the rest of the code, so I think it is ok.

@traversaro
Copy link
Member

Can you also rebase on the top of the latest master? This should fix CI.

@PeterBowman
Copy link
Member Author

PeterBowman commented Jan 13, 2021

I add some minor comments inline, furthermore could you update the CHANGELOG? Thanks!

Can you also rebase on the top of the latest master? This should fix CI.

Should be all done now, thanks!

Edit: macOS-latest builds are still failing, but I'm not sure why.

@traversaro
Copy link
Member

Edit: macOS-latest builds are still failing, but I'm not sure why.

It is probably due to actions/runner-images#2322, actions/runner-images#2391 or other GitHub Actions/Homebrew regression, feel free to ignore. Probably eventually we should add conda-based macOS CI also here, for the robotology-superbuild has proved to be much more stable then the homebrew-one.

@traversaro
Copy link
Member

Thanks @PeterBowman !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants