Every year, the IUT (University Institute of Technology) in Nîmes, France, organizes a sumo robot tournament. The rules are simple: build an autonomous robot that can push opponents out of a circular ring. The constraints are strict: weight limits, size restrictions, and a tight development timeline. It's a hands-on engineering challenge that forces you to make real trade-offs between power, control, and reliability.
I participated three times and each time taught me something different about electronics design and embedded systems.
First Time: Learning the Basics (Bachelor's Degree)
During my bachelor's, I joined as part of a three-person team. My role was PCB design and microcontroller programming. It was my first time designing a board from scratch for a real application with actual performance requirements. We had to integrate motor drivers, sensors for edge detection, and power management all while keeping the board compact and lightweight.
The robot worked, but barely. We learned the hard way that a schematic that looks good on paper doesn't always survive the chaos of a combat arena. Loose connections, noise in the sensor readings, and motors drawing more current than expected these weren't abstract problems anymore. They were things I had to debug on the spot, with a soldering iron in hand and five minutes before the next match.
Second Time: Raising the Bar (Master's First Year)
By my first year of master's, I wanted to do better. This time, I teamed up with one other person. I took full responsibility for the PCB design and programming, this time using an STM32 microcontroller. I focused on making the design more robust, better power filtering, proper grounding, and modular firmware that I could tune between matches.
We performed significantly better. The robot was faster, more responsive, and didn't randomly shut down mid-match. But I also realized that hardware alone wasn't enough the control logic mattered just as much. Tuning the motor response, adjusting sensor thresholds in real time, and optimizing the decision-making loop became just as important as the circuit design itself.
Third Time: Experimenting with FPGAs (Master's Second Year)
For my second year of master's, we decided to experiment. Instead of a traditional microcontroller, we used an FPGA development board. The idea was to leverage parallel processing for faster sensor fusion and motor control. I handled the PCB integration and the low-level programming to interface the FPGA with our sensors and actuators.
It was ambitious maybe too ambitious. FPGAs are powerful, but they're also unforgiving. Debugging timing issues and ensuring stable communication between the FPGA and peripherals was a steep learning curve. We didn't win, but I learned more from that project than from any textbook. It taught me when to push the limits of a technology and when to stick with what works.
Fourth Time: Passing It On (Master's Third Year)
In my final year, I didn't compete. Instead, I helped first-year master's students with their PCB designs. Watching them make the same mistakes I did and helping them avoid some of the pitfalls I'd learned the hard way was surprisingly rewarding. It reminded me that engineering isn't just about solving problems yourself, it's also about sharing what you've learned so others can build on it.
What I Took Away
The sumo robot tournament wasn't just about building robots. It was about iteration, failure, and learning to work under constraints. It taught me how to design hardware that's not just functional, but reliable. It showed me that good embedded systems require both solid electronics and smart software. And it reinforced something I already believed: the best way to learn engineering is to build something real, test it, break it, and build it better.
