Updates and rollback

Release discipline

Update the selected stack as a coherent set of images and configuration. Record the current stack version, immutable artifact identifiers, configuration revision and local changes first. A mutable latest or branch tag is not a reproducible rollback target.

The source branch matrix describes what current CI builds. A local feature branch is not automatically a published release. Pair robot configuration with compatible runtime images and Unity asset activation metadata.

Update workflow

1. Back up current configuration, saved overrides and required runtime data.
2. Read the target release's compatibility information for CPU architecture, JetPack/L4T and configuration.
3. Finish/stop active robot work and prepare the robot for service interruption.
4. In console HRSDK, check available updates/releases and select the intended compatible release. Configuration pull, container update and release switch are separate controls.
5. Follow the background task and inspect its final result/logs.
6. Verify selected configuration and all expected image/asset identifiers.
7. Perform read-only API/graph checks, then controlled audio/perception/Unity/hardware checks.
8. Keep the prior baseline until acceptance passes.

For CLI users, pulling a manifest's images does not itself set the configured startup version. Use the CLI configuration workflow and verify the selected release before starting. Avoid manually retagging individual images as an undocumented release switch.

Configuration changes

Review local Git changes before pulling configuration updates. Preserve calibrated assembly files and saved node overrides. A source update and a saved override can interact: compare effective runtime values after restart rather than assuming a source default won.

Environment scripts execute during startup. Review changes to env/*.sh, launch scripts and Compose alongside YAML/data changes. Do not resolve a conflict by replacing an entire robot-specific configuration tree with another robot's defaults.

Jetson and model updates

Perception updates must match host L4T/NVIDIA runtime. Rebuild/regenerate platform-specific engines when model/runtime requirements change. Test camera USB access, CUDA/TensorRT inference, actual output types and DDS across hosts. An amd64 smoke test does not validate this path.

Rollback

Stop the affected lifecycle owner, restore the recorded prior release selection and configuration, retain the required prior images/assets, and restart. If a data schema changed, restore the corresponding compatible database backup or follow the release's migration reversal; image rollback alone may be insufficient.

Recheck the same acceptance items used for the update. If the prior mutable image tag has moved, use the recorded digest rather than re-pulling that tag and assuming it is the old version.

Interrupted work

Retain task IDs and stage logs. Check whether an operation is still running before starting it again. A disconnected browser does not cancel server work. On daemon restart the task store marks previously running task records failed; installer-specific stage state may still allow resumption. Inspect that state before repeating installation or deleting partial downloads.

If only some containers/assets changed, compare the intended manifest with actual local images and activation paths. Restore a coherent baseline before returning to operation.

Evidence: console setup/release/container services, CLI manifest/start/pull code, current CI and perception platform policy. No robot updates were executed to validate this handbook.