Encoder problem
 

We're having some problems coding our traction control. We have traced it back to an issue with the encoders.

Our robot has 7 encoders on it. 1 encoder on each wheel, 1 on our idler wheel, and 1 each on our front and rear steering.

The issue we're having is 4 of the encoders are all changing together when you turn a specific one of the 4.

I'm not sure if this is an issue with the Encoder class, or what

We're coding in C++ using windriver.

Is there like a 4 encoder limitation or something? I ask because it is like the 5th, 6th, and 7th encoders are actually replacing the reference to the 1st encoder, and then the 1,5,6,7 encoders are all referencing to the same place in memory, and are changing with the ports from the 7th encoder. Changing the ports associated with 1, 5, and 6 doesnt increase the count, but changing the 7th set of ports is causing the numbers on all 4 (1,5,6,7) to change.

Re: Encoder problem
 

Yes, there is. I'm pretty sure that this information is in the well commented source code for WPILib. It might also be in the docs too. I seem to remember that there was a work around mentioned in the WPILib source as well.

Re: Encoder problem
 

The limit is because the cRIO FPGA can (currently) only allocate four, 4x encoder interfaces. The workaround is to declare your encoders as 1X or 2X (see WPILib documentation on how to do this); this forces the FPGA to implement your encoders as up/down counters, which have different FPGA implementations.

Which encoders should you keep as 4X and which should you implement as 1X or 2X? Generally, encoders that directly measure position (like your steering encoders) you should leave at 4X for the highest precision. Encoders that measure speed (your drive wheels and idler wheels) are often better off at 1X for several reasons. First, when timing the period between two edges longer amounts of time mean more accurate measurements because of the limitations of the timers. At 1X, the edge-edge time is 4 times as long as with 4X. Second, due to manufacturing and assembling tolerances, all both phases are often not exactly 90 degrees out of phase, and each phase is often not exactly at a 50% duty cycle. By only counting a certain edge (say, rising edge of phase A), you ignore these problems.

Re: Encoder problem
 

You could also substitute a non contact absolute rotary position sensor for an encoder. Then the software just has to time an a to d. Cherry makes a 360 degree packaged unit that includes a magnet. Look at Future electronics. There is also a white paper on rotary position sensors on chief Delphi.