[JDNovak]

Joe,
You bring up a lot of interesting conflicts.
We tried traction control in 2009 by cascading a velocity loop with a ground speed loop providing the target speed but that was through the CRio and we were trying to keep the wheels spinning just slightly faster than the ground speed.

Pre-processing the feedback is interesting. Using something like a USDigital MA-4 to provide an analog position and processing it fast enough to push the Jaguar sample time could be useful. I tried it and failed years ago because of throughput limits of the IFI system but a dedicated processor now days could probably pull it off. I'm not sure of the analog conversion rates on an Arduino.

I have pretty well given up on using absolute wheel position for autonomous distance because of wheel slip issues. This year our carpet was enough different from the field carpet that we had large errors when we tried to go fast enough for double tube scoring. I feel like trying to increase the wheel coupling will create problems that we don't have now with motor overloading and drive train reliability. Instead we went back to an encoder with an omni-wheel running on the floor. We have used an X axis encoder to control drift and crab angle fairly successfully too. I haven't tried to use this for velocity feedback yet but I think it is possible. I do know that the absolute distance accuracy was repeatable even on tile and with careful control over down pressure it held up well.

The issues of synchronization using CAN are still unresolved as far as I can tell. We tried synching our two elevator motor Jaguars several ways including paralleling the encoder to both, copying the output of one to the other, and using the CAN synch commands and the two would never stop at the same position. One would still be driving and heat up the motor if stopped long enough. There is a long thread on CD from this year on the subject and I don't think a solution ever surfaced there either. We finally had to use a cRio PID loop with the output sent to both. Eventually we went back to PWM and used a Y cable. This was because of a CAN system problem that we never could totally avoid where the bus just wouldn't initialize occasionally and we had to manually reset if it happened on the field.

I don't know if any of this directly addresses rate control but all these affect the ability to pull it off well.