For the final of my first class in the Unified Robotics series, RBE 2001: Actuation, we were tasked with creating two robots to carry and accurately place metal “solar panels” around a field. We needed to use a state machine to follow a very specific set of steps, as well as create an emergency stop and start function using an IR remote.

The robots needed to be four bar linkages created from the concepts we learned in class. One needed to have a gripper operating on a continuous servo, and another on the position servo. We needed to be able to present all the calculations that went into it, as well as utilize MATLAB and Solidworks. Our chassis were Romis and provided for use by the class, although we did have to solder on line readers and do some other basic electrical work.

I had three teammates, and although we were all more than capable of doing every single step of the project, we certainly played to our strong suits. One teammate did all of the CAD, another handled all of the math, and then myself and another teammate did all of the software in PlatformIO. My counterpart on software mainly focused on the arm, which used quadrature encoders on the blue motor, as I had COVID the week we did that lab. He also did a lot of the electrical work, as that went hand-in-hand. In the final push, he also did a lot to the debugging and fine-tuning, of course, as we had two robots due.

My main focus was the state machine, and although I was really proud of my concept at the time, there is one major improvement I would make now that I am a much stronger programmer. Basically, you needed about 40-sum-odd states to achieve everything by the exact protocol they required. Most of my classmates wrote that many states, with the better ones making helper functions. We, of course, wrote a bunch of helper functions too.

Instead, I developed a system that would only require us to have about 9 states. To move between states, we had a step variable that would iterate step++ each time we exited a state. That variable corresponded to indices in two arrays, the first containing every step in order, and the second containing a parameter for the helper function. For example, if the next step was to drive until our ultrasonic was within 3 cm of the wall, we would have the first array tell us to move to the drive state, and the second one telling us to pass 3 as our param into our driveToDist() function.

My major change would be to make a single array of step objects. I definitely did not fully utilize the fact that we were in C++ and thus writing object-oriented code. This would mean we could’ve seen both the state and the param next to each other instead of halfway down the page, which would have saved a lot of time and confusion overall.

Three all-nighters later, (two for my teammates, but I digress), we went from worried about having anything working to 117% with the extra credit in a matter of an hour, with a perfect run in our demo the next morning.