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:
Set up the associated I/O pins as inputs with Interrupt On Change
Build a simple state machine to remember current state, count, and direction
Create an ISR for the Interrupt On Change.
Inside the ISR read, isolate, and align the I/O bits of 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.
On a regular basis, ie every 10msec, read the counters, convert to speed and distance, and zero the counter. Be careful to mask off interrupts when clearing the current count.
siiiir , you got me , that is what i wanted but please can you explain it in more detailed
first i have 2 channels per encoder so there is A and B
second when im moving forword For example Channel A should be high and Channel B should be low
thirdly can you explain how i can compare the next state with the prevouse state like flow chart on something like that
fourthly you said (
On a regular basis, ie every 10msec, read the counters, convert to speed and distance, and zero the counter. Be careful to mask off interrupts when clearing the current count.)
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 —||----|___
In this case A follows B and we would call this reverse. In all cases, only one channel changes.
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.
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.
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.
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.
I recall having some Arduino code to a very low speed test. Will look and post later.
I’m a beginner in these jobs and I want to make a system that just walks forward when I try to shut it down. My question is whether I should buy a car kit with encoders or without. In what cases are encoders justified?
Which Arduino are you using? I think the Uno only has two interrupt pins, whereas you’re trying to catch state changes on four signals. I recently got the encoder reading working from a Rover 5, but I used an STM32 instead of an Arduino because I wanted faster processing for faster speeds, and I wanted to catch all four encoder signals. It’s working great so far. I can put the code here if needed. It’s almost the exact same code that would work on an Arduino.
When are encoders justified - when you need to know or control the exact speed or distance that your robot travels. If your robot doesn’t drive straight, you can use encoders to detect that one wheel is moving faster than the other. If you are using sensors to map an area, you would need to know exactly how far your robot has travelled. Encoders allow you to know how far your robot has travelled, and where it is in relation to its starting point. They are not the easiest thing to get integrated into the control of a robot. If you’re just getting started then I wouldn’t recommend taking on the use of encoders until you’ve gotten very comfortable with programming and wiring the basic control of the robot first. There’s nothing wrong with having them installed and ready to use though. If buying a Dagu Rover 5, I’d recommend getting the one with encoders. They’re hard to add later if your motors don’t support them.
Here’s the code that I put together recently to read encoders from my Dagu 5 Rover. This is for a Maple Mini STM32, but I think it would work just fine on an Arduino that supports at least four external interrupts (Mega, Leonardo, Due). The Uno/Nano only support two interrupts so I definitely wouldn’t recommend them for reading wheel encoders.
