Is CAN FD backward-compatible with classic CAN?

Physically yes — same twisted pair and transceivers — but framing differs. A CAN FD node can be configured to talk classic CAN, but a classic-CAN-only controller cannot decode FD frames. Confirm which variant your master supports and set matching bitrates on both arbitration and data phases.

Can I put a CAN component on an EtherCAT machine?

Yes, through a CAN-to-EtherCAT gateway, but you add cost, a point of failure, and latency. If most of your components are CAN, question whether EtherCAT is the right machine bus at all.

Why is EtherCAT rare on Chinese hands and actuators?

These components grew out of the research/legged-robot world, where CAN and open SDKs won on cost and bring-up speed. EtherCAT lives in the industrial-arm and factory-cell segment; you'll see it more on precision arm joints than on QDD modules or hands.

How many CAN nodes can share one bus?

Roughly 110 per segment before transceiver loading and timing force you to split the bus or drop the bitrate. In practice, keep segments short, terminate both ends at 120 Ω, and budget bandwidth per node at your target loop rate.

What bus should tactile and force sensors use?

Most F/T and tactile devices ride CAN or a dedicated fast link; vision-based tactile sensors often use USB for the image stream. Match the sensor's output rate to your loop — a fast sensor on a slow or saturated bus gives you stale data, not fast data.

Is RS-485 obsolete for robotics?

No — it's fine for a single hand or a simple actuator on a PLC/UART, and it runs long cable distances cheaply. It just lacks CAN's arbitration and ecosystem, so it rarely scales to a full multi-joint limb.

EtherCAT vs CAN FD in Robot Components: What Integrators Should Spec

The four buses at a glance

	EtherCAT	CAN FD	RS-485	USB (2.0/3.x)
Raw bandwidth	100 Mbit/s full-duplex	~2–8 Mbit/s data phase, 64-byte frames	~100 kbit/s–10 Mbit/s (falls with length)	480 Mbit/s (HS) to multi-Gbit/s
Determinism	Hard real-time; sub-µs jitter with DC sync	Good; priority-arbitrated, low jitter at modest load	Depends entirely on your protocol (often Modbus)	Not deterministic; host-polled
Typical loop rate	1–10+ kHz across many axes	1 kHz realistic per bus segment	100 Hz–1 kHz	Best-effort
Topology	Line/ring, daisy-chained	Multi-drop bus, 120 Ω terminated both ends	Multi-drop bus, terminated	Point-to-point (hub/tree)
Nodes	65,535 (practically hundreds)	~110 per segment (transceiver-limited)	32 unit loads (256 with modern drivers)	127 per host controller
Cabling	Standard Cat5e/shielded Ethernet	Twisted pair + ground	Twisted pair	USB cable (short runs)
Cable length	100 m/segment	~40 m @ 1 Mbit/s, less at higher rates	Up to ~1,200 m at low rates	≤5 m (2.0), less at 3.x
Master cost	High (dedicated master card/stack)	Low (MCU peripheral, USB-CAN dongle)	Very low (any UART)	Built into any PC
Where it fits	Industrial arms, multi-axis cells	Legged robots, hands, actuators, sensors	Budget/simple devices	Cameras, LiDAR, config

What each spec line actually means for you

Bandwidth

Bandwidth is the least interesting number for a control bus and the most over-weighted in sales sheets. A 12-DOF hand streaming position, current and a handful of tactile channels at 1 kHz needs far less than CAN FD delivers. EtherCAT's 100 Mbit/s matters when you're moving high-resolution force/torque and dual-encoder data across many axes on one wire — a 6-axis industrial arm plus its wrist sensor. USB's headline gigabits are real but irrelevant to a servo loop; they exist to move camera frames and point clouds.

Determinism and latency

This is the number that decides whether your control loop is stable. EtherCAT is hard real-time: distributed-clock sync keeps jitter in the sub-microsecond range, which is why it dominates precision multi-axis motion. CAN FD is deterministic enough for the vast majority of research and humanoid work — arbitration is priority-based, so your critical torque command wins the bus, and a well-loaded segment holds 1 kHz comfortably. RS-485 has no inherent determinism; timing lives in whatever protocol rides on top (usually Modbus RTU), so you own the scheduling. USB is host-polled and non-deterministic — never put a closed servo loop across it.

Topology and node count

CAN FD and RS-485 are multi-drop: every node hangs off one twisted pair, terminated 120 Ω at both ends. That's cheap and tidy for a limb full of joints, but a missing or doubled terminator is the single most common "the bus won't come up" bug — check it first. EtherCAT is daisy-chained line/ring; you cable device-to-device and the topology is self-addressing, which scales to hundreds of axes but wants an EtherCAT master. USB is a tree off one host and tops out at 127 devices, but practical hub limits and 5 m cable runs make it a device-level interface, not a machine bus.

Cabling and connectors

EtherCAT rides standard shielded Ethernet, so cabling is commodity — an underrated advantage on the shop floor. CAN FD and RS-485 want a proper twisted pair with a common ground reference; skipping the ground or running unshielded next to a servo drive is how you get phantom bus errors. USB runs are short and fussy over EMI, another reason it stays on perception, not power-electronics-adjacent control.

Ecosystem and tooling

For Chinese-sourced components this is decisive. CAN wins on ecosystem for research and humanoid parts: a cheap USB-CAN dongle, open SDKs, and Python examples get you a spinning joint the same afternoon. EtherCAT's tooling is mature but industrial — you're buying or licensing a master stack (TwinCAT, IgH, Acontis) and budgeting integration time. RS-485/Modbus is universally supported by any UART but leaves protocol details to the vendor doc. USB is plug-and-play on any PC, which is exactly why perception devices choose it.

When each bus is the right choice

CAN FD / CAN — default for legged robots, dexterous hands, QDD actuators and most F/T sensors. Pick it when you're building on an embedded controller or a robot SDK and want fast bring-up.
EtherCAT — pick it when you already run an EtherCAT master and need synchronized, hard-real-time motion across a multi-axis industrial cell. Don't add it for a single hand; the master overhead isn't worth it.
RS-485 / Modbus — fine for a single hand or a slow actuator on a simple PLC/UART setup. Adequate, cheap, unglamorous.
USB — cameras, in-palm vision, and USB-interface LiDAR; also the config/flashing channel for many CAN devices. Not a control bus.

What the catalog actually ships — and how to avoid a mismatch

Scan the dexterous-hands and actuators-joint-modules categories and a pattern jumps out: CAN and RS-485 dominate; EtherCAT is rare on these embodied-AI components. A few concrete examples from the catalog:

Component	Category	Interface
Inspire Robots RH56 / FTP	Dexterous hand	RS-485 / CAN
T-MOTOR AK80-9	QDD actuator	CAN
MyActuator RMD-X8	QDD actuator	CAN
Damiao DM-J4310	Micro QDD	CAN
Unitree GO-M8010-6	QDD actuator	RS-485
Robstride RS00 / CyberGear class	Micro QDD	CAN

The practical takeaway: if your controller is an EtherCAT master and you buy a CAN-only hand or actuator, you'll need a CAN-to-EtherCAT gateway — extra hardware, extra latency, and a week of integration you didn't plan for. That single mismatch is the classic integrator error (the actuator sourcing guide calls it out too — see the joint modules & actuators guide).

Four checks before you commit to a component:

Match the bus to your controller, not to the spec sheet. List what your master actually speaks, then filter the catalog to that. CAN-native controller → buy CAN parts.
Confirm CAN vs CAN FD explicitly. They share wiring but not framing; a classic-CAN controller won't decode FD frames without support. Ask for the exact variant and bitrate.
Ask for the protocol doc and SDK before you buy — sample one unit. As with actuators, if the English CAN/Modbus manual is complete and the SDK has examples, the rest integrate in days. This predicts project success better than any bandwidth figure.
Note that fast sensors need bus headroom. A tactile array like the PaXini PX-6AX GEN2, quoted at <10 ms response, only delivers that if the bus and loop rate keep up — verify the end-to-end path, not just the sensor.

When in doubt about whether a given hand, actuator or sensor will talk to your stack, put the controller and bus you're standardizing on into your RFQ — a serious supplier answers the interface question before quoting. And if this is your first import, the how-to-buy playbook covers the paperwork side.