Camera mast

Camera mast – definition

A camera mast is a structural assembly that positions one or more cameras above, ahead of, or away from the main chassis of a mobile robot. On an unmanned ground vehicle (UGV), it typically consists of a rigid bracket, vertical support, mounting plate, fasteners, cable routing features, and sometimes vibration-isolation components.

The term is primarily mechanical. It is not a defined ROS or ROS 2 interface type. In a ROS 2 system, however, the camera mast establishes the physical location of camera coordinate frames relative to base_link. Its geometry therefore affects perception, sensor fusion, obstacle detection, visual odometry, and SLAM.

For Leo Rover and Raph Rover, a camera mast is commonly used to mount an RGB camera, stereo camera, depth camera, or a combined camera and LiDAR payload at a height that improves visibility over the rover body. The assembly must remain sufficiently rigid because changes in camera pose caused by vibration or loose mounting can invalidate the assumption of a static extrinsic transform used by the robotics software.

Camera mast geometry in a UGV frame tree

A camera mounted on a mast must have a known transform to the robot base frame. ROS coordinate conventions are described by REP 103, while mobile-robot frame relationships are defined in REP 105. A typical navigation frame chain is map → odom → base_link → camera_link → camera_optical_frame.

The mast usually introduces a fixed transform from base_link to camera_link. This transform contains the camera position and orientation relative to the chassis. It must be measured after final assembly, including any spacer, quick-release plate, vibration damper, or adjustable bracket.

base_link represents the robot body reference frame.
camera_link represents the mechanical camera housing or mounting interface.
camera_optical_frame follows the optical-frame convention in REP 103: positive Z points forward through the lens, positive X points right, and positive Y points down.
camera_info provides calibrated intrinsic parameters and the camera projection model.

A camera mast does not replace camera calibration. Intrinsic calibration estimates lens and image parameters. Extrinsic calibration defines the rigid relation between the camera and the robot. Both are required when camera data is fused with wheel odometry, IMU measurements, LiDAR scans, or GNSS data.

Key engineering parameters

Mast design should be specified as part of the sensor integration package. The relevant values depend on the selected camera, the intended terrain, and the compute workload. The table separates mechanical parameters from ROS-facing parameters.

Parameter	Why it matters	Verification method
Camera height above `base_link`	Changes horizon position, ground coverage, obstacle occlusion, and the camera lever arm.	Measure the final installed sensor origin and update the URDF or static transform.
Pitch, roll, and yaw alignment	Incorrect orientation causes projection and perception errors.	Mechanical alignment followed by extrinsic calibration or target-based validation.
Structural stiffness	Dynamic deflection changes the effective camera pose during driving.	Inspect recorded images and IMU data under representative motion.
Payload mass and centre of gravity	A high-mounted payload can affect stability and wheel-ground contact on uneven terrain.	Check against the rover payload specification and conduct controlled field tests.
Cable strain relief	Prevents USB, Ethernet, CSI, or power connectors from loosening due to vibration.	Inspect cable bend radius, retention, and connector movement.

ROS 2 integration

In ROS 2, a camera driver normally publishes image data using sensor_msgs/msg/Image and calibration data using sensor_msgs/msg/CameraInfo. The message definitions are maintained in the official sensor_msgs documentation. A depth camera may additionally publish depth images, point clouds, and aligned colour streams.

The camera transform should be published through tf2. A fixed mast is normally represented in URDF and published by robot_state_publisher, or published as a static transform with tf2_ros. ROS 2 TF2 documentation distinguishes static transforms from transforms that change over time.

<joint name="base_to_camera_mast" type="fixed">
  <parent link="base_link"/>
  <child link="camera_link"/>
  <origin xyz="${camera_x} ${camera_y} ${camera_z}"
          rpy="${camera_roll} ${camera_pitch} ${camera_yaw}"/>
</joint>

<link name="camera_link"/>

The variables above must be replaced with measured values from the final physical installation. Do not reuse transforms from a different bracket configuration or a different rover payload.

Use on Leo Rover and Raph Rover

Leo Rover is a four-wheel differential-drive platform with native ROS 2 support on its Raspberry Pi-based compute unit. A camera mast can provide a clearer field of view for indoor navigation, object detection, visual inspection, or mapping experiments. Leo Rover is not autonomous out of the box, so a camera mast must be integrated with the selected navigation, localisation, and perception stack.

For a lightweight Leo Rover configuration, the mast should avoid blocking access to the onboard compute unit, power connectors, and serviceable components. Camera cables should be restrained near the mast base and routed so that chassis vibration does not transfer directly to connector loads.

Raph Rover is intended for larger payloads and can accommodate sensor assemblies that combine cameras with LiDAR, GNSS/RTK antennas, or more capable edge-computing hardware. The same frame-management requirement applies: every sensor frame must have a documented transform to base_link. When a camera is mounted far from an IMU or GNSS antenna, the lever arm must be included in the estimation model where the selected localisation software supports it.

Limitations and validation

A higher camera position can reduce occlusion from the rover chassis, but it can also increase mast vibration and raise the payload centre of gravity. Adjustable masts are useful during prototyping, yet every adjustment requires the extrinsic transform to be updated and revalidated.

Validate the installation with a recorded ROS 2 bag. Check that the TF tree is connected, image timestamps are monotonic, and the optical frame orientation matches REP 103. For stereo or depth cameras, confirm that the published CameraInfo data matches the active resolution and mode. A changed camera mode can require a different calibration file.