/diagnostics — open axol.almond.bot/diagnostics (or https://<axol-host>:8001/diagnostics on the LAN) while axol serve is running. Like the control panel, its layout is responsive and works from a phone or tablet.
Motor status
A card per motor (8 per arm) shows its status, temperature, bus voltage, and live position, refreshed by the server’s 1 Hz health ping. A motor reads OK whether enabled or disabled — only genuine error codes (over-temperature, lost comm, …) or an unreachable motor light up red. Clicking a card opens the fullmotor.info readout — model, firmware, control mode, gains, and live readings — without launching a CLI session.
The buttons in this section run the motor plumbing ad hoc: CAN setup for the hub provisioning command (can.setup), CAN enable for the adapter picker described below, Set CAN ID (motor.set-can-id), and zeroing via motor.set-zero-pos — Zero motor for a single motor, or Guided zeroing to walk joints of one arm against their end stops with step-by-step Continue prompts. Guided mode has the same joint checkbox picker as the ROM tests, so you can rezero just a subset (e.g. the wrist joints after swapping a motor).
The same section also carries the motor-servicing tools that used to require the vendor’s Windows software: Dump config (motor.dump-config) reads every configuration parameter from one motor — or all of them when the CAN ID is left blank — into the run log; Set config (motor.set-config) tabs between reading a single parameter and writing it; and Flash firmware (motor.flash) overwrites a MyActuator motor’s firmware from a .bin on the serve host. Restoring a saved snapshot stays on the CLI (motor.restore-config), since the browser can’t hand the server a snapshot file.
Choosing CAN adapters
CAN enable opens the CAN adapter picker: choose which arms are attached — one adapter is enough for a single arm — and each arm’s SocketCAN interface, either from the ones detected on the host or typed by name. The Axol hub’s persistently-named pair (can_alm_axol_l / can_alm_axol_r, created by can.setup) is the prefilled default; a generic adapter enumerated as can0 works just as well. Save & connect persists the mapping in the shared settings (robot.left_channel / robot.right_channel), brings the interfaces up, and (re)connects the robot link — reopen the dialog at any time to remap. The same picker is offered on the robot-link banner when the link is disconnected or failing.
The saved mapping then drives the whole dashboard: every diagnostic and calibration run launches against the configured interfaces automatically — no dialog asks for an interface name, and with a single arm configured the other arm is skipped everywhere (the ROM tests get the skip flag implicitly, and the single-arm tools pre-select the attached arm). On the CLI the same is done explicitly with the matching flags (--left-channel / --right-channel and --no-left / --no-right on the two-arm commands, --channel on the single-motor tools, can.enable --channels … for the bring-up).
Live telemetry
Position, velocity, and torque charts for the selected arm stream continuously at 10 Hz while the robot link is connected. The server keeps a 10-minute rolling buffer, so the charts backfill on page load. The filter row scopes all three charts: time window presets (30s–10m), arm, and per-joint toggles; scroll to zoom and drag to pan, which pins the view until you press Go live. Each chart’s header button expands it to full screen (Esc to exit) for a closer look. Telemetry is sampled by the idle robot link, which is the single owner of the CAN bus. While a diagnostic or operation owns the bus the stream pauses and the charts label the gap — history is kept, and streaming resumes as soon as the bus is released.Diagnostics
Each diagnostic —diag.rom-enable, diag.rom-disable, and the diag.zed-cable camera-cable check — is a card: click it, set parameters in the dialog, and hit Run. The ROM tests expose a joint checkbox picker so you can soak a subset (e.g. just the wrist joints). The card shows the running state, elapsed time, and the latest output line; completion lands as a notification, and the full log is kept with the run in the history below. The ROM tests hand the CAN bus over for the duration of the run; the camera-only ZED cable check leaves motor telemetry streaming.
On robots fitted with the powered cart’s telescoping lift, the lift’s lift.home calibration and lift.goto install-height move appear here as cards as well.
Motor-driving runs are fault-gated, but only for the motors they actually touch: a joint-subset or one-arm run (a wrist-only ROM soak, guided zeroing of selected joints, a single-motor tool) isn’t blocked by unreachable or faulted motors outside its scope — e.g. a bench arm with only some motors on the bus.
Hands-on steps — like clamping an item in the ROM grasp test — pause the run and surface a Continue button on the card with the instruction (e.g. “Position the item in the RIGHT gripper, then close it.”). The test waits for you and proceeds when you click, so nothing moves until you’re ready. Under the hood the diagnostic prints a [prompt] marker and blocks on stdin; the button writes a line back to it. (The motor.info / motor.health read set needs no action here — the motor cards above show it live.)
Powering the robot host off or rebooting it is done from the control panel’s Axol Host tile, which carries the Restart and Shut down buttons whenever a host is connected.
Run history
Every diagnostic test (the cards above — not the ad-hoc CAN/calibration buttons) is recorded as a run: command, arguments, duration, exit status, log, and the telemetry observed while it executed (persisted under~/.almond/diagnostics/runs on the serve host; the Clear button deletes the history). The list is paginated newest-first (10 runs per page). The ROM test additionally writes its own 5 Hz position/torque capture, since it owns the CAN bus while it runs — opening a run charts its capture with the same joint filter and zoom/pan as the live charts.