Our team is having trouble getting a consistent rate value from one of the optical encoders. The Rate value jumps around a lot, even when we use 1x decoding and choose to average 127 samples. When we made our own rate code based on the encoder’s Distance, the variance persisted. It really messes with our PID loop when it tries to keep the speed of the motor consistent. (Note: the jumpiness occurs when the PID loop is not controlling the speed of the motor, so the problem is not caused by the PID controller.)
Any idea what the problem could be and how to fix it?
We use this. Tomorrow I will make sure the optical disk is properly mounted to the shaft and I will rotate the shaft slowly by hand and read the encoder counts and I’ll let you know if I get consistent results for each revolution of the shaft.
Since I forgot my team is not meeting until next Tuesday, I will check it then.
Averaging the rate further with a moving average gives us a mostly constant speed (±2%), but the problem is that when the PID loop adjusts the motor speed, it will oscillate the motors because the “moving-averaged” process variable that the PID uses does not accurately reflect the present rate of the motor. Would applying any of the filters described in this thread give us a smoothed rate that more accurately reflects the present speed of the motor?
I tightened the encoder discs on the axle as shown in the video, and I made sure there wasn’t any slipping. When I rotated the encoders by hand, the Distance count was kind of consistent: I’d say about ±10 counts.
I tested an IIR filter of the encoder speed and compared it to a moving average. You can see an example of my results in this video. The problem with the PID loop adjusting the speed is still present. I’m still not sure if there is a good filter or not.
That’s an extraordinarily noisy signal. Is the green the moving average and the red the IIR? Also, just out of curiosity: how are you obtaining the encoder input, through a Jaguar or the DSC?
I don’t know about you, but we ran into issues with scratched encoder wheels and damaged encoder wires (there was no visible damage; I assume it was internal from abusive zip-tying, but swapping out the wire resolved the issue).
A bit of advice I’ve been given by my mentor (although I’ve never personally experienced this problem) is to always separate signal runs from power runs so that the power runs don’t induce noise in the signal; if they have to cross, run them at right angles. Ether would be able to elaborate more on this.
I should clarify my last post and note that my video was not based off my actual data. I generated the “measurement” (green line) by adding a random number to the rate I set - in reality the “amplitude” of the noise is about half of that. The red line is the IIR, and the blue line is the moving average.
With the optical encoder I use the DSC.
Yes, I made sure the encoder wheels were not scratched - I scratched a lot of them when we first started using them last year. We did twist the encoder wires with a hand drill to make the wiring look good - maybe that’s a problem?
Thanks for the ideas. I’ll try to use a new, different encoder cable and separate the power and data wires and see if the rate I get is any less noisy.
Twisting the wires like that is some serious abuse; you’re placing a lot of tension on a solid length of copper. Wire may flex, but spinning it is asking for trouble. If anything, braid the wires.
To clarify, I don’t mean separating the power and data lines coming from the encoder; I meant separating all 4 encoder lines (+5, A, B, GND) from the power lines going to the motor. Ether, could you comment on how recognizable this effect would be?
I don’t have any pertinent test data. It would make a good project. Put a scope on an encoder signal wire and observe the noise when it’s routed near motor wires. Has anybody done this and have data to share?
I posted this in another thread, but if you use the wpi’s getRate function, I’ve been told it looks at rate in the following way.
1count / (current time - time of last count)
the way we helped limit this noise is using the sum of the counts
encoder counts / (current time - time of last loop)
then reset the encoder.
this will give you a much steadier reading. Just try to limit the function to being called one time per loop. For example, only our PID calculates speed, where everything else reads from a variable it stores the speed in after the calculation. Thus ensuring that is only called once every PID loop.
In the original post I used the sampling in WPI’s encoder settings, but now I don’t. As per lineskier, I believe it samples it much quicker than 2½ seconds though, though.
1x. Encoder class.
I placed code that is like “read count, subtract previous count, divide by measured elapsed time since previous sample” in the 100ms loop in the Periodic Tasks VI, so it’s assumed. Indeed, during my work with the magnetic encoder, I found that the actual time does vary. I could try to use a Timed Loop to make the time more consistent.
Make sure that the shaft is well centered relative to the encoder sensor. We had an encoder problem where the distance was reading correctly, but the rate was varying. The problem turned out to be that the shaft and disk were eccentric relative to the sensor. You could see the disk move up/down/side to side relative to the sensor. After correcting the centering, our readings improved dramatically.
We did twist the encoder wires with a hand drill to make the wiring look good - maybe that’s a problem?