Problems with Encoder Counting

[bjimster1]

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

[Jared Russell]

Did you calibrate the encoder?

[bjimster1]

how do we go about doing that?

[Keo-san]

How would you go about calibrating the encoder??

[Michael DiRamio]

Originally Posted by bjimster1

But sometimes it misreads the direction.

The direction is determined by the B signal. If your wire is loose/not plugged in it would only count in one direction... try making sure the wire connections are good and plugged all the way into the RC.

[Mike]

If you could get your hands on an oscilloscope you'd be able to rule out the encoder.

[jgannon]

Calibration instructions are in this document:
http://www.banebots.com/docs/EN-G0361-KT-Assembly.pdf

[oddjob]

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.

 if(pwm<127) encoder_count = -encoder_count;

This isn't quite as accurate as using the direction signal in circumstances where the wheel changes direction between successive passes through your timer loop. But it works well in practice.

[wireties]

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)

[ChrisSanborn]

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.

[Hydra]

So, in the end is it worth it to buy encoders? Or is it better to program a counter?

[Hydra]

Another question: How sensitive are the encoders to movement? Such as bumping or shaking the robot.

[Alan Anderson]

Originally Posted by Hydra

So, in the end is it worth it to buy encoders? Or is it better to program a counter?

It depends on how precisely you need to control something. For driving a preprogrammed route, polling and counting a relatively coarse sensor works. For keeping drive motor speeds precisely synchronized on an omnidirectional drivebase, I think encoders and interrupts are more appropriate.

[Hydra]

I just saw your post. Thank you for the advice and suggestions !

[whytheheckme]

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!