Glossary

Fictionlab > Glossary > Add-on Modules

Add-on Modules

Add-on Modules – definition

Add-on modules are optional hardware or software components attached to a mobile robot to extend its baseline capabilities without changing the core drivetrain, onboard computer, or control architecture. In UGV practice, the term usually refers to payloads, sensor kits, communication interfaces, compute accelerators, power distribution elements, and software packages that can be integrated as separate functional blocks. The key property is modularity: the robot remains a general-purpose platform, while a specific task is enabled by adding a defined module.

In ROS and ROS 2 based systems, add-on modules are typically represented at two levels. First, there is a physical interface: USB, Ethernet, UART, CAN, I2C, CSI, GPIO, or a dedicated power rail. Second, there is a software interface: a driver node, message definitions, TF frames, parameters, and launch files. A module is not fully integrated until both layers are defined and tested. In this sense, an RGB-D camera connected over USB is only a peripheral until the robot publishes topics such as /camera/color/image_raw, /camera/depth/image_rect_raw, /camera/camera_info, and matching TF transforms.

For mobile platforms such as Leo Rover and Raph Rover, add-on modules are the standard way to adapt the same chassis to different research tasks. One configuration may focus on teleoperation and basic odometry. Another may add LiDAR and IMU for SLAM. A third may include RTK GNSS, an edge GPU, and a stereo camera for outdoor navigation or field inspection. The concept is therefore central to research robotics, where repeatable integration matters more than a fixed product configuration.

How add-on modules work in mobile robotics

A mobile robot platform usually provides a stable base layer: locomotion, power, embedded compute, and low-level control. Add-on modules sit above that layer and consume mechanical space, electrical power, communication bandwidth, and CPU or GPU resources. Their integration must be planned against these constraints.

In practical UGV design, add-on modules fall into several technical classes:

  • Sensing modules – 2D LiDAR, 3D LiDAR, IMU, RGB cameras, depth cameras, GNSS, RTK receivers, wheel encoders, environmental sensors.
  • Compute modules – external SBCs, NVIDIA Jetson devices, USB accelerators, dedicated AI coprocessors.
  • Communication modules – Wi-Fi, LTE/5G modems, long-range radios, Ethernet switches, VPN gateways.
  • Power and I/O modules – regulated DC rails, USB hubs, battery monitoring boards, relay boards, GPIO expanders.
  • Software modules – ROS 2 packages, Nav2 plugins, SLAM nodes, perception pipelines, simulation descriptions, Dockerized runtime stacks.

The module boundary should remain explicit. A well-structured integration defines the module input, output, timing, and failure mode. For example, a LiDAR add-on should specify scan rate, field of view, message type, TF frame, power draw, and expected mounting pose. Without this, the module cannot be reused across robots or experiments.

ROS 2 integration model

In ROS 2, add-on modules are usually integrated as composable nodes, standalone nodes, or launchable subsystems. Interface consistency is guided by standard message packages and ROS Enhancement Proposals. Coordinate frames should follow REP 103 for units and conventions, and REP 105 for mobile platform frame semantics such as base_link, odom, and map.

A typical module integration in ROS 2 includes the following artifacts:

  • driver package for the device or subsystem
  • URDF or Xacro description of mount position and geometry
  • TF publication for the module frame
  • parameter file in YAML
  • launch file for startup order and namespacing
  • diagnostics and logging configuration

Common ROS 2 message types used by add-on modules include:

Module type Typical ROS 2 message Examples of topics
2D LiDAR sensor_msgs/msg/LaserScan /scan
IMU sensor_msgs/msg/Imu /imu/data
Camera sensor_msgs/msg/Image, sensor_msgs/msg/CameraInfo /image_raw, /camera_info
GNSS sensor_msgs/msg/NavSatFix /fix
Odometry source nav_msgs/msg/Odometry /odom
Point cloud sensor sensor_msgs/msg/PointCloud2 /points

The example below shows a simplified ROS 2 launch pattern for a LiDAR add-on on a UGV.

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(
            package='rplidar_ros',
            executable='rplidar_node',
            name='rplidar',
            parameters=[{
                'serial_port': '/dev/ttyUSB0',
                'frame_id': 'laser_frame',
                'angle_compensate': True,
                'scan_mode': 'Standard'
            }]
        )
    ])

Key parameters and metrics

Add-on modules are evaluated by measurable properties. These values affect system performance and should be documented from the vendor specification or driver documentation.

  • Power draw – voltage range, average current, inrush current, peak load.
  • Mass and dimensions – affects center of gravity, vibration, and payload margin.
  • Interface bandwidth – USB 2.0 versus USB 3.x, Ethernet throughput, UART baud rate.
  • Update rate – for example IMU at 100-400 Hz, LiDAR at 5-20 Hz, GNSS at 1-20 Hz depending on model.
  • Latency – relevant for sensor fusion and closed-loop navigation.
  • Time synchronization – system clock, hardware timestamps, PPS support, PTP or NTP strategy.
  • Environmental rating – ingress protection, temperature range, shock and vibration resistance.

For ROS 2 deployments, module timing must also be checked at the topic level. It is common to verify publication frequency and jitter with the ROS 2 CLI.

ros2 topic hz /scan
ros2 topic hz /imu/data
ros2 topic echo /diagnostics

Add-on modules on Leo Rover and Raph Rover

On Leo Rover, add-on modules are commonly used to move from a teaching or teleoperation setup to a research configuration. The platform uses a built-in Raspberry Pi class compute unit and supports ROS 2. This makes Leo Rover suitable for lightweight modules and for pipelines that fit within limited CPU, memory, and power margins. Typical additions include a 2D LiDAR for indoor mapping, an IMU for state estimation, a depth camera for obstacle perception, or a GNSS receiver for outdoor experiments. Since Leo Rover is a four-wheel UGV and not an autonomous system out of the box, navigation requires a separately integrated software stack such as SLAM plus Nav2.

On Raph Rover, the same concept applies, but the integration envelope is larger. Raph Rover is intended for higher payload and more demanding field setups, so it can host heavier sensors, larger compute modules, and more complex power distribution. This makes it more suitable for multi-sensor fusion, 3D perception, and extended outdoor deployments. It does not replace Leo Rover in lab and education scenarios, but it supports add-on modules that would be mechanically or energetically difficult on a smaller platform.

Examples of practical module combinations include:

  • Leo Rover + 2D LiDAR + IMU + Nav2 for indoor navigation experiments
  • Leo Rover + RGB-D camera for visual odometry or obstacle detection
  • Raph Rover + RTK GNSS + 3D LiDAR + Jetson for outdoor mapping
  • Raph Rover + long-range communication module for remote inspection in open terrain

Integration constraints and trade-offs

Add-on modules improve capability, but they also increase system complexity. In mobile robotics, most failures come from integration details rather than from the module itself. A camera may be supported by a ROS 2 driver but still fail under field conditions because USB bandwidth is saturated. A GNSS receiver may publish valid fixes but be unusable for navigation because antenna placement is poor. A LiDAR may provide clean scans but destabilize localization if its TF frame is rotated incorrectly.

The main trade-offs are straightforward:

  • more sensors usually improve observability, but increase calibration effort
  • higher compute capability improves perception throughput, but raises power and thermal load
  • modularity improves reusability, but adds connectors, mounts, and failure points
  • outdoor robustness improves field usability, but increases mass and cost

For this reason, add-on modules should be treated as versioned subsystems. A complete module definition should include firmware version, ROS 2 package version, frame naming, calibration files, and tested operating conditions.

Normative references and standards

The term add-on module is broader than a single ROS standard, but its implementation in robotics should align with established ROS interface conventions and hardware specifications. The most relevant references are:

  • REP 103 – standard units of measure and coordinate conventions in ROS
  • REP 105 – coordinate frames for mobile platforms
  • ROS 2 documentation – nodes, parameters, composition, launch system, QoS policies
  • sensor vendor specifications – power, update rate, interface type, environmental limits
  • IEEE terminology where applicable for sensor characterization and robotic system integration

In practice, a module is considered integration-ready only if its electrical, mechanical, and software interfaces are all documented and reproducible. That is the standard expected in research labs and in field robotics engineering.

See also