My first experience with hardcore engineering was through my freshmen year Cornerstone class. Despite having declared myself as a Computer Engineer, I had yet to write my first program. This is when I found myself tasked with creating a series of robots over two semesters using Arduino, C++ coding, various sensors, and a given robot chassis. Working alongside 3-others, the end goal was to create a robot that could detect alcohol. But before we could get there, we had to create robots to avoid obstacles and find light.
To achieve our first milestone, we needed to create an autonomous robot capable of avoiding obstacles. In this case, the obstacles were the walls of the room we were testing in and other robots. In addition, we were given a budget of $50, had to have a button that when pressed would stop all operations, and had to laser cut a custom part.
Considering that this was an introductory project in a freshmen year engineering course, we were given a lot of resources to work with. In addition to the chassis, we also had most of the code needed to instruct the robot on what direction to move in. All we needed to do was adapt the code to whatever algorithm we decided on.
Given our budget, it was easy to conclude that an ultrasonic sensor would be the optimal tool to utilize. Once we had that down, we needed to figure out how we wanted to use the sensor. When it came to brainstorming for our algorithm, we went all out. Some of our initial ideas were far beyond the realm of possibilities. Regardless, we spent a good deal of time humoring all suggestions no matter how absurd some of them were. We wanted to make sure that we came up with the best solution. Suggestions that didn’t make the cut, but I would like to give an honorable mention to are:
But as it would turn out our days of humor were short lived.
Thinking that we already had a fully assembled chassis and most of the code done, we naively believed that this project would be easy sailing. Yet, for the first couple of days we were unable to get the robot to function at all. We couldn’t even turn it on. Knowing that we were fast approaching our deadline, we finally caved in and decided to go to the first-year engineering center for help. It was there, upon closer inspection, that we discovered the source of all our problems. Instead of mechanically screwing together the components of the robot, the people before us had decided to just hot glue everything together??? This excessive use of hot glue was obstructing the motors and several other key parts from operating.
Figuring out the problem was only the first step to recovery. We then had to spend hours physically removing all the hot glue. In the process, the battery tray, switch, and motors had to be completely replaced.
Rebuilding the robot from scratch did not leave us much time for anything else. Crunched to meet our deadline, we had to make significant tradeoffs. In terms of the algorithm, we decided to just let the robot spin around its axis. While spinning, the ultrasonic sensor checked to see if any objects were in the way. If no, then the robot simply moved forward. But if yes, the robot dodged towards the opposite direction. As for the laser cut part, we always knew that we wanted something to enhance our robot’s aesthetic. Since we didn’t have time for something elaborate, we simply designed a holder for our sensor.
In the end, our robot technically worked. At the bare minimum, our robot was able to avoid most obstacles. But having only one sensor did not translate well for multiple obstacles at once. Had we had more time to test and debug our algorithm, I am sure we would have added at least one more sensor. In addition, our robot was not aesthetically pleasing at all. Even looking past all the exposed electrical wires, our robot was not professional by any means. Learning from our failures this time around, we hoped to avoid them in our next robot.
Our second milestone involved creating another autonomous robot. In addition to avoiding obstacles, our new robot was expected to pinpoint sources of light from at least 15 feet away. Along with being given a budget of $50, the aesthetics of the robot were to be given priority this time around.
We were unable to do a lot of testing on our robot the first time. We were too busy brainstorming, removing the hot glue, and quite frankly didn’t think it was important. This led there to be edge cases we didn’t pick up on until the actual demonstration. To avoid that, we decided to make all our design decisions experimentally. This meant that instead of picking one solution and then rolling with it, we would come up with several solutions. Then depending on their success during prototyping, we would choose the one that worked best.
Since all first-year engineers have easy access to photoresistors, we knew we would be using them to detect light. The real question was how many did we need? Looking back at our first design, having only one sensor proved to be suboptimal. It greatly limited the scope of how much the robot was able to detect at once. So, when we started testing for the light seeking robot, we played with different number of sensors. Eventually we determined that having 5 photoresistors and 1 ultrasonic sensor accounted for all possibilities.
With the hardware down, our algorithm fell into place quickly. 4 of the photoresistors were oriented on the robot in the cardinal directions while the 5th was in the middle pointing up. When turned on, the robot quickly identified which of the 4 cardinal photoresistors had the highest reading. Once it figured that out, it would then proceed to move in that direction. If for some reason the robot was unable to complete this step, it was then expected to spin in place until it could. The robot would continue to move in the direction with the highest reading until all 4 horizontal sensors had similar values. If so, and the 5th photoresistor on top had the greatest value, then the robot would stop moving. Some kinks we had to work out along the way are:
Our aesthetics the first time around were a mess. Unfortunately, we did not improve by much the second time either. We went in with the game plan, “out of sight, out of mind.” This just meant we bought this huge, obnoxious bowl from Target and plopped it onto our robot. We then went on to shoddily cut out holes for the sensors to protrude out of. During testing, we noticed that the robot’s movement caused the bowl to shift and block off one of the sensors. Moreover, the bowl’s weight put an uneven amount of stress on the robot. This caused it to flip over on itself sometimes. Our solution? Adding a Styrofoam cutout to balance out the weight distribution and taping down the bowl to stop the sliding.
Okay, before I go on any further, I need to make a confession. Not once during testing did our robot ever work. Despite putting in countless late nights and early mornings, it refused to go near light. By the time the actual demonstration came up, we were exhausted, frustrated, and demoralized. Mentally we had prepared ourselves for failure. But to our surprise, the robot was a resounding success! It found the light source very quickly after carefully avoiding a wall and turned itself off underneath the source. It outperformed even our best-case scenarios.
Since then, we have come up with many theories as to what happened that day. Maybe the light we were testing with wasn’t bright enough, maybe a last-minute code change fixed everything, etc. Regardless, I see what happened that day nothing short of a miracle. In fact, I accredit it as one of the key reasons why I continue to be an engineer.
The robot finally working did not mean we were out of the woods yet. In the middle of our demonstration someone decided to make fun of our robot’s appearance. In hindsight, they weren’t wrong, but at the time it felt like the end of the world. Using this slight as fuel, we were determined to blow everyone away with the aesthetics of our final robot.
The culmination of months of hard work was our third and final robot. The end goal was always to be able to detect alcohol. The autonomous and light seeking robots were simply meant to lay the groundwork we needed to do so. For the final robot, we were given a budget of $50, had to implement an additional laser cut part somewhere, and use an audio alarm to indicate when the alcohol was found. The catch, however, was that were only allowed to use the SparkFun alcohol sensors.
I don’t know if you’ve ever had the misfortune of working with these sensors, but they are the absolute worst. Not only do you need an initial 48-hours to burn them in, but even a whiff of alcohol will instantly saturate them. Once saturated, you then need to wait for minutes on end to air them out before attempting any further readings. Considering that our robot needed to take constant measurements in an enclosed space, these sensors were far from ideal.
We had an inkling of how unreliable the sensors were going to be. However, it wasn’t until we actually started working with them that we realized we basically had nothing. Intially our algorithm took the average of the readings from the two alcohol sensors on the robot. Since we knew the dimensions of the room we were going to demonstrate in, our original plan was to have our robot map out the room while storing constant average readings. Once finished, our robot would return to the location with the highest stored value.
On paper our plan seemed pretty fool proof. In a MATLAB simulation we ran, our robot found the source of alcohol 99% of the time. The only problem we hit was finding the right balance between speed and accuracy. We saw that while going slow gave us more accurate readings, the tradeoff was that the robot took way too long to find the alcohol. Playing around with various speeds on MATLAB, we ultimately settled on a value that gave us the max time of 5 minutes with fairly accurate readings.
Despite our simulation giving us promising results, our algorithm was simply not functional with our sensors. They became instantly saturated in the presence of even traces of alcohol. We did not have the time to wait for minutes on end for the sensors to air out after each reading. At one point, we contemplated laser cutting small fans for the sensors to help with the time needed to air out. In the long run though, there was not much that we could do. We ended up tossing the whole room mapping idea and settled for more of a free for all approach. In this algorithm we just had the robot randomly go around the room in the general direction of the sensor with the greater alcohol reading. Once a certain threshold value was hit, the robot would indicate that a source of alcohol was found.
Our final algorithm was by no means much better than what we had originally intended. Nonetheless, since it depended on fewer sensor readings, we found it to work slightly better. Having little faith in the actual functionality of the robot due to factors out of our control, we went all out for the aesthetics. While brainstorming for ideas, it came up that I was the only one in my group who had never seen Star Wars. Therefore, to annoy me and out of spite for the random kid who made fun of our robot last time, my group ended up designing our final robot in the shape of the Millennium Falcon. Taking it even one step further, we used the Star Wars theme song for the audio alarm to indicate when alcohol was found.
To nobody’s surprise the robot was not successful in the actual demonstration. As disappointing as the final outcome was, I look back and can’t help but be incredibly proud of my group. We went into a project that was quite frankly always meant to fail. Rather than sit around and mope, we chose to put our all in to find the best possible solution. We constantly changed plans, stayed up countless nights, and shed quite a few tears out of frustration. Yet, we remained resilient as ever. In all of this, there was one silver lining. Even though our robot was unable to locate the source of alcohol, we did win best aesthetics. While not a focal point of the project, it meant a lot to us to see how far we had come in terms of that.
It has now been many years since I’ve done this project. But it is the one thing that I always bring up in my interviews. It’s funny that had we succeeded, I probably would never talk about it. Having failed, I think I got a lot more out of the project. I can talk passionately for hours about what we could have done differently, or how frustrating the Sparkfun sensors truly were. Til this day I continue to use the lessons I learned from this experience in my day to day engineering career.