gazebo_ros_diff_drive does not clamp cmd_vel to hardware velocity limits

[147258369ymc]

Description

The gazebo_ros_diff_drive plugin accepts arbitrary velocity commands via /cmd_vel
without clamping them to the robot's physical limits. For TurtleBot3 Burger, the
hardware maximum is 0.22 m/s (linear) and 2.84 rad/s (angular), but the plugin
will attempt to drive the simulated robot at any commanded velocity.

This causes the simulation to diverge significantly from physical robot behavior,
where OpenCR firmware constrains velocities to hardware limits.

Steps to Reproduce

ros2 launch turtlebot3_gazebo empty_world.launch.py
ros2 topic pub --once /cmd_vel geometry_msgs/msg/Twist "{linear: {x: 5.0}}"

Expected Behavior

The plugin should clamp the velocity to the configured maximum before applying
forces to the model, matching the physical robot's behavior.

Actual Behavior

The simulated robot accelerates toward 5.0 m/s, reaching ~1.0 m/s (4.5x the
hardware limit). Observed via ros2 topic echo /odom.

Impact

• Algorithms developed in simulation may fail on physical hardware
• Safety-critical velocity assumptions are violated
• Downstream nodes receive physically impossible state feedback

[sungjinjung2806]

This seems like a valid concern regarding sim-to-real consistency, since the simulation can accept velocity commands beyond TurtleBot3 hardware limits.
However, since gazebo_ros_diff_drive is a generic plugin used across different robot platforms, robot-specific velocity limits may be better handled at the controller or simulation configuration level rather than directly in the plugin itself.
That said, adding proper velocity constraints in the TurtleBot3 simulation stack could help make the simulation behavior more realistic and consistent with physical hardware.

[kmhswimgirl]

I'm pretty sure that any messages published on /cmd_vel that are above max speed on the physical Turtlebot just get ignored (dropped) and not clamped to the max speed.