OTA updates and configuration management

1. Engineering problem

Updating robots remotely risks corrupting them: a partial download, a wrong version, or a map that does not match the software. Verification, compatibility checks and rollback make it safe.

2. When is this needed?

• Designing an update mechanism.
• Managing per-site configuration.
• After a bad update.

3. Selection and design decisions

Elements: integrity (compare a cryptographic hash of the downloaded artifact with the published one; a signature additionally proves who published it), compatibility (software requires specific configuration schema and map versions), atomic install (install the new version beside the old, switch, and keep the old for rollback), staged rollout (see the deployment guide) and configuration as code (versioned, reviewed, applied the same way everywhere). Remote access and updates must also be secured: the ROS 2 security documentation (SROS2) covers authenticated and encrypted DDS communication.

4. Advantages and disadvantages

• Signatures add key management and prevent tampering.
• Two slots cost storage and make rollback instant.
• Frequent small updates reduce risk per update and increase their number.

5. Requirements and constraints

• No installation without a verified artifact.
• A self-test after every update and an automatic way back.
• A record of what runs on each robot.

6. Architecture

build ─▶ sign and publish (hash) ─▶ robot downloads ─▶ verify ─▶ compatibility check ─▶ install to inactive slot ─▶ self-test ─▶ switch ─▶ report

7. Implementation

1. Publish artifacts with hashes (and signatures).
2. Verify on the robot before install (below).
3. Check compatibility with config and map.
4. Install atomically and self-test.
5. Report the version and roll back on failure.

import hashlib
package = b"robot-software 1.5.0 payload"
published = hashlib.sha256(package).hexdigest()
received_ok, received_bad = package, package + b"x"
print("published sha256:", published[:16], "...")
print("download intact:", hashlib.sha256(received_ok).hexdigest() == published)
print("download corrupted:", hashlib.sha256(received_bad).hexdigest() == published, "-> do not install")
compat = {"software 1.5.0": {"config schema": {2, 3}, "map": {"v8"}}}
robot = {"config schema": 3, "map": "v7"}
for k, ok in compat["software 1.5.0"].items():
    print(f"{k}: robot has {robot[k]!r}, needs one of {sorted(ok)}", "OK" if robot[k] in ok else "-> update first or block the rollout")

Printed (checked by the site’s tests):

published sha256: 148fd194285dad50 ...
download intact: True
download corrupted: False -> do not install
config schema: robot has 3, needs one of [2, 3] OK
map: robot has 'v7', needs one of ['v8'] -> update first or block the rollout

Reading it: a download that matches the published SHA-256 is accepted and one with an extra byte is rejected; the compatibility check passes the configuration schema (version 3 is accepted) and blocks the update because the robot has map v7 where the software needs v8. The artifact is an invented example.

8. Real examples

• Fleet update: map v8 deployed first, then software 1.5.0 in stages with automatic rollback.

9. Failure scenarios

• Installing a truncated download.
• Software rolled out before its map.
• Configuration edited by hand on each robot.

10. Troubleshooting

1. Check the hash and signature first.
2. Check version compatibility.
3. Check the self-test log after a failed update.

11. Validation

• The verification example prints the lines shown (executed by the site tests).
• A deliberately corrupted artifact is rejected and a failed self-test triggers rollback.

12. Engineering checklist

• Hash verified
• Compatibility checked
• Atomic install
• Self-test and rollback
• Versions reported
• Secure channel

13. Further references

• ROS 2 Jazzy, Introducing ros2 security: docs.ros.org (the page exists and was not read in detail). Hash verification is standard practice (SHA-256).

Related on FixTheRobot