Rocker-bogie
Rocker-bogie – definition
Rocker-bogie is a passive suspension architecture used on wheeled mobile robots that must maintain wheel-ground contact on uneven terrain without using active suspension actuators. The mechanism typically consists of two main side assemblies. Each side has a rocker link and a bogie link connected through a pivot. The left and right rockers are usually coupled by a differential or an equivalent passive linkage so that body pitch is reduced when one side climbs an obstacle. In mobile robotics, the term refers both to the mechanical layout and to the resulting mobility behavior.
In UGV practice, rocker-bogie is associated with low-speed traversal of rough terrain, step climbing, and stable contact geometry. It is not a drive type by itself. It is a suspension and chassis kinematics concept. Traction still depends on the wheel drives, motor torque, tire material, ground pressure, and control stack. The architecture became widely known through planetary rovers, but in research robotics it is also used on terrestrial platforms where terrain variability is more important than speed.
For Fictionlab platforms, rocker-bogie should be understood as an alternative suspension topology relative to a standard differential-drive 4-wheel chassis. Leo Rover is a 4-wheel differential-drive platform, not a rocker-bogie rover. Raph Rover is a larger UGV platform oriented toward higher payload and field integration, but the term rocker-bogie should still be used only if a given chassis variant actually implements this mechanical linkage. The concept is relevant in projects where Leo Rover or Raph Rover are used as reference platforms for navigation, perception, and ROS 2 integration, and where a custom UGV may require better passive terrain compliance than a rigid or simple sprung chassis.
Mechanical principle and kinematics
The core objective of rocker-bogie is to distribute contact forces across multiple wheels while limiting chassis attitude change. The mechanism is passive. It does not require controlled suspension joints. This reduces control complexity, but introduces specific geometric constraints.
A typical rocker-bogie side has three wheels. The front wheel is mounted on the rocker. The middle and rear wheels are mounted on the bogie. When the front wheel meets an obstacle, the rocker rotates upward. The bogie then follows and shifts load between the middle and rear wheels. A differential coupling between left and right rockers helps keep the main body more level.
From a mobility standpoint, the main effects are:
- improved wheel contact on discontinuous terrain,
- reduced peak body pitch compared with a rigid chassis,
- better obstacle negotiation at low speed,
- higher mechanical complexity than a fixed 4-wheel chassis.
Unlike a simple differential-drive rover, a rocker-bogie platform is usually modeled as a multi-body mechanism. For simulation and state estimation, body pose is often decoupled from suspension joint states. In ROS and URDF, this means the platform description includes multiple links and joints even if the suspension is passive.
Rocker-bogie in ROS 2 and simulation
ROS 2 does not define rocker-bogie as a special robot class. Integration is done through standard robot description, transforms, controllers, and odometry interfaces. The same conventions used for other UGVs apply. Coordinate frames should follow REP 103 for units and axis orientation, and frame naming should follow REP 105 for mobile platforms.
In practice, a rocker-bogie robot in ROS 2 usually includes:
robot_descriptionin URDF or Xacro,tf2tree withbase_link, wheel links, and sensor frames,- wheel joint state publishing,
- odometry from wheel encoders, IMU, or fused estimators,
- Gazebo simulation with passive or constrained joints.
A simplified URDF fragment may look like this:
<joint name="left_rocker_joint" type="revolute">
<parent link="chassis_link"/>
<child link="left_rocker_link"/>
<origin xyz="0.0 0.18 0.0" rpy="0 0 0"/>
<axis xyz="0 1 0"/>
<limit lower="-0.6" upper="0.6" effort="50" velocity="1.0"/>
</joint>
<joint name="left_bogie_joint" type="revolute">
<parent link="left_rocker_link"/>
<child link="left_bogie_link"/>
<origin xyz="-0.22 0.0 0.0" rpy="0 0 0"/>
<axis xyz="0 1 0"/>
</joint>
For navigation, the suspension itself is usually not directly controlled. The ROS 2 stack consumes velocity commands and publishes state. If the platform uses skid steering or differential steering across multiple driven wheels, the controller layer must match the actual drivetrain. A rocker-bogie chassis can still use differential steering, but wheel slip on rough ground can degrade encoder-only odometry.
Key parameters and metrics
Rocker-bogie performance is governed by geometry and terrain interaction more than by software alone. The most important metrics should be measured on the real chassis and documented in the robot specification.
Common parameters include:
| Parameter | Why it matters | Typical unit |
|---|---|---|
| Wheel diameter | Affects obstacle climbing and ground clearance | mm |
| Wheelbase within bogie | Changes load transfer and breakover behavior | mm |
| Track width | Affects lateral stability | mm |
| Ground clearance | Limits underbody contact | mm |
| Static stability margin | Indicates rollover resistance | % or mm |
| Maximum negotiable obstacle | Summarizes terrain capability | mm |
| Suspension joint range | Defines passive articulation envelope | deg or rad |
A common first-order rule is that obstacle climbing capability scales with wheel radius and link geometry, not only motor torque. Real performance also depends on friction coefficient, center of mass location, and whether all wheels are driven.
Practical context for Leo Rover and Raph Rover
Leo Rover is a compact 4-wheel differential-drive robot with ROS 2 support on Raspberry Pi-based compute. Its chassis is not rocker-bogie. That distinction matters for modeling, controller selection, and terrain expectations. On Leo Rover, obstacle traversal is determined by wheel size, chassis clearance, and traction rather than passive suspension articulation. For lab work, education, and indoor-outdoor research, this simpler architecture is often easier to maintain and simulate.
Raph Rover addresses use cases with larger payload and more demanding field integration. In that context, engineers may compare rigid, sprung, and rocker-bogie chassis concepts when designing custom UGVs around heavier sensor sets such as 3D LiDAR, RTK GNSS, industrial IMUs, or edge GPUs. A rocker-bogie concept can be justified when terrain compliance and sensor stability during slow traversal are more important than top speed or mechanical simplicity.
For both platforms, the engineering decision is application-driven:
- choose a simple 4-wheel chassis when cost, packaging, and software iteration speed dominate,
- choose rocker-bogie when passive terrain adaptability is a primary requirement,
- validate odometry drift under slip if navigation relies on wheel encoders,
- fuse IMU, visual, LiDAR, or GNSS data when terrain excites chassis motion.
Limitations and trade-offs
Rocker-bogie improves terrain compliance, but it is not universally better. The mechanism increases part count, joint wear points, and modeling complexity. It is usually suited to low-speed operation. At higher speeds, passive articulation can become difficult to control dynamically, and suspension without damping may reduce stability.
From a robotics software perspective, the main trade-offs are:
- more complex URDF and simulation setup,
- less reliable encoder-only odometry on deformable terrain,
- higher calibration effort for wheel contact and mass distribution,
- larger mechanical envelope for the same payload bay.
Normative references and standards
When documenting or integrating a rocker-bogie UGV in ROS 2, the most relevant normative references are REP 103 for standard units and coordinate conventions, and REP 105 for coordinate frames on mobile platforms. These are maintained within the ROS ecosystem and are the correct baseline for frame naming and pose interpretation. Simulation and controller implementation should also follow the interfaces required by the ROS 2 distribution in use, for example Humble, Iron, or newer on platforms such as Leo Rover.