Legacy Support

Legacy Support – definition

In mobile robotics, legacy support means maintaining compatibility with older hardware, software, interfaces, and workflows that are still used in deployed robotic systems. In practice, it covers continued operation of drivers, communication layers, build systems, operating systems, message formats, and device protocols even when newer replacements already exist. For UGV platforms, legacy support is not only a software maintenance topic. It directly affects field reliability, sensor reuse, upgrade cost, and the ability to reproduce experiments over multiple years.

In ROS-based systems, legacy support usually appears when a robot must combine components from different technology generations. Typical examples include ROS 1 nodes bridged into ROS 2, USB serial sensors with vendor-specific binary protocols, cameras with discontinued SDK versions, or embedded motor controllers exposing only older packet formats. A mobile robot may still function correctly with such components, but integration requires version pinning, wrappers, protocol adapters, and additional validation.

For platforms such as Leo Rover and Raph Rover, legacy support often means preserving compatibility with previous payloads, established ROS packages, and research lab infrastructure. Since Leo Rover supports ROS 2, typically Humble-class deployments or newer depending on the software image, legacy support most often concerns ROS 1 migration paths, older Linux packages, archived sensor drivers, or custom interfaces created for earlier experiments. On a larger platform such as Raph Rover, the issue is similar but usually broader because payload diversity and long service life increase the chance of mixed-generation components.

Why legacy support matters in UGV systems

A UGV is a system of systems. The compute unit, motor controller, localization stack, perception pipeline, and teleoperation interface often come from different vendors and release cycles. Replacing one obsolete component can force changes in many other layers. Because of that, legacy support is often the difference between a robot that remains operational and one that becomes costly to maintain.

In research and education, backward compatibility also supports repeatability. A laboratory may need to rerun an experiment from two years earlier on the same rover with the same topic structure, map format, or bag file schema. If those interfaces break, the original result may be hard to reproduce.

Area	Legacy element	Typical impact on UGV
Middleware	ROS 1 nodes or APIs	Requires `ros1_bridge` or partial rewrite for ROS 2
Sensor integration	Deprecated SDK or serial protocol	Driver pinning, custom parser, limited OS support
Compute platform	Older Ubuntu or kernel version	Blocks upgrade of drivers, CUDA, or DDS implementation
Robot description	Old URDF/xacro conventions	Simulation and TF migration work
Control interface	Custom motor controller packet format	Need for protocol shim and regression testing

Legacy support in ROS and ROS 2

The term is especially important in ROS migration projects. ROS 1 and ROS 2 differ in transport, node lifecycle, parameter handling, security model, and build tooling. ROS 1 commonly uses catkin, while ROS 2 commonly uses ament and colcon. ROS 2 also standardizes DDS-based communication and has a different parameter API and executor model. As a result, support for legacy software rarely means simple recompilation.

From a practical standpoint, legacy support in ROS environments often includes the following tasks:

maintaining ROS 1 packages for devices that have no ROS 2 port
using ros1_bridge to exchange selected message types between ROS 1 and ROS 2
keeping older message definitions stable to avoid breaking log processing or autonomy pipelines
freezing dependency versions in Docker images for reproducible deployment
documenting TF trees and topic contracts so that older payloads still attach correctly

ROS naming and interface consistency are also part of legacy support. REP-103 defines standard units and coordinate conventions. REP-105 describes coordinate frames for mobile platforms, including frames such as map, odom, and base_link. If an older sensor driver violates these conventions, downstream localization and navigation nodes may still work only through compatibility patches. That is legacy support in an operational sense.

# Example: checking ROS 2 interfaces on a rover after integrating an older driver
ros2 topic list
ros2 topic echo /odom
ros2 topic hz /scan
ros2 run tf2_tools view_frames

Typical legacy support layers on Leo Rover and Raph Rover

On Leo Rover, legacy support usually starts at the edge of the native ROS 2 stack. The platform is built around an onboard Raspberry Pi compute unit, so CPU budget, available RAM, and package availability matter when older software requires unsupported binaries or heavyweight compatibility layers. If a historical project used a ROS 1 LiDAR driver or an older camera SDK, the common options are bridging, containerization, or driver replacement.

On Raph Rover, the same principles apply, but larger payload capacity may lead to more complex mixed setups. A field robot may carry GNSS/RTK, a 3D LiDAR, one or more depth cameras, and a custom perception computer. In such cases, legacy support often means preserving stable Ethernet or serial interfaces, PPS timing paths, and published ROS topics while modernizing only the compute layer.

Typical legacy components on UGV platforms include:

2D LiDARs with vendor SDKs built for older Ubuntu releases
IMUs publishing proprietary serial frames instead of standard ROS messages such as sensor_msgs/msg/Imu
GNSS receivers without native ROS 2 drivers
motor controllers accessed through historical packet formats and fixed baud rates
older SLAM pipelines expecting /tf and /odom semantics from ROS 1-era packages

Key technical practices

Good legacy support is deliberate. It should be documented, tested, and bounded. Otherwise, compatibility work becomes technical debt that blocks future upgrades.

On robotics projects, the most useful practices are:

Interface freezing – keep message types, frame names, and topic contracts stable where possible
Containerization – isolate old dependencies in Docker images to avoid host OS conflicts
Protocol adapters – convert vendor serial or CAN formats into standard ROS 2 messages
Regression tests – verify odometry, sensor timestamps, and command latency after every change
Lifecycle planning – define which parts are temporary compatibility layers and when they will be retired

# Example compatibility note for a legacy sensor node
legacy_lidar_bridge:
  ros__parameters:
    serial_port: /dev/ttyUSB0
    baudrate: 115200
    frame_id: laser
    publish_rate_hz: 10.0
    output_topic: /scan

Risks and trade-offs

Legacy support improves continuity, but it has costs. Older dependencies may stop receiving security fixes. Vendor SDKs may support only outdated kernels or libc versions. Timing behavior may also degrade when a compatibility wrapper adds serialization or bridge latency. For navigation, even small changes matter. A delayed LiDAR stream or inconsistent IMU timestamps can reduce SLAM accuracy and planner stability.

There is also a documentation risk. If an old payload works only because of an undocumented patch, the integration becomes fragile. This is common in academic environments where one-off scripts survive longer than expected.

For Leo Rover and Raph Rover deployments, the practical rule is simple: preserve old interfaces only when they support a concrete operational or research need. If a legacy component blocks ROS 2 maintenance, prevents reproducible builds, or creates untestable behavior, replacement is usually safer than indefinite support.

Normative references and technical basis

The concept of legacy support is not defined by a single robotics standard, but its implementation relies on formal interface and software conventions. In ROS environments, the most relevant references are ROS 2 documentation, the ROS Enhancement Proposal system, and package-level interface definitions. REP-103 standardizes units and coordinate conventions. REP-105 defines coordinate frames for mobile platforms. These are important because legacy compatibility often fails at the level of frames, timestamps, or units rather than at the level of raw connectivity.

For practical engineering, the authoritative sources are:

ROS 2 documentation on nodes, parameters, lifecycle, DDS, and migration from ROS 1
REP-103 and REP-105 for unit and frame consistency
vendor specifications for LiDAR, IMU, camera, GNSS, and motor controllers
Linux and Ubuntu package support matrices for target compute hardware
platform documentation at docs.leorover.tech for Leo Rover integration details