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.

[christophfroehlich]

Thanks for your comment @destogl

Here my two cents:

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.

We have that now optional with max_acceleration_reverse and max_deceleration_reverse.

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.

We (accidentally) have chosen the nav2 naming below, with max_deceleration being negative.

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

We (accidentally) have it similar, but only with non-abbreviated names

ros2_controllers/diff_drive_controller/src/diff_drive_controller_parameter.yaml

Lines 131 to 160 in c9ca6f7

	max_velocity: {
	type: double,
	default_value: .NAN,
	validation: {
	"diff_drive_controller::gt_eq_or_nan<>": [0.0]
	}
	}
	min_velocity: {
	type: double,
	default_value: .NAN,
	validation: {
	"diff_drive_controller::lt_eq_or_nan<>": [0.0]
	}
	}
	max_acceleration: {
	type: double,
	default_value: .NAN,
	description: "Maximum acceleration in forward direction.",
	validation: {
	"diff_drive_controller::gt_eq_or_nan<>": [0.0]
	}
	}
	max_deceleration: {
	type: double,
	default_value: .NAN,
	description: "Maximum deceleration in forward direction.",
	validation: {
	"diff_drive_controller::lt_eq_or_nan<>": [0.0]
	}
	}

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.

I moved the diff_drive limiter logic to the RateLimiter in control_toolbox. We should compare the two algorithms and see if we can use the saturation_limiter also in the control_toolbox ros-controls/control_toolbox#287