[nathanww]

To me the driver, it feels like there is a "delay" in the system.

Not to go too much into technical discussion, but the delay you're noticing is likely due to the physics of the playing field. Essentially, high responsiveness=large,sudden changes in motor speed=slipping=decreased responsiveness. The job of the traction control system is to keep manuevering within the envelope where it is not slipping. If tuned correctly, this will mean that overall maneuverability and acceleration is increased, but if it is overzealous the reverse might be true.

There are many options that allow for quick control. One of the ones posted (by 121 I believe) had encoders mounted on free-spinning wheels, one on each side.

Actually, a purely closed-loop traction control can be quite slow because you have to wait for enough data to come in. Otherwise, you might be dealing with a situation where, say, a motor encoder has registered 1 tick and a follower has registered 0. If you don't wait for enough data, this will indicate that you're operating at 0% efficiency. The technique that we're using to correct this problem is a "hybrid" approach--a basic ramping system limits acceleration to somewhat reasonable values while we wait for an average from an accelerometer.

Have it only enable when a button is pressed, or don't use it at all. This allows the driver to drive in 'raw' mode most of the time, then use traction control when quick acceleration is needed.

I would be extremely cautious about doing this, because

1. Functionality of the robot != responsiveness to commands. The cRio is capable of making tactical descisions in the time it takes a human driver to blink. With something that requires as much prescision as traction control, the robot needs to be able to override the human operator, not vice-versa
2. Similar to this, making an effective descision to disable a TC system requires understanding at a low level of what is going wrong with the system. If you think that you can do that with the robot 50ft away from you, on a competition floor, while driving, in about 10 seconds, that's great, but otherwise it's likely that mucking about with the robot's programmatic internals on the field will do more harm than good(our original plan was to have a system to essentially fix common problems that might come up with the robot from our OI, but we scrapped this after we discovered that our drivers thought process was something like "robot acting odd->mash buttons"