Debouncing Encorders and Debugging them

[TrickyNekro]

Hello again, Happy new year...
I'm having a problem with my encoders....

I know they are of poor quality but this now becomes quite devastating...
I read the encoder inputs as interrupts, but there are not noise free... in fact they give a a hell of noise... (debounce effect)
I use differential drive which means that I use two encoders no quadrature....

The two threads have differences so encoders are needed...

My problem is that the code on encoder debouncing isn't going to work right no matter what....
In order to cancel debouncing I use a pause... right??? right!!! But with two interrupts and a big pause
I LOOSE steps!!!! which is no good... With small wait time I have more steps!!!
I found that a good debouncing time is that of 10ms but still I'm not happy with it...

So has anyone in mind any good piece of code for encoders generally... And how I'm supposed to improve the
efficiency of my encoders???


Thanks in advance, Lefteris
Greece

[cosminprund]

How about this: Use a timer interrupt that gives you a 1 ms interval. Set up an counter for each of your encoders. In the interrupt service routine for the encoder test the counter, only do work if the counter is zero. If you do some work then init the counter to a constant. In the timer interrupt dec all counters (unless they're allready zero).

Pseudo-code:

Code: [Select]

int enc1;
int enc2;

void enc1isr (void) {
  if (!enc1) {
    enc1 = 10;
    // do the normal stuff
  }
}

void enc2isr(void) {
  if (!enc2) {
    enc2 = 10;
    // do the normal stuff
  }
}

void TimerISR(void) {
  if (enc1) enc1=enc1-1;
  if (enc2) enc2=enc2-1;
}



[Asellith]

Better option would be to debounce your encoders with electronics.

something like this

http://www.bioinspired.com/users/ajg112/electronics/debounce.shtml

[TrickyNekro]

I understand what you mean but a timer here isn't necessary...
I use timer1 to do speed calc but then it's just it....

I tested the system and I have a new problem...
The one wheel is racing the other see the video I concluded....
How do I eliminate this???

[youtube=425,350]9jfRJCdamXA[/youtube]

[TrickyNekro]

Better option would be to debounce your encoders with electronics.

something like this

http://www.bioinspired.com/users/ajg112/electronics/debounce.shtml

Thanks!
I had to options to tell you the truth, one with schmitt trigger 74HC14 and the other using a voltage comparator...
I never knew schmitt triggers help with debouncing!!!
Thanks again... I'll try that... I also didn't knew about that capacitor trick!!!
I'll try it right away, problem one solved for the moment....


Still have the second though....


Best regards, Lefteris
Greece

[cosminprund]

I understand what you mean but a timer here isn't necessary...
I use timer1 to do speed calc but then it's just it....

With the software debounce you can guarantee that you take action every time your encoder does what it does to encode (don't know what encoder you're using) and that it only takes that action once. I assume your encoder is some sort of wheel encoder, that's triggered an fixed number of times per every rotation of the axle. If you know the maximum RPM of that wheel / axle you can calculate a "dumbness" period for the software debounce routine that's perfectly suited for your encoder. Example: If your wheel has a maximum of 200 RPM then you'll know your encoder should be triggered a maximum of 200/60 ~= 3.33 times per second. Since you can't have successive triggers faster then 300 ms (1 second / 3.33 ~= 300 ms) you can safely set a debounce dumbness as long as 250 ms! Since you're triggering an interrupt for the encoder it doesn't matter how weak or short the encoder signal is, as long as there's some signal.

I suggested using a timer for the debounce/denoise routine in order to do it with minimum changes to the software. If you're allready using a timer for something else then really, the change is insignificantly small.

Now I'm going to venture into the unknown and comment on the capacitor+schmitt trigger hardware debounce method: The math in that case looks allot more difficult to me. First of all you'd need an capacitor small enough so it can discharge fast enough for your encoder yet large enough so it can compensate for bounce. Unlike with a button this math is critical because you can't rely on the encoder staying down/triggered for enough time to discharge the capacitor, the wheel is continuously spinning. Maybe you could do it the other way around, discharging the capacitor through a diode when the encoder triggers and charging throw the resistor - that way the schmitt trigger would quickly change when the encoder is first triggered but resist moving back to it's untriggered state. As I've said, I'm venturing into uncharted waters here, I'm a software guy, not a hardware guy. Hope you use the hardware debounce and comment on it in your tutorial (the youtube title says something about an tutorial). 

Cosmin Prund,
Romania

[izua]

Multi-input debounce is done in the following fashion:

you allocate a timer to sample 10x or 20x the delay which is considered a valid state: for example, if a switch is on or off for 10 ms, it should be registered as on or off, but if it's on or off for several brief 3ms, that those states will not register.

in the case of an encoder, you should also consider the maximum output, which is something along the lines: max speed (rot/s) * lines/rot * 2 (if it's quadrature). your maximum delay is the value you get * 2 (to satisfy the nyquist sampling theorem, i recommend at least 8x for experience). Now, you need to configure your software timer to sample 10 times that value. if all 10 samples will register as on or off, than that particular input is debounced on, or debounced off.

you do this in a loop, and a vertical counter should take care of sampling and managing all the inputs. you basically reset an input counter if pin's value = registered value, and keep increasing the counter if pin's value != registered value. when the counter for a pin reaches 10, you basically switch the registered value to the pin's value.

take note that deboucing works both ways: you have noise so a single 'click' might register as several when pressing, but when releasing, the same noise might trigger more samples, or if the user is jiggling his hand on the button, it might cause a premature.. ahem.. detection of release (trying to avoid an obvious term here ).
This is esspecially valid for a mechanical encoder, because the speed determines the rate of switches, and the noise is similar in both directions of transition.

my personal opinion: you don't know to code well. no good programmer uses pause for such important tasks. also, this kind of stuff is usually mantained by a separate mcu. polish up your skills.
another thing might be that you're using low quality encoders. don't settle for anything lower than optical.

[cosminprund]

my personal opinion: you don't know to code well. no good programmer uses pause for such important tasks. also, this kind of stuff is usually mantained by a separate mcu. polish up your skills.
another thing might be that you're using low quality encoders. don't settle for anything lower than optical.

I assume you're talking about MY software skills (cosminprund) since I'm the only one that posted code in this thread, but you do realize the encoders are not mine, since I'm not the originator of this thread. Also would you mind explaining why you'd assume my version of the code would be so bad, since an encoder is not generating an analog signal but an square-wave-form signal and it's highly predictable. The Nyquist–Shannon sampling theorem applyes to analog stuff, or that's the way I understand it:

In essence the theorem shows that an analog signal that has been sampled can be perfectly reconstructed from the samples if the sampling rate exceeds 2B samples per second, where B is the highest frequency in the original signal.

So far I'd only add something to my code to make it less likely to miss-fire if the encoders have the bad habit of firing when they shouldn't.

[izua]

Nope, I was talking to the op.
I find it disturbing that someone advanced into te robotics field as the op actually consideres to use a pause construct to debounce.

@cosmin: how do you like it here? I see you're close to the hundred posts, glad you're enjoying

well, as I see it, the SN theorem applies to any kind of signal. you have to do a little twisted thinking to see how it applies in this case, but I think it's the same: if I want a debounce of 10 ms, by sampling at 10 times the frequency (1 ms samples), I am effectively creating a low-pass filter. Now, the theorem states that I need to sample at twice the most highest frequency if I want to be able to store/render it. I know that sampling a 20khz sinewave at 40khz will show a square signal instead of the sine wave.
This is exactly what happens here. If you take two samples out of your 10ms range, you have a higher chance of sampling parasites, than if you take several samples, and average them out.

The problem in the OP's case is that his software might not be considering the sampling theorem, and it waits waaay longer than it should, losing steps. I'm not sure if I'm really clear on this, it's quite clear in my head, but it doesn't sound right when it comes out

[cosminprund]

@cosmin: how do you like it here? I see you're close to the hundred posts, glad you're enjoying

I like it here. I've been around many forums but this forum is quite unique: I see young people mixing with more experienced people and really experienced people taking time to answer basic questions (without getting aggravated).

As with the NS theorem it just seems to me it's not a perfect fit for debouncing an input because it seems to deal more with approximating an analog signal. Maybe I'm just not being creative enough with my interpretation. When debouncing we're not trying to get a reproduction of the input signal, we're just trying to avoid taking action on the brief period where bad signals might exist. Outside that brief period the signal would be clean, perfect "0" or perfect "1". This particularity gives us the freedom to implement many different solutions, possibly better suited to the problem.

[TrickyNekro]

That was a long answer, thanks!!!

Look.... 250ms delay is not possible at all... The encoder wheel is separated at 24 pieces and I can either have 24 interrupts per revolution or 12....
Of course to reduce noise I selected the 12 interrupt per revolution (you can have the interrupts to fire of at pin toggle or do edge detection)
Will loose most steps this way... And when executing an interrupt no other interrupts routines can be handled.... extreme problem!!!!

I installed hardware debounce last night and plus to the software debounce it work good enough... smoothed things a lot....
I can't be possibly use a timer.... I can set it.... cause I have a spare one, but timer is too produce an interrupt
and there is no interrupt in interrupt routines.... So it's impossible to debounce with timer...

Apart I use timer0, timer2 in PWM mode and timer1 as a CTC with OCR1A interrupt enabled....
I also accept that the encoders are the same thus, I get the same error from them...
Soon I'll be using UART interrupts... Crap that's too much... but hey.... I like it!!!!

I'm beginning to understand the code I need... so that's good...

And Yup, sooner or later I'll have a tutorial... But the bot is gonna be hell more complicated.... That's for sure...
But it will be a step to step tutorial... to easy up things

[TrickyNekro]

@ izua

So how do you really suggest that I build my code...
I simply though...
How many fragments I have??? 24 per revolution... I assume that the maximum speed is 100 rpm cause it's a wheel encoder
100rpm is ~2rps... 24 fragments, produce 12 interrupts per revolution so we have 12 * 2 interrupts per second
So we have 24 interrupts per second which is like frequency doesn't it???
So f = 24Hz which means a T =~ 41msec
Considering that I have 2 interrupts T =~ 20msec
So that the maximum pause time for its interrupt...

I'm using a ATMEGA32 to run the whole show... Can you tell me how to do that with a timer???
I have an idea on how... let me tell...
Each 1ms I fire an interrupt from the timer... Then I check the state of the pin...
I do that for 20ms... So if I measure that the state of the pin was the same for most of the time then It's good...
Generally, if more than 7 continuous samples are good then there was a click and a fragment change...

Ok, I'll try timer out...
BTW My code is as good as I want it to go... But, I really never be taught advanced coding not even coding...
What I can do as far, Is what I learn so far alone... Both in hardware and software...


Thanks a lot for the replies,
Best regards, Lefteris
Greece

[Asellith]

just a comment on NS theory and digital signals. You need to be checking twice as fast at least or you run the risk of missing a step. You need to check twice within one period of the pulse. The pulse is 300 ms long but the high might be in the middle of that period. So you check at the beginning of the pulse and wait till the next pulse starts before checking again and you miss a step. So your sampling rate has to be twice as fast at least. That way you register the high and the low. You really need to be twice the frequency of the pulses but longer then the actual length of the longest pulse. A software trick might be needed to take into consideration if you encoder is something simple like a IR and cardboard setup where it will give you a steady high if the encoder stops on a slot. this could be something simple like comparing the last value to the new one and if they are both high ignore it because you should be seeing a low.

[Admin]

I read the encoder inputs as interrupts, but there are not noise free... in fact they give a a hell of noise... (debounce effect)

Out of curiosity what encoders are you using?! Debouncing is something that you should only see on mechanical switches, not optical . . . I suspect instead that your motors (probably toy el-cheapo types) are sending electrical noise up your sensor line creating false triggers.

If this was the case, the capacitors you installed would have fixed it. You'd probably want some ceramic caps across your motors anyway if you don't already have some.

[TrickyNekro]

I have ceramic capacitors other the motors (MKT to tell the truth)...
Capacitors at almost every IC at 100nF....
The Motor board is full of caps ranging from 10nF to 2200uF...
I've installed nice big silver tape to aid to ground... and so much...
There are optic encoders... And I only thing they need fine trimming at the comparator...
The problem with debouncing persists even without the motors...
The 5ms wait plus the electronic debouncing solves the problem...

To clear this out my problem is that on a optic transition I may get more clicks than I want... thus the wait time...
I'll try to reduce the waiting time to get a faster code...

I'm having doubts if setting the encoders on interrupt lines is actually good...
It seems that the timer method is.... better...
I'll just try it out...
Don't have much options left...

[Admin]

To clear this out my problem is that on a optic transition I may get more clicks than I want

When your motors run I hear a lot of noise. Is there a lot of friction or vibration?

[TrickyNekro]

well... there is a kinda problem in the gear box.... Creating some hysteresis over cycles... But nothing too worry...
The noise may as well be produced by friction...
This base is far from perfect, not to even mention good...
Also, I'm using an ATX for power supply... I don't know how clean this source is cause I lack a scope....
Another bad thing is that they are wheel encoders and not shaft encoders... getting less resolution per rev.
And I'm really in a point that things get official... and not only hobby so I can't just build another base in a day...
With University and all these...
I'll try to make the code, accepting that the encoders get me the same error per wheel...
Also note that this problem happens when I move the wheels extremely slowly, and without the wait time
Still I need this pause time if I'm to run with normal or higher speeds...
I ended up thinking that it's not electrical noise... But the reflective surfaces that aren't so good...
I don't know....


Thanks for the interest and help so far...

Best regards,
Lefteris, Greece