[velocity smoother] Deceleration limit not applied when command timeout

[BriceRenaudeau]

Bug report

Required Info:

• Operating System:
  • Ubuntu 22.04
• ROS2 Version:
  • Humble
• Version or commit hash:
  • last release
• DDS implementation:
  • cycloneDDS

Steps to reproduce issue

Expected behavior

When the command timeout, the smoother sends a deceleration slope using the deceleration limit.

Actual behavior

When the command timeout, the smoother sends a 0 velocity command.

Additional information

Tested on real robot using this config:

{"smoothing_frequency": 20.0},
{"scale_velocities": False},
{"feedback": "OPEN_LOOP"},
{"max_velocity": [0.5, 0.0, 0.8]},
{"min_velocity": [-0.5, 0.0, -0.8]},
{"velocity_timeout": 0.5},
{"max_accel": [1.0, 0.0, 1.2]},
{"max_decel": [-1.0, 0.0, -1.2]}

[SteveMacenski]

I believe what you are referring to is happening here: https://github.com/ros-planning/navigation2/blob/main/nav2_velocity_smoother/src/velocity_smoother.cpp#L223

If we stop receiving commands, we go into a panic to say "stop!". I think that's reasonable behavior since that's a critical failure and I'd want to forcefully stop at the full power of my system rather than what might be the most comfortable. But, I'm assuming there that your robot's dynamics characteristics are either safe or low-level controller set to safe for the application so you don't dump an unsecured load.

If that's not the case, then yes, it could make sense to bake the ramp down here, potentially with its own acceleration profile for "timeout stopping" (or just use the deceleration profile).

Is that something you'd be willing to contribute? Admittedly this is not something I can prioritize building for the next several weeks to months, so if you wanted it, contributing it would be the fastest solution!

[BriceRenaudeau]

I think I see how to do it cleanly.
I will take some time to do a PR.

[SteveMacenski]

#3512 Imminently to be merged.