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
 

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.

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.

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.

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
 

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.

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!

Re: Problems with Encoder Counting
 

its probably too late now but what we ended up doing was getting a divider kit and calibrating using the LEDs on it to know if the encoder was in the correct position. Once the divider kit was installed i was able to install it with very little fidgeting.

Re: Problems with Encoder Counting
 

Yes, BaneBots sells these divder cards Here

If you order them ASAP, banebots can get them to you, and you should be able to install them in just a few minutes when you get to your competition.

Jacob

Re: Problems with Encoder Counting
 

After assembly, of course....

Re: Problems with Encoder Counting
 

I would be wary about using those in a competition though, 424 used them and they unexpectedly stopped working. I they weren't designed to be on a robot in a competition it was designed to be a bench diagnostic tool. but that was my experience not sure if anything stupid was done between uses.

Re: Problems with Encoder Counting
 

The Banebot encoders worked fine for us. Calibration was fairly simple, using a USB oscilloscope. Counts are accurate, even with both wheels at maximum speeds. We didn't have to use the divide-by-ten circuits.

The only time we had trouble with counts in one direction only, was when a plug pulled loose or a signal wire came off the Robot Controller. Make sure the plug is pushed in very firmly, until it clicks.

Mechanically, they should be fine as long as (a) the plastic case surrounding them is not damaged during competition, (b) the encoder wheels or infrared pickups are damaged during motor change-out or excessive shaft play.