Encoders, interrupts, and edge-triggering issues
 

I just fixed a nagging problem with our encoders tonight. The nature of the problem is such that I think many people might be suffering from it. Here's the deal:

The encoder counts wouldn't always track the motion properly. Theoretically, for one full rotation, the software should always see exactly 64 counts. On occasion, it would apparently miss counts. Even though I was sure the rate wasn't too high, I added the 7474 "Phase B Catcher" circuit. I don't know whether or not that fixed the original problem, or if I was misunderstanding what was wrong in the first place, but a new and consistent problem appeared: it would often give extra counts.

Analyzing the situation yielded a theory. If the encoder were at a point where a little bit of wiggling made the Phase A signal change, it would get an interrupt for each wiggle past that point in one particular direction, because the interrupt is configured to occur only for one edge. That theory was supported by intentionally wiggling the encoder back and forth repeatedly until it started counting with no net motion actually occurring.

To fix it, I added code to toggle the interrupt edge from rising to falling, and vice versa, each time an interrupt occurred, and to treat the Phase B signal backwards for the additional edge. Now it interrupts (and counts) twice as fast, but it never loses a count or sees an extra one.

And the 7474 circuit apparently isn't necessary -- saving almost a half ounce of weight. :)

Re: Encoders, interrupts, and edge-triggering issues
 

Alan,

Yes, this effect is easy to produce with encoder in hand, but I can't imagine this would ever be a problem in practice because any mechanical system that you'd couple the encoder's shaft to will possess far more rotational mass than the shaft alone. This coupled mass, in general, will strongly dampen vibrations that might cause this effect.


It may not be a problem for you, but I suspect doubling the number of interrupts per unit time will cause problems for many people.


I'm not sure I would make a blanket statement like this.

-Kevin

Re: Encoders, interrupts, and edge-triggering issues
 

It's a problem in our practice. The mechanical system to which we have connected our encoder is a very small, very light omniwheel which rolls on the carpet. Like any simple omniwheel, it bounces some as it rolls. I guarantee that without the additional interrupt-edge-switching logic we get spurious counts, and with it we do not.

We're using a 64 count per revolution encoder. At an unreasonably high 15 fps, it would normally generate about a thousand interrupts per second. We figure the PIC can easily handle "several" thousand interrupts per second, so doubling the rate shouldn't break anything. Even at the unreasonably fast rate, the time between Phase A changing and Phase B changing is greater than 200 microseconds, plenty of time for the interrupt service routine to read the Phase B state. In our application, at least, the pulse catcher circuit is not needed. Indeed, it would not work for us at all without significant modification to clock on both transitions of Phase A.

Re: Encoders, interrupts, and edge-triggering issues
 

Alan,

We did exactly what you have done last year, but for different reasons. We haven't noticed the same kind of missing or phantom pulses as you've described, but last year we had only a 16 count/rev mechanical encoder handy, 0 days left to ship, and a wrist motor that needed to be limited and controlled in autonomous mode.

The 16 counts were not quite enough resolution, and gearing it was not possible due to weight and time, to get the positional accuracy we needed, so we interrupted on both the rising and falling edge, and reversed inc/dec behaviour based on the B-phase for the additional interrupts. It was a super quick and dirty way to get 2X the pulses from your encoder.


THIS year however, is a whole other story.


Not wanting to be left out in the cold again, we sourced some Grayhill 63R256s to place on our drivetrain and elsewhere. At low speeds, they performed wonderfully. Even at highspeeds, they performed wonderfully, without the 7474 signal stretcher...

But if you jerked, or bumped the robot - anything causing a momentary quick (albeit small) movement - we would often see pulses in the wrong direction, and the PID loop would compensate erroneously, sometimes causing runaway motors.

We built and installed the 7474 signal stretcher circuit, and it's cleaned everything up very nicely.

If it were my decision, regardless of your count rates, I would use the 7474. Your average count rates are one thing, but if EVER there is a situation that there will be a "bump" or other short, very fast movement where even two counts will come in very fast, then I would highly recommend the 7474.

-SlimBoJones...

Re: Encoders, interrupts, and edge-triggering issues
 

Hello,
We are having a similar problem with our PID control at high speed. Could you please direct me to some information on the 7474 signal stretcher circuit. Any circuit diagrams/types of chips used would be extremely helpful.

Another thing I was thinking was putting in our PID code into the the Process_Master_IO part of the code which is being called every cycle at a faster rate than 26 ms. The thinking is if the phase-B will operate at a faster rate giving the code more consistency. If my idea is completely newbie and unfounded for, don't be cruel.

Thanks for your help.

Re: Encoders, interrupts, and edge-triggering issues
 

On a "whim", we purchased a bunch of "budget" encoders to see if we could get them to work (they were less than $2 each). I made a little low pass filter by adding a capacitor between the output and ground on each phase (about 0.01uF-0.1uF seems to do the trick, thus far). It helps increase the time it takes the signal to go high due to the RC time constant caused by the pull-up resistor that is supposedly at the input pin. We have yet to *really* test it, but it really seems to rid of the noise associated with the aforementioned wiggling.

By "yet to *really* test it", I mean that we've hooked the shaft of the encoder directly to a drill running on the higher of two speeds without skipping pulses. We tested it briefly on the actual robot going around 8 ft/sec and it was working acceptably well from what I could tell. The plan may be to go ahead and order the $20 encoders everyone else is using, but it would be nice to know if the noise will really be much better for an optical encoder.

If anyone has an oscilloscope and is going to be at the Boilermaker Regional, let me know....

Re: Encoders, interrupts, and edge-triggering issues
 

Kevin Watson posted this schematic:
http://kevin.org/frc/encoder_phase_b...ng_circuit.pdf

It works great (though it didn't solve the more mechanical issue in our case).
No, that won't do what you want it to. The PID function is written to work correctly only if it's called at a regular rate, and the "fast loop" doesn't have a guaranteed timing. It runs quickly most of the time, but gets delayed every time the 26 ms communication arrives, and there's no easy way to determine how often it runs.

You almost certainly don't need the PID sampling to run more quickly than 39 times a second anyway. If the mechanical response of a system is faster than that, it's probably not going to need PID control in the first place.