Glossary

Fictionlab > Glossary > Mecanum wheel

Mecanum wheel

Mecanum wheel – definition

A Mecanum wheel is a driven wheel with passive rollers mounted around its circumference at an angle, commonly 45 degrees to the wheel plane. The angled rollers generate a traction component both parallel and perpendicular to the wheel’s rolling direction. A mobile robot with four independently driven Mecanum wheels can therefore translate forward, backward, sideways, diagonally, and rotate about its vertical axis without changing its chassis heading.

In mobile robotics, a Mecanum wheel is part of an omnidirectional drive system. It is not a steering wheel and does not provide controlled lateral propulsion by itself. Omnidirectional motion is produced only when wheel speeds are coordinated according to the platform geometry and roller orientation. The original Mecanum wheel concept was patented by Bengt Ilon in 1975. The design is also referred to as a Swedish wheel in robotics literature.

For ROS and ROS 2 systems, Mecanum drive is represented as a holonomic base. The robot can command linear velocity on the x and y axes plus angular velocity around the z axis. This differs from a differential-drive UGV, which normally accepts forward velocity and yaw rate but cannot generate a commanded lateral velocity.

Mechanical principle and wheel arrangement

A standard Mecanum base uses four wheels: front-left, front-right, rear-left, and rear-right. The roller handedness must alternate between sides. Viewed from above, the roller axes usually form an X-shaped pattern across the chassis. Incorrect roller orientation prevents the expected lateral and diagonal motion.

Each wheel contributes a force vector. During forward motion, lateral force components cancel. During sideways motion, longitudinal force components cancel while lateral components add. During rotation, wheel directions are selected to produce a torque around the robot centre.

Motion command Wheel speed relationship Expected chassis motion
Positive vx All wheels contribute forward traction Forward translation
Positive vy Diagonal wheel pairs rotate in opposite directions Left translation
Positive wz Left and right wheel sides rotate in opposite directions Counterclockwise rotation about the z axis

The exact motor direction depends on wheel mounting, gearbox orientation, encoder polarity, and the controller’s wheel-order convention. It must be validated on the physical platform before autonomous operation.

Mecanum kinematics for ROS 2 mobile bases

ROS coordinate conventions should follow REP 103. In a body-fixed base_link frame, x points forward, y points left, and z points upward. A commanded planar velocity is commonly expressed as:

v = [vx, vy, wz]T

For a four-wheel Mecanum platform with wheel radius r, half wheelbase Lx, and half track width Ly, one commonly used inverse kinematics convention is:

[w_fl]   1/r [ 1  -1  -(Lx + Ly)] [vx]
[w_fr] = 1/r [ 1   1   (Lx + Ly)] [vy]
[w_rl]   1/r [ 1   1  -(Lx + Ly)] [wz]
[w_rr]   1/r [ 1  -1   (Lx + Ly)]

Here, w_fl, w_fr, w_rl, and w_rr are wheel angular velocities in rad/s. This equation assumes a specific roller arrangement and positive wheel rotation convention. Other implementations may invert rows or swap wheel indices. The configured model must match the actual drivetrain.

In ROS 2, a Mecanum controller converts a body velocity command into individual wheel commands and estimates odometry from wheel feedback. The ROS 2 mecanum_drive_controller in ros2_control is intended for this type of drivetrain. It uses wheel geometry, wheel interface names, and a frame configuration supplied through controller parameters. The controller documentation for the installed ROS 2 distribution should be treated as authoritative because parameter names and interfaces can change between releases.

mecanum_drive_controller:
  ros__parameters:
    front_left_wheel_command_joint_name: front_left_wheel_joint
    front_right_wheel_command_joint_name: front_right_wheel_joint
    rear_left_wheel_command_joint_name: rear_left_wheel_joint
    rear_right_wheel_command_joint_name: rear_right_wheel_joint
    wheel_radius: 0.075
    wheel_separation_x: 0.420
    wheel_separation_y: 0.360
    base_frame_id: base_link
    odom_frame_id: odom
    enable_odom_tf: true

The values above are an integration example, not a specification for Leo Rover or Raph Rover. Wheel radius must be measured at the effective rolling surface. Wheel separation values must correspond to wheel contact-point geometry.

ROS 2 messages, odometry, and navigation

A holonomic navigation stack requires a velocity interface that preserves lateral velocity. In ROS 2, body velocity is conventionally represented by geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped. The relevant fields are linear.x, linear.y, and angular.z. Wheel odometry is normally published as nav_msgs/msg/Odometry, with the transform chain odom -> base_link.

For Nav2, the local controller and velocity smoother must permit non-zero vy if sideways motion is required. A configuration intended for differential-drive robots may set lateral velocity limits to zero and will not use the Mecanum drivetrain’s holonomic capability.

  • base_link should comply with REP 103 axis orientation.
  • Wheel encoder feedback supports short-term odometry only.
  • An IMU improves yaw-rate estimation and motion-state filtering.
  • LiDAR, depth cameras, or visual sensors can support localization and obstacle detection.
  • SLAM or localization should fuse wheel odometry with exteroceptive observations where required.

Practical limitations on UGV platforms

Mecanum wheels are effective on smooth, level, high-friction indoor surfaces. Their rollers introduce more compliance and discontinuous ground contact than conventional pneumatic or solid UGV wheels. As a result, lateral odometry error can increase on uneven floors, loose soil, gravel, grass, thresholds, and surfaces with changing friction.

Wheel slip is a significant limitation. Encoder-derived odometry does not directly measure chassis motion when rollers skid, lose contact, or encounter obstacles. Payload distribution also matters because the four wheels require consistent normal force for predictable traction. These constraints are relevant to research platforms carrying LiDAR, cameras, edge computers, batteries, or sensor masts.

Leo Rover and Raph Rover context

Leo Rover is a four-wheel differential-drive platform. Its standard drivetrain is not a Mecanum drivetrain, and its native motion model does not support commanded lateral translation. Installing a ROS 2 Mecanum controller on Leo Rover without mechanical conversion would produce incorrect wheel commands and odometry.

A Mecanum experiment based on Leo Rover therefore requires a custom chassis or drivetrain modification, four compatible Mecanum wheels, independently controllable wheel motors, encoder feedback, and an updated URDF and ros2_control hardware configuration. The platform’s Raspberry Pi compute unit can run ROS 2 Humble or newer, but controller selection must reflect the real mechanical architecture.

Raph Rover may be used as a base for a custom omnidirectional platform only if its drivetrain is specifically designed or modified for independently driven Mecanum wheels. Its larger payload capability does not, by itself, make it holonomic. For outdoor inspection, agriculture, construction, or uneven terrain, conventional wheels or tracks are generally more appropriate because Mecanum rollers are sensitive to terrain irregularity.

Normative references and technical sources

The following sources define the coordinate and software conventions relevant to Mecanum drive integration.

See also