Skip to main content
Run can.setup once on a new computer, and again whenever you add or move a CAN adapter. It finds each attached adapter, gives it a fixed interface name and brings it up.

​
Before you run it

  • Plug every CAN adapter into the computer.
  • Power on Axol, Jelly and Mantis. can.setup identifies each adapter by the devices that answer on it, so an unpowered device can’t be identified.
  • Stop any operation that is using the robot. can.setup resets every attached CAN link.

​
Run it

can.setup asks for sudo when it needs it. It does the following:
  1. Installs the gs_usb kernel driver if the kernel lacks it. See can.driver.
  2. Identifies each adapter and pins it to its interface name by USB serial number.
  3. Writes udev rules, a startup script and a hotplug service, so the interfaces come up on every boot and whenever an adapter is plugged back in.
  4. Resets each link to 1 Mbit/s and brings it up.
  5. Downloads this Axol’s factory calibration into ~/.almond/factory_calibration.json. If the computer is offline, it keeps the copy it already has.
Every bus is optional. can.setup configures whatever it finds. The Mantis Hub is the same dual-channel board as the Axol Hub. Axol and Mantis can be set up together in one run, and setting up one never removes the other. The Jetson’s built-in CAN controller is left alone.

​
Jelly lift wiring

Jelly’s lift controller can be wired in either of two ways:
  • On a separate adapter. can.setup names that adapter can_alm_axol_c.
  • On the wheel bus. The lift shares can_alm_axol_b with the four wheel motors, and there is no can_alm_axol_c.
can.setup detects which wiring you have. axol teleop, lift.home, lift.goto and diag.lift-cycle use can_alm_axol_c when it exists and can_alm_axol_b otherwise. If you move the lift onto the wheel bus, run axol can.setup again. You don’t need can.setup to drive Jelly, because axol teleop brings Jelly’s interface up itself. Running it gives the adapter a name that stays the same across reboots. The control panel also pins a powered Jelly’s adapters when it detects them.

​
How adapters are identified

If an adapter that was set up before stays silent, it keeps its previous name. If a dual-channel hub is silent, can.setup asks whether it is Axol or Mantis, or whether to skip it.

​
If something goes wrong

  • Secure Boot blocks the driver. can.setup stops before it changes the driver. Sign and enroll the module, or use a newer kernel whose built-in gs_usb driver supports your adapters. See can.driver.
  • TX queue stalled after an emergency stop. Unplug the Axol Hub and plug it back in before you run anything that moves the arms.
  • The hub drops off USB on a Raspberry Pi 5 (disabled by hub (EMI?) in dmesg). can.setup already turns on the Pi 5 USB noise filter. If it keeps happening, add a ferrite choke or shielding to the hub’s USB cable, or put a small powered USB hub between the Pi and the Axol Hub.

​
Recovery after an emergency stop

When motor power is cut mid-motion, the commands that were in flight stay queued. If they were sent when power returns, the arm would jump to the pose it was commanded to when power died. Axol clears those commands and holds the arm still until the bus answers again. Before any arm bring-up enables a motor, it also checks the queue and refuses to enable if old commands remain. To clear the queue from a manual axol serve or axol teleop, the computer needs the permissions that axol provision installs. Without them the old commands stay queued until you unplug and replug the hub. Every arm bring-up updates the Axol Hub to the firmware that ships with axol. See hub.flash.