Show EOL distros: 

yujin_ocs: cmd_vel_mux | yocs_controllers | yocs_velocity_smoother

Package Summary

Bound incoming velocity messages according to robot velocity and acceleration limits.

  • Maintainer status: developed
  • Maintainer: Jorge Santos Simon <jorge AT yujinrobot DOT com>
  • Author: Jorge Santos Simon <jorge AT yujinrobot DOT com>
  • License: BSD
  • Source: git https://github.com/yujinrobot/yujin_ocs.git (branch: groovy-devel)
yujin_ocs: yocs_cmd_vel_mux | yocs_controllers | yocs_diff_drive_pose_controller | yocs_math_toolkit | yocs_velocity_smoother | yocs_virtual_sensor | yocs_waypoints_navi

Package Summary

Bound incoming velocity messages according to robot velocity and acceleration limits.

yujin_ocs: yocs_cmd_vel_mux | yocs_controllers | yocs_diff_drive_pose_controller | yocs_joyop | yocs_keyop | yocs_math_toolkit | yocs_rapps | yocs_safety_controller | yocs_velocity_smoother | yocs_virtual_sensor | yocs_waypoints_navi

Package Summary

Bound incoming velocity messages according to robot velocity and acceleration limits.

yujin_ocs: yocs_cmd_vel_mux | yocs_controllers | yocs_diff_drive_pose_controller | yocs_joyop | yocs_keyop | yocs_math_toolkit | yocs_rapps | yocs_safety_controller | yocs_velocity_smoother | yocs_virtual_sensor | yocs_waypoints_navi

Package Summary

Bound incoming velocity messages according to robot velocity and acceleration limits.

yujin_ocs: yocs_cmd_vel_mux | yocs_controllers | yocs_diff_drive_pose_controller | yocs_joyop | yocs_keyop | yocs_math_toolkit | yocs_rapps | yocs_safety_controller | yocs_velocity_smoother | yocs_virtual_sensor | yocs_waypoints_navi

Package Summary

Bound incoming velocity messages according to robot velocity and acceleration limits.

New in groovy

Ros API

VelocitySmoother Nodelet

The velocity smoother nodelet is intended to run together with the kobuki_node to apply robot's velocity and acceleration limits to the incoming commands before resending them to the robot.

Subscribed Topics

~raw_cmd_vel (geometry_msgs/Twist)
  • Input velocity commands.
~odometry (nav_msgs/Odometry)
  • We compare the output velocity commands to "real" velocity to ensure we don't create very big jumps in the velocity profile.

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.

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.

Report a Bug

Use github to report bugs or request features.

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.

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.

Wiki: yocs_velocity_smoother (last edited 2018-01-09 09:00:51 by GvdHoorn)