JetPack 7.2 now supports Jetson Orin with Jetson Linux 39.2; use this robotics deployment checklist for power, containers, security. Read now.
Start from the JetPack and Linux base
Treat the platform stack as fixed before you ship application code. JetPack 7.2 with Jetson Linux 39.2 is the supported path for Jetson Orin, so pin your build images, flash tools, and host SDK to that combination and document them in the same place you track firmware. Rebuild kernels, device trees, and drivers only from that baseline so field units do not drift into untested combinations. For robotics fleets, separate the BSP image from your app layer: flash a golden system image once, then layer containers or install packages on top so OS updates and app updates can move on different schedules.
Confirm boot media, storage layout, and recovery paths on a spare module before the first production flash. Know how you will re-image a unit that fails mid-update, where logs live after a bad boot, and which interfaces must come up for remote recovery. Edge robots rarely have a desk next to them; a documented recovery path is part of the product.
Power and thermal design before model tuning
Power budget and cooling decide whether inference is reliable under load. Map the full draw of the module plus cameras, motors, radios, and sensors, then size the supply and cable harness with headroom for startup spikes and brownouts. Prefer staged power-up so high-draw actuators do not collapse the rail that feeds compute. Set a clear power mode for each duty cycle—idle, navigation, peak perception—and test transitions, not only steady state.
Thermal paths matter as much as watts. Mount the module so heat can leave the enclosure, verify airflow or conduction under real ambient conditions, and throttle or shed non-critical workloads when temperatures climb. In robotics, a silent thermal trip looks like a random hang; log temperature and power state next to inference latency so field failures are diagnosable.
Containers for reproducible edge workloads
Containers keep CUDA, runtime, and application dependencies aligned with the JetPack base without baking everything into the root filesystem. Build images on a matching architecture, pin base layers to the same JetPack lineage as the device, and keep models and configs as mounted volumes or versioned artifacts so you can roll models without rebuilding the whole stack. Prefer multi-stage builds that leave only runtime libraries on the device, and keep secrets out of the image layers.
- Define one service unit or compose file per process boundary (perception, planning, health, OTA agent).
- Set resource limits for CPU, memory, and GPU access so a leaky node cannot starve the robot stack.
- Ship a health endpoint and structured logs; restart policy should be explicit, not default-and-hope.
- Test offline start: cold boot with no network must still reach a safe operational state.
Security and fleet hygiene
Edge robots are networked computers with actuators. Lock down unused ports and services, require authenticated remote access, and keep the device identity (certificates or keys) unique per unit and rotatable. Sign OTA packages and verify them before apply; refuse partial updates that leave the system half-migrated. Separate network segments for sensors, compute, and external links when the architecture allows, and treat physical ports as attack surface—disable or restrict what is not needed in production.
Close the loop with a short pre-ship checklist: confirmed JetPack 7.2 / Jetson Linux 39.2 image, power and thermal soak under peak workload, container stack starting cleanly offline, signed update path verified, and credentials rotated from factory defaults. If any item fails, hold the unit. A short, enforced list prevents the class of field failures that no amount of model accuracy can fix.