Skip to main content
Pins the Jetson clocks the real-time loops depend on:
  • the strongest supported power mode — MAXN SUPER when it is present in the active /etc/nvpmodel.conf, otherwise MAXN (mode IDs vary by Jetson configuration) — which uncaps the clock ceiling the other two pins reach (nvpmodel otherwise caps how high the governor and engine clocks can go),
  • the NVENC / VIC / GPU engine devfreq nodes, so the camera relay’s hardware H.264 encode and the ZED SDK’s CUDA processing stay low-latency (the default devfreq governor scales them for throughput, which roughly triples per-frame encode time), and
  • the CPU governor, so the bursty IK loop isn’t underclocked.
And the real-time scheduling that keeps the camera and motor paths from contending:
  • The CAN adapters’ USB-controller interrupt is steered onto a CAN core. Both USB CAN adapters hang off one xHCI controller whose interrupt the Jetson otherwise delivers to CPU0 — a core the camera relay’s worker pool shares. Every motor reply crosses that CPU’s interrupt bottom half, and a real-time camera thread runnable there delays it: with the relay’s capture chain SCHED_FIFO, both arms faulted on missing feedback within seconds of arming. Moving the interrupt beside its consumer (the axol-rt bus loop pinned to that core, where no camera or dataset thread is ever scheduled) ends the coupling. The interrupt is resolved from the CAN interfaces’ USB bus each boot, never hard-coded; a warning names the manual echo N | sudo tee /proc/irq/<irq>/smp_affinity_list if it can’t be applied, and another if irqbalance is running and could undo it.
  • The Argus capture daemon (nvargus-daemon, every ZED X frame passes through it) runs SCHED_FIFO one notch above the relay’s capture threads, confined to the camera cores so it never lands on a control, IK, CAN, or interrupt core.
You don’t run this yourself: axol provision applies all of it as its last step, on whichever Jetson it runs on. These settings reset on every reboot, so the one-command install’s axol.service re-applies them at every boot with axol provision --boot (its ExecStartPre). axol jetson.setup is the same thing under its old name, kept for units written by older installers. It is not called from teleop / collect-data / serve — those entry points just run. Supported Jetsons: Orin NX 16GB (ZED Box), AGX Orin (32GB / 64GB / Industrial), and Thor T5000. The steps key off what the module exposes rather than its name — the power-mode names in its nvpmodel.conf, its engine clock nodes (Orin’s *.nvenc / *.vic / *.gpu, pinned min_freq = max_freq; on Thor the encoder is clocked by the GPU’s multimedia domain gpu-nvd-* and CUDA by gpu-gpc-*, which are switched to the performance governor as NVIDIA’s Thor power guide prescribes — their frequency files take the devfreq lock, which a JetPack 7.2 GPU hang has been seen to block on — while VIC keeps *.vic), and its online CPUs for where the interrupt and the camera daemon go. If changing the power-gating configuration requires a reboot, Axol declines the immediate reboot so it cannot interrupt an installation or robot session. It records the selected mode for NVIDIA’s nvpmodel.service to apply on the next natural boot; axol.service is explicitly ordered after that service before it re-pins the clocks.
NVIDIA classifies MAXN and MAXN SUPER as experimental, unconstrained modes and does not recommend sustained heavy workloads in them unless the module was flashed with the corresponding -maxn configuration and its more conservative thermal settings. Ensure the robot has adequate power and cooling and monitor thermal throttling during sustained local inference or training. Axol normally selects a named mode exposed by the active BSP configuration; on legacy or unreadable configurations it attempts NVIDIA’s conventional mode 0 and reports any rejection. It does not change the board’s thermal policy.
Best-effort and a no-op on non-Jetson machines. Everything here needs root: run as root, or you’ll be prompted for sudo once on a terminal; if escalation isn’t possible it logs the manual command and continues.
jetson.setup is the per-boot half. The install-time half is axol provision, which grants your login the rtprio allowance a manual axol serve / axol teleop needs to run its control loop and the camera relay’s capture chain SCHED_FIFO. Without both, the control loop refuses to start (set AXOL_ALLOW_CFS_CONTROL=1 to run degraded) and the camera relay falls back to SCHED_OTHER (camera capture threads stay SCHED_OTHER at startup), dropping exposures under load. Only PAM applies that grant, so a session over Tailscale SSH or a PAM-less systemd unit inherits a zero limit no matter how often you provision — axol provision reports whether the current session can actually use it.