Of course, OpenUC2 places a strong emphasis on modularity. The goal is to digitally replicate virtually any optical setup through a flexible system of hardware and firmware (maybe there will be an openMINFLUX Box at one point? 😇). Each component – motors, sensors, illumination modules – can be quickly reconfigured and controlled. Until now, a single ESP32 managed all motor drivers and laser drivers centrally. This allowed communication over Wi-Fi, USB, and Bluetooth, including support for external controllers such as PlayStation devices. However, as more features were added, we encountered memory constraints and performance bottlenecks.
So far everything went through one ESP32 board that received a single firmware that one could flash through this link: https://youseetoo.github.io/
Modularizing the electronics became the next logical step. I²C seemed like an obvious choice because it only requires four wires and offers a multitude of available sensors and modules. Yet, I²C did not handle higher voltages and certain fault conditions reliably in our tests. A short incident involving a disconnected neutral line at 12 V caused current to flow through the data lines, damaging all attached devices. This limitation, combined with I²C’s lack of an event-driven mechanism (it requires the master to poll continuously), pushed us to explore an automotive-grade solution.
This is the openUC2 ESP32S3 Xiao-driven Motor Controller running via I2C – the problem: A missing GND cable causes all electronics to essentially burn 🔥
The CAN bus, already widespread in automotive applications, supports differential signaling on two wires (CAN_L and CAN_H), handles up to 12 V natively, and treats each node equally rather than imposing a master/slave hierarchy – perfect if an event from a motor has to be broadcastet to all other nodes or the master simply needs an update without pulling it. Data frames can be small by default, but there are established protocols for larger payloads. One such approach is ISO-TP, allowing segmentation and reassembly of bigger data packets. We adapted open-source ISO-TP code to the ESP32’s built-in TWAI interface (Yay! Open-Source for the win), effectively bridging the gap between the firmware control logic and the new bus system.
An important benefit of this setup is scalability. Any number of motors, lasers, or LED drivers can be attached to the bus. Each device can exchange data without saturating the main controller. Firmware updates and parameter adjustments – like motor current, speed, or microstepping modes – become modular and can happen in parallel, even during ongoing experiments.
One of the most exciting aspects is the open-source collaboration. Much of the code was refined through community contributions, including one developer who works as a chimney sweeper by day and codes by night. This collective effort has led to a more reliable and flexible firmware for the entire OpenUC2 ecosystem. New frames and configurations are in development, aiming to accommodate user-defined setups without firmware limitations. Curious? Check out the corresponding code.
This is the network: A HAT that powers a Raspberry Pi 5 or Jetson Orin has an additional CAN transreceiver that connects to all sattelite ESP32s3 CAN modules driven by SEEED Studio Xiaos. And the best: All modules run the same firmware. Yay!
The plan now is to release these CAN-enabled modules and firmware updates publicly. Though documentation may still be limited in certain areas, support is available through our forum, and feedback is always welcome. Future expansions are already in progress, including a new galvo module developed in collaboration with FlimLabs. Everything remains fully open source, awaiting fresh ideas and community-driven improvements.
Our forum: https://openuc2.discourse.group
