![]() |
Problems with Encoder Counting
We have a 56mm banebots encoder and it count the revolutions fine.But sometimes it misreads the direction.Its not mounted on a drive motor so it won't spin too fast.Any ideas or suggestions?the problem seems to be at its worst at low speeds
|
Re: Problems with Encoder Counting
Did you calibrate the encoder?
|
Re: Problems with Encoder Counting
how do we go about doing that?
|
Re: Problems with Encoder Counting
How would you go about calibrating the encoder??
|
Re: Problems with Encoder Counting
Quote:
|
Re: Problems with Encoder Counting
If you could get your hands on an oscilloscope you'd be able to rule out the encoder.
|
Re: Problems with Encoder Counting
Calibration instructions are in this document:
http://www.banebots.com/docs/EN-G0361-KT-Assembly.pdf |
Re: Problems with Encoder Counting
We use the banebot encoders and had concerns with the mounting method and getting knocked out of calibration if the robot gets bumped. So we simply use only the pulsecount and ignore the direction signal. (meaning that you don't have to use the encoder board and can wire either encoder output directly to an FRC interrupt input)
Your code can assume the direction is the way you expected from the pwm setting to the motor. Use the Optical Encoder block in easyc rather than the Optical Quad Encoder block. Code:
if(pwm<127) encoder_count = -encoder_count; |
Re: Problems with Encoder Counting
It is not a given that your motor is always traveling in the direction commanded by the Victor. The Victor can instantaneously change its output. But unless someone changes the laws of physics the motor cannot. And remember the relationship of Victor output to velocity (of the wheel) is dependent on the torque curve of the motor, friction, traction, mass distrbution over the wheel, dynamic losses in the linkage etc. (thus the beauty of a servo that can determine direction and speed)
|
Re: Problems with Encoder Counting
Also be cautious to interrupt only on one side, A or B, do not trigger interrupt on both.
I suggest interrupt on A, and read the state of B, this will be your direction. |
Re: Problems with Encoder Counting
So, in the end is it worth it to buy encoders? Or is it better to program a counter?
|
Re: Problems with Encoder Counting
Another question: How sensitive are the encoders to movement? Such as bumping or shaking the robot.
|
Re: Problems with Encoder Counting
Quote:
|
Re: Problems with Encoder Counting
I just saw your post. Thank you for the advice and suggestions:) !
|
Re: Problems with Encoder Counting
We use these encoders.
Initially, we used the direction portion of it with the Encoder card. The problem with this is that the encoder needs to calibrated VERY WELL. 2 of our wheels we couldnt get the signals at 90 degrees or even 80 degrees because there was not enough play on the mount. We decided just to wire one of the encoders on each wheel directly to the computer and not use the encoder cards. Our program figures out the direction. Ironically, this procedure wound up frying our encoders (not through fault of the encoders themselves)... A 12V signal was *accidentally* applied to the 5V Digital I/O bus by a *non-electrical* member of the team. This fried the encoders. What's ironic about this, is that had we been using the encoder cards, this would not have broken the encoders. Anyway, thats my opinion. Jacob --Remember, good rep is always nice for a useful post! |
| All times are GMT -5. The time now is 21:49. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi