As an engineering student, I have fallen flat on my face far more often than I care to admit. The silver lining, if there ever was one, is that I always knew why. It usually goes to the tune of not taking all aspects into consideration, dismissing potential pitfalls or “hoping” that things don’t go wrong. At least there’s a way to rectify the outcome should it ever play out again. But what happens when you do everything you can, and things unimaginably go wrong?
It’s probably one of the biggest misfortunes of living in the interconnected ecosystem that we call society. Given our dependence on each other, it is possible to do everything right, but still fail. And not only fail, but be under the direct consequence of that failure.
This past summer, I was building a robot as part of the UBC Engineering Physics experience. And an experience it was — featuring everything from team disagreements to unorthodox concept design to major design pivots halfway through an already rushed five week timeline. The endeavor culminated in a competition in which the robots had to perform a series of tasks autonomously. Heading into the final weeks of our timeline, and many iterations removed from our initial concepts just over a month prior, we rigorously reinforced, simplified and tested our robot to ensure reliability. Two nights ahead of the competition, we were successful — we had everything working, every single time.
Over the next day and a half, every component of our robot operated as it was intended. We had a list of the most likely reasons we could fail and we worked to mitigate those risks. Everything from the arm on our robot not working, to our robot not being able to properly following the path it needed to follow, to not being able to retrieve the objects it needed to retrieve were among our concerns. Multiple successful tests later, we called it a night and we were headed to the competition, filled with a certain assurance of our final product. Surprisingly, the issues we had anticipated to arise in the final hours of development and testing had not arisen.
We got to the morning of the competition. Out of superstition, we refused to keep testing it down to the final minute. Previous iterations of the competition featured stories of teams “overtesting” to the point at which their robots failed. Intending to not go down that path, we patiently waited until the competition.
When we were on the surface for our turn, we were ready and confident. At the very least, we anticipated a successful run, akin to the many attempts that had yielded success over the previous two days. With the bell rung, we flipped the switch to start up our robot. There was a wait time in between turning it on and having it perform the tasks it needed to perform. With everything in place, we waited for it to start. And we waited. It didn’t start. We quickly regrouped, checking our gears to see if they had locked together. We checked to see if something was preventing the motor from turning. Nothing of the sort was evident. Everything we had built was working as it should have — except for the fact that our robot was not moving.
Once we got to the back, we dislodged our wheels only to find that the motor was broken. The very motor that we, along with every other team in the competition, had received was broken. It was the first time in the near five week design cycle that a motor had failed to turn. The first time that the motor broke was the morning of the competition. Now that was a hard pill to swallow. Countless tests, many iterations, and a number of implementations of our design had been withstood by our motors — up until the moment when it mattered themost.
In retrospect, it could be said that the potential for motor failure was something of which we should have been weary. We could have made it easier to change motors and swap in a more functional one in the given context. Yet, the motor was seen as a constant; it was used by every team, had withstood years of use prior to us even handling them and was widely accepted as reliable. Given the near negligible likelihood of a risk such as the motor failing, identifying it as a risk would have been a challenge. It likely would have required us to observe the malfunction during testing before we realized it was a possibility that needed tending. Unfortunately for us, the first time we did witness the pitfall was during the competition.
In the aftermath, it did make us wonder — had we tested later into the night, would we have identified the failure? Of course, pondering down that path is a dangerous road that will never see an end. A cutoff point needed to be established, and choosing one on the back of many successful trial runs was rational.
Was it fair? Despite the near endless hours spent designing, testing and reiterating, something that was accepted as outside of our control drove the first, only and final nail into our coffin. It doesn’t really matter if it was fair or not. In the end, our robot failed to do what it needed to do, and the team I was a part of lived in the consequence of that failure.
Thanks for taking the time to read my views! The robot we ended up designing along with the competition details arelocated here on our Project Roberto page. You can learn a little more about the life I lead as an engineering physics undergrad with a distinct interest in entrepreneurship at nishadjamaldeen.com.