|
Re: The "Right" way to program
I completely agree with rsisk and Ryan. The sad reality of robotics is that the programmer ends up having the least say in how the robot works. Basically, if they driver doesn't like something, you change it until they do. If it's technically and/or mathematically "correct", and the driver doesn't like it, too bad. Good example: this year, we used swerve drive on our robot. Instead of doing the usual way to control it and using trig (using the vectors from one joystick to do point-and-shoot), he wanted one joystick to control the wheel angle and the other joystick to control the wheel speed, thus isolating the two values and making a couple of vector math things a bit more complicated. But the technical "correctness" of the code doesn't win the game.
Also, yes, there is a very large discrepancy between the virtual world and the real world. Theoretically, on a differential drive (tank drive) robot, the left and right sides should have the same maximum speed. Well, not exactly. Different chain tensions, different bolt tightnesses, whatever it is, one side will almost invariably be slightly faster than the other. Last year, we ended up putting a slight turn in our code during autonomous so the robot would run straight. That's one of those things that you try until it works.
Basically, the "correct" way to program is the way that makes the program work the way the user wants it to. Even if your supervisor comes up behind you and says, "That's a shoddy way to do it," if it works, it's right. It's worth learning the generally-accepted way, because you'll probably learn something, but if it works now and you're on a deadline, don't change it.
|