Glossary

Fictionlab > Glossary > Hub motor (in-wheel motor)

Hub motor (in-wheel motor)

Hub motor – definition

A hub motor, also called an in-wheel motor, is an electric traction motor integrated into the wheel assembly of a vehicle or mobile robot. The motor generates torque directly at or near the wheel hub. This removes the need for external transmission components such as chains, belts, long drive shafts, or gearboxes mounted elsewhere on the chassis.

In wheeled UGVs, a hub-motor architecture usually assigns one motor to each driven wheel. Each motor can be controlled independently, allowing differential-drive or skid-steer motion. The approach can be relevant to compact four-wheel platforms such as Leo Rover and higher-payload platforms such as Raph Rover when their wheel-drive architecture uses independently actuated wheel modules. Distributed wheel actuation simplifies mechanical packaging and can support odometry from wheel encoders.

The term does not define a specific motor technology. A hub motor may use brushed DC, brushless DC (BLDC), permanent-magnet synchronous motor (PMSM), or a geared motor construction. In robotics documentation, the essential distinction is mechanical: the traction motor is part of the wheel module rather than mounted centrally in the vehicle frame.

Mechanical and electrical operation

A hub motor converts electrical power into wheel torque. The resulting longitudinal force at the tyre-ground contact patch drives the UGV. For a wheel with effective radius r, wheel (output) torque T, and wheel angular velocity ω, the ideal relationships are:

tractive force:     F = T / r
wheel speed:        v = r × ω
mechanical power:   P = T × ω = F × v

Real systems have losses in the motor winding, motor driver, bearings, gearbox, and tyre contact. Motor torque is also constrained by controller current limits, battery voltage, thermal conditions, and traction. A wheel can spin before the motor reaches its electrical torque limit when operating on loose soil, wet grass, gravel, or ramps.

For a four-wheel UGV using differential drive, wheels on the left and right sides are treated as two velocity groups. The kinematic model uses the linear velocity v, angular velocity ωz, and effective track width b:

v_left  = v - (ωz × b / 2)
v_right = v + (ωz × b / 2)

This model is applicable when left and right wheel speeds can be commanded independently. It remains an approximation for four-wheel skid-steer vehicles because tyre scrub and surface-dependent slip introduce odometry error.

Hub motors in ROS 2 mobile robots

ROS 2 does not define a dedicated hub-motor message type. A hub motor is normally exposed through a motor controller and a hardware interface. The software stack publishes wheel-state feedback and receives velocity commands at the vehicle level.

A common ROS 2 integration uses ros2_control and diff_drive_controller. The controller commonly accepts geometry messages of type geometry_msgs/msg/TwistStamped; some older controller versions use geometry_msgs/msg/Twist. It converts commanded body velocity into left and right wheel velocities. It can publish wheel-derived odometry and the transform between odom and base_link.

Wheel encoder data is normally exposed through hardware state interfaces, including position in radians and velocity in radians per second. A joint-state broadcaster can publish this data in the sensor_msgs/msg/JointState message, which defines arrays for joint name, position, velocity, and effort. ROS coordinate conventions should follow REP 103, which specifies SI units, radians for angular quantities, and the right-handed coordinate convention. Frame naming and the mobile-robot transform tree should follow REP 105.

diff_drive_controller:
  ros__parameters:
    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.32
    wheel_radius: 0.10
    publish_rate: 50.0
    enable_odom_tf: true

The values above are an example only. Wheel separation and radius must be measured on the actual platform. They must not be copied into a Leo Rover or Raph Rover configuration without verification against the installed wheels, tyres, encoder resolution, and drivetrain documentation.

Encoder feedback and odometry quality

Hub motors used in autonomous UGVs may provide repeatable feedback. Incremental encoders or absolute encoders may be integrated into the motor or installed on the motor shaft. Hall sensors can also provide rotational feedback, although their resolution may be limited for odometry applications. Encoder counts are converted to wheel angle and then integrated into odometry.

Odometry is useful for short-term motion estimation, but it is not an absolute position source. The following effects are important in field robotics:

  • Wheel slip during acceleration, braking, turning, or climbing.
  • Tyre deformation and changes in effective wheel radius.
  • Unequal wheel loading caused by payload placement.
  • Encoder quantisation and missed pulses.
  • Skid-steer scrub, especially on high-friction surfaces.

For navigation, wheel odometry is commonly fused with IMU data using an estimator such as robot_localization. LiDAR SLAM, visual odometry, or RTK GNSS can provide additional corrections when the operating environment and sensor installation support them.

Use on Leo Rover and Raph Rover

Leo Rover is a four-wheel mobile platform with an onboard Raspberry Pi and ROS 2 software support. Its wheel-drive system should be treated as a velocity-controlled mobile base, not as a complete autonomous-navigation solution. A navigation stack still requires sensor integration, frame calibration, localisation or SLAM, costmaps, and safety logic.

When integrating wheel-drive feedback on Leo Rover, the main engineering task is to ensure that the robot description, controller configuration, wheel geometry, and encoder interpretation are consistent. The URDF should define wheel joints and their axes correctly. Incorrect joint direction or wheel radius produces reversed motion, incorrect speed scaling, or curved trajectories during nominal straight-line commands.

Raph Rover is intended for larger payloads and can require different wheel-module sizing, motor current capability, thermal design, and structural load assessment. A hub-motor selection for Raph Rover must account for total mass, expected terrain, slope, wheel diameter, duty cycle, and the transient current capability of the battery and motor drivers.

Advantages and limitations

Distributed in-wheel actuation reduces mechanical transmission length and allows modular wheel replacement. Independent wheel control also supports differential steering and per-wheel diagnostic feedback.

The main trade-off is that the motor is close to terrain impacts, water, dust, vibration, and shock loads. The wheel module may also increase unsprung mass, although this term is more critical for suspended vehicles than for low-speed rigid UGV chassis. Environmental protection, cable strain relief, connector rating, thermal dissipation, and service access must be reviewed as part of the complete platform design.

Normative references and technical sources

The following sources define relevant ROS conventions and interfaces. They do not prescribe a single hub-motor design.

See also