View Single Post
  #25   Spotlight this post!  
Unread 17-04-2010, 19:13
vamfun vamfun is offline
Mentor :Contol System Engineer
AKA: Chris
FRC #0599 (Robodox)
Team Role: Engineer
 
Join Date: Jan 2009
Rookie Year: 2003
Location: Van Nuys, California
Posts: 182
vamfun is a glorious beacon of lightvamfun is a glorious beacon of lightvamfun is a glorious beacon of lightvamfun is a glorious beacon of lightvamfun is a glorious beacon of lightvamfun is a glorious beacon of light
Send a message via AIM to vamfun
Re: Unexpected results from Encoder::GetRate()

Quote:
Originally Posted by vamfun View Post
Making a 1x insensitive to oscillations could be done a number of ways:
One simple mapping is to enable count when B (low) and count when B(high)
This requires B transitions for counting.
So..
1x, 2 interrupts per cycle, not sensitive to oscillations
rate sensitive to rising edge phase errors of A channel
A (rising) B (high) increment , reset enable
A (falling) B (high) decrement, reset enable
A (rising) B (low) enable count
A (falling) B (low) enable count

Ill have to go back and review how Kevin did his. Its been a while.
I took a look at Kevins code while watching the Einstein Final...
Congrats 67/177/294

In the same mapping style, it translates to:
A(falling) B(high)...................set Backward state
A(falling) B(low) ...................set Forward state
A(rising) B(low) Backward........decrement
A(rising) B(high) Forward.........increment

This works well to prevent edge oscillation error counts since it requires a B transition to count also.
Kevin used the single interrupt scheme on the first two encoder channels and this two interrupt scheme on the three and four channels. He had the foresight to know that sometimes you need fewer interrupts with high velocity encoders and more interrupts with high precision distance encoders.

Note to Joe H: For your 1x, I don't like your algorithm because the count oscillates when stuck with an oscillating A edge over a BHigh or Blow state. I believe this can really aggravate the GetRate() noise.

Code:
Count = (ARising | AFalling) & ((BHigh & UpRisingEdge) | (BLow & UpFallingEdge))
CountUp = Count & !(BHigh ^ DownRisingEdge ^ ARising)
CountDown = Count & (BHigh ^ DownRisingEdge ^ ARising)
Revisiting the 1x example with DownRisingEdge=false,UpRisingEdge= true this simplifies to:

CountUp = BHigh&ARising
CountDown = Bhigh&!Arising --> Bhigh&Afalling if counting.

You count up or down on the A edge transition if Bhigh so you oscillate between +1 and -1 increments. My 1x non-oscillating scheme and Kevin's will not do this. Mine will allow a single proper count in the normal direction and no change on the oscillatory reversal. Kevin's will not allow any count until B changes sign.

Last edited by vamfun : 17-04-2010 at 20:44.
Reply With Quote