For the past 2 days we have been having problems with the encoders on our drive train. We only are ever able to get one reading at a time from the encoders (left side works, right side doesn’t/right side works, left side doesn’t). We have tried replacing the encoders, then the encoder wires, and finally the ds; still no results. We have tested all the points of failures as far as we can tell, and we still have no results.
Because we are able to get a reading from each encoder individually, we know both encoders work.
Because we have switched the wires on both the encoders and on the ds, we know the wires work.
Because we have switched out the ds to a brand new one, we know it works (unless we have extremely bad luck and have two broken sidecars).
If anyone has any input or has ever encountered this problem before, help would be appreciated!
Another thing to look for with the Kit encoders is extra play in the encoder shaft. If the shaft can be push/pulled even a little bit, then the encoder discs can shift into and out of range to disrupt your readings.
Do they work if one set is run backwards and the other is run forwards or vice verse, I have heard of problems resulting in reading two encoders at the same time in code, but I don’t know much about that. We used S-6 encoders from US digital this year after off season prototyping to remedy any encoder woes, they are bulletproof and work extremely well.
We are using US Digital… I asked Matt to get the model numbers…
The ones giving failure are mounted on the drive… its yer basic tank drive.
We are assuming 4x as we had success with that for last years robot… Unfortunately I’m the software guy and do not know for certain what encoders we have yet… (awaiting reply from Matt)
We are using wind-river c++ the GetRate() method in WPI library… I am confident the software works because we use the same exact code for our last years robot with proper read back.
In regards of what method we are using… We have another encoder problem that I was thinking of posting, but it may be related.
I have attached two dumps which show two different methods of capturing the rate… one of which is the GetRate() which uses the GetPeriod technique. The second pw2… is using the GetDistance() where it gets the delta each 10ms iteration (The t= shows the time per iteration). And that then is divided by the time where both show units of RPS. I’ve verified that both techniques work properly on the other robot (I can attach this dump if you want to see). Anyhow, there is another anomoly that this dump presents where every 2 iterations the pulses fail to update… I’m surprised how well GetRate() kept the average. I believe the GetDistance technique show a real problem… as even with the GetRate() the faster speeds looked choppy. I want to try the 1x 2x speeds to see if that will solve it.
Just to clarify, “ds” here refers to the digital sidecar here, right? (In my experience, DS is used for the Driver Station and DSC for the digital sidecar). It’s probably not your problem, but was your ribbon cable checked and fixed correspondingly?
What, if anything, did you change to switch which encoder you can read data from?
Were they the ones received in the KoP this year or from AMFIRST choice? If the answer is yes to either, then you’re using the E4P encoder with a 360 CPR wheel.
There has been a wealth of discussion on this topic and how to filter encoder data to return a more stable rate. I would suggest doing a forum search and comparing your results with those that others have documented. I doubt it’s related to the problem that this thread was created to discuss, as this is a widely documented issue that is commonly expected of encoders, whereas the one that you’re experiencing hints of a connection problem.
We had a very similar problem, but with PWM outputs in the offseason - we could power one side of the 2011 robot or the other side, but it would fail if we tried to drive all 4 drive motors. It turns out the DS can draw enough power from the data cable to power up to 3 PWM outputs, but once you try for 4 it fails. Once we figured out the power problem, everything worked. Maybe this failure mode applies to the digital inputs too?
In years past, 4X with GetRate() was not recommended. Too noisy. I’ve heard that this year, the C++ WPILib added averaging to GetRate() to attempt to reduce the noise. Does anyone know if this works well?
Also, does anyone know: has the GetRate() FPGA bug definitely been fixed in this year’s image?
In regards to the 2011 bug last year:
I worked with Joe H. personally on this bug, during the 2012 beta period… I also traced the source code history on it as well when I fell victim to it in 2011… I’ve verified it as fixed. That particular bug would yield NAN (division by zero), and I used the work around for it, then disabled work-around when I verified the 2012 image.
The irony is that GetRate() worked better for this choppy problem, but at higher speeds it would have a distinct 30-40 radian skip between the numbers like 300.30 10x 330.2 3x 300.10x (around 47 rps). I’ve found that I could work-around this problem by using the kalman filter.
If someone can point me to the best link where others are talking about the current choppiness this year… that would be greatly appreciated. (I’m a bit search engine challenged).
I believe they are from the KoP… I know that the power wheel encoder is indeed the 360 CPR… as I use (1/360) when I set the pulse distance to get RPS units.
Thanks for the tip on the other discussions… I’ll definately want to check them out… but I should reiterate something… I do the same identical test with last years robot and this years with the same exact code. I simply turn the wheel by hand, and last years robot was very smooth numbers. There has got to be some explanation. I’ll try to find what you are talking about as well.
Note the 67,680 counts per sec. I’m told the FPGA is only good for 40,000 counts/sec, but I don’t know if that’s per channel or for both channels of an encoder.
For the E4P, the maximum output frequency is 60 kHz (60,000 cycles per second). A 360 CPR encoder produces 360 pulses on each channel per revolution. To solve for how fast the encoder’s shaft must turn per second to reach the maximum output frequency, divide the maximum frequency by the pulses per revolution. 60,000 / 360 = 166 revolutions per second. To convert to RPM multiply by 60 (10,000 RPM).
That’s an encoder limit. I’m talking about the FPGA.
This is from WPILib Encoder class:
/**
* Common initialization code for Encoders.
* This code allocates resources for Encoders and is common to all constructors.
* @param reverseDirection If true, counts down instead of up (this is all relative)
* @param encodingType either k1X, k2X, or k4X to indicate 1X, 2X or 4X decoding. **If 4X is
* selected, then an encoder FPGA object is used and the returned counts will be 4x the encoder
* spec'd value since all rising and falling edges are counted.** If 1X or 2X are selected then
* a counter object will be used and the returned value will either exactly match the spec'd count
* or be double (2x) the spec'd count.
*/
Ah ok, good to know… In the RateDump1.txt attachment I posted earlier even the slower 10rps speeds were exhibiting the symptom using GetRate()… And using the GetDistance() technique any rps showed the symptom (e.g. turning by hand).
Have you ensured you have wired it correctly? Can you get your two robots together and plug the known good encoders into your new robot, and vice versa, to test where the difference lies?
The problem is not that we have wonky readings, but that we have none at all. We either have readings from the left side and none from the right side, or readings from the right side but none from the left side.
Yes, ds is digital sidecar, and the ribbon cable was checked and fixed (Victor’s weren’t blinking).
We switched out what we thought was a faulty encoder on the drive train after we were only getting readings from one encoder at a time by switching the wires only at the encoder, not on the ds.
Don’t think so, as we have had 4 working encoders before earlier in the season and both sides of the drive train (2 CIMS on each side) works great.
The encoder wires we are using for the drive train are soldered together the same way the encoder wire for our shooter is, which works. (1 PWM white-yellow, the other PWM black-brown, red-orange, and blue-white) We have even replaced one of the encoder wires that we believed was faulty with no results.
