Add acc limit consideration to avoid overshooting in RotationShimController

[RBT22]

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	NA
Primary OS tested on	Ubuntu
Robotic platform tested on	own robot hardware
Does this PR contain AI generated software?	No

---

Description of contribution in a few bullet points

Currently we don't do the deceleration as a function of its target orientation with RotationShimController. This PR implements this behavior using the max_angular_accel param.

Description of documentation updates required from your changes

The parameter description has to be updated.

---

Future work that may be required in bullet points

For Maintainers:

• Check that any new parameters added are updated in docs.nav2.org
• Check that any significant change is added to the migration guide
• Check that any new features OR changes to existing behaviors are reflected in the tuning guide
• Check that any new functions have Doxygen added
• Check that any new features have test coverage
• Check that any new plugins is added to the plugins page
• If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists

[RBT22]

@SteveMacenski Let me know if you would introduce a separate deceleration limit parameter or if a min_angular_speed param is needed here.

[codecov]

Codecov Report

Attention: Patch coverage is 66.66667% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...m_controller/src/nav2_rotation_shim_controller.cpp	66.66%	1 Missing ⚠️

Files with missing lines	Coverage Δ
...m_controller/src/nav2_rotation_shim_controller.cpp	94.73% <66.66%> (-0.51%)	⬇️

... and 2 files with indirect coverage changes

[SteveMacenski]

i'm curious - did you test this with a small value for angular_disengage_threshold?

If this worked as expected, I would expect the behavior to be a:

• Rotate accelerating to full rotational speed
• Rotating decelerating to the angle of the path, once in deceleration area
• Stop relatively close to the angle, with a small disengagement threshold (20 deg or less?)
• Then controller starts moving

If so, that would make a really nice behavior - very precise, very 'robotic'. A gif to put in the migration guide for this would be splendid to show it at work and the value of it. My hope was that this would be used to create very dynamic hand offs with the controllers, but I think experience has told me now from feedback that this isn't what people want (and most of the controllers don't take kindly to being started in a high-acceleration-turn when starting path tracking)

Let me know if you would introduce a separate deceleration limit parameter or if a min_angular_speed param is needed here.

Nah, I think this can be symmetric. If someone has a problem with that, they can have a follow up PR. A bunch of controllers for rotating to heading do this, so this is consistent behavior

[RBT22]

Yes, we tested it with a small angular_disengage_threshold and with accelerations. The behavior aligns closely with what you described: accelerating to full rotational speed, decelerating near the path angle, and stopping close to the target with a small disengagement threshold.

One thing to note however is that we moved the shim to open-loop to integrate it seamlessly with our setup. This approach worked well for our case, but I'm curious if this is something you'd consider supporting optionally.