Feat/rate limited teleop doc

[tothelast]

Fixes #5848

Add an Advanced tutorial: Smoothing keyboard teleop with a rate-limiter.

Included

• New page: source/Tutorials/Advanced/rate_limited_teleop.rst
• Toctree entry added in source/Tutorials/Advanced.rst

Rationale
Keyboard teleop can produce abrupt 0→max command steps. A small Twist acceleration limiter improves smoothness and safety, especially in indoor labs and teaching settings.

Checks

• DCO Signed-off-by present on all commits
• Page referenced in Advanced toctree (Sphinx will render it)

Update: Addressed review feedback - added a “See also” section referencing control_toolbox::RateLimiter and the control_filters::RateLimiter plugin for ros2_control (with links).

[tothelast]

Thanks for taking a look.
Summary: Adds an Advanced tutorial on smoothing keyboard teleop with a simple Twist acceleration limiter.
Placement: Linked in Tutorials/Advanced.rst.
Notes: Commits include DCO Signed-off-by.
I’m happy to adjust naming/placement, parameter defaults, or add a C++ snippet if preferred. Please let me know what edits would make this easiest to merge.

[Amronos]

Perhaps mention the RateLImiter from ros2_control?

[tothelast]

Perhaps mention the RateLImiter from ros2_control?

Thanks for the pointer. I added a “See also” section referencing control_toolbox::RateLimiter and the control_filters::RateLimiter plugin for ros2_control (with links).
The tutorial still shows a standalone node for setups without ros2_control.

[fujitatomoya]

@tothelast thanks for creating issue and PR.

although i think this is useful, i believe this feature can be implemented in teleop package as optional argument with documentation in that package? if this is the major problem when we use the teleop, that is gonna be much helpful for user instead of implementing this example into their workspace. IMO, once it is completed, we probably refer to the optional argument in the tutorial here.

what do you think about this?

besides that, i think Rate Control Subscription can be the feature for any Subscription endpoints to avoid the situation that more messages are coming in than it can handle. but this is another discussion.

[tothelast]

@tothelast thanks for creating issue and PR.

although i think this is useful, i believe this feature can be implemented in teleop package as optional argument with documentation in that package? if this is the major problem when we use the teleop, that is gonna be much helpful for user instead of implementing this example into their workspace. IMO, once it is completed, we probably refer to the optional argument in the tutorial here.

what do you think about this?

besides that, i think Rate Control Subscription can be the feature for any Subscription endpoints to avoid the situation that more messages are coming in than it can handle. but this is another discussion.

Agreed, adding an optional rate-limit flag in teleop_twist_keyboard makes this much easier for users. I can open an Issue + PR there to add a --rate-limit option (with linear/Angular accel params and default-off) and then update this tutorial to point to that flag as the primary path, keeping the standalone node as a fallback. If that approach sounds good, I can proceed and link the PR here. What do you think? @fujitatomoya