Testing and Cause of Failure for Encoders and Hall Effect sensors

[ChrisH]

Al, and Mike,

Thanks for the help. The item Mike linked to does look pretty neat and I will propose getting one to our Fearless Leader. We have a plethora of laptops that were surplused by one of our sponsors (every kid on the team gets one as a loner, they remain team property) and they all have USB and meet the specs. Maybe they can be useful for something besides scouting

And yes Mike we do design the sensors into our design.

Last year we had an encoder. The encoder measured the rotation of a jack shaft. The shaft had a gear mounted on it and the encoder had it's own gear. It was mounted fairly rigidly and there was at least 0.015" slop between the teeth of the gears (approx 1/4 tooth). The encoder was buried in the robot where it would have taken major structural damage to be impacted by part of another robot. Shielding destroyed, major bent aluminum, nothing subtle here, 6" of deflection of the outer shell for contact.

We failed three encoders from two different manufacturers before we gave up. Fortunately our programmers followed my suggestion and made it so the encoder was not essential to operation. (always provide a manual overide for all automated functions) It was never determined just what caused the encoders to fail. One of them is still on the robot, but it has been disconnected. I'm not sure the fate of the others or if they could still be evaluated. We looked at using a pot but it didn't have the resolution we needed to be effective.

I have made it a project for the off-season to better understand how to use these neat little toys. As long as they worked, they worked pretty well, but losing 3 in one and a half competitions was a little too risky for us. I'm thinking about going to Vex chain and sprockets for mechanical isolation to make sure the motion transmission mechanism can't impact the encoder shaft. But that won't help if the real problem is power spikes floating around the electrical system, or the shock of being hit by another robot.

ChrisH

[Al Skierkiewicz]

Chris can you fill us in on the sensor that was failing and what the input frequency may have been?

[ChrisH]

Originally Posted by Al Skierkiewicz

Chris can you fill us in on the sensor that was failing and what the input frequency may have been?

I'd have to look at the robot to be sure, but as I recall it was a 256 step optical encoder with quadrature. The arm was rotating around 4 rpm and the jack shaft was about 5 times that due to a 5:1 reduction between it and the arm. The arm position was what we were trying to control.

So say we had 20 rpm and 256 steps/rev, that works out to about 17Hz. Well within the capability of the sound card scope anyway

[eugenebrooks]

Chris,

This thread caught my eye, and I have a few observations:

1) You mentioned that you don't use a pot because of resolution
issues, and I am wondering if you have tried a 10 turn pot on the
drive shaft that turns 5 times faster to resolve that problem. By
hooking the feedback closer to the motor, so to speak, you can also
remove instability arising from the slop in the gearing between the
motor and the arm.

2) With regard to sensor testing, we have used led indicators as
part of the design, so that a quick look can determine if it
is "blinking," software running in the RC that prints a message
each time a sensor value changes, and finally, a scope. There also
relatively cheap multi-meters that have a "frequency display" for
a TTL input level, and you can use these to see if a high pulse
rate sensor is working correctly.

3) I am a little worried about triggering an input to the RC
at 17khz and expecting the RC to track it, although I have not
tested the limits of the interrupt based inputs on the current RC.

3) The electrical environment in a robot is very noisy, with lots of
spikes on the power lines. If a sensor requires power from the 12
volt line, we bring that power in through a substantial inductor, a
capacitor bypass, and then on board voltage regulation. We usually
ground a sensor at the RC, instead of elsewhere, to avoid
any ground loops that might introduce spikes into the sensor output.

Although we have had some fun with PID control systems running amok
when a collision knocked the analog connector to the RC loose, we have
never had a sensor fail electrically, and we tend to salvage the more
expensive ones by desoldering from a prior years custom circuit board
and putting them into a new custom circuit board made for each build
season.

I hope that this helps...

[Mike Betts]

Doctor B,

It was 17 Hz that he reported, not 17 KHz.

Mike

[ChrisH]

Originally Posted by eugenebrooks

2) With regard to sensor testing, we have used led indicators as
part of the design, so that a quick look can determine if it
is "blinking," software running in the RC that prints a message
each time a sensor value changes, and finally, a scope. There also
relatively cheap multi-meters that have a "frequency display" for
a TTL input level, and you can use these to see if a high pulse
rate sensor is working correctly.

....

3) The electrical environment in a robot is very noisy, with lots of
spikes on the power lines. If a sensor requires power from the 12
volt line, we bring that power in through a substantial inductor, a
capacitor bypass, and then on board voltage regulation. We usually
ground a sensor at the RC, instead of elsewhere, to avoid
any ground loops that might introduce spikes into the sensor output.

I like the LED idea. Especially if we can implement it using the LEDs on the RC. I'm not sure how we were grounded, but I'm pretty sure we did it at the RC. At least there were no extra ground wires running around. We might have had an unintentional ground, but we're pretty good about following good electrical practice (two of our mentors do this stuff for a living and they make sure we do it right) The problem with pots was that they only give 255 "clicks" and we needed 540 to get the resolution we wanted.

Originally Posted by SlimBoJones

What we didn't account for were "jolts." Momentary hits that moved the encoder just far enough to record a count or two (at 256 ppr, this isn't much movement), and fast enough that the RC would read the quadrature signal incorrectly. The end result was a count going in one direction was being misread in the other direction - this is what happens when you read a quadrature signal too slowly. This caused havoc with our PID loops, which functioned great until you smacked the robot, and things would go haywire until you settled everything down again.

I'll have to look more closely into just what was happening at failure. We spent a lot of time getting smacked while we were minding our own business stacking tetras. While we are reasonably sure there was not direct contact with the sensor, we haven't evaluated the possibility of shock inducted counts at a high rate.

[Alan Anderson]

Originally Posted by ChrisH

The problem with pots was that they only give 255 "clicks" and we needed 540 to get the resolution we wanted.

The RC analog input is ten bits, giving 1024 steps. The simple definitions in the default code throw away two bits of resolution in order to emulate the pre-2004 system, but the full range of values is available just as easily.

[ChrisH]

Originally Posted by Alan Anderson

The RC analog input is ten bits, giving 1024 steps. The simple definitions in the default code throw away two bits of resolution in order to emulate the pre-2004 system, but the full range of values is available just as easily.

Somewhere along the line this info seems to have gotten garbled or missed entirely by our team. Either that or I just didn't get the info from the right guy. While I'm a mechanical sort of guy, I have helped design and control process equipment. Due to some very bad experiences I absolutely hate input sources that give me back only 1 and 0 for non-binary input. For a temperature I don't want to hear from the sensor "The temperature has increased 3.7 degrees in the last 2 minutes." That may be an important secondary factor, but what I really want is "The temperature is 253F." If the rate of increase is important I can track that by comparing subsequent readings easily enough.

Encoders can tell me how fast something is moving, and how far it has moved from the start point (assuming the integration routine is working and nothing has been skipped) but they will not tell me absolute position. (unless I use a very special encoder which is out of our price range as I recall) Since position is what I'm trying to control, I'd rather work with a directly correlating signal than deal with trying to integrate or differentiate to get what I really need.

Do I just have to change the variable definition to increase the bit size?

[Alan Anderson]

Originally Posted by ChrisH

Do I just have to change the variable definition to increase the bit size?

The Get_Analog_Value() function returns the full 10-bit result from the analog-to-digital converter. For example,

 Get_Analog_Value(rc_ana_in01)

will give you a number from 0-1023 representing the voltage (from 0 to 5 volts) on the first RC analog input.

Typically, one will #define a more friendly name for the signal:

#define angleFeedbackPot = Get_Analog_Value(rc_ana_in02)

And that's all it takes.

[eugenebrooks]

Originally Posted by ChrisH

The problem with pots was that they only give 255 "clicks" and we needed 540 to get the resolution we wanted.


I'll have to look more closely into just what was happening at failure. We spent a lot of time getting smacked while we were minding our own business stacking tetras. While we are reasonably sure there was not direct contact with the sensor, we haven't evaluated the possibility of shock inducted counts at a high rate.

The resolution, on the old PBASIC RC was 255. The resolution on the
new RC programmed in C is 1024 (only on the RC, not the OI), but I will
agree that your desired resolution is too close to the limit for comfort.

If you are using busy polling in the "fast loop" to detect state transitions,
you can be missing changes that happen while the RC is not looking.
This happens while the RC is busy with its periodic processing of inputs
and outputs, between the calls to get and put a packet.

One of the things that we do here is track the minimum number
of consecutive on, and off, measurements and report that as
a diagnostic to indicate the risk that we might have missed any.
You can indicate that the minimum has been violated with an
LED output, and print the number when the computer console is
being used. We start to get worried if the minimum number
gets lower than 5 or so.

Another strategy is to use an interrupt scheme to track the encoder,
but this method has plenty of its own potential gremlins. You have
to be very careful to avoid all the pitfalls, but an interrupt based
scheme is capable of tracking state transitions at a much higher rate
because only higher priority interrupts will interfere with it.

[foobert]

firstly, let me say that i have no actual experience with the first gear, (i dropped out of high school way too long ago for that), but i did buy myself a vex kit to play with and the hardware seems to be pretty much the same. you guys just have a little more of it.

anyway, the problem with polling an encoder on my controller would be that for 2ms out of 18.5ms it's busy in a timing loop generating its pwm outputs. that seems like an excellent opportunity to miss a signal.

conversely, the problem with using an interrupt to catch the signals from the encoder is that if it occurs during the 2ms that the processor is counting cycles to produce the pwm it will cause glitches in the signals to the motors.

overall i'd say, that if your issue is positioning, go with a pot. you do have ten bits of resolution. on the other hand at 17Hz you're likely not going to miss anything.

oh, well, guess i've contributed approximately nothing.

later.

[Mr. Lim]

Originally Posted by ChrisH

I'd have to look at the robot to be sure, but as I recall it was a 256 step optical encoder with quadrature. The arm was rotating around 4 rpm and the jack shaft was about 5 times that due to a 5:1 reduction between it and the arm. The arm position was what we were trying to control.

So say we had 20 rpm and 256 steps/rev, that works out to about 17Hz. Well within the capability of the sound card scope anyway

Sorry Chris, I tend to disappear from CD for days at a time, so I apologize for the late response.

http://www.virtins.com/ shows a little diode circuit to clip the signal at about 1V, which Al alluded to as roughly the limit of the sound card. Additionally, an amplifier set up as a unity gain buffer (doesn't actually amplify) provides some isolation, and impedance matching. I don't have any schematics for you handy, but I'm sure they can be found on the net, or someone here can provide them. You could probably get away with just the diode circuit in the link above, if you're using it on the 5V signals from your sensors. I can't make any promises though =). I haven't used the sound card oscilloscope myself yet.

Lastly, we used 256 ppr quadrature encoders on our drivetrain last year (Grayhill 63R series). We initially had a lot of problems when we bumped into things, or our drive chains backlashed. We worked out our max RPMS, and pulse rates, and they were all well below our maxes...

What we didn't account for were "jolts." Momentary hits that moved the encoder just far enough to record a count or two (at 256 ppr, this isn't much movement), and fast enough that the RC would read the quadrature signal incorrectly. The end result was a count going in one direction was being misread in the other direction - this is what happens when you read a quadrature signal too slowly. This caused havoc with our PID loops, which functioned great until you smacked the robot, and things would go haywire until you settled everything down again.

We actually worked around this with a quadrature stretching circuit, the schematics of which you can find here, courtesy of Kevin Watson.

-SlimBoJones...