for documentation – karlin sent us an email that explains the math and stuff in the arcade drive vi.
I’m attaching an isolated .vi that just contains the “math” for the arcade drive. [sherri note – this is on zak and is called arcadeDrive.vi] All I did was delete any references to motors. If you open this .vi and run it (don’t deploy, just open it without opening the FRC project file), you can change the x and y joystick values and then see what the corresponding left/right motor outputs are.
So, yes, the weird signage on the joystick values pretty much makes things incredibly non-intuitive, but it all works out.
With the odd signs, a negative motor output means the motor spins forward and positive motor value means it’s spinning backwards. (yay FIRST)
If you look at this file carefully and test out the different joystick values, you should see that the following is what the default arcade drive does (you already figured out most of this – I’m just writing it out to be thorough)
1a. The first case structure is just “square inputs” or not and in the default case, if you look in RobotDefRef, you’ll see that the default is “false” (the green switch is off) so it doesn’t square the inputs.
1b. so since the default is just to take the x and y values directly, it then sends the joystick values to the second case structure.
2. Within the second case structure, you have 4 cases (true-true, true-false, false-true, false-false) which correspond to the 4 different joystick quadrants.
True-true = lower right quadrant (backward/right)
true-false = upper right quadrant (forward/right)
false-true = lower left quadrant (backward/left)
false-false = upper left quadrant (forward/left)
But in general, the arcade drive takes the maximum of the x or y joystick value and sets that to be the maximum speed of one of the motors (it changes depending on what quadrant you’re in).
Then, based on where the joystick is, it either sets both motors to spin at the same rate (x=0) or makes the motors spin at the same rate but in opposite directions (y=0). And when the joystick is in the middle of the quadrant, if you’re closer to the x-axis, the arcade drive is set to make the robot pivot, which makes it turn sharply, whereas if it’s near the y-axis, it mostly is moving forward/backward and turning only a little. Again, the math for making the motors do that is different within the 4 quadrants.
Um…I don’t think that explanation helps any, but just take a look at this file, step through the different joystick locations, and I think you’ll see that the “maximum number” block makes sense. Just write down the weird coordinate system and remember that negative motor values = forward and vice versa. It does what you programmed your old robots to do with logic based coding instead of using an equation. We can go over this when I see you.
By the way, you can probably code up the drive code without having the chassis design finished or whatnot. I still think you should put encoders on your drive wheels because it doesn’t hurt to have them. You could also just use um…scotty? (forgot the name) and hook up the new control system to it for practice. There would be some ghetto rigging, but I don’t think it would be that difficult.