Friday, March 7, 2008

Timeline for Future Progress

First, the bad news: I probably won't be making too many updates to the bot for a few months. I've got competitions, scouting, scholarships, school to do. Once I graduate, I expect I'll spend far more time actually working on the bot.

At this point, I don't think I'll need the shop anymore, unless I want to make the bot go faster, which would more likely be a sprocket issue. Almost all the issues are with the software (although a reliable way to test the gyro wouldn't hurt). So, once summer kicks in, expect a lot more updates about how the project is coming. Until then, be patient that it is a little quiet around here.

Thursday, March 6, 2008

Software Overview

This post may be edited later, but oh well.

The software to run Mecanum drive with robot-centric drive is just some formulas. Field-oriented drive simply adds a step to the process. I fully expect the complicated part to be getting the motors to drive at a consistent speed, to eliminate drift (PID loops). And that much assumes that your wheels are always making consistent contact with the floor.

In my software, the first step is to convert the controls from field-oriented to Robot-centric drive. I actually use three steps to do that. The first is a hardware-specific function to fetch the controls. This returns a structure describing the controls in as raw a way as possible. The second step is to do basic interpretation/standardization on those controls. Specifically, some mappings are applied to adjust the deadzones, flip the x-axis of the joysticks around, what have you. Finally, I use a rotation matrix (based on current gyro heading) and inlined matrix math to compute the robot-centric controls from field-oriented controls.

After computing the controls, we use some equations from this presentation on drive systems (warning: The diagrams show the rollers in an 'O' shape, but that is a bottom view; a top view has the rollers in an 'X' shape). You only need to include the (a+b) part if you want to be able to move your rotation center, or if your center of rotation isn't at the intersection of the x- and y-axes of symmetry. If you include code to auto-correct orientation, that would go here as well. The difference between the current gyro reading and the previous gyro reading should give the bot how much to adjust the user's requested turn by to correct for drift.

Repeat for an unknown and long period of time.