Payload (10kg)

Payload (10 kg) – definition

In mobile robotics, payload is the maximum additional mass that a robot platform can carry while staying within its specified operating limits. A payload value of 10 kg means the unmanned ground vehicle (UGV) is designed to transport up to 10 kilograms of extra equipment, excluding the robot’s own base structure and, depending on the manufacturer’s convention, sometimes excluding or including the standard battery pack. The exact convention must always be checked in the platform specification.

For UGVs, payload is not only a mass number. It is a systems constraint that affects traction, stability, motor current, energy consumption, braking distance, localization quality, and mechanical durability. A 10 kg payload can be a LiDAR stack, RGB-D camera rig, RTK GNSS receiver, compute box, battery module, radio, sample container, or a research instrument mounted on top of the rover. In practice, the useful interpretation is: how much external equipment can be installed without violating drivetrain, power, thermal, and navigation constraints.

In the context of Fictionlab platforms, payload matters differently for Leo Rover and Raph Rover. Leo Rover is a compact differential-drive research rover with onboard Raspberry Pi compute and ROS support. It can carry sensors and small compute modules, but it is not intended to become a heavy cargo platform. Raph Rover is the larger platform intended for applications where more payload capacity is required. Therefore, a “10 kg payload” threshold is usually closer to the class of platform and integration scenario associated with Raph Rover than with a compact educational rover.

What is included in payload in a UGV specification

Payload figures can be misunderstood if the scope is not defined. In robotics documentation, the number is useful only when paired with mounting location, terrain assumptions, and speed limits. The same 10 kg can be acceptable on flat indoor floors and problematic on rough outdoor terrain.

When evaluating a 10 kg payload rating, engineers should verify the following technical boundaries:

whether the payload excludes the standard battery, charger, and base electronics
whether the value applies on flat ground or off-road terrain
whether the rating assumes a specific center of gravity height
whether the payload can be dynamic, for example a sloshing tank or moving gimbal
whether the stated value applies at nominal speed or only at reduced speed

A practical payload statement should therefore be read as a constrained operating point, not as an unconditional mass allowance.

Why payload is more than mass

In a ROS 2 UGV project, adding 10 kg affects several subsystems at once. The impact is visible in mechanics, control, power, and perception. A payload mounted high above the chassis increases roll moment and may reduce stability on slopes. A payload mounted far from the geometric center changes wheel loading and can introduce slip. A payload that draws electrical power also changes runtime and thermal load.

The most important engineering effects are listed below.

Subsystem	Effect of higher payload	Typical consequence
Drivetrain	Higher torque and current demand	Lower acceleration, more heating, possible current limiting
Battery	Higher average power consumption	Shorter mission time
Suspension / chassis	Higher static and dynamic load	More deflection, reduced durability margin
Navigation	More wheel slip and inertia	Worse odometry and path tracking
Perception	Sensor pose changes under vibration	Reduced SLAM consistency
Safety	Longer stopping distance	Need for lower speed limits

For this reason, “payload 10 kg” should always be evaluated together with mission speed, terrain class, and sensor placement.

Payload in ROS 2 integration practice

ROS 2 does not define payload as a dedicated message type or REP field. Instead, payload appears indirectly in robot description, state estimation, and controller tuning. The robot model in URDF should reflect the installed sensor mass and inertia when that mass is large enough to change vehicle dynamics or pose estimation assumptions.

In ROS 2, the payload itself is often represented by additional links and joints in the robot description. This is especially relevant when the payload is a mast, LiDAR tower, GNSS pole, pan-tilt sensor, or modular compute enclosure.

<link name="payload_box">
  <inertial>
    <origin xyz="0 0 0.12" rpy="0 0 0"/>
    <mass value="10.0"/>
    <inertia ixx="0.12" ixy="0.0" ixz="0.0"
             iyy="0.10" iyz="0.0" izz="0.08"/>
  </inertial>
</link>

<joint name="payload_mount" type="fixed">
  <parent link="base_link"/>
  <child link="payload_box"/>
  <origin xyz="0.0 0.0 0.18" rpy="0 0 0"/>
</joint>

In a differential-drive platform, controller parameters may also need retuning because higher payload increases inertia. This can affect acceleration limits in local planning and wheel controller gains.

controller_server:
  ros__parameters:
    FollowPath:
      max_vel_x: 0.4
      acc_lim_x: 0.3
      decel_lim_x: -0.4

velocity_smoother:
  ros__parameters:
    max_accel: [0.3, 0.0, 0.8]
    max_decel: [-0.4, 0.0, -0.8]

For Nav2 on ROS 2 Humble or newer, a heavier rover usually benefits from lower acceleration limits and more conservative obstacle inflation and stopping profiles.

Key parameters and metrics

A payload figure becomes useful when paired with other measurable parameters. Engineers should document at least the following values during integration and validation.

payload mass – total external mass in kg
payload center of gravity – position relative to base_link, usually in meters
payload power draw – average and peak electrical load in W
mission speed – for example 0.3 m/s vs 1.0 m/s
slope limit – maximum grade with the installed payload
runtime reduction – battery endurance before and after payload installation
odometry drift – change in error under loaded conditions
braking distance – stopping distance at nominal operating speed

A simple first-order check for static axle loading is the moment balance around the chassis center. If a payload mass m is mounted at horizontal offset x from the center, the additional moment is:

M = m * g * x

where g is gravitational acceleration, approximately 9.81 m/s². Even moderate offsets can significantly increase front or rear wheel loading.

Use on Leo Rover and Raph Rover

On Leo Rover, payload should be treated conservatively. The platform is intended for research, education, and field experimentation with sensors and moderate add-ons. Typical payloads are compact LiDAR units, Intel RealSense depth cameras, IMUs, GNSS receivers, radios, or small edge compute modules. A full 10 kg integration on a compact rover is usually not the default operating scenario and may exceed the practical limits of stability, power budget, and mobility depending on mounting geometry and terrain.

On Raph Rover, a 10 kg payload is a more realistic engineering target. This larger platform is intended for heavier sensor stacks, larger batteries, compute enclosures, or application-specific hardware for inspection, agriculture, and outdoor research. Even then, the integration must still validate center of gravity, structural attachment, cable routing, power distribution, and controller tuning.

For both platforms, payload should be mounted as low and as close to the geometric center as possible. Tall sensor masts improve visibility but penalize stability and vibration performance.

Typical 10 kg payload examples

A 10 kg payload budget is often consumed quickly in field robotics. The examples below are realistic combinations rather than extreme laboratory setups.

3D LiDAR + RTK GNSS + IMU + Jetson-class computer + weatherproof enclosure
stereo or RGB-D perception rig + onboard UPS + LTE or Wi-Fi bridge + data logger
inspection sensor pack with thermal camera, pan-tilt unit, and high-capacity battery
research payload with sampling box, embedded controller, and environmental sensors

Each of these combinations should be checked against both mechanical payload capacity and electrical power budget.

Standards, documentation, and verification

There is no universal ROS REP that defines payload as a single mandatory field for mobile robots. However, related ROS conventions matter. REP 103 defines standard units and coordinate conventions used when documenting mass, geometry, and frames. URDF and robot_state_publisher workflows are the normal way to represent mounted payload geometry in ROS and ROS 2. For navigation and localization, the effect of payload is verified indirectly through odometry, IMU behavior, and controller performance rather than through a dedicated payload API.

Verification should use manufacturer specifications for the base platform and mounted devices. For sensor payloads, use official specifications from vendors such as Intel RealSense, Slamtec, Fixposition, or NVIDIA. For the rover platform itself, use the official technical documentation and published hardware limits. If the mission is safety-relevant, test under worst-case terrain, battery state, and thermal conditions rather than relying on nominal lab measurements only.