i implemented the encoder file from Kevin’s site… but it doesn’t work. I plugged it in to what it said, and i update it with:
LeftWheelCount = Get_Encoder_1_Count();
RightWheelCount = Get_Encoder_2_Count();
what could my problem be?
what other code is being implemented are you using the camera?..GTS?..timers?..other sensors?
make sure the encoder outputs are plugged into the correct inputs.
make sure you are using the right type of encoder, I believe that kevin watson has his code set up for a quadrature encoder.
also make sure that you call all the right functions in the right places ie. encoder_counter() in Interrupt_Vector_low(), encoder1_init() in user_init().
another problem that happened to me was overlapping interrupts. If you do a “find in project” for a bit in the register to see if they are used anywhere else, you may eliminate this problem.
Did you follow the steps in the readme that came with the encode code… such as adding the initialization call?
i did follow the steps in the initialization. i am also using the camera. I’ll check the encoder type. Where do i find what kind they are exactly? I do call Initialize_encoders() in initialization, and i call interupt handler low from Default routine.
Don’t do that.
The interrupt handler is “called” by a hardware feature of the processor. You don’t have to do anything more than define it as the interrupt handler.
k thanks… still haven’t gotten a chance to test again
EDIT: nope, still doesn’t work…
How do you know the encoders are not changing? Are you simply trying to print your xxxxWheelCount variables to a terminal and noticed they don’t change?
If so, then that’s likely the only problem and your encoders are just fine. Your variables are probably declared long int and, as such, you need to typecast them before printing. Try the following:
printf("Left encoder = %d", (int)LeftWheelCount
);
and see if it works. Sometimes the simple things really get on your way!
actually, they’re not longs. they’re ints. a long can hold up to 2147483648, which is about a mile. i just used ints. they’re printed using
printf("Left Encoder: %d Right Encoder: %d\r", LeftWheelCnt, RightWheelCnt);
But it’s a good point. i’ll try printing the values directly from the method…
did anyone have to change their encoder code to get it working? what did you do? cuz ours still isn’t working
I tossed a USB flash drive containing Kevin Watson’s frc_encoder.zip file to the lead student programmer and told him to follow the directions in encoder_readme.txt. He did the nine required steps and compiled it. I added a tiny bit of code in Process_Data_From_Local_IO() to turn the raw encoder counts into odometer and heading information, and put a printf statement in Process_Data_From_Master_uP() to verify the proper operation of the encoders.
That’s it. It was painless.
does the type of encoder affect the code? where did you guys get your encoders?
The code is designed to work with any encoder having a quadrature output. That means there are two signals, each producing a square wave signal as the shaft turns, but the A and B signals are a quarter-cycle out of phase with each other.
We’re using US Digital’s E4P encoders. http://www.usdigital.com/products/e4p/index.shtml
I believe we bought them from Newark Electronics, but I’m not the one who purchased them, and I’m not certain.
would the number of clicks per revolution make it more or less likely to work? because ours runs at 128 clicks per revolution, and some are concerned that that’s too fast for the RC to detect
Make sure the encoders are wired right. You can leave the power pins plugged in and look at the signal wires with an oscilloscope or multimeter. If they change as you rotate the wheel, the problem is in the program. If not, there’s an electrical problem.
k thanks, we’ll try that
How many revolutions per second?
We’ve chosen 256 counts per revolution of the drive wheel. Moving at high speed will give a couple thousand interrupts per second. Our 2005 robot didn’t seem to have a problem keeping up with that kind of rate.
There might be a problem with storing a long to an int without typecasting… Kevin’s Get_Encoder_n_Count() functions return a long. If you want to store them as ints you should typecast them:
LeftWheelCount = (int)Get_Encoder_1_Count();
RightWheelCount = (int)Get_Encoder_2_Count();
Otherwise you might get only the most significant bits of the long, which make the int variables 0. In other words, it’s counting, but you’re not printing them correctly. We had a similar problem with printf displaying longs without typecasting:
printf("Left encoder count = %d", Get_Encoder_1_Count() ); //incorrect
printf("Left encoder count = %d", (int)Get_Encoder_1_Count() ); //correct
I believe the first one tripped us up because it only printed the highest 16 bits of the long, making it appear like it’s not counting.
This might be something you already know, in which case I’m sorry I can’t help. But if you have a problem with encoders generating too many counts, BaneBots has an encoder divider board that we’re using this year. They have jumpers to select divide by factor: 1, 4, 8, or 16. We have one 128/revolution encoder coupled 2:1 to each CIM motor shaft (that’s ~5000 counts/sec at no load speed), divided by 4 so we don’t overwhelm the processor with counts.
You can also try leaving things as longs and printing using “%ld” instead of “%d”
i’m not sure which motors we’re using but i think they’re the chalupas. i’ll try typecasting the method’s returns as ints. I use ints because i get paranoid about the amount of space the robot really has…
Thanks to everyone for all of their help! It hasn’t yet been fixed, but i have great confidence it will be, thanks to this huge outpouring of help!
Dont be paranoid… unless you are doing some crazy coding then you should be fine.
either way, the proper replacement macro in printf for a long is %li