<p> How to use a Quadrature encoder</p><p>As we know when we are thinking in simple easy and developing Localization system we can think about shaft encoder sensor that sense the number of revolution for a wheel so in this tutorial we will talking about the Quadrature encoder (" ("that Mounted in rover 5S platform</p><p>:Firstly if you want to create your own library here is some explanation :and steps to implement that</p><p>Quadrature encoder software is quite trivial. For low speed you can measure the time between pulses and for high speed you can count the pulses. Adafruit has example code for ::counting pulses. In general</p><p>Set up the associated I/O pins as inputs with Interrupt On-1 Change</p><p>Build a simple state machine to remember current state,-2 count, and direction</p><p>Create an ISR for the Interrupt On Change-3</p><p>Inside the ISR read, isolate, and align the I/O bits of-4 interest. Compare with previous state. You have 3 possible conditions: No Change, A follows B, B follows A. With this information you know direction. Increment or decrement the associated counter. Do NOT use a switch() statement .within the ISR as it is very slow</p><p>On a regular basis, ie every 10msec, read the counters,-5 convert to speed and distance, and zero the counter. Be careful to mask off interrupts when clearing the current .count</p><p>There are two channels typically called A & B. Each .generates a square wave that idealy are out of phase ----|___|----|___|---- A ____|----|___|-----|_ B In the above drawing channel B follows A. For this .condition we could assign the direction to forward ----|___|----|___ A ____|----|___|--- B</p><p>In this case A follows B and we would call this reverse. In all .cases, only one channel changes</p><p>It is necessary that the processor is fast enough to process the data before the next transition. Your encoder generates 8 transition on both A & B per motor revolution. If I recall correctly, the wheels are geared down by about 83:1. If you motor is spinning at 6000RPM that is 100 per second * 8 transitions / sec or 1.25 msec per transition / channel. For 4 encoders at 2 channels this means you have to process an !!!!interrupt every 157 usec. Please check my math Assuming 5usec ISR processing time per interrupt you should be able to keep ahead. Note that sometimes you might get transitions on multiple encoders at the same time. This will require some thought on your part. Lock out interrupts and service just one encoder or loop inside the .ISR to check for other active channels</p><p>Another "trick" is to only use quadrature encoding at low speeds. Once the motor is going fast you "know" it cannot .change direction in 0.1seconds</p><p>It is often necessary to disable interrupts when doing this type of work. Incrementing a 16-bit counter requires multiple CPU cycles and you do not want the main task and .ISR code to each overwrite the other</p><p>BTW, I only use software encoding for low speed systems. For anything that would begin to tax the CPU I would switch chips to one that has hardware support for .quadrature encoding such as the Microchip PIC24F series</p><p>I recall having some Arduino code to a very low speed test. .Will look and post later</p><p>: Secondly if it’s hard to implement your own system , there is a :library Compatible with this encoder type here is it </p><p> https://www.pjrc.com/teensy/td_libs_Encoder.html</p>