Estimate velocity using quadrature encoder data

Many motors offer a quadrature encoder that give feedback on whether, and in which direction, the motor shaft is moving. But if you’re clever about analyzing the data you can use a quadrature encoder to estimate motor velocity. [Jason Sachs] makes the case that it’s fairly easy to get this wrong. Lucky for us he has carefully laid out his process of extrapolating velocity from the two edge-trigger data sources.

The process starts with reading from the encoder. Many chips have peripherals that will interface with a rotary encoder, but hardware lacking that built-in helper can still be used by monitoring pin-change interrupts. Once connected samples are taken over time and the rest is left to the quality of your algorithm.

What can this velocity data be used for? That’s up to you. But we can think of a couple of projects. It may be useful in a spinning POV display like this FPGA-based beauty. You also find quadrature encoders in exercise equipment. Knowing the velocity will help if you’re building your own computer to replace what came with that Stairmaster.

Without reading the article but knowing basic physics…
Velocity is the change in position divided by the change in time aka v=dp/dt.
For quadrature/rotary encoder you can either (a) time between the pulses or (b) count the pulses. With (a) you are measuring dt for a given dp (360/resolution), with (b) you are measuring dp for a given dt (timer period, or 1/timer freq).
For absolute encoders (grey or analog), setup a timer for a given period (dt), record the position (p1) and the previous position (p2), dp = p1 – p2.

I have a Tempest arcade machine. It uses quadrature encoding to monitor the position of the spinners, with hardware decoders. Since the relatively slow CPU polls the decoder circuitry, it’s possible to spin the spinner so fast, the claw moves backward around the pipe.

I wrote several comments on the blog, but somehow they’re not showing up, or being removed by the author (perhaps because he wants to cover the same method in part 2?)

What I’ve done in the past is recording the number of pulses (or steps up/down), and the timestamp of the last event. The control loop would keep a copy of these values from the previous iteration, and calculate both the delta position and the delta time. It can do this, because it has recorded the timestamps of the last event of this cycle, and the last event of the previous cycle; therefor, the delta time always exactly covers the time between the counted events. So you calculate the delta position / delta time, where neither is constant, and the two are always consistent.

If the time since the last recorded event is longer than the time between the two previous events, the speed is dropping; calculating the time since the last recorded event will give you an upper limit of the current speed, so when no more events are received (encoder stopped), the speed will asymptotically go towards 0.

Umm. since velocity is a vector quantity, most rotary motors have zero velocity, even when they’re running. You could chuck it at your local mechanics nerd and give it velocity. ITYM “angular velocity” or “speed(rpm)”