Robotic arm

Robotic arm – definition

A robotic arm is a multi-joint electromechanical subsystem mounted on a robot to position an end-effector in 3D space. In mobile robotics, the term usually refers to a lightweight manipulator installed as a payload on a UGV rather than a fixed industrial cell. The arm adds interaction capability to the vehicle. It can move a camera, a gripper, a sampling tool, or a probe. In this context, the robotic arm is not the robot itself. It is one subsystem integrated with the mobile base, sensors, power distribution, and onboard compute.

For UGV platforms such as Leo Rover or Raph Rover, a robotic arm is understood as a payload that extends mission scope beyond perception and locomotion. Typical tasks include pressing buttons, collecting samples, opening lightweight access panels, positioning sensors, or inspecting hard-to-reach areas. In ROS 2 systems, the arm is represented as a kinematic chain in URDF, controlled through standard interfaces such as sensor_msgs/JointState, trajectory_msgs/JointTrajectory, and the ros2_control framework. The mobile base and the arm should be modeled together, because arm motion changes center of mass, power draw, reachable workspace, and collision geometry.

In practical UGV engineering, a robotic arm is evaluated by payload, reach, degrees of freedom, repeatability, mass, supply voltage, control interface, and software support. For mobile platforms, these parameters matter more than absolute speed. A manipulator that is acceptable on a bench may be unusable on a small rover if it exceeds the power budget, destabilizes the chassis, or blocks sensors.

How a robotic arm is modeled in ROS 2

In ROS 2, the arm is usually integrated as part of the full robot description. The preferred model format is URDF, often generated with Xacro. Kinematic structure, inertial properties, joint limits, and collision meshes should be declared explicitly. This is required for visualization, planning, and simulation.

Several ROS conventions are relevant here. REP 103 defines standard units and coordinate conventions. REP 105 defines coordinate frames for mobile platforms. For a rover with a manipulator, the arm base frame is typically attached to base_link or to a dedicated mounting frame rigidly connected to the chassis. Joint states are published continuously, and transforms are broadcast through tf2.

The most common software building blocks are:

robot_state_publisher – publishes the transform tree from the URDF and incoming joint states
joint_state_broadcaster or hardware drivers – provide sensor_msgs/JointState data to the ROS graph
ros2_control – hardware abstraction and controller management in ROS 2
joint_trajectory_controller – executes time-parameterized joint trajectories
MoveIt 2 – motion planning, kinematics, and collision-aware manipulation

A minimal ROS 2 launch pattern may look like this:

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(
            package='robot_state_publisher',
            executable='robot_state_publisher',
            parameters=[{'robot_description': '<urdf content here>'}]
        ),
        Node(
            package='controller_manager',
            executable='ros2_control_node',
            parameters=['config/controllers.yaml']
        ),
        Node(
            package='controller_manager',
            executable='spawner',
            arguments=['joint_state_broadcaster']
        ),
        Node(
            package='controller_manager',
            executable='spawner',
            arguments=['arm_controller']
        )
    ])

Key parameters and metrics

On a UGV, arm selection is constrained by rover mechanics and mission profile. Parameters should be checked against platform limits, not only against the manipulator datasheet. For Leo Rover this is especially important because the platform uses a Raspberry Pi-class onboard compute unit and a compact four-wheel chassis. Raph Rover allows a larger payload envelope, but the same integration logic still applies.

The main engineering parameters are listed below.

Parameter	Why it matters on a UGV	Typical ROS 2 representation
Degrees of freedom	Determines reachable poses and dexterity	URDF joints, `JointState`
Payload	Limits tool mass at a given reach	Defined in hardware specs, not a ROS message
Reach	Sets workspace around the rover body	Derived from kinematics and joint limits
Repeatability	Important for inspection and sampling tasks	Validated experimentally
Mass	Affects stability and wheel traction	URDF inertial model
Power draw	Impacts battery life and regulator sizing	Electrical design parameter
Control rate	Affects smoothness and disturbance rejection	Controller update frequency

Two practical checks are critical. First, the static tipping margin decreases when the arm is extended. Second, the end-effector pose error increases if the chassis is moving on uneven ground. Even a well-calibrated arm becomes less accurate when mounted on a compliant mobile base.

A simplified static moment check is:

M = m_payload * g * d + m_arm * g * d_com

where d is horizontal distance from the tipping edge to the payload, and d_com is the projected distance of the arm center of mass. This is only a first-order estimate. Dynamic effects, terrain slope, and wheel-ground interaction must be evaluated separately.

Integration on Leo Rover and Raph Rover

On Leo Rover, a robotic arm should be treated as a constrained payload. The platform is suitable for research and education, but it is not a manipulation platform out of the box. Integration requires mechanical mounting, power budgeting, URDF updates, controller configuration, and often an external compute upgrade if perception or planning is heavy. Because Leo Rover is a four-wheel mobile rover with native ROS 2 support, the manipulator should not obstruct wheel clearance, front-facing sensors, or the main field of view used for navigation.

On Raph Rover, a larger manipulator or heavier tool is more realistic because the platform is intended for higher payload applications. This can support field inspection payloads, larger depth cameras, or more rigid arm mounts. Still, Raph Rover does not replace Leo Rover in laboratory or educational scenarios where smaller footprint, lower energy use, and simpler deployment are required.

Typical integration tasks on both platforms include:

adding an arm base frame to the rover URDF
declaring mass and inertia for all links
configuring joint drivers through ros2_control
publishing synchronized joint states and tf2
updating collision models for navigation and simulation
checking battery, regulator, and thermal limits under stall and peak loads

Navigation, perception, and manipulation coupling

A robotic arm on a UGV changes more than mechanical capability. It also affects autonomy. An extended arm modifies the robot footprint and can interfere with LiDAR, RGB-D, or stereo fields of view. If Nav2 is used in ROS 2, costmap footprint and obstacle layers may need adjustment for deployed and stowed arm states. In many field systems, the arm is stowed during navigation and deployed only at the task location.

Perception is also linked to manipulation. If the end-effector carries a camera or depth sensor, transform accuracy between base_link, arm links, and sensor frame becomes essential. Calibration error propagates directly into target localization. Time synchronization matters as well, especially if images, IMU data, and joint states are fused during visual servoing or contact tasks.

Limitations and trade-offs

The main trade-off is between manipulation capability and rover simplicity. A larger arm improves reach and payload but increases mass, energy consumption, and software complexity. For small UGVs, these penalties appear quickly. Compute load is another issue. MoveIt 2 planning, depth perception, and arm control can compete with SLAM or Nav2 on limited onboard hardware.

There are also terrain-related limitations. Mobile manipulation in outdoor settings is harder than bench operation because the base is rarely perfectly level. Wheel slip, suspension compliance, and vibration reduce end-effector accuracy. For this reason, mobile rover arms are often used for low-speed interaction, inspection, or tool positioning rather than precision assembly.

Normative references and standards

The following references are the most relevant when defining and integrating a robotic arm in a ROS-based UGV system:

REP 103 – Standard Units of Measure and Coordinate Conventions
REP 105 – Coordinate Frames for Mobile Platforms
URDF specification – robot kinematic and inertial description used across ROS tools
sensor_msgs/JointState – standard ROS message for joint position, velocity, and effort
trajectory_msgs/JointTrajectory – standard ROS message for trajectory execution
ros2_control and ros2_controllers documentation – hardware interfaces and controller architecture in ROS 2
MoveIt 2 documentation – kinematics, planning scene, and collision-aware motion planning