Right to Repair & Hack

Right to Repair & Hack – definition

In mobile robotics, Right to Repair & Hack means that a robot platform can be inspected, repaired, modified, and extended by its owner or integrator without artificial technical or legal barriers. In practice, this covers access to spare parts, mechanical drawings, wiring information, software interfaces, firmware update procedures, and documented communication protocols. For UGV platforms, the term also includes the ability to replace sensors, change compute hardware, rebuild a drive module, and run custom software stacks such as ROS 2.

This is not a single formal standard like a ROS Enhancement Proposal. It is a design and support principle that can be verified through technical facts. Examples include whether the robot exposes standard ROS 2 interfaces, whether a damaged wheel motor can be replaced as a field service action, whether the platform accepts third-party payloads, and whether software is distributed under licenses that permit modification. In robotics research and education, this matters because a UGV is rarely used exactly as shipped. It is usually reconfigured for SLAM, outdoor testing, teleoperation, perception research, or sensor benchmarking.

For platforms such as Leo Rover and Raph Rover, Right to Repair & Hack is best understood as a combination of three layers:

Mechanical serviceability – access to chassis parts, fasteners, wheel modules, sensor mounts, and enclosure elements.
Electrical openness – documented power rails, connectors, buses such as USB, UART, I2C, CAN, and safe methods for integrating external devices.
Software openness – ROS 2 compatibility, package-level customization, documented topics, frames, parameters, and support for standard Linux development workflows.

How the concept applies to UGV platforms

On a mobile robot, repairability and hackability have direct operational impact. A UGV used in a lab or field trial will often suffer wheel wear, cable damage, sensor replacement, enclosure rework, or compute upgrades. If the platform is closed, the entire test program can stop because one undocumented component fails. If the platform is open, the failed part can be replaced and the software stack can be rebuilt with minimal downtime.

In ROS 2-based systems, hackability also means the robot does not require a proprietary end-user interface for core functions. Instead, standard interfaces can be used for integration and debugging. Typical examples are:

/cmd_vel with message type geometry_msgs/msg/Twist for velocity commands.
/odom with nav_msgs/msg/Odometry for wheel odometry output.
/tf and /tf_static for coordinate transforms defined according to REP 105.
sensor_msgs/msg/Imu, sensor_msgs/msg/LaserScan, or sensor_msgs/msg/Image for sensor integration.

These interfaces are important because they reduce vendor lock-in. A researcher can swap a 2D LiDAR for a depth camera, change the localization method, or move from teleoperation to Nav2 without rewriting the whole robot stack.

Practical indicators of repairability and openness

The term can be vague unless it is tied to measurable properties. For robotics platforms, the following indicators are useful when assessing whether the Right to Repair & Hack is actually supported.

Area	Technical indicator	Why it matters in UGV work
Mechanical	Replaceable wheels, motors, brackets, covers, standard fasteners	Reduces downtime after field damage or drivetrain wear
Electrical	Documented voltage rails, current limits, connector pinouts	Allows safe addition of LiDAR, GNSS, cameras, radios, compute modules
Software	Linux access, ROS 2 packages, editable launch files and parameters	Enables custom autonomy, logging, perception, and simulation workflows
Interface level	Use of standard ROS messages and REP-aligned frames	Improves compatibility with Nav2, RViz, rosbag2, SLAM packages
Serviceability	Published documentation and spare parts availability	Makes the platform usable in semester-long or multi-year projects

Right to Repair & Hack in ROS 2 workflows

For a ROS 2 robot, openness is visible in the development workflow. A user should be able to inspect nodes, remap topics, modify parameters, record bags, and launch custom components without bypassing proprietary tools. This is especially relevant in ROS 2 Humble and newer distributions, where composition, lifecycle nodes, and DDS configuration are common parts of system integration.

A repairable and hackable UGV should support common diagnostic steps such as topic inspection and parameter changes from the command line.

ros2 topic list
ros2 topic echo /odom
ros2 node list
ros2 param list
ros2 doctor
ros2 bag record /odom /tf /scan /imu/data

It should also be possible to replace or extend a subsystem through launch configuration rather than vendor-specific binaries. A simple example is swapping a LiDAR driver or adding a new static transform.

/**:
  ros__parameters:
    use_sim_time: false
    frame_id: laser
    serial_baudrate: 115200
    angle_compensate: true

ros2 run tf2_ros static_transform_publisher \
0 0 0.18 0 0 0 base_link laser

If these operations are blocked, undocumented, or dependent on cloud authorization, the platform is technically difficult to repair and modify.

Context for Leo Rover and Raph Rover

On Leo Rover, the Right to Repair & Hack is relevant because the platform is commonly used in education, prototyping, and research. Leo Rover uses a Raspberry Pi-based onboard compute unit and supports ROS 2. It is a four-wheel skid-steer UGV with an IP54-rated enclosure. This makes it suitable for mobile robotics experiments, but not autonomous navigation out of the box. Users typically add their own navigation stack, sensor configuration, and autonomy logic.

In practical terms, a Leo Rover user may want to:

replace a damaged wheel or drivetrain component after outdoor testing,
mount a 2D LiDAR, depth camera, or RTK GNSS receiver,
change the ROS 2 launch setup for teleoperation, SLAM, or Nav2,
add Docker-based deployment or CI checks for custom packages.

On Raph Rover, the same principle applies at a larger scale. Because Raph Rover is intended for higher payloads, users often integrate heavier sensing or compute equipment. This increases the need for documented power budgets, mounting interfaces, cable routing, and software portability. A high-payload UGV is often used as a carrier for custom perception stacks, inspection payloads, or outdoor localization experiments. If repair and modification are restricted, integration cost rises quickly.

Limitations and trade-offs

Right to Repair & Hack does not mean that every component is user-serviceable without risk. On a UGV, changes to power distribution, battery systems, motor drivers, sealing, or EMC-sensitive wiring can reduce reliability or safety. A modified IP54 enclosure may no longer maintain its original protection level. A new sensor can exceed available current on a regulated rail. A custom ROS 2 node can also break timing assumptions in the control loop.

For that reason, repairability must be paired with engineering discipline. Typical checks include supply voltage range, peak current draw, CPU and memory headroom, network bandwidth, thermal load, and frame consistency under REP 103 and REP 105. In short, openness enables modification, but does not remove the need for validation.

Normative references and technical sources

The term itself is broader than ROS, but its implementation in robotics can be grounded in existing technical references. The most relevant sources are the ROS and ROS 2 interface conventions and hardware specifications from component vendors.

REP 103 – Standard Units of Measure and Coordinate Conventions.
REP 105 – Coordinate Frames for Mobile Platforms.
ROS 2 documentation – node, topic, parameter, launch, and lifecycle conventions at docs.ros.org.
Platform documentation – service and integration details for Leo Rover at docs.fictionlab.pl/leo-rover.

When evaluating a robot under this concept, the key question is simple: can an engineer inspect, replace, extend, and reprogram the system using documented interfaces and standard tools? In mobile robotics, that is the operational meaning of Right to Repair & Hack.