OTA update (Over-the-Air)

OTA update – definition

An OTA update, or Over-the-Air update, is the remote delivery, verification, installation, and confirmation of software or firmware on a connected device. In mobile robotics, OTA updates are used to maintain the operating system, ROS 2 packages, container images, sensor drivers, robot configuration files, microcontroller firmware, and security certificates without requiring physical access to the UGV.

The term does not require a specific network protocol. An update may be transferred through Wi-Fi, Ethernet, cellular connectivity, or another network connection. In practice, OTA describes the remote update workflow rather than the transport medium. A complete OTA system must protect software integrity, authenticate update metadata, prevent downgrade attacks, preserve a recoverable system state, and report the result to an operator or fleet-management service.

For a UGV such as Leo Rover or Raph Rover, OTA updates are relevant because the robot may operate in laboratories, warehouses, agricultural sites, construction areas, or inspection environments where physical access to the compute unit is limited. The update process must not leave the platform in an undefined motion state or interrupt a mission without supervision.

OTA updates in ROS 2 mobile robots

ROS 2 does not define a built-in OTA update standard. ROS 2 manages distributed robot applications through nodes, packages, launch files, parameters, services, actions, and DDS communication. The operating system and firmware update mechanism is normally implemented outside the ROS 2 graph.

A robotics OTA workflow commonly updates several independent layers. Each layer has different compatibility and rollback requirements.

Base operating system: Linux packages, kernel updates, bootloader configuration, system libraries, and device drivers.
ROS 2 workspace: ROS packages, launch files, parameter YAML files, URDF/Xacro descriptions, Nav2 configuration, and custom nodes.
Container image: A versioned Docker or OCI image containing a fixed ROS 2 runtime and application dependencies.
Sensor firmware: Firmware for LiDARs, depth cameras, GNSS/RTK receivers, motor controllers, or embedded safety devices.
Security material: TLS certificates, VPN credentials, DDS security governance files, and SROS 2 keystores.

Before an update is installed, the robot should enter a safe operational state. For a differential-drive UGV, this normally means stopping velocity commands, disabling autonomous navigation, confirming that no ROS 2 node is publishing unsafe motion commands, and validating battery power or external power availability.

ROS 2 applications commonly use geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped for velocity control. An OTA agent should not assume that stopping one node is sufficient. It must account for all command sources, including teleoperation, Nav2, custom mission software, and hardware watchdogs.

OTA architecture and update states

A robust OTA architecture separates update metadata from update payloads. Metadata identifies the approved software version, target hardware, hash values, signatures, expiration time, and dependency rules. The payload is the actual package, image, firmware binary, or container artifact.

The update state machine should be explicit and observable. A typical implementation includes the following stages.

Discovery: The robot retrieves signed metadata and checks whether an approved update exists.
Download: The payload is transferred over an authenticated network connection.
Verification: The client checks signatures, target identity, cryptographic hashes, version constraints, and hardware compatibility.
Staging: The update is written to an inactive partition, staging directory, or inactive container slot.
Activation: The robot reboots or restarts selected services in a controlled maintenance window.
Health check: The client verifies boot status, ROS 2 service availability, hardware communication, and application readiness.
Commit or rollback: The new version becomes active only after the health check succeeds. Otherwise, the system returns to the previously known-good version.

Dual-root filesystem designs are often called A/B updates. Slot A runs the active system while slot B receives the new image. After reboot, the bootloader starts slot B. If the health check fails, the system can revert to slot A. This approach is more resilient than replacing files in the active root filesystem.

Key OTA parameters for UGV deployments

OTA systems should expose measurable deployment data. These values allow an operator to determine whether a robot is running an approved software baseline and whether an update completed safely.

Parameter	Purpose	Example implementation
Artifact version	Identifies the deployed software or firmware release.	Semantic version, Git commit SHA, OCI image digest.
SHA-256 digest	Verifies payload integrity after download.	Digest stored in signed update metadata.
Target hardware ID	Prevents installation on an incompatible compute unit or controller.	Board model, architecture, minimum bootloader version.
Rollback index	Prevents installation of an older vulnerable release.	Monotonic version counter stored in protected state.
Health-check timeout	Defines when a new image is considered non-functional.	Boot confirmation plus ROS 2 node and hardware checks.
Update result	Records installation, rollback, and diagnostic status.	Structured log, telemetry event, or fleet API response.

Example ROS 2 deployment manifest

The following YAML file is an example of application-level metadata. It is not a ROS 2 standard and should be signed or delivered inside a signed OTA artifact. The image digest should be treated as immutable, unlike a mutable tag such as latest.

robot:
  platform: leo-rover
  ros_distro: humble
  application_version: "2.4.1"
  container_image: "registry.example.org/ugv/navigation@sha256:REPLACE_WITH_DIGEST"
  required_nodes:
    - robot_state_publisher
    - nav2_controller
    - nav2_bt_navigator
  update_policy:
    require_stationary_robot: true
    require_external_power: false
    rollback_on_health_check_failure: true
    health_check_timeout_seconds: 120

OTA updates on Leo Rover and Raph Rover

Leo Rover uses an onboard Raspberry Pi-based compute unit. OTA updates can therefore cover the operating system, ROS 2 workspace, Docker images, network configuration, and software used for sensor integration. Leo Rover is not autonomous out of the box, so an OTA deployment must preserve the compatibility of the installed navigation stack, localization method, sensor drivers, and motor-control interface.

For example, an update of a Nav2 configuration may alter costmap parameters, velocity limits, transform frames, or controller plugins. Such a change should be validated in simulation and on a controlled test route before deployment to a field robot. Updating a ROS 2 package without updating its dependent parameter files can produce startup failures or unsafe navigation behaviour.

Raph Rover can carry heavier payloads and additional compute hardware. Its OTA design may therefore include separate update channels for the main computer, an edge GPU computer, sensor payloads, and embedded controllers. These components should not be updated as one unverified bundle unless their compatibility is explicitly tested.

Security and standards

Secure OTA systems require cryptographic verification before installation. Transport encryption alone is insufficient because a compromised server or storage location could still distribute a malicious artifact. The update client must verify signed metadata and content hashes locally.

The Uptane Standard defines a security framework for software updates in ground vehicles and other distributed systems. Uptane builds on The Update Framework (TUF) and uses signed roles, delegated metadata, expiration rules, and attack-resilience mechanisms. Its principles are applicable to UGV fleets even when an implementation does not use the full Uptane reference architecture.

At the ROS middleware layer, ROS 2 security is based on DDS Security concepts. The ROS 2 security documentation describes authentication, access control, and encryption through SROS 2 and DDS security artifacts. OTA procedures must handle these artifacts carefully because replacing certificates or governance files can prevent ROS 2 nodes from communicating after reboot.

For embedded Linux systems, tools such as RAUC, SWUpdate, Mender, and OSTree can implement signed image delivery and rollback. The selected tool should support the storage layout, bootloader, architecture, and recovery requirements of the robot compute unit.