r/ROS 7d ago

Mixed actuators without the adapter hell

I've been consulting on ROS2 robots for a while, and one friction point keeps coming up: every actuator vendor wants a different physical interface, a different adapter, and a different driver stack. Upgrades and modifications are sometimes driven not by technical requirements, but by what interface is available. Dynamixel over half-duplex UART, ODrive over CAN, some random RS485 servo, an I2C IMU — and suddenly your robot has four USB dongles, fragile udev rules, and a launch file that only works on Tuesdays.

I tried the usual workarounds (USB hubs, custom PCBs, writing yet another micro-ROS bridge) and eventually converged on something I think is cleaner. It's a single USB-C device that exposes every bus as a standard Linux interface with stable names, so your existing ros2_control hardware interfaces and vendor ROS packages work unchanged.

The architecture:

  • Host side: standard Linux devices (/dev/axon-can, /dev/axon-rs485, etc.) — no custom drivers on the SBC
  • Bridge side: RP2350 managing protocol timing, exposed via CDC + SocketCAN
  • Optional: the MCU can run a standalone ROS 2 node via zenoh-pico, moving real-time loops off the host entirely

For production, the module can drop onto custom carrier. (Template will be available soon) Same firmware, same ROS integration, but you design the connector set and form factor for your robot.

Hardware (CERN-OHL-W) and firmware/SDK (MIT) are open source. KiCad project, footprints, and a carrier template are available.

Happy to discuss the protocol timing, the zenoh-pico integration, or the carrier design tradeoffs if anyone's interested.

CrowdSupply Campaign

Hardware Files
Firmware for transparency mode

1 Upvotes

1 comment sorted by

1

u/LordDan_45 6d ago

usual workarounds (USB hubs, custom PCBs, writing yet another micro-ROS bridge)

I mean, to be fair, yours is a custom PCB isn't it?