[mmaunu]

If you can, I would urge you to do as Ether says and get an incremental encoder. We love these from US Digital:
http://www.usdigital.com/products/en...tary/shaft/S4T

(Well, we actually use the older S4 line, but they are kind of discontinued [you can order them if you call them up, but they are encouraging new customers to move away from the S4s]. The S4T seems to be the successor to the S4.)

We get them configured as single-ended with bearings. They are not cheap, but they are great!

EDIT: DO NOT USE THESE FOR YOUR DRIVE TO MEASURE DISTANCE. SEE ETHER'S POST BELOW.

If you need to, you can use the MA3 (which are also great encoders...but trickier to use in this scenario). We have used MA3s to maintain state for a shaft that has multiple rotations by creating a wrapper class with an MA3 field. The wrapper class maintains a separate position variable (a double) that gets updated based on a delta we acquire from the MA3. Basically, as the data from the MA3 changes, we calculate the change from the last reading to this reading, and then we update the separate position variable in this class. You should be able to map the value of this separate position variable to distances traveled.

Here's some (Java-esque) pseudocode.

class MA3Wrapper implements PIDSource {
  MA3 ma3;
  double position, lastMA3Value;

  void updatePosition() {
    double currentMA3Value = ma3.get();
    double delta = currentMA3Value - lastMA3Value;
    //the reality is that the delta calculation is complicated by the wrap-around
    //behavior of the MA3, but you can figure it out...left as an exercise for the reader?

    position += delta;
    lastMA3Value = currentMA3Value;
  }

  public double pidGet() {
    return position;
  }
  
}

With something like this, you would call updatePosition() periodically (in a separate thread or from teleopPeriodic() and autonomousPeriodic()). You could use the wrapper as a PIDSource for a PIDController object. Again, this is Java-flavored but I believe that a C++ implementation would have similar elements.

You will have to map the position variable to some real-world distance to make it meaningful, but you will have to do something similar to give meaning to an incremental encoder's count as well.

Lastly, if the encoder can turn more than half a revolution between updates, then your position will get off. That might make it a deal breaker in this case depending on what shaft you monitor. It should be fine if you monitor one of your wheel's shaft.

Hope it was helpful and not just some incomprehensible wall o' text.

TL;DR It's doable with an MA3, but it would really be better to get a good incremental encoder.