A novel encoder interface for measuring speed
Andrew B. Wright, S. M. ’88, Ph. D.
6/22/2017 (under construction)
Next Posts: Beaglebone: 1. Bumper switches (off-PRU GPIO inputs), 2. PWM (turning motors) 3. I2C (accelerometer, light sensor) 4. Cape Wiring (pulls all the earlier electrical bits together), 5. Battery holder case (repurpose tutorial introduction), 6. range and identity detection, 7. PID control, 8. state space control, 9. mode selection logic, 10. redesigned CASSY robot body
The archive <- don’t hold your breath
I published the details of an encoder velocity measurement scheme in the 2013 ASME IMECE. This interface was implemented on a PIC based system. It looks like the PRU will be easy to translate.
Some thoughts on resolution and aliasing …
Nyquist would have us believe that the max frequency that can be reconstructed by a digital system is half the sampling frequency (this is true, yes it is). This number, however, is not the maximum velocity that can be measured. it is the maximum reversal in velocity that can be measured. The velocity for this measurement represents the magnitude of the signal, not the frequency.
The low frequency resolution is set by the one encoder tick occurring within the sampling time. This value is a function of both the number of divisions on the encoder, but also the sampling time.
The amount of bandwidth consumed is related to the number of divisions on the encoder. More divisions means more ticks to count.
The number of divisions on an encoder, therefore, sets the bandwidth (min freq to max freq) of the encoder. The sampling frequency pins down the end of the window. In order to extend the bandwidth, more divisions have to be added.
The magnitude of the velocity is also quantized by sampling. This can be figured by assuming that the encoder is moving in one direction (not reversing as in the previous case). At the high end, more and more ticks will occur in the sampling window. Each tick will consume processor time, so there’s not an infinite number of ticks that can be measured. With a PRU measuring a mechanical system, it’s safe to assume that the maximum velocity of the system can be measured.
Minimum velocity is more tricky. To resolve an actual event, at least one change (low to high or high to low) on one channel (A or B) must occur within a sampling interval to complete an event. To detect an entire event, two changes must occur. If those two changes occur just on the edges of the sampling interval, then the velocity measured would be 2*pi/Ndiv/Ts (i.e, 2*pi/Ndiv radians passed in Ts seconds).
In order to determine the frequency resolution, this amplitude of the velocity must be known. After all, in order to reverse direction, the encoder must pass through zero, which is not measurable. Rather, the velocity will pass through the minimum counterclockwise direction to the minimum clockwise direction within one sampling period. In other words, one positive tick and one negative tick have to occur in the sampling interval. In order to see these changes, the velocity must be large enough to allow the encoder to travel across one division.
See Accessing GPIO off the PRU for a list of CASSY pin outs. The encoder inputs will be done using P9. 27, 30, 41, 42. The bumper switches will go “off PRU” and use P8. 7, 8, 9, 10.
To test a switch, acquire a breadboard, a 1k resistor, a switch, and some jumper wires. Wire up the switch according to the pic.
NOTE: use P8-7, 8, 9, 10 instead of P9-30, since we’re going off-pru to interface the bumper. I’ll update the figure above sometime.
It turns out that getting gpio2 and gpio3 to work, a number of extra items have to be done. The normal inputs, gpio0 and gpio1, have these things turned on by default.
Let’s do a few tests before wiring the encoder up:
1. Use a voltage divider and 5v on the beaglebone to test the R31 inputs
2. test one encoder channel from the CASSY
3. test quadrature with two channels
Archived Post: Beaglebone: Adding i2c sensors to CASSY