Which is more accurate for turning: gyroscope or shaft encoders?
Which is more accurate for total distance: accelerometer or shaft encoders?
How about IME vs the big red encoder?

I'm an FTC team member, but this should still apply

From my extremely limited experience, the TETRIX encoders we have are pretty accurate, but inferring position estimates from them quickly degenerates into dead-reckoning (<-- avoid at all costs!).

Which gyro+accel combination are you using? We're planning on coupling this with a prototype board, but I doubt that we're fusing the accelerometer data. From what I've heard, if you can get your head around the Kalman Filter, you'll be fine.

Gyroscopes are accurate for short time frames, but tend to "drift" away from the true position over time. Accelerometers, on the other hand, are "noisy" (i.e. give inaccurate readings) but don't drift. Which is why they're usually sold in combination Some are even packaged with magnetometers, although I tend to wonder how accurate those are next to so many motors.

LIS344ALH acceleromter http://www.vexrobotics.com/276-2332.html
LY3100ALH gyroscope http://www.vexrobotics.com/276-2333.html
Why does using the encoder for positioning degenerate into dead reckoning?
Should a combination of all of them be used?
How long does it take for a gyroscope to drift? The maximum time that it will be active for is 2 minutes, but there is another period (separate from the 2:00) that it would only be active for 15 seconds.
thank you.

Is this for Toss Up? (http://www.roboticseducation.org/vex-ro ... rent-game/)
I don't know how many sensor ports the PIC has available, but if you have enough, more sensors is always better
2:00 should be fine for a gyro of that price...
http://vamfun.wordpress.com/tag/ly3100alh/
This guy seems to have done some testing, according to him, you'll have a total of less than 0.5 degrees of drift. So you should be fine.
Again, if you can understand the Kalman Filter (and implement that in RobotC), you could go for hours without significant problems.
If you're positioning yourself (other than extremely low-level code) using encoders, you're probably going to end up doing it too much, and before you know it, your entire autonomous program will be dead-reckoning If you can control yourself though, have fun!

(We plan on using a much cheaper gyro, and we might end up manually correcting it during tele-op with a button or something.)

Yes, it's for toss up. I'll try out the Kalman filter for the accelerometer. Should encoders be used for distance measuring only, or not at all? The gyro seems good, with that kind of accuracy, turning should be perfect. I had always thought that dead reckoning as going turning on motors for a certain amount of time without any feedback.

Well, generally dead reckoning can be off of anything (be it encoders, time). Wikipedia just says it's estimating position based on previously known conditions (speed in this case). So, basically, an open loop controller (without feedback).
Don't forget to use both gyro and accel data in your Kalman filter; they make up for each others' shortcomings.

thanks a lot!