View Full Version : Consistent encoder rate
Hi,
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?
Thanks for any advice.
Hi,
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?
Thanks for any advice.
What is the encoder brand and model number ?
If you rotate it slowly by hand and read the encoder counts, do you get consistent results for each rev of the shaft?
Check to make sure the optical disk is properly mounted to the shaft.
We use this (http://www.usdigital.com/products/encoders/incremental/rotary/kit/e4p). 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.
We use this (http://www.usdigital.com/products/encoders/incremental/rotary/kit/e4p). Tomorrow I will make sure the optical disk is properly mounted to the shaft
Look at the 2:15 minute mark of this video:
http://www.youtube.com/watch?v=4hJfzhxZwKw
Since I forgot my team is not meeting until next Tuesday, I will check it then.
Averaging the rate further with a moving average (http://zone.ni.com/devzone/cda/epd/p/id/82) 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 (http://www.chiefdelphi.com/forums/showthread.php?t=101244) give us a smoothed rate that more accurately reflects the present speed of the motor?
No luck. We have decided to look into testing (http://www.chiefdelphi.com/forums/showthread.php?t=103973) the magnetic encoder from the KOP on a test motor.
We use this (http://www.usdigital.com/products/encoders/incremental/rotary/kit/e4p). 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.
How did this work out?
How did this work out?
Like so:
No luck. We have decided to look into testing (http://www.chiefdelphi.com/forums/showthread.php?t=103973) the magnetic encoder from the KOP on a test motor.
Like so:
I wanted him to clarify whether that post was pertinent to the attempt at filters or rotating by hand. I should've been more clear on that point.
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 (http://tinypic.com/r/205ffi0/5). 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.
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 (http://tinypic.com/r/205ffi0/5). 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.
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.
Here are a couple other things to consider:
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.
+-10 out of how many? and roughly how accurately did you rotate it (i.e. by "eye" or did you make a mark etc)
The Rate value jumps around a lot, even when we use 1x decoding and choose to average 127 samples.
127 samples at 20ms per sample? That's 2½ seconds. That's not what you meant is it?
When we made our own rate code based on the encoder's Distance, the variance persisted.
This doesn't sound right. Would you mind describing exactly what you did?
- 1x or 4x?
- Counter class or Encoder class or something else?
- sample time? how controlled? measured or assumed?
- did your code look like this: read count, subtract previous count, divide by measured elapsed time since previous sample?
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?
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?
Hi,
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?
Thanks for any advice.
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.
+-10 out of how many? and roughly how accurately did you rotate it (i.e. by "eye" or did you make a mark etc)
360. I put tape on the wheel and made one rotation.
127 samples at 20ms per sample? That's 2½ seconds. That's not what you meant is it?
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 or 4x?
- Counter class or Encoder class or something else?
- sample time? how controlled? measured or assumed?
- did your code look like this: read count, subtract previous count, divide by measured elapsed time since previous sample?
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 (http://zone.ni.com/devzone/cda/tut/p/id/11466) to make the time more consistent.
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.
Sorry, I meant braid.
rwood359
29-02-2012, 15:13
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.
Sorry, I meant braid.
How do you braid with a hand drill?
during my work with the magnetic encoder, I found that the actual time does vary. I could try to use a Timed Loop (http://zone.ni.com/devzone/cda/tut/p/id/11466) to make the time more consistent.
Team 358's "Timing Is Everything" paper is worth reading:
http://team358.org/files/programming/ControlSystem2009-/LabVIEW/Timing%20is%20Everything.PDF
How do you braid with a hand drill?
My terminology is terrible. :rolleyes: By twist I thought slijin meant twisting each individual wire. I did this (http://www.instructables.com/id/A-Perfect-Twist/).
Team 358's "Timing Is Everything" paper is worth reading:
http://team358.org/files/programming/ControlSystem2009-/LabVIEW/Timing%20is%20Everything.PDF
I should try to implement that and see if that makes an improvement.
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.
I noticed this was a problem with one of the encoders when Ether reminded me to make sure they were properly mounted, but one was properly mounted. Unfortunately, I could not correct it before the robot was bagged.
My terminology is terrible. :rolleyes: By twist I thought slijin meant twisting each individual wire. I did this (http://www.instructables.com/id/A-Perfect-Twist/).
Just for clarification, braids resemble these:
http://theautry.org/ortega/images/four_string_braid.jpg.
Light braiding will work for wire management (you don't want to braid stuff very tightly either), because all you're doing is flexing the wire. In the link you gave, though, there's a lot of tension on that wire - an absolute no-no in a moving application subject to vibration, especially on signal wires.
In the link you gave, though, there's a lot of tension on that wire - an absolute no-no in a moving application subject to vibration, especially on signal wires.
Why is that so bad?
ayeckley
29-02-2012, 18:54
Why is that so bad?
Especially when you consider that most instrumentation cable used in industry is in twisted/paired form. Clearly installing a twisted pair without any kind of slack would be bad, and twisting it by hand (drill) raises the possibility of excessive strain on the strands if it's "overtwisted", but I'm not sure why it should be considered bad practice in the context of the FRC.
In simple terms, the advantage to twisting the wires is that voltages induced in the conductors by external, changing magnetic fields (a type of EMI) in accordance with Faraday's Law are made self-cancelling due to the twist. The ideal twist pitch is a function of the characteristics of the shape of the magnetic field. In most instrumentation cable you'll encounter pitches between 1 and 8 twists per inch. In FRC, the major source of changing magnetic fields is the brushed DC motors we use.
Why is that so bad?
The way I see it, putting tension like that on a wire is liable to either stress it past its breaking point or make it particularly brittle. Once that wire gets tied down to the frame of a robot, chassis vibrations (from driving, turning - any movement) then propagate into the wire, which is liable to break it. Given that the E4P's wires are so fragile already (you can actually rip these wires by hand), I'd be wary of putting any undue stress on them.
Alex, I am aware that twisting wire is a common practice in industry for the very reason you mention; my position is that the undue stress placed on the wire by twisting it with a hand drill, especially to the extent of the link, is likely to do more damage than good, especially in this particular example.
That being said, don't focus too much on the physical aspect; wire twisting could be the issue, but it won't necessarily be the issue. If you can, get some testing done; prepare a bench test (or a test setup on another bot) to see if you can troubleshoot your encoder problem. Use a similar wire setup (twisted wires and all) and see what you can do to isolate your problem. Although conditions won't be exactly the same, you probably will find issues that you didn't even originally notice, and then find a solution before competition.
It turns out that inconsistent elapsed time between loops was the main culprit. I fixed the variation in our speed readings with a Timed Loop.
Thanks again for the help.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.