Building an Autonomous Vehicle

During the Spring 2014 semester, I had the opportunity to take Professor Valvano’s Real-Time Operating Systems class with some of my best friends in ECE at UT. We spent the first several labs developing a RTOS: implementing thread switching, cooperation between threads, a file system, and communication through CAN-USB.

The class itself and the initial projects were rewarding, but the capstone of the class was one of the most fun projects on which I’ve worked at UT. We built, programmed, and raced an autonomous robot against others in the class. A video can be found here.

We built the robot from the ground up, including:

  • The motor circuitry
  • The body of the robot
  • The sensor configuration, connection, and communication
  • The operating system
  • The PID (Proportional, Integral, Differential) control system

After more than a month of development and testing, we raced against other teams in the class on a previously unknown track with numerous turns and pitfalls. A video can be found here. Though we did end up winning the competition, that is not what I remember most from the experience. Rather, I learned lessons that I will carry with me to future projects far after I forget the race itself.

First, A good team is everything.

A team of smart and hardworking students would not be enough — everyone in the class was smart and hardworking. An effective team needed people who knew different things than each other. Most importantly, everyone trusted others’ areas of expertise but knew enough to challenge each other on design decisions in a brainstorming effort.

The spread of the project — from motor circuitry to operating systems to control systems — was more than any one person could handle. The single most important success factor was that the team was composed of a circuit designer, a mechanical and circuit builder, a sensing and control systems engineer, and a perfectionist who outworked everyone in integrating and calibrating the machine. It helped that everyone liked each other and invested in the singular goal of making a great robot.

Second, In hardware, slow and steady wins the race. In software, fail fast and iterate.

We started out slow. While other teams had a working end-to-end robot as early as a week into the project, we spent several weeks building a robust chassis and neatly soldering the motor circuitry. Yes, we tried several designs, but then we spent the time and built a stable system. This investment meant we were initially behind other teams, but we more than made up the time later. While others struggled with fixing their hardware while simultaneously debugging their software, we could rely on our physical build.

On the other hand, we weren’t afraid to prototype and try many different code architectures, control system decisions, and calibration settings in software. Source control meant that we weren’t afraid of losing what was working well enough while we searched for something better. Our final design wasn’t our first, or even the hundredth. It was a continual process over several weeks to find the best configuration.

Third, hard work matters, but so does luck. So just have fun and make sure you learn something.

The teams that we saw in the lab every night of the month did well as a whole. The perfect concept cannot overcome a lack of execution time in building a complex system, but hard work can mask poor initial decisions. However, on any given day or race, the exact order is a matter of luck. For example, one of our motors fell off in a fluke at the end of the final qualification race. Luckily, we had already qualified for the finals. If the motor had fallen off even one race earlier or later, our outcome would have been far different.

Unfortunately, we had to dismantle our robot the day after the competition so that the parts could be salvaged and reused in future semesters. The dismantling provided one final lesson: Products don’t survive long, but lessons and memories do.