Skip to main content
Axol installs with a single command on the machine wired to the robot (typically a ZED Box / NVIDIA Jetson). It sets up the axol CLI and starts the web control panel as a background service — so once it finishes you can drive the robot from a browser, no terminal needed.
Working on Axol itself, or running without the install script? See Development install in the Advanced section for the clone + uv sync path.

​
Requirements

  • Axol set up (if you are installing for an Axol): mounted, powered, and wired to the compute. See Hardware Setup for your mount.
  • Linux with systemd (the installer registers a service).
  • (Optional) NVIDIA Jetson — a ZED Box Orin NX 16GB, an AGX Orin (32GB / 64GB / Industrial), or a Thor T5000 — required for the GMSL-attached ZED cameras used in data collection and policy inference. The installer runs on any Linux host; the Jetson-specific tuning steps simply no-op elsewhere.

​
ZED Box login

If you’re setting up a ZED Box from Almond, log in with the default credentials.
Change the default password after first login if the machine is reachable by anyone else.

​
Install

Run this on the robot machine:
On aarch64/Jetson, the pinned PyPI torch==2.10.0 wheel is CPU-only. Teleoperation, recording, and remote policy inference remain available, but local run-policy / collect-dagger CUDA inference requires an explicitly managed, JetPack-compatible Torch + Torchvision build (or use --device cpu). Reinstalling or updating replaces the environment, so re-apply such a custom build afterwards. Use remote inference until that platform-specific build is managed separately.
This one command:
  • Installs uv if it isn’t already present.
  • Installs the axol CLI from PyPI, pinned to the latest release (Python 3.13 bundled), with the lerobot, sim, and tracker extras. The reverse-engineered pyvut runtime remains a separate explicit VIVE Ultimate setup step.
  • Provisions the headset-video stack — the pyzed bindings, GStreamer/PyGObject, and the patched ZED source plugins — via axol provision. Each step self-gates and no-ops if the ZED SDK isn’t present.
  • Installs adb and the Quest udev rule (also via axol provision) for the optional Quest-over-USB controller link — no extra setup needed on the robot to use it.
  • On a factory-flashed ZED Box (Duo or Mini), upgrades an outdated GMSL camera driver to the release pinned for the ZED SDK (zed.driver, also via axol provision). The new driver only loads at boot, so when it upgrades, the installer reboots the host as its last step, which ends the SSH session. Reconnect in a minute or two. A no-op on any other machine.
  • On a Jetson (Orin NX, AGX Orin, Thor), applies the real-time tuning (jetson.setup) as the last provision step — power mode, clocks, CAN interrupt, camera daemon — and the systemd unit re-applies it at every boot.
  • Registers a root systemd service (axol.service) that runs axol serve at boot and restarts it automatically if it ever goes down. The service is pointed at the installing user’s home for dataset storage (HF_LEROBOT_HOME=~<user>/.cache/huggingface/lerobot), so collect-data datasets land in that account rather than /root even though the service runs as root. The recording commands also hand each dataset back to that user after every episode save, so you never need sudo to read, copy, or upload your own recordings. The installer also puts a default ACL on that folder, so anything the root service creates there, calibration files included, stays read/write for that user. The service is written before provisioning runs, so it still starts if a provisioning step fails. If only optional steps fail (Lighthouse tracking, the patched camera plugins, …), the installer finishes with a warning naming them; Axol works without them, and re-running the installer once the host is fixed adds them. If the required realtime core fails, the installer exits with an error; the control panel then shows the failing step and can apply a fixed release through Update.
When it finishes, open axol.almond.bot and connect to the machine — see the Web Control Panel guide. From then on, everything happens in the browser.
The service runs as root, so privileged steps (CAN bring-up, ZED daemon restarts) need no sudo password.
Both the hosted panel and direct CLI runs store datasets under ~/.cache/huggingface/lerobot (or the panel’s Dataset root setting), so recordings made from either are visible in both.

​
Staying up to date

Installs track GitHub releases, not individual commits. The server checks for a newer release in the background; when one exists, the control panel shows an update banner with the installed and latest versions (e.g. v0.1.2 → v0.1.3). Press Update to apply it — the server reinstalls at the new release tag, re-provisions, and restarts once idle. Nothing updates without that button press. Re-running the install command also upgrades to the latest release.

​
First connection

Open axol.almond.bot on any machine on the same network and enter the robot machine’s IP address. The very first time, your browser will warn about the self-signed certificate — accept it once (the certificate is shared between the control panel and the VR teleop link). See the Web Control Panel guide for the full connect flow. The control panel runs can.setup for you on first connect, so there’s no manual hardware setup on the install path.

​
Next steps

Teleoperation

Drive the robot from a VR headset.

Web Control Panel

The browser UI that drives every operation.