Mobile robots: Twist limiter vs motor speed limiter

[christophfroehlich]

I though that I could use a common implementation from the SpeedLimiter and the TractionLimiter to fix #1317 and remove duplicated code in this repo.

I created PRs for both to be moved to the control_toolbox repo

• Move speed limiter from ros2_control repo control_toolbox#212
• Mv/traction limiter control_toolbox#218

But I realized that they have a different approach and both have its design flaws.

Speed Limiter

Was designed to limit the input command, i.e., a body twist. It limits the velocity v (linear or rotation):

• min_velocity < v < max_velocity
• min_acceleration < dv/dt < max_acceleration
• min_jerk < d2v/dt2 < max_jerk

min_* values can be negative!

As reported with #1317, it might be useful to have different acceleration/deceleration limits.

Traction Limiter

Was designed to limit the output command, i.e., the motor velocity. As the error message suggests:

"The positive limit will be applied to both directions. Setting different limits for positive "
"and negative directions is not supported. Actuators are "
"assumed to have the same constraints in both direction"

min_* values are always positive!

• min_velocity < |v| < max_velocity
• min_acceleration < |dv/dt| < max_acceleration if dv/dt > 0 OR min_deceleration < |dv/dt| < max_deceleration if dv/dt < 0
• min_jerk < |d2v/dt2| < max_jerk

This has the effect that

• Setting min_velocity: the robot can't stand still
• Setting min_deceleration/min_acceleration: the robot can't move with constant velocity
• Setting min_jerk: the robot can't move with constant acceleration

Can this behavior be useful at all?

Summary and Question

We discussed that once in a WG meeting that limiting the velocity output of the controller (motor velocity) does not make much sense once the limits from the URDF are enforced by the ressource_manager (see ros-controls/ros2_control#1526). But I see that the URDF specification is very limited, i.e., there is no difference of acceleration or deceleration. Is there a use-case for doing this at controller level?

For the twist command input to the controller: Which of the two limiters is the more appropriate one?
I have the feeling that the original SpeedLimiter with additional parameters for different values for deceleration than acceleration would do the job because I don't see the reason for the robot not moving with zero or constant velocity, but I can imagine that there are different limits for forward or reverse movement (different obstacle detection sensors for example).