uv tool install can’t manage: system packages, drivers, permissions and the axol-rt control core. Run it after you install or update axol. It is safe to run on any computer and to run again at any time.
sudo password once, for the steps that need root. Without a working sudo, it exits with a message.
What it installs
Steps that don’t apply to the computer, such as camera steps on a computer without a ZED SDK, are skipped.
On a computer without the ZED SDK at
/usr/local/zed, the pyzed and ZED GStreamer steps are skipped. The GStreamer steps are also skipped on computers that aren’t Jetsons. Everything else, including axol-rt, is installed on any Linux computer.
Exit codes
provision runs every step even when one fails, then reports what failed.
When
axol serve runs provision during an update, it exits 0 if only optional steps failed. The update still goes ahead, and the control panel shows the missing steps as a warning.
--require-rt is accepted for compatibility. provision already exits 1 when axol-rt fails.
If apt fails
provision never interrupts apt-get or dpkg, even if axol.service restarts. If an install fails, the log names the package dpkg couldn’t process. Repair it, then run provision again:
Real-time scheduling
The control loop needs real-time priority. Without it,axol teleop, collect-data, collect-dagger and run-policy stop with refusing to run without real-time scheduling, because the arms would hitch and lunge. The camera relay also logs camera capture threads stay SCHED_OTHER, and recordings may drop episodes under load. Set AXOL_ALLOW_CFS_CONTROL=1 to run without real-time priority anyway.
provision writes /etc/security/limits.d/50-axol-rtprio.conf, which takes effect at your next login. To check it, run ulimit -r. It should print 20.
Host tuning
Host tuning runs last. On a Jetson (Orin NX 16GB, AGX Orin, Thor T5000), it sets:- the maximum power mode
- fixed video encoder, GPU and CPU clocks
- the CAN adapters’ interrupt on a CAN core
- real-time priority for the camera service on the camera cores
jetson.setup for why each one matters. A Raspberry Pi 5 or a workstation needs no tuning. On every computer, provision logs which CPU cores each part of Axol uses, for example core layout: 14 cores online: CAN 12-13, control 2, IK 3, relay 4-5, recorder 10-11, camera 0-1,5-9.
Host tuning resets at every reboot.
axol.service reapplies it at each boot by running axol provision --boot, which runs only this step. axol jetson.setup does the same thing. You don’t need to run it yourself: after an update, axol provision and a fresh login are enough.When the control panel updates axol, its provisioning skips host tuning, because the service restart at the end of the update applies it.Reboots
Some steps take effect only after a reboot, such as a new ZED Box camera driver or a Jetson power mode change. When one of them runs,axol provision reboots the computer at the end of the run, which ends your SSH session.
- A run with failed steps never reboots. The reboot stays pending, so the next successful run reboots.
- If a reboot didn’t fix the step that asked for it,
provisionreports the problem instead of rebooting again. - A
provisionstarted byaxol servenever reboots by itself.
The hosted installer runs
provision --no-reboot, then provision --apply-reboot once the service is installed. The axol serve updater runs provision --no-reboot, then reboots instead of restarting the service, and only while no operation is running.
See Development install: Headset-video stack for when you’d run this by hand.