Zargoz

We were very picky about what our robot needed to do, unfortunately that meant that if something had to be changed, usually a lot of other things had to be changed too. This meant that we actually went through a few variations of our bot before the end. The one that we entered in the final contest was actually our third attempt, and thankfully ended up having a much more simple internal structure than the others, making our last minute fixes a little easier. The decision to completely rebuild the robot just a few days before the competition was made because we felt as if we would be unable to operate with the precision that the old robot required.

Coding for a hardware application was very interesting, especially before the hardware was actually finished. I wrote a lot of code before we had actually finished the chassis, so I couldn't test much of it. And of course once we did, we ended up rewriting a lot of it due to unexpected bugs. And then after the rebuild we ended up scrapping a lot of the code from the old robot. All of the functions using the sensors had to be discarded or modified because in the rebuild we only used the VPS, and a lot of other functions were scrapped or significantly changed. We kept everything very modular which was great, because we often had to change hardcoded values or slightly modify something to get the robot to work better. If we hadn't known it before, we definitely would have learned -> keep code segments small and easily changed! Particularly when coding for hardware, where debugging can be very difficult and incredibly time-consuming.

Coding started with getting the robot to drive straight - we started out using encoders for a proportional correction system, which worked pretty well until we realized one of the encoders was creating a lot of friction in the drive train. So we ended up ripping it off and using the gyroscope. In the final design we just used the VPS theta value to do proportional control. The next coding challenge was navigating to points, which we did by finding the difference in x and y position between our robot and the desired point, and then finding the necessary angle to get there and correcting to it. This code came in handy later in the process when we were trying to get to gearboxes. To avoid walls, we had a function that navigated the robot around the board by taking it to a point in the middle of each sector. The code determined which sector the robot was currently in, took where it was supposed to go, and found the quickest way around to get there. Our strategy to avoid the other robot basically consisted of not going to a sector that they were in. We also had code to drive around them based on their heading, but we didn't implement it in the final code because we never got a chance to test it. In the final design, our strategy to capture territories was to drive to the center of a territory and then set our heading opposite a gearbox and back into it with the gearbox-turning gears in the back turning. Unfortunately, while we did eventually get it to do this, the robot would tip up when it hit the gearbox and not turn the gears. If there had been more time I would have added a bumper sensor and told the motors to stop when we got to the gearbox, or maybe made the robot bigger or added a physical stop against the wall so it wouldn't tip up on contact with the gearbox.

At the beginning, besides knowing that we wanted to go small, we had no real plans for how to do our bot. So what ended up happening was just a lot of trial and error as we sought out the best ways to make tools to do the tasks given to us without being hopelessly complex or bulky. Honestly though, this was perhaps the most fun part of the entire class as it meant that we just played with LEGO's for pretty much the entire week.

Another problem we were facing at the beginning was the looming terror of the drop test. By the end of the first week, we were self-testing and rebuilding almost constantly, but our two- wheeled design was giving us grief. We had a nonfunctional third wheel mounted on the back simply for stability. The problem was, this was falling off the majority of the time we tested it, no matter how we braced it on. So what we did was design for the failure, we put a convex drag piece on the pieces directly in front of the wheel, then, when we dropped it, the wheel would come off, but we would have a perfectly good sliding surface there to keep the bot stable. The organizers weren't exactly thrilled with our ingenuity, but in the end they had to give us the pass.