Urgent issue on encoder interruptions and PID timing

Hello,

We are a group of engineering students very close to a deadline on a robotics projects (roughly 32 hours...)

We are stuck because of what seems to be a timing issue that is causing us to miss encoder ticks when we try to move the robot at any decent speed. We are using 2048 PPR rotary encoders handled via interrupts, and want to use the data to update a PID control system for the motors.

We designed to the system on Matlab to handle via an error on position and speed, for now we would be happy enough if just the position part worked properly.

Originally we had coded the interrupt functions so it got ticks on both A and B of each encoder using 2 digitalReadFast2 for each.
We called the automatic control functions through an isrt running through flexiTimer at different intervals (we had hoped for every 50ms but even 200ms would be fine).

We would miss ticks constantly, and would cover about 33cm for the robot to have thought it covered 30. We think this is because somewhere we are missing ticks, possibly due to interference from the flexitimer interrupt...?

So a few questions :

  1. any idea on our problem?
  2. is flexitimer interrupt going to interfere with the encoder interrupts?
    If we try and call the function every 50ms with milis() that's even worse right since it disables them reactionaries interrupts whenever called? Anyway to do something with interrupt priority to be sure not to miss ticks?
  3. is there a difference between digitalReadFast and digitalReadFast2?

We are trying to modify the interrupt functions for the encoders based on this article :
http://www.hessmer.org/blog/2011/01/30/quadrature-encoder-too-fast-for-arduino/

We hope this will maybe make the interrupt routines for the encoders faster and let us miss less ticks

Thanks so much for any help! We are stuck and not that familiar yet with real time constraints.

Easy_Slave_V7.zip (5.97 KB)

How did it go?

If you are using pin change interrupts on your rotary encoders, why do you need to do a digitalRead? Aren't you just interested in the transitions?

Every time your timer interrupt runs, it will lock out the encoder interrupts so you will miss steps. What about a busy wait loop instead?

I would advice on:

1 Isolate ONE problem: extract from the code just a small piece that HAS THE SAME problem than the whole code, but JUST ONE problem. Keep it simple, comment it and post it. Post the concerned part of hardware.

2 Could be noise?. Could be serial.print ? (i've had quite a trouble using this).

Good luck.

Seems like a good example of the need to ask your questions in plenty of time ...

And (if you are serious about getting an answer) to check back with the Forum frequently ...

...E

is your input signal debounced in hardware? feeding a raw and usually very spiky encoder signalmdirectly to an interrupt pin is a BAD THING. your isr will spend a lot of time in and out cleaning off the spikes while it should actually be doing itsmproper thing. while its doing all that, other ints will suffer, e.g. timing ints

if the signal is seriously spiky, as it will be as you get faster, your ISRmmight spend so much time spike.cleaning that it doesnt have time to spot the other channel changing....thereby missing a beat

either way, you MUST have a bounce free clean square edge signal going to your ISR before you can b3gin to work out if there are any other timing conflicts.

thre are lots of folk out there who will tell you to expect all kinds of we if you feed dirty signals direct to an interrupt pin...after all,it was listening to them that got my encoders glitch.free, im just passing on hard.won wisdom I stole form others, but it works.