Testing and Cause of Failure for Encoders and Hall Effect sensors

[ChrisH]

I have a question about the use of optical encoders and hall effect sensors in our robots. When they fail, how do you test to determine that they have failed and what was the failure mode?

For example, if we are using an encoder to control the position of our arm, and the arm stops behaving properly (not moving on command, not stopping on command, or oscillating when before it was holding still). How would we determine whether the failure was in software or in hardware? If it in hardware (like a fried encoder) how would we determine whether the source of failure was a mechanical overload or some electrical problem?

Please keep the replies simple. I'm just a mechanical, but when something breaks I'm the one who has to correct the problem and prevent recurrence. I hate to use stuff where I don't even know how to check whether or not it is working in the first place.

Do we need to add an oscilloscope to our pit equipment? If so how do I hook it up to get the answer I need? I know what to do for limit switches and pots, but encoders seem to take a little more than my trusty VOM.

[TimCraig]

I'm working through an encoder problem now. The support guy at US Digital suggested that lacking a scope, you can power the encoder and use a digital voltmeter to check the output between the output pins and ground. For their model he said it should vary between 0 and >=2.5 volts as you turn it. Obviously, you can't turn the shaft too quickly or the DVM will not have time to settle. (Makes you wonder if an analog meter might react better) I tried this and couldn't see anything on the B channel which was easiest for me to tap. In my case, I'm absolutely sure it's the encoder because I have two, one on each transmission, and simply moved the cable from the known good one to the suspect one and got bupkus.

As an aside, I was trying to test just the encoder unit out of the robot since I thought it would be easier. I slid a sheet of paper into the slot and saw nothing. However, the support guy said the HEDS detector they use will only register the lines on the disk and not show the paper. I'm also a mechanical also so I'm not up on how this works. You'd think breaking the beam is breaking the beam.

When I get around to it, I'm going to have to build a test connector to make some of these tests easy.

[John Gutmann]

take a camera and just point it at the IR LED to test that if it works you should see the light on the lcd, even a simple camera fone works

[Al Skierkiewicz]

Chris,
We use a calibration program that our crack software team writes up. It allows us to look at the raw data as the sensor is manipulated and when needed allows a calibration routine to set mechanical center or a soft stop. Of course using a pot for arm position or steering position is easily checked with power on for 0- 5 volts or with power off with an ohmmeter and the output disconnected. Most of our pots and sensors are connectorized so they are easy to check and change.
As to using a scope, connect the scope lead common to the sensor common and the scope probe to the output lead. It should be obviously be in one state or the other. (set vertical sensitivity to 2v/division.) Move the part that is being sensed and the output should change states. If the output is always low, check that the sensor is getting power. If the output is always high, suspect that the sensor output is open.

[Tom Bottiglieri]

You could build a test kit with the EDU-RC. Wire up green, yellow, and red LEDs in a line, and another special red "warning" LED. When the encoder is moved clockwise (forward) have the green light up. When at rest, have yellow light up. When revolving CCW, have red for reverse come up. If there is no signal, or an erratic signal have the warning LED come on. This may be an easy plug and play way to check quickly for dead encoders.

If you like this idea, or something similar, but are short staffed in the programming department, send me a PM and I could probably whip something up for you.

[Alan Anderson]

We had a "diagnostic" mode in our software this year. With the proper switch activated, some of the OI LEDs show the direction of rotation of the three encoders we used on the robot. That sort of simple diagnostic feedback is something your programmer(s) will have to provide if they want to quickly eliminate hardware as a potential problem.

Originally Posted by TimCraig

As an aside, I was trying to test just the encoder unit out of the robot since I thought it would be easier. I slid a sheet of paper into the slot and saw nothing. However, the support guy said the HEDS detector they use will only register the lines on the disk and not show the paper. I'm also a mechanical also so I'm not up on how this works. You'd think breaking the beam is breaking the beam.

White paper doesn't completely block the light getting to the sensor. It gets illuminated, and the sensor detects the diffuse light coming from it. You'd have to put something totally opaque there, like a bit of electrical tape or foil, before the detector will stop seeing anything.

[sciguy125]

Originally Posted by Alan Anderson

You'd have to put something totally opaque there, like a bit of electrical tape or foil, before the detector will stop seeing anything.

During what became a very long troubleshooting session, I discovered that electrical tape isn't opaque to bright IR LEDs. It turns out that a lot of plastics aren't either. I try to use scraps of metal now.

[Mark Pierce]

Our team installed switches on our control board to select which motion we wanted to monitor. The selected measurement was displayed on the OI LED display. Data such as input states, measured position, and commanded position relating to the selected motion are also sent out the serial port for more thorough diagnostics.

I've used IR sensors in machinery for measuring lumber and it is amazing how much material a IR light source can go through. Block it with metal to be sure it's blocked.

[Mr. Lim]

Originally Posted by ChrisH

1) When they fail, how do you test to determine that they have failed and what was the failure mode?

2) How would we determine whether the failure was in software or in hardware?

3) If it in hardware (like a fried encoder) how would we determine whether the source of failure was a mechanical overload or some electrical problem?

Chris,

1) Usually I'll setup a timer in code that will periodically printf my encoder counter to the programming port - like a constantly running diagnostic mode. It prints about once a second or so - slow enough that it doesn't hamper performance during competition, but fast enough to get meaningful information for troubleshooting in the pits. The first check is to power on the robot while disabled, read the encoder counts, rotate the encoder a known amount, check encoder counts again. Repeat in opposite direction.

2) After doing 1), in general if the encoder counts agree, you have a software problem elsewhere. If counts don't agree you have a hardware problem. If counts only decrement, or increment no matter which way you turn your encoder, your non-interrupt phase is disconnected or blown. If you get no counts in either direction, the phase connected to your interrupt is disconnected or blown - or both phases are disconnected or blown.

3) With the encoders we use, the only clue to mechanical failure we've found is to compare the rolling resistance to a brand new encoder. With optical encoders with no detents, too much resistance means you've destroyed the bearing which we've done in the past with excessive side-loads. We don't have a scope either, so our electrical diagnostic is just swapping it out with a new one and seeing if it flies.

If you're reluctant to drop money on a scope, this might interest you. Some isolation circuitry is recommended though... your mileage may vary =).

-SlimBoJones...

[ChrisH]

Originally Posted by SlimBoJones

Chris,

If you're reluctant to drop money on a scope, this might interest you. Some isolation circuitry is recommended though... your mileage may vary =).

-SlimBoJones...

Actually we already have a scope, but it is rather large and heavy to be dragging to away competitions. Especially if we are flying. The software looks interestng as we have plenty of laptops around. I'll have to check that one out. What kind of isolation circuitry would I need?

[Matt Krass]

Originally Posted by ChrisH

Actually we already have a scope, but it is rather large and heavy to be dragging to away competitions. Especially if we are flying. The software looks interestng as we have plenty of laptops around. I'll have to check that one out. What kind of isolation circuitry would I need?

Yes seconded, what kind of isolation circuitry would be needed? Would attaching anything besides a mic to my line in on my new laptop void its warrantee and finally I'm assuming I'd have to split one end of a minijack cable in to two probes?

Thanks, this looks interesting...

[Al Skierkiewicz]

Seeing as this is a software only device, one must assume that the bandwidth is only what the sound card is capable of handling. Most sound cards are designed to handle an A/D conversion for CD quality audio which means, best case bandwidth of 22kHz with acceptable distortion of an audio signal. Add to that the aliasing of the conversion (dither, noise, approximation, etc.) you may be only able to see real bandwidth in the 15kHz range. One must assume that using the line level inputs, a maximum voltage of just over one volt RMS is the upper limit, which would require an input stage with attenuators capable of analyzing the 12 volt plus signal at the output of the speed controller.
On the plus side, the PWM output is around 2kHz and the limited bandwidth would certainly hide brush noise and other switching by products present when looking at motors. You may not be able to see the raw output of a sensor, particularly one that has an output frequency above the A/D. Additionally, the inputs are single ended, where one side of the signal path is computer common. As such anything that is common mode will raise the chassis and ground of the computer to a point that might interfere with normal computing operations. A transformer would be a big help in preventing these currents but needs to be shielded for obvious reasons. There are other scope accessories that can attach to laptop and desktop computers that may be easier to carry and less expensive than a full up scope.

[Gdeaver]

A logic analyzer is useful in these situations. You can actually see the steps and phase from a run. Professional grade logic analyzers are expensive. A pic however can be turned into a acceptable analyzer with the proper hardware and PC program. I believe Parallax sells one and there is this link.
http://kronosrobotics.com/pj_analyzer/analyzer.shtml
Great for testing coproc communications and I2C - SPI.

[ChrisH]

Al,

Let me see if I understand you correctly and maybe you can translate the parts I don't understand into something a lowly mechanical can get his head around.

Originally Posted by Al Skierkiewicz

Seeing as this is a software only device, one must assume that the bandwidth is only what the sound card is capable of handling. Most sound cards are designed to handle an A/D conversion for CD quality audio which means, best case bandwidth of 22kHz with acceptable distortion of an audio signal. Add to that the aliasing of the conversion (dither, noise, approximation, etc.) you may be only able to see real bandwidth in the 15kHz range.

Ok I think you just said the max sample rate would be 15kHz. Since I don't plan measuring the speed of any motors directly, this is probably not an issue. If the signal is cycling that fast I need to do something different.

One must assume that using the line level inputs, a maximum voltage of just over one volt RMS is the upper limit, which would require an input stage with attenuators capable of analyzing the 12 volt plus signal at the output of the speed controller.

I think you said we have to knock the robot's 12V signal down to 1V max. I assume our electricals can handle that. But a hint or so wouldn't hurt

On the plus side, the PWM output is around 2kHz and the limited bandwidth would certainly hide brush noise and other switching by products present when looking at motors. You may not be able to see the raw output of a sensor, particularly one that has an output frequency above the A/D.

One of the things we might want to look at is the PWM output and happily it falls within the likely range of the sound card. However certain sensors might output at a frequency about the range and so not read correctly.

Additionally, the inputs are single ended, where one side of the signal path is computer common. As such anything that is common mode will raise the chassis and ground of the computer to a point that might interfere with normal computing operations.

If we don't do this right, the computer might fry, or at least get confused.

A transformer would be a big help in preventing these currents but needs to be shielded for obvious reasons.

And these obvious reasons might be? and it prevents this how? and just how is the shielding accomplished?

There are other scope accessories that can attach to laptop and desktop computers that may be easier to carry and less expensive than a full up scope.

There are other ways that might be cheaper and lighter than a full up scope. And these might be?


As I mentioned before, we already have a scope, we just never thought it would be useful to drag it with us to a competition. Of course our sensors have been pretty limited as well, so we haven't really needed it.

I think we are in sort of a chicken and egg situation. We don't use sensors because we can't test them when things go wrong, and therefore don't trust them. But since we don't use them we don't develop the knowledge and capabilty to test them. Why test something we don't use? So I guess you could say the goal of this thread is to lay an egg and render the question moot.

[Mike Betts]

Originally Posted by ChrisH

There are other ways that might be cheaper and lighter than a full up scope. And these might be?

Chris,

I would suggest this.

On another note, I feel that the single most important function which the mechanical team can provide the electrical team is to integrate the sensor(s) and wiring into your design from the beginning. In other words, protect it so that it will not break...

Walk around any competition and you will see wonderfully designed mechanical mechanisms with limit switches or potentiometers mounted with rubber bands, tie wraps and hot glue. These devices and their wires are invariably exposed to the interface between 130 lb robots colliding at 5 to 10 ft/sec.

Just as invariably, you will hear the mechanical team complaining about the lack of robustness of the sensors. In my view, it is the shortsightedness of the mechanical team which allowed such a fragile item to be exposed to such an environment.

Don't leave the mechanical design of electrical components to the electrical team. They do not have your experience.

As an example: When you CAD a gearbox, add in an extra gear and mount for an encoder within the gearbox at design time. Without side loads and properly protected, these devices should be as robust as anything else in your geartrain.

Designing for failure tends to encourage failure. Worrying about failure analysis during the competition can become a self fulfilling prophesy. Break your pots in the fall and learn how to keep them from breaking.

Driver practice, software verification and strategy aside, the winning robot is not the fastest, the most powerful or the most clever design. At the end of the day, it is often the last robot standing which wins the competition.

JMHO,

Mike