/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 shows its status, temperature, bus voltage, and live position, refreshed by the server’s 1 Hz health ping. Axol displays 8 motors per arm; Mantis displays the gripper at ID 8 on each side. 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 automatic Axol/Mantis hub provisioning (can.setup), CAN enable for the adapter picker described below, and the applicable motor tools. Axol also offers zeroing via motor.set-zero-pos; it is hidden for Mantis because its Damiao grippers self-calibrate.
The same section also carries 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, and Set config (motor.set-config) tabs between reading a single parameter and writing it. File-based operations stay on the direct CLI: motor.flash flashes a local firmware image, and motor.restore-config restores a local snapshot. The web API deliberately accepts neither path, so a remote request cannot make the root service read an arbitrary host file.
Choosing CAN adapters
CAN enable opens the adapter picker. Choose Axol or Mantis, which sides are attached, and each side’s SocketCAN interface from the detected list or by name. The defaults arecan_alm_axol_l/r for Axol and can_mantis_l/r for Mantis; a generic adapter such as can0 also works. Save & connect brings the interfaces up and reconnects the diagnostics link. If the selected named hub has not been provisioned yet, the server probes and configures it automatically; silent or ambiguous hardware still asks you to run interactive axol can.setup. Axol mappings are persisted in the shared robot-operation settings; Mantis mappings are diagnostics-only, so inspecting the rig cannot overwrite the robot’s saved channels.
The selected profile and saved mapping drive the whole dashboard: diagnostics and calibration runs do not ask for arm interface names, and with a single side configured the other side is skipped automatically. Mantis mode streams only the two grippers, scopes health and fault checks to them, injects --target mantis into supported helpers, and limits ROM and direct-CAN diagnostics to the gripper. Axol-only lift commands are hidden in Mantis mode; their dialogs can still expose the separate lift/base bus. On the CLI, choose Mantis with --target mantis; can.setup and normal can.enable bring up every configured hub automatically. Arm mappings remain explicit where supported (--left-channel / --right-channel and --no-left / --no-right on two-arm commands, --channel on single-motor tools, and can.enable --channels … for 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, the mounted-robot diag.lift-cycle test, and the diag.zed-cable camera-cable check — is a card: click it, set parameters in the dialog, and hit Run. Axol ROM tests expose a joint checkbox picker so you can soak a subset; Mantis ROM tests automatically use the gripper-only path. Lift cycle is Axol-only. To check the Mantis triggers against their grippers, run Teleoperation with Mantis selected — it needs only CAN and drives the grippers from the triggers whether or not tracking is set up. The card shows the running state, elapsed time, and latest output; completion lands as a notification and the full log is kept below. CAN-owning tests pause idle telemetry for their duration, while the camera-only ZED cable check leaves it 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. Lift cycle is the mounted-robot test: enter a positive cycle count, then it ramps the selected arm S1 joints to their mirrored 90° clearance pose, continuously verifies the held arm pose, and runs that many full down/up cycles. A successful run verifies the lift is up and stopped, smoothly returns only S1 to 0° rest while holding every other joint at its measured starting position, then disables the selected arm motors. It uses the named lift bus can_alm_axol_c by default; its dialog accepts another interface for custom mappings.
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.