At Solideon, my supervisor designed an industrial belt grinder that was going to mount on a robot arm and I took ownership of making all the electronics work. The challenge was building the entire control architecture from scratch so that a grinding system could be driven automatically by a Kuka robot while also supporting manual pendant operation with an E-stop for safety.
One of my most common approaches at this point is to prototype each subsystem in isolation before bringing them together and I started doing exactly that with individual ESP32 programs in Arduino IDE aided heavily by Cursor, the agentic AI coding assistant. The first component I tackled was an SMC Pneumatic Regulator which needed a PWM-to-voltage converter to set regulated pressure plus a voltage divider feeding an ADS1115 analog-to-digital converter to read back the actual pressure. Similarly, an SMC Actuator Position Sensor required another voltage divider and ADS1115 channel to track actuator position in real time. There were also two SICK Photoelectric Proximity Sensors that needed voltage dividers paired with optocouplers so the logic levels played nicely with the ESP32 inputs.
The most involved component to integrate was a Yaskawa VFD which drove the main grinder motor. The VFD supported MODBUS over RS485 so I sourced an RS485-to-TTL board that allowed the ESP32 program to talk directly with it and control forward, reverse, stop, and frequency commands. There was also an IMS MDrive 17 Plus stepper motor that required both basic output pins for run-time direction control plus direct firmware programming through a dedicated RS-422 cable. In fact, I nearly got derailed right out of the gate with that stepper because we purchased the RS-422-to-USB programming cable on eBay and it just would not communicate when it arrived. I opened it up, noticed the ribbon cable inside looked like it had been fiddled with at some point, realized it was plugged in upside down, flipped it, reassembled everything, and after that it programmed perfectly.
Once every individual component was communicating reliably I built a couple of test demos to gain confidence before moving into the full system. One demo let me control the VFD and grinder motor from a single push button and a potentiometer. Another demo used the two SICK proximity sensors together with the stepper motor so the stepper would rotate in different directions or stop depending on which sensor combination was active at any given moment. That sensor-and-stepper logic turned out to be core to what kept the grinding belt tracking properly later on.
From there I started designing the remote control pendant itself which housed its own dedicated ESP32 and measured about 12 by 8 by 4 inches, so fitting everything into a form factor that was comfortable to hold while still being rugged enough for shop use took some thought. Before locking anything in, I did a little user surveying with a few different remote control layouts I mocked up, showed them around to the operators who would be using it day-to-day, and got great feedback on button placement and ergonomics. That shaped the final faceplate significantly. I started by adding switches for VFD control: forward, reverse, stop plus frequency adjustment. Then I figured out how to wire the E-stop button directly into the VFD circuit so it cut power at the hardware level rather than relying on software alone which felt like an important safety redundancy similar to how I handled relay state persistence in the gas switching system I built earlier at Solideon.
For communication between the two ESP32s I set up CAN Bus using TJA1050 transceiver modules so the grinder’s main controller and the remote control pendant could exchange commands reliably over the shop floor distance. All of the wiring between the boxes, CAN bus lines, E-stop wiring, 5V power, everything ran through a single Ethernet cable that could disconnect cleanly when we detached the pendant from the robot setup, which made maintenance much simpler.
When it came time to integrate everything with the robot itself I had to wire Beckhoff digital and analog outputs from the Kuka controller into the ESP32 via optocouplers and program the output behavior directly in WorkVisual on the robot. That gave the robot full authority over forward, reverse, stop, and frequency commands through the VFD when the control switch was set to robot mode. Bringing it all together I designed several additional custom DIN rail clamps for the various PCBs and modules that were needed, similar to the bracket designs I used for the gas switching system and IoT environmental sensors previously, then wired everything into that 20 inch electrical enclosure which had well over 60 individual wire terminations crammed inside it. The routing was tight but organized and after days of careful work the box was ready to connect out to the robot.
I loaded up the final firmware on both ESP32s and the system worked really well from the first full integration test. When in robot control mode, any program running on the Kuka controller could drive forward, reverse, stop, and frequency commands through the VFD. When switched to manual mode via a toggle on the pendant, the remote took over with full override capability and the grinder responds to all of the button and switch inputs immediately. The SICK proximity sensors paired with the stepper motor served an important role by keeping the grinding belt centered without slipping off. The proximity sensors detect which direction the belt is drifting and the stepper tilts an idler wheel to counteract movement in real time.
This project ran from around July 2025 through March 2026 with a roughly two month gap in between where other priorities took over, but when I was working on it I was deeply invested in the puzzle of it all. There were so many discrete parts that had to mesh together, analog sensors and digital control, safety interlocks, industrial communications protocols, physical enclosures for both units, and a programming workflow with Cursor that made rapid iteration possible. It was one of those projects where every system I built individually paid off when they finally clicked together as one working whole.