Skip to main content
Installs the parts of Axol that 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.
Run it from your normal login. It asks for your 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.
This file applies only to a normal ssh login. Tailscale SSH, terminals opened over it, and systemd units without LimitRTPRIO don’t get it.When provision runs in such a session, it raises the limit on your shell and the terminal above it, such as tmux or an IDE, so new commands and terminals from there get it. The fix lasts until those processes exit. If provision can’t do this, it prints two ways out:
  • Reconnect over ssh.
  • Run sudo prlimit --pid $$ --rtprio=20:20 in that shell.
axol-rt keeps real-time priority in any session, and so does anything run as root.

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
See 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, provision reports the problem instead of rebooting again.
  • A provision started by axol serve never 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.