JetPack 7.2 uses Jetson Linux R39.2.0 on Orin Nano; use this robotics edge AI checklist for deploys, tuning, Docker, and security. Read now.
Confirm the JetPack and Linux baseline before you flash
Start every Orin Nano deploy from a known software baseline. JetPack 7.2 ships with Jetson Linux R39.2.0; treat that pair as the contract for drivers, CUDA stack components, and board support. Mismatched BSP, container base images, or host libraries are a common source of “works on the bench, fails in the field” failures. Record the exact JetPack and Jetson Linux versions on each unit, and refuse to promote a build until flash, first boot, and a short smoke test all complete on hardware that matches production.
For robotics fleets, pin the same baseline across development boards, CI runners, and field units. When you must diverge for a pilot, document the delta and re-validate inference, camera pipelines, and real-time paths before you scale. Version drift is easier to prevent at flash time than to debug after models, sensors, and orchestration are already layered on top.
Deploy and tune for edge workloads, not laptop defaults
Edge AI on Orin is constrained by power mode, thermal headroom, and I/O latency as much as by raw compute. Choose a power mode that matches your duty cycle, then verify sustained performance under load—idle benchmarks hide throttling that shows up after minutes of continuous inference. Prefer fixed clocks and explicit resource limits for latency-sensitive control loops; leave opportunistic turbo for batch or offline jobs where variance is acceptable.
Treat model packaging as part of the deploy checklist: convert and optimize models on the target stack, store engine or serialized artifacts with the app version, and gate releases on a fixed set of sample inputs. Measure end-to-end path latency (sensor → preprocess → inference → postprocess → actuator or network), not only model runtime. If a stage dominates, fix that stage before chasing kernel-level micro-optimizations.
- Flash and verify JetPack 7.2 / Jetson Linux R39.2.0, then lock the image identity in inventory.
- Set power mode, fan or thermal policy, and resource limits before performance sign-off.
- Ship prebuilt inference artifacts for the target stack; rebuild only when the stack or model changes.
- Run a soak test under realistic sensor and network load before marking a unit production-ready.
Package with Docker so runtime matches the device
Docker helps when base images, CUDA-related libraries, and application dependencies match the Jetson Linux generation you flash. Build multi-stage images on or for Orin, not only on x86 with a vague “compatible” tag. Mount model weights and config as versioned volumes or layers so you can roll models without rebuilding the whole stack when the runtime stays stable. Keep privileged access and host network modes to the minimum your sensors and GPU access actually require.
CI should build the same image tags that field units pull. Tag by app version plus JetPack/Linux baseline so you never pull a container built for a different BSP. Health checks should cover GPU visibility, model load, and a minimal inference call—not only process uptime.
Harden the device as part of the same checklist
Robotics edge nodes sit on factory floors, vehicles, and remote sites; treat them like production servers with extra physical risk. Disable unused services, replace default credentials, enforce SSH key auth or a managed identity path, and restrict outbound traffic to update and telemetry endpoints you control. Sign or checksum update bundles and require verified images before apply. Separate developer debug access from production accounts so a single leaked key does not own the fleet.
Log enough to diagnose inference and connectivity failures, but avoid storing raw camera streams or secrets on disk by default. Encrypt at rest where the platform and threat model justify it, rotate credentials on provision, and plan a wipe-or-reflash path for decommissioned Orin Nano units. Security is not a post-deploy add-on: if it is not in the checklist that gates “ready for field,” it will not be consistent across the fleet.