Holonomic / non-holonomic

Holonomic / non-holonomic – definition

In mobile robotics, the terms holonomic and non-holonomic describe motion constraints of a robot base. The distinction is kinematic. It does not primarily describe sensors, autonomy level, or control quality. It describes which instantaneous motions are physically feasible for the platform.

A holonomic mobile robot can command all degrees of freedom of its planar pose directly and independently at the velocity level. For a ground robot moving on a flat surface, the pose is usually expressed as (x, y, yaw). A holonomic base can generate velocity in x, velocity in y, and angular velocity around z without violating its wheel constraints. Typical examples are omnidirectional platforms with omni wheels; mecanum platforms are commonly treated as holonomic in practice, although this assumes adequate traction and limited slip.

A non-holonomic mobile robot has motion constraints that cannot be integrated away into simple position constraints. In practice, this means that some instantaneous directions of motion are not possible. A standard differential-drive rover cannot move sideways. It can move forward or backward and rotate, but lateral velocity in the robot frame must remain zero. This is the common case for UGVs used in research, field robotics, and education.

For ROS and UGV integration, this distinction affects the full stack: kinematic models, controller choice, motion planning, local trajectory generation, odometry interpretation, and simulation settings. Leo Rover is a non-holonomic differential-drive platform. Raph Rover, in its typical rover-style configuration, is also treated as non-holonomic unless a different drivetrain is explicitly designed and integrated.

Kinematic meaning in planar UGV motion

The standard state of a mobile base on a plane is represented in SE(2): position x, position y, and heading θ. The commanded body-frame twist is usually written as v_x, v_y, and ω_z. In ROS 2, this is commonly transported with geometry_msgs/msg/Twist.

For a non-holonomic differential-drive robot, the kinematic constraint is:

v_y = 0

This does not mean the robot can never change its global y position. It can, by rotating and then moving forward. The constraint applies to the instantaneous lateral velocity in the robot frame. That is the key point.

A common continuous-time differential-drive model is:

x_dot = v * cos(theta)
y_dot = v * sin(theta)
theta_dot = omega

Here, v is longitudinal velocity and ω is yaw rate. There is no direct lateral term in the body frame. This is why path planners and controllers for differential-drive robots must generate curvature-feasible trajectories rather than arbitrary sideways motion.

How the concept appears in ROS 2

ROS 2 does not classify a robot as holonomic or non-holonomic with a single global flag in the core middleware. The distinction appears in robot description, controller configuration, odometry, and navigation stack parameters. The most relevant components are ros2_control, diff_drive_controller, URDF, TF, and Nav2.

For Leo Rover and similar UGVs, the motion interface normally exposes /cmd_vel with a planar twist. Even though Twist has a linear.y field, a differential-drive base should ignore or reject non-zero lateral commands.

ros2 topic pub /cmd_vel geometry_msgs/msg/Twist \
"{linear: {x: 0.3, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.5}}"

In a non-holonomic platform, this command is valid. A command with linear.y != 0 is not physically feasible unless the drivetrain supports omnidirectional motion.

For ROS 2 control, a differential-drive controller is the standard choice. It estimates odometry from wheel motion and applies wheel velocity commands according to the differential-drive model.

diff_drive_controller:
  ros__parameters:
    publish_rate: 50.0
    base_frame_id: base_link
    left_wheel_names: ["left_front_wheel_joint", "left_rear_wheel_joint"]
    right_wheel_names: ["right_front_wheel_joint", "right_rear_wheel_joint"]
    wheel_separation: 0.36
    wheel_radius: 0.0925
    use_stamped_vel: false

In this controller class, the controller assumes non-holonomic behavior. Parameters such as wheel_separation and wheel_radius directly affect odometry quality and closed-loop motion tracking.

Practical implications for Leo Rover and Raph Rover

The holonomic versus non-holonomic distinction has direct consequences for how these platforms should be modeled and deployed. Leo Rover uses a four-wheel differential-drive layout. Even with four wheels, its planar motion is still non-holonomic because the left and right wheel groups constrain lateral slip-free motion.

For Leo Rover, this means:

the correct low-level controller is differential drive, not omnidirectional drive
local planning in Nav2 should assume no lateral body motion
odometry from wheel encoders should be interpreted with non-holonomic constraints
trajectory feasibility depends on wheel slip, terrain, and whether in-place turning is supported by the surface and drivetrain

Raph Rover is a larger UGV intended for higher payload and more demanding field integration. In typical rover configurations, it is also treated as non-holonomic. The larger footprint and payload may increase inertia and wheel-ground interaction effects, but the kinematic class remains the same unless the drivetrain changes fundamentally.

In field robotics, non-holonomic assumptions are often only approximately true. Loose soil, gravel, mud, and grass introduce slip. The platform is still modeled as non-holonomic for control and planning, but state estimation may need IMU and GNSS fusion to compensate for encoder drift.

Effects on planning, control, and simulation

Navigation and simulation pipelines depend strongly on this concept. A holonomic local planner can produce lateral strafing commands. A non-holonomic planner must generate arcs, in-place rotations, or smooth curvature-limited trajectories.

In Nav2, planners and controllers should be selected and tuned according to drivetrain constraints. For a differential-drive UGV, important practical points include:

min_y_velocity_threshold should remain consistent with zero lateral capability
controller and critic settings should discourage infeasible side motion
footprint and inflation settings must account for turning in narrow spaces
reverse motion support depends on platform safety and localization quality

In URDF and simulation, the drivetrain should also reflect the real kinematics. If a non-holonomic rover is simulated as omnidirectional, controller tests will be misleading. This affects Gazebo simulation, wheel joint definitions, friction coefficients, and wheel slip modeling.

Key parameters and metrics

The classification itself is qualitative, but deployment depends on measurable parameters. For ROS 2 UGV work, the following parameters matter most.

Parameter	Meaning	Why it matters
`linear.x`	Forward velocity command in m/s	Main translational DOF for non-holonomic rovers
`linear.y`	Lateral velocity command in m/s	Should be zero for differential drive
`angular.z`	Yaw rate in rad/s	Determines turning behavior and path curvature
Wheel separation	Distance between left and right wheel contact lines	Used by differential-drive odometry and control
Wheel radius	Effective rolling radius	Converts joint speed to ground speed
Odometry rate	Typical controller publish rate, often tens of Hz	Affects estimator and controller responsiveness

For mobile robots using ROS 2, odometry is typically published as nav_msgs/msg/Odometry, TF between odom and base_link follows common ROS conventions, and higher-level planners consume this estimate together with sensor data.

Standards, conventions, and references

The terms are standard in robotics and control theory, but their practical use in ROS follows interface conventions rather than a single REP dedicated only to holonomy. In ROS systems, the most relevant references are message definitions, TF frame conventions, and controller documentation.

geometry_msgs/msg/Twist – standard ROS 2 velocity command message carrying linear and angular components
nav_msgs/msg/Odometry – standard ROS 2 message for estimated pose and twist
REP 103 – standard units of measure and coordinate conventions in ROS
REP 105 – coordinate frames for mobile platforms, especially map, odom, and base_link
ros2_controllers documentation – differential drive controller behavior and parameters

These references define how kinematic assumptions are expressed in software, even when the mathematical distinction comes from classical robotics literature and control theory rather than from ROS alone.

Limitations and common mistakes

A frequent mistake is to treat any four-wheel rover as holonomic. Wheel count does not determine holonomy. The determining factor is whether the platform can realize independent planar DOFs without violating wheel constraints.

Another mistake is to confuse non-holonomic with underactuated in a general sense. Many mobile bases are controllable over time, yet still non-holonomic because of instantaneous velocity constraints. For Leo Rover or Raph Rover, this means the robot can reach a broad set of planar poses, but not by arbitrary instantaneous sideways motion.

Holonomic / non-holonomic