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).

[destogl]

Here my two cents:

1. Having min_* values positive doesn't make any sense. I fully agree with your observation above.
2. In the most robots there should be enough to have max_velocity, max_acceleration and max_deceleration, as often times in practice the acceleration and deceleration have different limiting values, either because of the physics or safety.
3. To support more advanced robots that are asymmetrical, I propose to have both also min_* values that than influence reverse movement, as there are robots that can not or should not move with the same dynamics forwards and backwards.
4. Generally, I think the names are a bit confusing, but also “standardized” within ROS. So we should be expecting and checking is that the min_* values are always negative to make (a bit more) sure people mean them as they are written.

Besides that, we should check:

1. Nav2 velocity smoother as they have the same limits. From the docs, it seems they are also always expecting negative values for the min_*: https://docs.nav2.org/configuration/packages/configuring-velocity-smoother.html
2. We have a JointSaturationLimiter that limits positions, velocities, and acceleration for the arms. Can we reuse that logic also here, by extending the limiter with a new on_enforce method to also accept the Twist (or TwistStamped) messages and do the limiting there. I suppose we can reuse the logic, and then we hopefully don't need to have two implementations. AFAIK, we can even create a new class for it as Joint in the name implies to be used on joint only.