Center of gravity

Center of gravity – definition

The center of gravity (CoG) is the point at which the resultant gravitational force acting on a robot can be considered to act. In a uniform gravitational field, the center of gravity coincides with the center of mass (CoM). For mobile robots and unmanned ground vehicles (UGVs), the CoG is a critical mechanical property because it affects static stability, rollover risk, wheel load distribution, traction, braking behaviour, and suspension loading.

For a robot with components of mass m_i located at positions r_i, the center of mass is calculated as:

r_CoM = (Σ m_i × r_i) / Σ m_i

In mobile robotics, the CoG is normally expressed relative to the robot body frame, typically base_link. REP 103 defines the standard ROS body coordinate convention: X points forward, Y points left, and Z points upward. The origin of base_link does not have to coincide with the robot’s CoG. It is a reference frame selected by the robot developer or integrator.

For a UGV such as Leo Rover or Raph Rover, the CoG changes when payloads are added, removed, relocated, or supplied with separate batteries. A LiDAR mast, camera housing, GNSS antenna, compute enclosure, agricultural sensor, or inspection payload can raise the CoG and reduce the maximum safe slope or lateral acceleration.

Why center of gravity matters for UGV stability

A wheeled robot remains statically stable while the projection of its CoG along the direction of gravity falls inside the support polygon formed by the wheel-ground contact points. On a four-wheel differential-drive platform, the support polygon is usually approximated as a rectangle when all wheels remain in contact with level ground.

Static rollover becomes possible when the CoG projection reaches an edge of that polygon. The relevant edge depends on the direction of the force acting on the robot.

Longitudinal stability concerns climbing, descending, braking, and acceleration.
Lateral stability concerns side slopes, cornering, uneven terrain, and one-sided payload placement.
Dynamic stability includes inertial forces caused by acceleration, deceleration, turning, wheel impacts, and terrain transitions.
Traction distribution depends on normal force at each wheel. A shifted CoG can reduce load on one axle or one side of the vehicle.

For a simplified static side-slope model, the tipping threshold is reached when the gravitational line of action intersects the outer wheel contact line. If b is the effective track width and h is the CoG height above the ground plane, and the CoG is centred laterally, the idealized rollover angle can be estimated as:

θ_tip = arctan((b / 2) / h)

This calculation is only an approximation and assumes that the vehicle does not slide before tipping. It does not account for tyre deformation, suspension travel, wheel sinkage, obstacles, acceleration, surface friction, or chassis flex. Field testing must therefore use conservative limits.

Center of gravity in ROS 2 and URDF

ROS 2 does not define a dedicated standard topic or message type for publishing a robot’s center of gravity. Instead, robot mass properties are usually represented in URDF through the <inertial> element of each link. The complete CoM is then derived from the mass and inertial origins of all links.

The <origin> inside <inertial> defines the inertial frame position and orientation relative to the link frame. Its XYZ offset should represent the component’s center of mass. The inertia tensor should be expressed about that inertial frame.

<link name="payload_box">
  <inertial>
    <origin xyz="0.12 0.00 0.08" rpy="0 0 0"/>
    <mass value="2.5"/>
    <inertia ixx="0.018" ixy="0.0" ixz="0.0"
             iyy="0.024" iyz="0.0"
             izz="0.011"/>
  </inertial>
</link>

The values in this example are illustrative and must be replaced with measured or CAD-derived data. Incorrect inertial parameters can reduce the validity of Gazebo or other physics-based simulation results. An incorrect CoG location may produce unrealistic wheel loading, oscillation, pitch behaviour, or rollover behaviour in simulation.

REP 103 is relevant because it defines the coordinate orientation used by common ROS frames. URDF defines the syntax used to describe link mass, inertia, and inertial-frame offsets. Neither specification mandates a single frame named center_of_gravity.

Measuring and validating the CoG

The CoG should be measured for the fully configured platform, not only for the empty chassis. This includes batteries, onboard computer, sensors, cables, enclosures, mounting brackets, and mission-specific payload. The mass distribution can change substantially after an integration update.

Common engineering methods include the following:

CAD calculation – uses assigned material densities and component mass properties. It is efficient during design but depends on accurate component models.
Wheel-scale measurement – uses individual scales under each wheel to estimate front-rear and left-right load distribution on level ground.
Tilt method – tilts the platform until a defined load-transfer condition is reached, then derives CoG height from the geometry.
Physical balancing – identifies an approximate CoG location for compact assemblies, but does not replace quantitative validation for a mobile platform.

For repeatable test records, store the total mass, payload mass, battery configuration, wheelbase, track width, tyre condition, terrain type, and estimated CoG coordinates. A CoG value without the corresponding robot configuration is incomplete data.

Leo Rover and Raph Rover integration context

Leo Rover is a four-wheel differential-drive mobile platform. When integrating navigation sensors or research payloads, the mass placement should be considered together with sensor visibility and cable routing. A high-mounted LiDAR or depth camera may improve line of sight, but it also raises the CoG. A payload placed far forward or rearward can increase pitch load transfer during acceleration and braking.

Leo Rover uses an integrated Raspberry Pi compute unit and supports ROS 2 deployments. Its standard drive configuration does not provide autonomous navigation by itself. When adding a ROS 2 navigation stack, SLAM sensors, or a compute expansion, the resulting mechanical configuration should be reflected in the URDF and simulation model.

Raph Rover is intended for larger and heavier payload configurations. Higher payload capacity does not remove the need for CoG analysis. A large payload mounted above the chassis can still reduce lateral stability, particularly during operation on ramps, agricultural terrain, construction sites, or inspection routes with uneven surfaces.

For both platforms, place dense components such as batteries, power converters, compute modules, and payload electronics as low and as close to the longitudinal centreline as practical. This reduces CoG height and minimizes asymmetric wheel loading.

Key integration checks

Before field deployment, validate the mechanical model and the physical vehicle in the same payload configuration. The following checks provide a practical baseline for UGV integration work.

Confirm that URDF link masses match measured component masses.
Verify that inertial origins are expressed in the correct link frame.
Check that the payload does not obstruct wheel travel, sensors, or emergency access.
Measure wheel loads on a level surface after every significant payload change.
Test slopes and turns progressively, with speed limits appropriate to the terrain.
Update simulation parameters when battery, sensor, or payload placement changes.

Normative references and technical sources

The following documents define the coordinate and robot-description conventions most relevant to representing CoG-related data in ROS-based mobile robots.

REP 103 – Standard Units of Measure and Coordinate Conventions, ROS Enhancement Proposal.
URDF documentation, ROS documentation.
Adding physical and collision properties to a URDF model, ROS documentation.
Leo Rover technical documentation, Fictionlab.