turtlebot3_fake_node — No cmd_vel Input Validation

[147258369ymc]

Description

In turtlebot3_fake_node/src/turtlebot3_fake_node.cpp, the command_velocity_callback() function directly assigns received cmd_vel values to internal state without any validation or clamping:

void Turtlebot3Fake::command_velocity_callback(
  const geometry_msgs::msg::Twist::SharedPtr cmd_vel_msg)
{
  last_cmd_vel_time_ = this->now();
  goal_linear_velocity_ = cmd_vel_msg->linear.x;      // no validation
  goal_angular_velocity_ = cmd_vel_msg->angular.z;     // no validation

  wheel_speed_cmd_[LEFT] = goal_linear_velocity_ - 
    (goal_angular_velocity_ * wheel_seperation_ / 2);
  wheel_speed_cmd_[RIGHT] = goal_linear_velocity_ + 
    (goal_angular_velocity_ * wheel_seperation_ / 2);
}

The TurtleBot3 Burger hardware has strict velocity limits:

• Max linear velocity: 0.22 m/s (XL430-W250 motor constraint)
• Max angular velocity: 2.84 rad/s

The physical robot's OpenCR firmware enforces these limits, but turtlebot3_fake_node does not.

Steps to Reproduce

# Terminal 1: Launch fake node
ros2 launch turtlebot3_fake_node turtlebot3_fake_node.launch.py

# Terminal 2: Send physically impossible velocity
ros2 topic pub --once /cmd_vel geometry_msgs/msg/Twist "{linear: {x: 100.0}}"

# Terminal 3: Observe — robot reports moving at 100 m/s
ros2 topic echo /odom --field twist.twist.linear.x

Expected Behavior

The node should clamp incoming velocity commands to hardware limits before computing wheel speeds, matching the physical robot's behavior:

constexpr double MAX_LINEAR_VEL = 0.22;   // m/s (Burger)
constexpr double MAX_ANGULAR_VEL = 2.84;  // rad/s (Burger)

goal_linear_velocity_ = std::clamp(
    cmd_vel_msg->linear.x, -MAX_LINEAR_VEL, MAX_LINEAR_VEL);
goal_angular_velocity_ = std::clamp(
    cmd_vel_msg->angular.z, -MAX_ANGULAR_VEL, MAX_ANGULAR_VEL);

Impact

• Sim-to-real gap: Algorithms developed using fake_node may rely on velocities exceeding hardware limits. These algorithms will fail silently when deployed on physical hardware.
• CI/CD false positives: Automated tests using fake_node may pass with physically impossible trajectories.
• Inconsistency: The teleop_keyboard node enforces BURGER_MAX_LIN_VEL = 0.22 and BURGER_MAX_ANG_VEL = 2.84, but the underlying node does not — creating inconsistent behavior depending on the input source.

Environment

• TurtleBot3 model: Burger
• ROS 2: Foxy Fitzroy
• Package: turtlebot3_fake_node (foxy-devel branch)

[sungjinjung2806]

This is an interesting point.

However, I wonder whether this behavior is intentional rather than a bug.

turtlebot3_fake_node appears to be designed as a lightweight fake simulation node, not necessarily a hardware-accurate simulator. In the official TurtleBot3 fake node demo, the robot also seems to move significantly faster than real TurtleBot3 hardware limits would allow: https://youtu.be/iHXZSLBJHMg?si=Av9WeJjjjpOIFHn2

If the goal of fake_node is fast testing and simple odometry emulation, unrestricted velocity commands may be acceptable. However, if the intention is to better match real hardware behavior, adding command clamping would improve sim-to-real consistency.