A Design Lesson from the Mars Rover Competition
Over the last year, I was part of the BYU Mars Rover team. The team’s job is simple: each year, the team builds a mobile robot that competes in the Mars Society’s University Rover Challenge (URC). The Challenge consists of four missions, with points awarded based on successful completion of smaller tasks within each mission. One of the missions, for example, was the “extreme retrieval” task. In this task, the rover would read signs and move small tools around a hilly, difficult environment. Points would be awarded for each small task (such as moving a water bottle to a mannequin “astronaut”) that the rover completed.
Pretty clear goals, right? That’s certainly what we thought. Although most of the team hadn’t been to the competition before, we thought we understood it well. The rules and requirements for each task are described thoroughly on the Mars Society’s URC website; plus, we’d watched video from last year’s competition. We wrote our system requirements documents based on the URC’s points system and began to look for flaws that had cost us points last year.
We quickly identified several major items we wanted to redesign. Based on reports from the previous year, we identified key flaws in our chassis and electrical systems—for example, we had lost points because of an electrical misconnection that required a manned intervention, immediately cutting 20% off our score for that event. We decided that fundamental redesigns were necessary for both systems. Over the next few months, we spent hundreds of hours developing and manufacturing a passive suspension system that would keep the rover stable on extremely rocky terrain, and at angles up to 60 degrees. We invested heavily to generate a PCB and single-plug systems; they eliminated the ground faults and wiring mistakes that had plagued previous rover designs.
Going into the competition, we felt prepared. The rover was in much better shape than it had been in past years, and in past years it had done well.
As the competition unfolded, it became clear that we weren’t as prepared as we thought. Although we had seen the video from last year’s competition, the competition challenges change each year. When we saw the dexterity challenges, it was clear we’d underestimated how hard they would be. When we got to the rough terrain portion, we dealt well with the terrain—but our arm wasn’t outfitted to fulfill some of the tasks we needed to complete to achieve points. For the science challenge, we discovered that our sample examination methods weren’t suitable for several of the new types of samples. We needed large, open areas of samples we could suck up with a vacuum, but we got small pans of limited depth, some containing rocks too big for methods. We still performed well—we got sixth place, out of 34 teams. But our performance wasn’t what we had hoped for.
Looking back, the thing that held us back wasn’t any specific engineering decision—rather, it was that we hadn’t sufficiently understood the product requirements (in our case, how the competition would evolve from year to year). Because we didn’t sufficiently understand what the competition would be like, important parts of our design did not receive enough attention. Our chassis was unflippable and our electrical box was beautiful—but it didn’t help our rover’s arm reach the switches it needed to flip or our science system to illuminate the rocks it needed to examine.
To me, this was an important lesson. We had thought we understood the market requirements for our product. We had thought we were focusing on the things that would get us the most points. But when the time came, there were other features we needed that we didn’t have, or even understand. We hadn’t understood our goal as clearly understood as we had thought—and in the end, it came back to bite us.
