Glossary

Fictionlab > Glossary > Mobile manipulation

Mobile manipulation

Mobile manipulation – definition

Mobile manipulation is the coordinated execution of mobility and physical interaction tasks by a robot that combines a mobile base with an actuated manipulator, end-effector, or tool payload. In the UGV context, the mobile base positions the robot near an object, surface, tool, or sensor target, while the mounted manipulator or end-effector performs an interaction such as pressing a button, operating a handle, collecting a sample, positioning a camera, or placing an inspection probe.

The term does not describe a stationary industrial robot operating in a fixed cell. A mobile manipulation system must account for base motion, wheel slip, localisation uncertainty, arm or tool reachability, payload mass, power consumption, and collision constraints. For a differential-drive UGV, the base cannot move laterally without turning. This non-holonomic constraint affects approach planning and final end-effector positioning.

On Leo Rover or Raph Rover, mobile manipulation usually means integrating an external arm, gripper, linear actuator, tool mount, or sensor probe as a payload. The rover is responsible for terrain traversal and approximate pose alignment. The payload provides the physical interaction function. Autonomous operation requires an integrated navigation, perception, transform, control, and safety stack.

System architecture for a mobile UGV

A practical implementation separates base navigation from payload control but maintains a shared spatial reference system. ROS 2 nodes exchange commands, feedback, sensor data, and coordinate transforms through defined message interfaces.

Subsystem Typical ROS 2 interface Purpose
Mobile base geometry_msgs/msg/Twist Linear and angular velocity commands for the rover base.
Wheel odometry nav_msgs/msg/Odometry Estimated base pose and velocity in the odom frame.
Manipulator state sensor_msgs/msg/JointState Joint position, velocity, and effort feedback.
Manipulator trajectory trajectory_msgs/msg/JointTrajectory Time-parameterised joint commands for an arm or actuator.
Coordinate transforms tf2 Relationships between map, rover, payload, camera, and tool frames.

ROS coordinate frames should follow the conventions in REP 105. A typical transform chain is map → odom → base_link → payload_link → tool0. The map frame represents globally corrected localisation. The odom frame provides locally continuous odometry. The base_link frame is rigidly attached to the rover chassis. Each payload link must be defined relative to the base through URDF and published through robot_state_publisher.

Planning and control in ROS 2

Mobile manipulation generally combines a navigation planner with a manipulation planner. Nav2 can guide a UGV towards a pre-manipulation pose. MoveIt 2 can evaluate arm kinematics, collision geometry, and joint-space trajectories. Neither system alone guarantees a successful task. The target must be reachable after the base stops, and the tool path must remain collision-free relative to the rover, terrain, and local obstacles.

For a differential-drive platform, the commanded base velocity is commonly represented as:

v = linear velocity along the base x-axis
ω = angular velocity about the base z-axis

cmd_vel = [v, 0, 0, 0, 0, ω]

The lateral velocity component is normally zero for a non-holonomic differential-drive base. If the tool requires a precise lateral approach, the navigation planner must create a feasible turning and alignment manoeuvre rather than commanding sideways motion.

A minimal ROS 2 workflow can launch rover navigation and a separate payload controller. The specific package names and hardware interfaces depend on the installed payload driver.

ros2 launch nav2_bringup navigation_launch.py use_sim_time:=false
ros2 run tf2_ros tf2_echo base_link tool0
ros2 topic echo /joint_states
ros2 action list | grep follow_joint_trajectory

Key parameters and validation metrics

Mobile manipulation performance should be evaluated as a combined system property. Base localisation can be sufficient for navigation while still being insufficient for a contact task. A rover may reach a waypoint correctly but present the tool several centimetres away from the required target because of map drift, wheel slip, chassis flex, payload calibration error, or camera-to-tool extrinsic error.

  • Base pose error: difference between estimated and measured rover pose at the task location.
  • Tool-centre-point error: distance and orientation error between the planned and actual end-effector pose.
  • Transform latency: age of the transform between base_link, sensor frames, and tool0.
  • Trajectory tracking error: difference between commanded and measured joint positions or velocities.
  • Payload limits: total mass, centre of gravity, mounting stiffness, electrical power demand, and permitted rover payload capacity.
  • Task success rate: completed interactions divided by attempted interactions under documented terrain, lighting, and obstacle conditions.

Calibration is critical when a camera guides a tool. The rigid transform from camera frame to tool frame must be measured or estimated through hand-eye calibration. A perception system that detects an object accurately in camera_link can still fail if the static transform to the tool is incorrect.

Mobile manipulation with Leo Rover and Raph Rover

Leo Rover is a four-wheel differential-drive platform with native ROS 2 support on its built-in Raspberry Pi compute unit. It can serve as the mobile component of a lightweight research or educational mobile manipulation setup. The default platform does not include an arm, a gripper, motion planning, or autonomous navigation. These functions require payload integration and a configured ROS 2 stack.

Typical Leo Rover tasks include positioning a depth camera for close-range inspection, carrying a small actuator to operate a simple fixture, or moving a sensor probe to repeatable observation points. Compute-intensive perception, dense 3D reconstruction, or real-time motion planning may require an external computer or an additional onboard compute unit, depending on the selected sensors and algorithms.

Raph Rover may be suitable where the integrated payload has greater mass, volume, or power requirements, subject to its published specifications. It should be selected based on the complete payload specification, including mounting structure, batteries, sensors, actuator loads, and centre-of-gravity effects. A larger platform does not remove the need for kinematic modelling, collision checking, localisation, or safety limits.

Relevant ROS standards and references

The following documents define commonly used conventions and interfaces for ROS-based mobile manipulation systems. They should be checked against the ROS 2 distribution and package versions used in the project.

See also