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.