Posted: This year our firmware team (me, JD, Bryan, and Taylor) was asked to code not one, but two different ways of driving our robot. Based on our strategy, our team’s electrical/firmware mentor Jeff decided that a Doom technique would be best (and I say him because we were all too young to know what he was talking about at first since he played that on his Commodore ’64 or something). Anyways, Doom controls basically consist of both tank and omni drive except with a person instead of a robot. The normal configuration causes the character to act as tank drive while holding a button on the joystick initiates omni drive (i.e. meccanum wheels).
I would argue that the driving system code is the most challenging, most important, and most fun part of the code each year (and I say each year because our team keeps switching development techniques between platforms so we haven’t recycled much code). The importance is obvious as this code is what moves the robot during competition. The fun comes in when seeing the final product and watching the robot almost glide seamlessly across the floor.
However, the challenge is what makes it robotics. And I learned a lot through this year’s code (and I hope my teammates did as well). For one, the first run at the code consisted of way too many if statements and still managed to barely work. Part of the reason for this I suspect was the eagerness to get it done and see the finished product. However, this was certainly not the right way to go about it and did prove to be extremely buggy and hard to visualize. Yet, thankfully, that’s where mentors come in. We (my team) sat down with our mentor and simply talked about possible ways to code it based on the mapping of the joystick (which I might add makes absolutely no sense in terms of positives and negatives whatsoever). After about an hour or so, we had a (relatively) simple formula that worked for all four possible quadrants of the joystick. It was awesome and worked much more smoothly than our first go at it. That, and it was about 200 less lines (note: exaggeration).
So yeah, I guess the moral of the story is to 1) simply sit down, think, and visualize a problem before diving into it (i.e. have a detailed plan) 2) nothing is ever good enough, it can always be improved and 3) don’t give up during the hard parts of coding or anything, that’s where you learn the most.
Comments