Ros API

VelocitySmoother Nodelet

The velocity smoother nodelet runs together with the kobuki_node to apply robot's velocity and acceleration limits to the incoming commands before resending them to the robot. It will however also work for any other generic ros mobile base driver.

Subscribed Topics

~raw_cmd_vel (geometry_msgs/Twist)

• Input velocity commands.

~odometry (nav_msgs/Odometry)

• We compare the output velocity commands to measured velocity to ensure we don't create very big jumps in the velocity profile.

~robot_cmd_vel (geometry_msgs/Twist)

• Alternatively, we can also compare the output velocity commands to end robot velocity commands to ensure we don't create very big jumps in the velocity profile. See robot_feedback parameter description below for more details.

Published Topics

~smooth_cmd_vel (geometry_msgs/Twist)

• Smoothed output velocity commands respecting velocity and acceleration limits.

Parameters

~accel_lim_v (double)

• Linear acceleration limit. Mandatory.

~accel_lim_w (double)

• Angular acceleration limit. Mandatory.

~speed_lim_v (double)

• Linear velocity limit. Mandatory.

~speed_lim_w (double)

• Angular velocity limit. Mandatory.

~decel_factor (double, default: 1.0)

• Deceleration/acceleration ratio. Useful to make deceleration more aggressive, for example to safely brake on robots with high inertia.

~frequency (double, default: 20.0)

• Output messages rate. The velocity smoother keeps it regardless incoming messages rate, interpolating whenever necessary.

~robot_feedback (int, default: 0)

• Specifies which topic to use as robot velocity feedback (0 - none, 1 - odometry, 2 - end robot commands). See hints below for more details.

Hints

• All the parameters except frequency are dynamically reconfigurable.
• Linear and angular velocities are smoothed proportionally to the more restricted, so we guaranty a constant rotation radius.
• If the input topic gets inactive, and the last command is not a zero-velocity one, (maybe the controller crashed, or just forgot good manners...), we introduce a fake zero-velocity command after a sort timeout.

• Take a look to the Kobuki's Control System Tutorial to learn how yocs_velocity_smoother works together with other components to build up a safe and flexible control system.

An extra word on robot_feedback parameter

By robot feedback we mean the current velocity at which robot "thinks" he moves now. The two common ways to know this are:

• measure the speed, i.e. odometry (option 1)
• assume that robots perfectly follows the commands we send to him (option 2)

Option 0 of course ignores any robot feedback. There are some reasons to use robot feedback. The two we face more often are:

• Multiple controllers accessing the robot through velocity multiplexer. A controller that has been excluded by another with higher priority will continue issuing commands to the robot as if it were the only one, while the robot actual velocity can be completely different from velocity smoother's assumption. If he regains control, his first effective command will jump from the last of the previous controller. This is well addressed by option 2.
• Robot fails to make effective the velocity commands he receives, for example if he cannot accelerate/move at the commanded speed (slopes, carpet, high-inertia robots...). Again the velocity smoother assumption is wrong. This is well addressed by option 1.

So the recommended option is 2 in most cases (if there aren't concurrent controllers it will have no effect), letting option 1 just for special situations. If people don't find it useful at all, we will probably remove.