I'm using an Mbed to drive a DC motor which will follow a trapezoidal trajectory. What is the most appropriate way to determine position from the quadrature encoder?
Should I use interrupts, or is there a risk of the trajectory routine (which calculates theoretical position) falling behind?
Alternatively, I could poll/sample the encoder in fixed time steps, but I'd imagine this would miss out many encoder counts.
How is this problem usually dealt with?
It's best if you have quadrature encoder hardware to handle the encoder pulses, unless the speed is very low. Many microcontrollers have at least one such peripheral on the chip.
You have to poll the state of the two Q input often enough not to miss a state transition. How quickly this is depends on how quickly the Q inputs can change, and only you can tell that. The correct way to do the counting is to use a 4-state FSM, which handles bounding and direction changes correctly.
How do you check often enough?
as Sphero stated, using Q-decoder hardware is a perfect way, and it will liklely be fast enough for any purpose.
you can use a timed or on-change interrupt to tickle your FSM. How fast you can do this depends on your system, and how much of its resources you want to spend on this task.
for in-frequently changing Q-inputs you could just poll the inputs.
A very great deal is going to depend on your motor/encoder setup, which you have not specified. Let's say (just as a starting point) the your motor shaft can run at a maximum of 600 rpm (10 rps) and your encoder produces 64 pulses per channel. That is, if you run the shaft at 10 rps, you get a 640 Hz square wave on each channel.
When using a quadrature encoder, you can derive 4 times as many position events, corresponding to both the rising and falling edges of the two channels, for a shaft resolution of 256 points per revolution, or 2560 points per second.
You have not provided a processor board specification, either, but let's say that it allows 4 channels of digital inputs. Then you can look at both your encoder channels, and also a pair of channels which have inverted versions of your encoder lines. Now you can write your software to generate an interrupt on each of the rising edges of the 4 inputs. At each interrupt you examine the two encoder lines and determine the local position. At the same time, you read your real-time clock to determine the time since the last encoder tick, and from that determine the shaft velocity. Can you do that in (let's say) 1/10 of the time between ticks? That's 40 usec. Also, you'll need to find some way to prevent any other interrupts from preempting your encoder routines for more than 400 usec. If you don't, you lose position information, and any process which prevents immediate time interval measurement will screw up your shaft rate calculation.
With only a small about of hardware (a couple of exclusive-OR gates and an RC delay) you can produce a single input which will generate interrupts for all four encoder transitions, so you could get away with 3 digital inputs.
If the transition frequency is low, as Wouter van Ooijen says, you can try simply polling the encoder outputs, but be aware that this will introduce uncertainties in your shaft velocity calculations, especially if your processor is doing anything else which may have higher priority, and any such uncertainty will degrade your ability to hold to a desired velocity profile, trapezoidal or otherwise.
Overall, I'd advise you listen to Spehro.
