Suggest a wheel encoder

edit

Hi Mark,

Thanks for the answer. Yes as you said reading the odometry cable is the bes choice but unfortunately that is not an option I have. I'm working with an actual electric car, so its powered my a motor with an built-in ecoder. Will reading that give me an accurate distance measurement?

I'll write a program to calucate the distance using the encoder ticks. Or should I use a seperate encoder as you suggested and interface it with the backshaft?

If you have access to the motor encoders, that would be best. I have mostly worked on differential-drive systems, so there is a simple strategy for using both encoders. I presume your car has Ackerman drive. The math is different, but if you have steering, then slippage should be small.

As far as using the encoders, you'll get two bits of input, call them A and B. They will cycle through 00-->01-->11-->10-->00, or the opposite order. If you concatenate the old and new inputs into a single 4-bit value, you can do if-else or switch to determine whether to increment or decrement.

Alternatively, if you get interrupts only on changes to the A input, then code like this will suffice (or might have the wrong sense, depending on your wiring):

if (A == B) {
    ++ticks;
} else {
    --ticks;
}

There are also packages to do this, depending on your hardware.

Hi, Thanks a lot again. I'll first look into to the encoders and try to code them as you suggested and get back to you when I have some results

One more thing: your motor controller may already be reading the encoder inputs, and there may be a way of reading a cumulative value from the controller. (Don't know anything about your hardware, of course.)

Hi Mark,

really sry for the late reponse. I finally got to know more abt the controller. It is a Curtis 1236 motor controller and it is communicated with curtis 1314 programming software which uses VCL. Coming back to your question, yes the encoders are already connected to the controller.