Before we begin, I need to explain the robotics project a bit. The goal is to have robots collect blocks, push them through a maze, and deliver them in a drop zone. Simple enough, right?
Starting where I left off in the last blog, I found myself back in the lab Saturday night. We combed through everything. The logic was good, and so was the math, and some progress started to show. With a program that broadcasted fixed points to the robot, it was able to successfully move the pots out of the way. Now, we had to set up our java planner. We have 3 webcams in the room that monitor different regions, and the idea was to send all the data such as robot and block locations to a master planner. The planner would then decide where to direct each robot, sending data via a Bluetooth connection. Elegant in theory, but TERRIBLE in reality. As the evening progressed, we encountered more and more problems, despite the logic being good. Calling it an almost failed night, we went home early in the morning.
I had to pull another allnighter Sunday night to work on my graphics course’s final project with my graphics team. Not much here, other than us pulling a miracle out of our rears with 2 hours to the deadline. I’d say we did rather well on that given the circumstances, being hopelessly puzzled as to the workings of Direct X throughout the night.
Sharing Wednesday with another group, we worked on the robot once again, with little gain. It would work sometimes, then stop working altogether with no real explanation. That night, it was go time. We HAD to finish this project that night, or fail the following day. In desperation, we decided to start working on a backup plan in parallel – something quick and easy. As the path we had planned for the robots was similar to following the wall, we decided that the navigation could be done altogether with sensors, cutting out ALL of the fancy stuff such as Bluetooth, GPS, robot coordinator, etc. The funny thing, the more we worked on this backup plan, the better and better it sounded, considering that the robot was still not obeying the navigation data sent via Bluetooth.
Since we were allowed to start the robots wherever we wanted, we started a robot near the flowerpots, with the intention of having it push them around a bit. The other two started in front of a block each, with hope that when the robots wall-followed back to the block area, they might move far enough from the wall to accidentally bump into a block near the wall. Amazingly, this worked rather well. The robots got stuck now and then, but we wrote some nice code for the robot that made it change direction if it didn’t move long enough. At this point, we didn’t care anymore, but were thinking that if we managed to do well in the competition, it would just be too funny.
The following day, Thursday, the competition had some very interesting events. Other groups who had managed to make an elegant working design, similar to our first, unexpectedly encountered all kinds of problems that we too had run into, and were forced to manually move the robots at one point, costing them dearly. Our idiot-proof method worked surprisingly well, bagging us a miraculous, but deserving 2nd place. I say Deserving because of the MANY hours we had invested in this project.
I won’t forget this week anytime soon, the many sleepless nights shared with not only my group partners but also with the students working on their own projects. Retrospectively, it was all worth it – friends were made during the wee hours of the night, strong memories of the good and bad times were committed to mind, and now I’ll be able to answer “Oh yeah” with a smirk when asked about teamwork experience during a job interview. I’ve included some videos filmed during the robotics work time – one of me filling in for the robot, and the other of my team and I watching our cheap but effective backup plan work brilliantly.