Choosing a USB-to-CAN adapter for robot joints

By Tolerance Labs engineering team · Updated 18 October 2026

The USB-to-CAN adapter sits between your computer and every joint on the bus. Its driver, latency and channel count decide whether your control loop runs at the rate you planned.

Classic CAN or CAN FD

If any joint on a bus uses CAN FD, the adapter must support CAN FD at the joints’ data-phase bit rate, commonly 2 or 5 Mbit/s. An FD adapter also handles classic CAN 2.0 frames. A classic-only adapter on an FD bus cannot even listen: it treats FD frames as errors and disturbs them, as wiring a CAN bus for robot joints explains.

Two more FD details matter. ISO CAN FD and the earlier non-ISO CAN FD use different CRC fields and cannot share a bus; most current parts use ISO, and many adapters can switch. And you must be able to set the bit timing, including the sample point, for both phases, because the joints and the adapter must agree on them.

Driver support on Linux

On Linux, most robot software talks to CAN through SocketCAN, the kernel’s CAN network layer. An adapter with a SocketCAN driver appears as a network interface such as can0, and any SocketCAN tool or library can use it. You bring it up with a command such as ip link set can0 up type can bitrate 1000000, and add dbitrate 5000000 fd on for CAN FD. Adapters reach SocketCAN, or fail to, in these ways:

Test the adapter’s driver on the kernel that the robot will run, including any real-time kernel. ros2_control for joint modules depends on this, because many hardware interfaces for CAN joints open a SocketCAN socket.

Latency and USB polling

USB moves data in scheduled transfers, in 1 ms frames on full-speed USB (12 Mbit/s) and 125 µs microframes on high-speed USB (480 Mbit/s). A frame received from a joint can wait up to about one USB frame before it reaches the driver, depending on the adapter firmware and host controller. Adapters that gather several CAN frames into one USB transfer raise throughput but can hold a frame until the batch fills or a timer runs out.

Typical round trips for a command and its reply, measured from the application, are a few hundred microseconds to about 2 ms for full-speed adapters, and less for high-speed ones. Operating system scheduling adds jitter, especially on a kernel without real-time support.

If the loop waits for each joint’s reply before it sends the next command, the round trips add up: six joints at 1 ms each take 6 ms per cycle. Send all commands first, then collect the replies. Measure the round trip on your own system, and use the worst case over several minutes, not the average.

Throughput: a worked example

The bus must have room for the frames the control loop needs, and the adapter must carry them. A classic CAN frame with 8 data bytes takes roughly 110 to 130 bits on the wire, depending on bit stuffing. Use 130 bits for planning. At 1 Mbit/s, one bus then carries at most 1,000,000 ÷ 130 ≈ 7,700 frames per second. Teams commonly plan for 50% load or less.

Example: a 12-joint quadruped runs its joints at 500 Hz, with one command and one reply per joint per cycle.

• Frames per second for the robot: 12 joints × 2 frames × 500 Hz = 12,000 frames/s.
• On one bus: 12,000 ÷ 7,700 ≈ 1.56, or 156% load. It cannot work.
• On four buses of three joints: 3 × 2 × 500 = 3,000 frames/s per bus. Bus load is 3,000 × 130 = 390,000 bit/s, or 39% of 1 Mbit/s.
• At 1 kHz, the same four buses carry 6,000 frames/s each, or 78% load, which is more than most teams accept. Use six buses of two joints, or CAN FD.
• The adapters must then pass 12,000 frames/s at 500 Hz, or 24,000 frames/s at 1 kHz, through USB without dropping any.

CAN FD helps twice: an 8-byte frame at 1 and 5 Mbit/s typically takes roughly half the bus time of a classic frame, and a 64-byte frame can carry commands for several joints if the protocol allows it. CAN, CAN FD, EtherCAT or RS485 compares the bus options.

Ask the adapter maker for the sustained frame rate per channel with all channels busy, not only the bit rate. Then test it: generate traffic with cangen, log it on a second interface with candump, and look for dropped frames and overruns.

Isolation, termination and connectors

• Galvanic isolation. An isolated adapter separates the computer’s ground from the bus ground. Choose one whenever the computer and the robot have separate supplies, such as a lab PC and a robot on its own battery. Without it, a ground fault between them can damage the adapter, the USB port or a joint.
• Termination switch. The adapter usually sits at one end of the bus, so it needs a 120 Ω terminator there. A switch on each channel lets the same adapter also tap onto a bus that is already terminated. Check its position first when you debug.
• Connector. Many adapters use a 9-pin D-sub connector. The common pinout puts CAN_L on pin 2, ground on pin 3 and CAN_H on pin 7, but check each maker’s drawing. Screw terminals are easier for short robot harnesses.
• Error reporting. The adapter should pass error frames, error counters and bus-off events to the driver; otherwise a wiring fault looks like a silent joint. A listen-only mode lets you log a bus without acknowledging frames.

Channels and timestamps

One adapter with two or four channels gives one bus per leg or per arm from a single USB port, with one shared USB link and one clock. Several single-channel adapters spread the load over more USB ports, but each has its own clock. Keep cameras and other heavy devices off the adapter’s USB host controller.

Hardware timestamps are taken by the adapter when each frame arrives, typically with microsecond resolution. Host timestamps include USB and scheduling delay. To measure loop jitter or the order of events across buses, use hardware timestamps, from one multi-channel adapter so that they share a clock.

Windows and Linux tools

Joint makers’ setup tools, for IDs, bit rates and calibration, often run only on Windows with certain adapters, while robot software usually runs on Linux. Check both, or plan for two adapters.

If a joint maker supplies an adapter for its tool, ask whether it also works as a SocketCAN interface on Linux. Firmware updates often use the same tool; see updating robot joint firmware.

Checklist

• Classic CAN or CAN FD to match the joints, with ISO CAN FD and the data-phase rate confirmed.
• Adjustable bit timing and sample point for both phases.
• A SocketCAN driver tested on your kernel, including any real-time kernel.
• Round-trip latency measured on your system, worst case over several minutes.
• Bus load per channel below about 50% at your control rate, within the adapter’s sustained rate.
• Isolation where grounds differ, a termination switch per channel, and a known connector pinout.
• Error frames, error counters and hardware timestamps passed to the driver.
• Support in the joint maker’s setup and firmware tools, on the operating system you will use.

Browse drivers and accessories and power and control cables, and compare joints by bus in Robot Parts.