Question: how many encoders can be used on the robot?

[Tomker]

We want to use 5 Encoders on the robot but we were not sure if the CRio will let us do so...
if anyone knows the answer please help us!!!

[MagiChau]

Originally Posted by Tomker

We want to use 5 Encoders on the robot but we were not sure if the CRio will let us do so...
if anyone knows the answer please help us!!!

I tried making 5 different encoders in java but I got an error telling me too many encoders.

[Trevor1743]

I believe that each encoders uses 2 digital input on the digital side card. So theoretically you could use 5 with 1 side card, and 10 with 2 side cards.

[AllenGregoryIV]

The FPGA will only let you declare 8 encoders. We are currently using 5 on our robot with out problems.

However there is a bug in the encoder code that won't let you return rate values for all 8 of those encoders.

[Tomker]

if i declare 3 encoders in the autonomous period and i declare 4 encoders in the teleop it will be fine?
(by declaring i meen using its value while 2/3 encoder from the autonomous period also used in the teleop)

[Joe Ross]

Originally Posted by AllenGregoryIV

The FPGA will only let you declare 8 encoders. We are currently using 5 on our robot with out problems.

Originally Posted by MagiChau

I tried making 5 different encoders in java but I got an error telling me too many encoders.

Both of you are right.

You can use 4 encoders in 4x decoding, and 8 more in 1x or 2x. This is described in the WPI Robotics Library User's Guide.

Originally Posted by Trevor1743

I believe that each encoders uses 2 digital input on the digital side card. So theoretically you could use 5 with 1 side card, and 10 with 2 side cards.

There are 14 DIO lines on the digital sidecar, not 10.

[theprgramerdude]

Originally Posted by AllenGregoryIV

The FPGA will only let you declare 8 encoders. We are currently using 5 on our robot with out problems.

However there is a bug in the encoder code that won't let you return rate values for all 8 of those encoders.

What language does this rate bug occur in, and will it occur if you're only using two encoders?

[apalrd]

The rate bug is in the FPGA image, so it affects all languages.
It affects every other encoder, so any number of encoders will have a few which do not return rate (the first one will be affected, the second will not).

If you only need distance, you can use the broken FPGA encoder modules for distance only, and not use Rate.

[BigJ]

Originally Posted by apalrd

The rate bug is in the FPGA image, so it affects all languages.
It affects every other encoder, so any number of encoders will have a few which do not return rate (the first one will be affected, the second will not).

If you only need distance, you can use the broken FPGA encoder modules for distance only, and not use Rate.

I have some questions for you experienced encoder-folk. This year 1675 has finally made its way into the world of motor feedback loops (at least on our test benchtop system).

We are using the rate on the encoder, and setting the distance per pulse to scale to -1.0 to 1.0 for the PIDController that goes to the motor controller.

I was perusing the WPILib users guide, at first because we were planning on using 5 encoders (4 drive, 1 lift) and assumed they could all be 4x (thankfully, I saw this thread!). I am under the assumption from reading the Guide that a 2x Encoder can still determine direction (our lift encoder would be a simple counter, it does need to count up and down though).

If a 2x Encoder can indeed tell direction, is the reduction in accuracy enough to make it a bad choice for drive? We'd need 4 encoders that can do rate for our current desired drive code system.

[theprgramerdude]

Originally Posted by apalrd

The rate bug is in the FPGA image, so it affects all languages.
It affects every other encoder, so any number of encoders will have a few which do not return rate (the first one will be affected, the second will not).

If you only need distance, you can use the broken FPGA encoder modules for distance only, and not use Rate.

Do you believe an easy work around would be to create twice the number of encoder objects, and stagger the "fake" ones on inputs we don't with the "real" ones, as to only let the fake ones have the broken code, and the real ones get the rates? We do need the rates.

[apalrd]

We are using all 1x decoding on our drive, with AndyMark 250-count encoders, and chain slack is a larger cause of innacuracy then the encoders themselves.

For a 250-count encoder, you will get 250 pulses (rising edge of one phase) per rotation. This is A LOT. For 2x, you will get 500 pulses (rising and falling edge of one phase) per rotation. This is still A LOT. With both of these, the B-phase will only be used to determine direction (but you still have direction). For 4x, you will get 1000 pulses (rising and falling edge of both phases). This is a serious ton of pulses.

Our drive is 1:1 from the encoder to 6" wheels (that's what happens with SuperShifter and live-axle drives), so we get about 1.4 degrees of accuracy, which translates into about 1/8" of movement. Far more than we actually need.

On PID:
You can scale the input to whatever you like. IT dosen't matter. As long as the setpoint and sensor are of the same units, the output scale does not matter (it will when you tune it, but it will only change the magnitude of the gains).

Also - If you need 4 encoders with rate, you will have to use FPGA counters (1x or 2x) because there are not 4 working rate encoders. jhersh posted a fix for LabVIEW here, which just disables all of the non-working encoders. http://www.chiefdelphi.com/forums/sh...4&postcount=54

[AllenGregoryIV]

Thanks for the clarification about the number of encoders you can declare with the different scale factors.

As far as getting rates from the encoders. We were able to get 4 rates by declaring 8 encoders 1,3,5 and 8 seemed to work for us. These were all declared at 2x. Encoders 2,4, and 6 were fake encoders that were assigned the digital inputs of limit switches that we were using for other things. Encoder 7 was used for our lift but we didn't need the rate from it. You may be able to get more rates by using the 4x encoders, but I am not sure. The best way is to just test them, when you get NaN as a rate you know that encoder declaration position won't work and just move on to the next one.