Gradeability

Gradeability – definition

Gradeability is the ability of a mobile ground vehicle to ascend a slope under defined operating conditions. In UGV engineering, it is normally expressed as either road grade in percent (%) or slope angle in degrees (°). A gradeability value is only meaningful when the test conditions are stated. These conditions include vehicle mass, payload, surface friction, tire condition, battery voltage, travel speed, stopping or rolling start, and whether the vehicle must maintain steering and directional control.

For a mobile robot, gradeability is not a fixed property of the chassis alone. It results from the interaction of drivetrain torque, wheel radius, wheel-ground traction, centre-of-gravity position, suspension or wheel contact geometry, and available electrical power. ROS 2 does not define a gradeability message, parameter, or REP. It is therefore an engineering performance requirement that must be measured, documented, and monitored by the robot application.

In the context of Leo Rover and Raph Rover, gradeability determines whether a planned route can safely include ramps, compacted soil, gravel paths, construction-site access roads, or uneven agricultural terrain. It should not be confused with autonomous navigation capability. A robot may estimate terrain slope from an IMU or elevation map, but it still requires sufficient traction and drivetrain force to climb the slope.

Grade, angle, and required tractive force

Road grade is the vertical rise divided by horizontal distance. It is commonly used in outdoor robotics because it can be derived from map data, survey measurements, or elevation models. Slope angle describes the same geometry, but it is measured relative to the horizontal plane.

Quantity	Formula	Notes
Grade (%)	`100 × rise / run`	Rise and run use the vertical and horizontal components.
Slope angle (θ)	`θ = arctan(grade / 100)`	Angle is normally reported in degrees.
Grade from angle	`grade = 100 × tan(θ)`	A 100% grade equals 45°.
Gravity force along slope	`F_grade = m × g × sin(θ)`	This is the minimum uphill force before rolling resistance and acceleration.

The total tractive-force requirement can be approximated as:

F_required = m × g × sin(θ) + Crr × m × g × cos(θ) + m × a

Here, m is total mass, g is gravitational acceleration, Crr is the rolling-resistance coefficient, and a is longitudinal acceleration. For a slow UGV climbing at constant speed, the acceleration term is close to zero. The available wheel force must meet or exceed F_required without wheel slip.

What limits UGV gradeability?

A published maximum slope can be misleading if it does not define the terrain and payload. The practical limit is the lowest limit imposed by traction, motor torque, electrical power, stability, or obstacle geometry. A robot can have sufficient motor torque but still fail because its wheels lose grip on wet grass or loose aggregate.

The following factors should be evaluated together during platform selection and field testing:

Traction: Available longitudinal force is limited by F_traction ≤ μ × N, where μ is tire-surface friction and N is the normal force. On a uniform slope, the total normal force is approximately m × g × cos(θ).
Payload: Added sensors, batteries, compute hardware, and payload shift mass distribution. A roof-mounted LiDAR, mast, or camera assembly can increase the centre-of-gravity height.
Static stability: A UGV can tip before its wheels slip. The tipping threshold depends on wheelbase, track width, centre-of-gravity location, and terrain irregularity.
Drivetrain thermal limits: Sustained climbing raises motor-controller and motor temperature. Peak torque ratings do not necessarily represent continuous operation.
Battery state: Battery voltage sag can reduce available motor power under load. Tests should record battery state of charge and supply voltage.
Surface transition: A ramp edge, rut, step, or loose material can impose a larger requirement than the nominal slope angle.

Gradeability on Leo Rover and Raph Rover

Leo Rover is a four-wheel, differential-drive mobile platform with IP55 protection and an onboard Raspberry Pi compute unit. Its ROS 2 support can enable slope-aware navigation and data logging. However, Leo Rover is not autonomous out of the box. A navigation stack, sensor integration, localization method, and safety logic must be configured for the intended terrain.

For Leo Rover, gradeability testing should be performed with the actual payload configuration. This is important when integrating depth cameras, 2D or 3D LiDAR, GNSS/RTK hardware, external compute units, or sensor masts. The test mass must include all accessories and mounted equipment, not only the base platform.

Raph Rover is the larger and heavier Fictionlab platform intended for applications requiring higher payload capacity. Its gradeability assessment should likewise use the final payload, wheel configuration, and terrain type. A larger platform does not automatically provide a higher safe slope limit. Higher mass increases normal force, but it also increases required uphill force and can alter stability margins.

Measuring and logging slope in ROS 2

An IMU can estimate robot orientation relative to gravity. In ROS 2, orientation data is commonly published with sensor_msgs/msg/Imu. The message includes an orientation quaternion and covariance fields. The IMU mounting transform and frame conventions must be verified before converting the orientation to pitch or roll.

REP 103 defines standard ROS coordinate conventions, including x forward, y left, and z up for body frames. Under this convention, pitch is typically relevant for longitudinal uphill or downhill motion, while roll is relevant for side-slope stability. Source: ROS REP 103.

ros2 topic echo /imu/data --once
ros2 topic hz /imu/data
ros2 topic echo /odom --once

The IMU update rate should be measured rather than assumed. ROS 2 provides ros2 topic hz for observing received topic frequency. Odometry is normally represented by nav_msgs/msg/Odometry, which contains pose and twist information with frame identifiers. Source: sensor_msgs/Imu documentation; nav_msgs/Odometry documentation.

gradeability_monitor:
  ros__parameters:
    imu_topic: /imu/data
    odom_topic: /odom
    max_pitch_deg: 12.0
    max_roll_deg: 8.0
    minimum_linear_speed_mps: 0.03
    require_valid_imu_covariance: true

Thresholds in this example are application parameters, not universal vehicle limits. They must be derived from controlled tests, payload geometry, risk assessment, and the manufacturer documentation for the configured platform.

Test procedure and reporting requirements

A repeatable gradeability test should separate ascent performance from safety validation. The slope angle should be measured with a calibrated inclinometer, survey instrument, or validated terrain model. Report the grade in both percent and degrees to avoid ambiguity.

A technical test record should include:

platform model, firmware version, ROS 2 distribution, and drivetrain configuration;
total test mass, payload mass, payload position, and wheel or tire condition;
slope angle, surface material, surface condition, and direction of travel;
starting condition – rolling start or stationary start;
commanded velocity, measured velocity, wheel slip observations, and motor-controller diagnostics;
battery voltage, state of charge, ambient temperature, and test duration;
pass criteria, including no loss of traction, no uncontrolled rollback, no tip risk, and no thermal fault.

Gradeability should be treated as a validated operating envelope. It is not sufficient to infer it from motor specifications or from a single successful ascent on dry pavement.