[Phazonmutant]

Just read over the thread, here's some thoughts from a 2nd-year team member: (warning, long)

1) For the teams that don't have mentors experienced or trained in engineering, it's difficult to understand how signal processing and sensors play together. For example, I've never even heard of things like high-pass or low-pass filtering - I thought accelerometers returned pretty decent values. Therefore, it seems like what we're going to go for is the simple solution that's been mentioned - limiting the rate of change of the joystick.

Regarding that, if you dig into the Jaguar.cpp class, the SetSpeed method (I believe) has an exponential curve implemented by default. It shouldn't be too hard to modify this to have a variable curve.
Specifically:
The Atack3 joystick has a "throttle" knob below the joystick. In the default code, this switches between Arcade and Tank, but I'm pretty sure custom code won't do this (haven't actually checked though). If that's the case, it should be simple to have the knob set a curve power that you pass into the SetSpeed method.

That may be a little unclear, so just to explain - the SetSpeed method essentially performs this function on the passed speed:
f(x) = x^p,
where x is the (passed) speed and p is the passed power, f(x) is the speed going to the motor.
By default, p=2. The knob could set this to be anywhere from 1 to say 5. The slope of this curve will be increasing for p>1. As p increases, the slope increases faster; that is to say, the second derivative of f(x) is more positive.

If I understand the formula correctly, though, you'll need to add a coefficient for each p that fits the curve to the 0-255 range that the jaguars can accept. However, the SetSpeed method is called for both autonomous drive and teleop (which raises the question of why there isn't the coefficient...). So, given that the joystick ranges from 0-100 on a given axis, you'll have to adjust the passed speed in the Drive method. I haven't quite worked this out, but I think the basic concept is sound.

Theoretically, the benefits to this approach are (a) a simple-to-understand and code change that can (b) produce a much more fine-tuned traction control system that doesn't involve complicated sensors.
Also, this would be simple enough to code for turning, too.

2) Our team considered having the wheels mounted on two axles that pivoted opposite of each other (ex. front turns clockwise while the back turns counterclockwise to turn the robot right), but after calculating the turn radius (especially with the trailer), it wasn't deemed worth it. Has anyone actually built something like this?

3) Just to clear up some confusion regarding the "minor" gains from traction control: Other people have pointed out that just looking at the difference in dynamic and static friction is oversimplistic, but that's not even the main reason to use traction control. Wheels deliver negligible power when they're slipping, so the main goal of a traction control system is to limit slippage. This has the benefit of improving handling.

4) If the accelerometers are noisy, wouldn't differentiating their output to get jerk result in even more noisy data? Also, question for those who don't have a problem with noisy accelerometers - do you buy custom ones?

5) Would calibrating the motors result in increased performance? How would one go about that?