We are using three quadrature banebots encoders with divider kits in interrupts 2, 3, and 4 (we broke off one of the pins in 1 by accident). We are also using the standard Kevin encoder code. Counting for encoder 2 works with no problem but 3 and 4 remain at zero. I switched the encoders on 2 and 3 to see if it was an encoder problem and the same thing happened, 2 worked but not 3 and 4. I’ve looked around and interrupts 1-2 are different from 3-6 which need the Port_B so I think the problem might be related to that. Thanks a ton for the help!
I have weird had problems before with the printf statements if thats what you are using to view your data. Save the encoder counts to a variable and print that out instead of the actual function if you can. I had a really weird error that took a couple hours of my time to try and fix…
OK, you can’t do what you’re trying to do. Kevin Watson’s encoder code is intended to decode A and B phase from an encoder. The Banebot encoder/divider "interferes’ with this process. ( the input at 2 only looks for ONE signal and so “mis-interperts” the signal from the divider as the A phase so you get data).
You have two options, you can either skip the banebot divider and wire directly to the digital inputs. 3 and 13 …4 and 14 …5 and 15… 6 and 16 … this is where the A and B phase outputs go to the SIG pins. you can connect the + and Minus to one of the +5 and Ground pins of the pair. You can do this as long as you don’t exceed 1 Amp. Then, you can just use the Kevin Watson code.
If you want to use the divider, you’ll have to write your own interrupt code to calculate the count by incrementing or decrementing (depending on the direction signal) on the signals from the divider.
Wish there were an easier solution but I can’t think of one.
Oh and By the way, 1(11), 2(12) use a single signal in a 4 state system. 3 (13) and 4(14) use 2 signals in a 4 state and 5(15) and 6(16) detects all 4 states.
Steve
What do you mean by states?
Ah… OK Quadrature is as it implies, a 4 state system. if you look at the diagrams from the Assembly instructions for the banebot assembly instructions page three shows the two signals in 90 degree phase shift. there are 4 possibilities. Low, Low… Low, High…High, Low… High, High
These are what I mean by states.
Steve
I thought the encoder kits were supposed to ‘clean up the signals’…? Does it just do away with the 4 states? or does it obscure them more? I remeber last year we were getting shakey direction readings from these encoders until we put divider kits on them. But they were on the first and second interrupts. and thanks again for the help.
Yes… you are feeding the A and B phase in and getting a number of states divided by whatever count you select AND a direction signal ( forward or backwards) the Kevin Watson code counts the states and determines the direction so it increments or decrements the count.
I am using two 64 counts per rev encoders on 6 " wheels and going directly into the 5,15 6,16 pins which gives me 128 states per rev. This Works great.
The banebot encoder doesn’t really clean up the signal… it’s digital anyway. Perhaps you were running too fast and losing counts.
Steve
Just a question… are you doing velocity control? If so, I’m guessing you’re running in the 39.37Hz (25.4ms) loop? Is this enough resolution?
By my calculations, you can have an absolute maximum velocity control resolution of 0.39ft/sec. Is your robot really really fast? Hence the low res encoder?
-q
I’m using the encoders for distance in autonomous mode. The robot is capable of about 8ft/sec at the very top speed. I’ve run it on short full speed but haven’t written the PID coding yet, so I don’t know the accuracy just yet, but the simple number tweaking I’ve done looks promising so I’m expecting really good results from the PID. I’m reading a 6" wheel which in theory gives me a resolution of 6*PI/128 about .15 inch/ count. That’s probably more than I need and I hope to have the PID tested and tuned by Monday, I hope.
Steve
OK I’m brain dead! Sorry, Actually, another solution is to duplicate the 1 & 2 coding for 3 and 4.
In encoder.c cut and replace the interrupt handler for 3 and 4 with 1’s (or 2’s) interrupt code
void Encoder_1_Int_Handler(void)
{
// Encoder 1's phase a signal just transitioned from zero to one, causing
// this interrupt service routine to be called. We know that the encoder
// just rotated one count or "tick" so now check the logical state of the
// phase b signal to determine which way the the encoder shaft rotated.
if(ENCODER_1_PHASE_B_PIN == 0)
{
Encoder_1_Count -= ENCODER_1_TICK_DELTA;
}
else
{
Encoder_1_Count += ENCODER_1_TICK_DELTA;
}
}
#endif
Changin all the 1s to 3s or 4s
so for 3 it becomes
if(ENCODER_3_PHASE_B_PIN == 0)
{
Encoder_3_Count -= ENCODER_3_TICK_DELTA;
}
else
{
Encoder_3_Count += ENCODER_3_TICK_DELTA;
}
}
#endif
The code expects the direction signal on the B pin which for 3 is digital input 13. Since it expects a high or low for direction it just so happens that will work for the signal from the encoder/divider.
I THINK that’s the only file you need to change. I’ll read through it again but I believe everything else is transparent to the interrupt handler. I can’t really est it but it looks right and would be easy to implement. You CAN change 5 and 6 the same way but you mentioned you’re only using 3 encoder/dividers.
Duh Me! I was so wrapped up in how I do it I didn’t bother to think there was another way even after you mentioned that 2 was working. Hope I didn’t throw you off!
Steve
Thanks! We’ll try that today at the meeting but it sounds like we’re gonna be OK 
thanks a lot for the help. I’ll post back after we try it.
Thanks! its working now. We just have a weird calibration error but that shouldn’t be too bad to fix.