Kit opto encoder resolution?

[ericand]

Originally Posted by Joe Ross

The decoding type can be used on any quadrature encoder. If you want to count the rising and falling edges on both the A and B channel, choose 4x. 2x does rising and falling edges on only one channel, while 1x only counts 1 edge on one channel. If you are using the encoder for position only, using 4x gets you extra resolution. If you are trying to use the rate function, you'll probably have better results with 1x. Choose whatever makes sense for your application.

One cool thing you can do with the scaling is get the encoder value in a measurement you want to use. For example, if you want to measure angle in degrees, put in a 1 for the scaling. Each tick will then be 1 degree (since the encoder has 360 ticks per revolution). Alternately, you could calcuate using your gear ratios and wheel size that each tick makes the robot move 1/10 of an inch. Put in 1/10 and then you will get the distance the robot traveled in inches.

Using the 2x and 1x, raises the question of which edge does it detect? I'm running into problems getting a good count of the encoders and I'm thinking the problem is that we have been using an old IFI robot controller theory of operation.

Our setup on our test setup has the encoder output going to a BaneBot encoder divider. This was done previously to allow us to use hardware to divide the counts of the A channel and latch the direction (B Channel) to preclude any latency issues when reading it on the old controller.

Our final robot will not have the dividers, but to save time, they were left on the practice chasis and the A and B signals were taken from the divider to digital I/O on the cRIO.

In this configuration, we are not getting any counts (getraw() returns 0, 1 -1) regardless of how much we move the robot. However, scoping the outputs of the encoders and the dividers shows that the signals are being generated as expected.

I suspect that the cRIO is getting confused since the B channel is not pulsing, but remains constant while the robot keeps moving. I'll be able to run more experiments on Thursday, with the encoder divider out of the picture to see if things work better.

I suspect it would be good to have the cRIO have a library call that would allow it to take advantage of hardware like the BaneBot divider, but given the current set of interfaces, I do not see how it can be done. I could set up a counter on the A channel, but I don't see how I can get an interrupt when the B channel changes so I can properly apply the direction to the A channel count.