In my mechatronics class, our project was to construct a fully automated rover equipped with navigation, targeting, and a weapons system to compete in an arena-style balloon-popping challenge. The entire timeline, from design to build, was one month. Initially, I expected the project to be straightforward with minimal issues—but I was quickly proven wrong.

The Struggles of Raspberry Pi and Sensor Communication

Our first challenge was setting up the Raspberry Pi, PixyCam, and communication protocols such as I2C, SPI, and USB. The initial learning curve was steep, especially when working with Raspberry Pis, which seemed to generate errors without clear explanations. Half the time, debugging felt like guessing in the dark, as there was no consistent way to determine what went wrong. Even basic setup processes, like flashing the OS onto the SD card or installing necessary libraries, were frustratingly unreliable. These obstacles made me realize that while Raspberry Pis are powerful, they require significant troubleshooting experience to use effectively in complex projects.

Once we had a functioning system, we faced another major hurdle—extracting relevant data from the PixyCam and passing it through the Raspberry Pi to the Arduino. The PixyCam was supposed to help us track and identify balloon targets, but making sense of its raw data was difficult. We needed to access specific registers, filter out unnecessary noise, and establish stable communication between the devices. Debugging I2C communication proved to be a tedious process, as small errors often resulted in the entire system failing to function. Understanding how to parse data correctly and send meaningful commands to the Arduino was a painstaking but necessary process in getting the rover’s targeting system operational.

Designing and Integrating the Rover’s Hardware

Alongside the software development, we had to carefully design our rover’s mechanical structure to fit within competition constraints. We aimed for a compact chassis to reduce weight and improve agility, ensuring our robot could quickly navigate the arena. To maximize maneuverability, we chose mecanum wheels, allowing for omnidirectional movement—a strategy we thought would give us an advantage. However, we soon realized that every other team had the same idea, making our approach less unique and less effective than anticipated.

With space being a limiting factor, we faced additional integration challenges. Fitting all the electronics, wiring, and our weapon system into such a small frame became increasingly difficult. The lance system, which was designed to pop balloons, had to be mounted at an angle because a straight configuration wouldn’t fit within the footprint limitations. While this solution allowed us to stay within the required size constraints, it also made aiming and actuation more complex. These challenges highlighted the importance of considering physical constraints from the very beginning of the design process, rather than trying to squeeze in components later.

The Reality of Systems Integration

Once all the hardware and software components were built, the real test began—getting everything to work together as a unified system. Software on its own had worked fine, and hardware independently seemed solid, but integrating them created new, unexpected issues. Wiring placement became a nightmare as different parts obstructed access to critical components, making it difficult to troubleshoot once the system was assembled. We quickly realized that poor wiring management can cause as many problems as software bugs, as loose connections and interference led to inconsistent performance.

The biggest challenge was calibrating our targeting and navigation systems in real-world conditions. Our code relied on sensor input to make decisions, but even small changes in lighting or obstacles could throw off the entire system. Testing in the actual competition arena revealed that what worked in controlled conditions often failed under unpredictable circumstances. This was an eye-opening lesson in the unpredictability of real-world deployment and the importance of making systems adaptable rather than rigidly coded for ideal conditions.

Competition Day: A Series of Unfortunate Events

Going into the competition, we were confident—our test runs had been successful, and everything seemed to be functioning as expected. However, in the very first match, our robot veered off course and went out of bounds, leading to a disqualification from the upper bracket. We later discovered that one of our IR sensors had been bent slightly out of position, causing it to misread boundaries. This minor calibration error, which had gone unnoticed, completely threw off our navigation system, proving just how sensitive these components can be to even the smallest disruptions.

We had one more chance in the lower bracket, so we quickly recalibrated the sensors, checked our wiring, and prepared for another run. However, just as the match started, our robot became stuck on an unexpected white line—one that hadn’t been present in our previous tests. We later learned that another team had added an extra boundary line near our starting position, which confused our navigation system. On top of that, our lance system failed due to a loose servo mount, preventing it from deploying properly. These unexpected failures highlighted the importance of building redundancy into designs and performing pre-run checks to catch small but critical issues.

Lessons Learned: Risk Prevention and Adaptability

Despite the disappointing performance in competition, this project was an invaluable learning experience. One of the biggest takeaways was understanding the importance of thorough testing and risk prevention. If we had taken extra time to double-check all sensors before the match, we could have avoided the IR calibration issue. If we had designed a more secure mounting system for our lance, we might have been able to recover from the setback. These small details, while easy to overlook, often make the difference between success and failure in real-world engineering.

Beyond the technical skills gained, this project reinforced the reality that engineering is rarely a smooth process. No matter how well you plan, unexpected challenges will always arise, and the ability to adapt and problem-solve under pressure is just as important as technical knowledge. While our rover didn’t perform as well as we had hoped, the journey of designing, building, and troubleshooting it was incredibly rewarding. The experience gave me a deeper understanding of mechatronics, real-world robotics challenges, and the necessity of resilience in engineering.