Testing and Cause of Failure for Encoders and Hall Effect sensors

[Al Skierkiewicz]

Chris,
I went to the site Mike linked to and wow, you get a lot for little money. It looks like it would solve the problems with using a sound card. Cables look a little short but you can probably get around that.
When sensors just are not working right, a scope with better that 15kHz bandwidth can tell you a lot. Some failure modes produce a lot of noise in the output and a low bandwidth may attenuate those spurious signals to a point where you would think they are insignificant. It is also possible that the sensors can't keep up with the stimulus, and a scope will show you the effect on the sensor output as speed increases. From and electrical standpoint, I will grab my Fluke first and a scope second.
As to using transformers...the device will couple signals without having to tie chassis to the circuit ground but it does so with magnetic fields. A shield is required (transformers are available with shields) to prevent magnetic fields from coupling into the transformer. Spinning motors do have some nasty magnetic coupling that would affect the display and accuracy. One other thing that came to me is that sound cards are capacitively coupled so looking at a DC component is out of the question with a sound card solution.
Many teams do not carry scopes with them to competition. We usually carry a beat up one and actually take it out from time to time to check on something. Since it is not new or in good condition, a bunch of bubble wrap will usually do OK to put it in the shipping container with the robot.

[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

[foobert]

have a look at the data sheet for the 18f8520 at the microchip website. it will explain how to configure the adc. eight bits of the output go into one eight bit register and the other two bits have to be extracted from another. whether you get the high order or low order eight bits in the register is configurable. you'll probably want the low order eight bits so you can move them to the low order byte an integer, then mask the high order bits into the two low order bits of the high order byte. wow, what a sentence.

i'll try to formulate a clearer response tomorrow.

g'nite.