Velocity Smoother: option to ignore deceleration limits when commanding full stop

[tonynajjar]

Feature request

Feature description

I believe it would make sense to have an option to ignore the deceleration limits when the commanded velocity is 0. Something like that would not be necessary if the cmd_vel is passed to e.g. the collision_monitor but in my application the velocity smoother would be the last publisher of cmd_vel so I need it to output zero as soon as the input is zero.

N.B: I didn't try the velocity smoother yet but this feature request only makes sense if max_decel does what I think it does and that is limit the deceleration, i.e. limit the rate of change from a higher to lower value in absolute value (as opposed to limiting the acceleration in the counter-clockwise direction)

Let me know if the feature makes sense to you.

Implementation considerations

[SteveMacenski]

I believe it would make sense to have an option to ignore the deceleration limits when the commanded velocity is 0

Recent work on adding cancellation callbacks into Controllers is to do the exact opposite, so that stoppages don't simply halt without the acceleration profiles 😆 We can never please everyone hah.

I don't think there's any action needed on the collision monitor, no? I think its just the velocity smoother. I suppose that could be a parameterization (that is default off) which would make sense in some cases. bypass_profile_on_stop or something similar. I personally don't really recommend this, but I wouldn't stop you from implementing it and merging it :-)

[tonynajjar]

I personally don't really recommend this

hmm I'm interested in why you would not recommend this. My application is a robot navigating at relatively high speed and scanning the ground, we need to stop as soon as there is a detection otherwise we risk passing the object while decelerating. Do you have another design suggestion for achieving a full stop while still using the velocity smoother for decelerating between non-zero values?

[SteveMacenski]

I think of the velocity smoother’s dynamics being the limits on the behavior you’d like the robot to exhibit. Bypassing that breaks the dynamic feasibility for behavior. Perhaps having 2 pipelines (normal and soft e-stop or similar) makes sense for having a ‘this is the real hardware / safe limit’

imagine you had a load on the robot or the CG was high. An instantaneous stop at speed could result in the robot dumping a load or flipping over. I think there should still be a profile applied even in the soft e-stop situation, albeit perhaps more aggressive. I suppose bypassing the vel smoother could enable that, if your robot can instantaneously stop without physical repercussions, but I don’t think that’s widely generally true (but sometimes is, especially at low speeds & small robots).

However, if using a dynamically feasible trajectory planner, then those outputs are already in the set limits, so the vel smoother is arguably not needed, as long as you have reasonable confidence in your traj planner’s performance (which a couple hours of cmd_vel data should convince you of). If you’re using a non-feasible trajectory planner, then that’s a bit different.