OCCRA
Go to Post Enlighten a man who sometimes has difficulty understanding why others stray outside the box, when the box appears to be an optimized and elegant solution. - JVN [more]
Home
Go Back   Chief Delphi > Technical > Electrical
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 09-04-2005, 01:04 PM
ChrisH's Avatar Unsung FIRST Hero
ChrisH ChrisH is offline
Generally Useless
FRC #0330 (Beach 'Bots)
Team Role: Engineer
 
Join Date: Jun 2001
Rookie Year: 1998
Location: Hermosa Beach, CA
Posts: 1,239
ChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond repute
Testing and Cause of Failure for Encoders and Hall Effect sensors

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.
__________________
Christopher H Husmann, PE

"Who is John Galt?"
  #2   Spotlight this post!  
Unread 09-04-2005, 05:44 PM
TimCraig TimCraig is offline
Registered User
AKA: Tim Craig
no team
 
Join Date: Aug 2004
Rookie Year: 2003
Location: San Jose, CA
Posts: 221
TimCraig is a splendid one to beholdTimCraig is a splendid one to beholdTimCraig is a splendid one to beholdTimCraig is a splendid one to beholdTimCraig is a splendid one to beholdTimCraig is a splendid one to beholdTimCraig is a splendid one to behold
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

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.
  #3   Spotlight this post!  
Unread 09-04-2005, 06:41 PM
John Gutmann John Gutmann is offline
I'm right here
AKA: sparksandtabs
FRC #0340 (GRR)
Team Role: Mechanical
 
Join Date: Feb 2005
Rookie Year: 2004
Location: rochester
Posts: 804
John Gutmann has a brilliant futureJohn Gutmann has a brilliant futureJohn Gutmann has a brilliant futureJohn Gutmann has a brilliant futureJohn Gutmann has a brilliant futureJohn Gutmann has a brilliant futureJohn Gutmann has a brilliant futureJohn Gutmann has a brilliant futureJohn Gutmann has a brilliant futureJohn Gutmann has a brilliant futureJohn Gutmann has a brilliant future
Send a message via AIM to John Gutmann Send a message via MSN to John Gutmann Send a message via Yahoo to John Gutmann
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

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
  #4   Spotlight this post!  
Unread 09-04-2005, 07:39 PM
Unsung FIRST Hero
Al Skierkiewicz Al Skierkiewicz is offline
Chief Robot Inspector
AKA: Big Al WFFA 2005
FRC #0111 (WildStang)
Team Role: Engineer
 
Join Date: Jun 2001
Rookie Year: 1996
Location: Wheeling, IL
Posts: 11,128
Al Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond repute
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

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.
__________________
Good Luck All. Learn something new, everyday!
Al
WB9UVJ
www.wildstang.org
________________________
Knowledge is power. Power UP!

Last edited by Al Skierkiewicz : 09-04-2005 at 07:43 PM.
  #5   Spotlight this post!  
Unread 09-04-2005, 07:49 PM
Tom Bottiglieri Tom Bottiglieri is offline
Registered User
FRC #0254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Jan 2004
Rookie Year: 2003
Location: San Francisco, CA
Posts: 3,305
Tom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond repute
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

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.
  #6   Spotlight this post!  
Unread 09-04-2005, 08:40 PM
Alan Anderson's Avatar
Alan Anderson Alan Anderson is offline
Software Architect
FRC #0045 (TechnoKats)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2004
Location: Kokomo, Indiana
Posts: 9,164
Alan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond repute
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

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.
Quote:
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.
  #7   Spotlight this post!  
Unread 09-04-2005, 08:47 PM
sciguy125 sciguy125 is offline
Electrical Engineer
AKA: Phil Baltar
FRC #1351
Team Role: College Student
 
Join Date: Jan 2005
Rookie Year: 2004
Location: Sunnyvale, CA
Posts: 519
sciguy125 has a reputation beyond reputesciguy125 has a reputation beyond reputesciguy125 has a reputation beyond reputesciguy125 has a reputation beyond reputesciguy125 has a reputation beyond reputesciguy125 has a reputation beyond reputesciguy125 has a reputation beyond reputesciguy125 has a reputation beyond reputesciguy125 has a reputation beyond reputesciguy125 has a reputation beyond reputesciguy125 has a reputation beyond repute
Send a message via AIM to sciguy125 Send a message via MSN to sciguy125 Send a message via Yahoo to sciguy125
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

Quote:
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.
__________________

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GE/S/P a-- e y-- r-- s:++ d+ h! X+++
t++ C+ P+ L++ E W++ w M-- V? PS+ PE+
5- R-- tv+ b+ DI+++ D- G
------END GEEK CODE BLOCK------
  #8   Spotlight this post!  
Unread 09-07-2005, 11:21 AM
Mark Pierce Mark Pierce is offline
Registered User
FRC #0085 (B. O. B.)
Team Role: Mentor
 
Join Date: Jan 2002
Rookie Year: 1999
Location: Zeeland, MI
Posts: 239
Mark Pierce has a brilliant futureMark Pierce has a brilliant futureMark Pierce has a brilliant futureMark Pierce has a brilliant futureMark Pierce has a brilliant futureMark Pierce has a brilliant futureMark Pierce has a brilliant futureMark Pierce has a brilliant futureMark Pierce has a brilliant futureMark Pierce has a brilliant futureMark Pierce has a brilliant future
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

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.
  #9   Spotlight this post!  
Unread 09-11-2005, 10:15 PM
Mr. Lim Mr. Lim is offline
Registered User
AKA: Mr. Lim
no team
Team Role: Leadership
 
Join Date: Jan 2004
Rookie Year: 1998
Location: Toronto, Ontario
Posts: 1,133
Mr. Lim has a reputation beyond reputeMr. Lim has a reputation beyond reputeMr. Lim has a reputation beyond reputeMr. Lim has a reputation beyond reputeMr. Lim has a reputation beyond reputeMr. Lim has a reputation beyond reputeMr. Lim has a reputation beyond reputeMr. Lim has a reputation beyond reputeMr. Lim has a reputation beyond reputeMr. Lim has a reputation beyond reputeMr. Lim has a reputation beyond repute
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

Quote:
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...
  #10   Spotlight this post!  
Unread 09-12-2005, 12:54 PM
ChrisH's Avatar Unsung FIRST Hero
ChrisH ChrisH is offline
Generally Useless
FRC #0330 (Beach 'Bots)
Team Role: Engineer
 
Join Date: Jun 2001
Rookie Year: 1998
Location: Hermosa Beach, CA
Posts: 1,239
ChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond repute
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

Quote:
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?
__________________
Christopher H Husmann, PE

"Who is John Galt?"
  #11   Spotlight this post!  
Unread 09-12-2005, 01:33 PM
Matt Krass's Avatar
Matt Krass Matt Krass is offline
"Old" and Cranky. Get off my lawn!
AKA: Dark Ages
FRC #0263 (Sachem Aftershock)
Team Role: Mentor
 
Join Date: Oct 2002
Rookie Year: 2002
Location: Long Island, NY
Posts: 1,186
Matt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond reputeMatt Krass has a reputation beyond repute
Send a message via AIM to Matt Krass
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

Quote:
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...
__________________
Matt Krass
If I suggest something to try and fix a problem, and you don't understand what I mean, please PM me!

I'm a FIRST relic of sorts, I remember when we used PBASIC and we got CH Flightsticks in the KoP. In my day we didn't have motorized carts, we pushed our robots uphill, both ways! (Houston 2003!)
  #12   Spotlight this post!  
Unread 09-12-2005, 02:13 PM
Unsung FIRST Hero
Al Skierkiewicz Al Skierkiewicz is offline
Chief Robot Inspector
AKA: Big Al WFFA 2005
FRC #0111 (WildStang)
Team Role: Engineer
 
Join Date: Jun 2001
Rookie Year: 1996
Location: Wheeling, IL
Posts: 11,128
Al Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond repute
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

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.
__________________
Good Luck All. Learn something new, everyday!
Al
WB9UVJ
www.wildstang.org
________________________
Knowledge is power. Power UP!
  #13   Spotlight this post!  
Unread 09-12-2005, 06:44 PM
Gdeaver Gdeaver is offline
Registered User
FRC #1640
Team Role: Mentor
 
Join Date: Mar 2004
Rookie Year: 2001
Location: West Chester, Pa.
Posts: 1,458
Gdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond repute
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

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.
  #14   Spotlight this post!  
Unread 09-12-2005, 07:51 PM
ChrisH's Avatar Unsung FIRST Hero
ChrisH ChrisH is offline
Generally Useless
FRC #0330 (Beach 'Bots)
Team Role: Engineer
 
Join Date: Jun 2001
Rookie Year: 1998
Location: Hermosa Beach, CA
Posts: 1,239
ChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond reputeChrisH has a reputation beyond repute
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

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.

Quote:
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.


Quote:
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


Quote:
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.


Quote:
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.


Quote:
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?


Quote:
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.
__________________
Christopher H Husmann, PE

"Who is John Galt?"
  #15   Spotlight this post!  
Unread 09-13-2005, 12:24 AM
Unsung FIRST Hero
Mike Betts Mike Betts is offline
Electrical Engineer
no team
Team Role: Engineer
 
Join Date: Dec 2001
Rookie Year: 1995
Location: Homosassa, FL
Posts: 1,442
Mike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond repute
Re: Testing and Cause of Failure for Encoders and Hall Effect sensors

Quote:
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
__________________
Mike Betts

Alumnus, Team 3518, Panthrobots, 2011
Alumnus, Team 177, Bobcat Robotics, 1995 - 2010
LRI, Connecticut Regional, 2007-2010
LRI, WPI Regional, 2009 - 2010
RI, South Florida Regional, 2012 - 2013

As easy as 355/113...
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 02:58 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi