Glossary

Fictionlab > Glossary > Omni wheel

Omni wheel

Omni wheel – definition

An omni wheel is a wheel with multiple passive rollers arranged around its circumference. The rollers rotate freely about axes that are typically perpendicular to the main wheel rotation axis. This geometry allows the wheel to transmit traction in one direction while permitting low-resistance motion in the lateral direction.

In mobile robotics, omni wheels are used to build holonomic or omnidirectional ground vehicles. A holonomic mobile base can generate planar velocity along its longitudinal and lateral axes while independently controlling yaw rotation. This differs from a differential-drive UGV, which normally produces forward or reverse motion and rotation, but cannot move laterally without changing its heading.

An omni wheel is not a complete drivetrain concept. Its practical behavior depends on the wheel arrangement, roller geometry, wheel radius, contact conditions, motor control, encoder feedback, and the inverse kinematics implemented by the robot controller. Common configurations include three-wheel Kiwi drives, four-wheel omni drives, and four-wheel Mecanum drives. Mecanum wheels use angled rollers and are related to, but mechanically distinct from, conventional omni wheels.

Omni wheels in UGV kinematics

For a mobile base, each driven omni wheel contributes a velocity constraint determined by its mounting position and roller direction. The controller converts a desired body twist into individual wheel angular velocities. In ROS terminology, planar commanded velocity is commonly expressed with geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped. By convention, and depending on controller configuration, linear.x, linear.y, and angular.z are commonly interpreted as requested motion in the robot base frame.

For an ideal holonomic platform, the body velocity vector is:

v = [vx, vy, ωz]T

where vx is forward velocity, vy is lateral velocity, and ωz is angular velocity around the vertical axis. Wheel angular velocities are calculated using a kinematic matrix:

ωw = J · v

In this expression, ωw is the vector of wheel angular velocities and J is a Jacobian defined by wheel positions, wheel radius, roller orientation, and chassis geometry. The matrix must match the actual mechanical configuration. Applying Mecanum-wheel equations to a conventional omni-wheel platform produces incorrect wheel commands.

ROS 2 integration

ROS 2 does not define one mandatory controller specifically for every omni-wheel geometry. A hardware interface normally exposes wheel states and accepts wheel velocity commands through ros2_control. The controller layer then converts chassis commands into motor-level commands.

For an omnidirectional base, the robot description should define the base frame according to REP 103 and REP 105. REP 103 specifies the ROS body-frame convention: x forward, y left, and z up. REP 105 describes coordinate frames including map, odom, and base_link. A holonomic controller must preserve these conventions, especially for the sign of linear.y.

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

On a correctly configured omni-drive base, this command requests leftward translation without intentional yaw rotation. On a differential-drive platform, lateral velocity is physically infeasible and should be rejected, ignored, or constrained by the base controller.

Odometry is usually published as nav_msgs/msg/Odometry, with the transform between odom and base_link broadcast through TF2. Wheel encoder odometry alone can be inaccurate on omni-wheel platforms because roller contact introduces additional slip modes. An IMU, visual odometry, LiDAR scan matching, or an extended Kalman filter can improve the estimate.

Key mechanical parameters

Wheel selection and drivetrain design require parameters from the wheel manufacturer rather than assumptions based only on diameter. The following properties affect payload capacity, controllability, and odometry quality.

  • Wheel diameter and effective rolling radius – determine the relation between motor speed and linear velocity.
  • Number of rollers – affects contact continuity and vibration when rollers transition at the ground contact point.
  • Roller material – influences friction, wear, noise, and performance on smooth or irregular surfaces.
  • Rated load per wheel – must include static payload, dynamic acceleration loads, and uneven load distribution.
  • Roller bearing construction – affects rolling resistance, backlash, and service life.
  • Floor flatness and surface friction – strongly affect lateral motion and wheel-slip behavior.

Omni wheels are generally best suited to flat, hard, and relatively clean indoor surfaces. Gaps, loose soil, gravel, wet grass, deep carpet, and uneven terrain increase vibration and roller slip. These effects reduce repeatability and can degrade localization based on wheel encoders.

Omni wheels compared with Leo Rover and Raph Rover

Leo Rover uses a four-wheel differential-drive architecture. Its standard drivetrain is designed for longitudinal motion and skid-steer turning, not lateral translation. Leo Rover can be used with ROS 2 on its integrated Raspberry Pi compute unit; supported ROS 2 distributions depend on the installed software image and current vendor support. Its standard kinematics should therefore be represented as differential drive, not omni drive.

Replacing Leo Rover wheels with omni wheels would be a custom mechanical and control-system modification. It would require validation of wheel mounting, motor torque, wheel clearance, encoder calibration, traction behavior, controller logic, URDF collision geometry, and odometry parameters. It would also change the rover’s terrain behavior and may reduce practical performance on uneven surfaces. The IP55 rating of the standard platform does not automatically apply after mechanical modifications.

Raph Rover is a larger platform intended for higher-payload mobile robotics work. Its standard use case also does not imply an omnidirectional drivetrain. A custom Raph Rover integration could use omni wheels only where a flat operating surface, a verified load distribution, and holonomic positioning are explicit requirements. For outdoor inspection, agricultural work, construction sites, or rough terrain, conventional pneumatic or terrain-oriented wheels are usually more appropriate than omni wheels.

Limitations and navigation implications

Holonomic motion can simplify docking, laboratory positioning, and movement in constrained indoor layouts. It does not eliminate the need for perception, collision checking, localization, or path planning. A navigation stack must be configured for the actual base kinematics and footprint.

In Nav2, lateral motion is meaningful only when the selected controller and robot base support it. A differential-drive configuration should constrain lateral velocity to zero. An omnidirectional configuration may allow non-zero vy, but acceleration limits, wheel slip, obstacle inflation, and controller sampling must still be tuned experimentally.

For UGVs operating outside controlled indoor environments, the main trade-off is between planar maneuverability and terrain capability. Omni wheels provide mobility on suitable surfaces, while conventional wheel designs generally provide better obstacle crossing, traction, and robustness on variable ground.

Normative references and standards

The ROS coordinate conventions used when integrating an omni-drive base are defined in ROS Enhancement Proposals. Hardware-specific dimensions, load limits, and torque values must be taken from the applicable wheel, motor, encoder, and motor-driver specifications.

See also