possible solution to the static problem

[MrForbes]

Originally Posted by EricH

Just on what I've seen on CD. This may be a small portion of teams that each fry multiple components, or not.

Eric--do you think we hear about problems more than we hear about things working well?

We haven't had any hardware trouble with the system, aside from some "no comm" during testing/practice, which might be due to the WGA location on the robot. And we used it almost continously from late December till ship.

[Jared Russell]

Originally Posted by EricH

Just on what I've seen on CD. This may be a small portion of teams that each fry multiple components, or not. I am not involved with a team this year due to location (no team within about 100-200 miles, and no car). However, my old team reports that if you set up the control system as spec'd, you should be fine (other than the risk of frying that has been reported).

I think we all have seen the 100+ reply thread about failing Jaguars, but outside of that my experience with the new system has been largely positive (though I still maintain that it is 5x bigger and heavier than it needs to be).

[David Brinza]

Can the moderators merge this thread with this one: Field Static Solutions?

[Bharat Nain]

Originally Posted by dlavery

Just out of curiosity, have you actually used the control system at all this year? Are your comments based on actual experience and personal practical knowledge? Or just second-hand information provided by others that you have not personally verified or validated?

I am just trying to understand how to calibrate credibility levels of the comments.



.

Just out of curiosity, are you still questioning the fact that teams have had problems with the control system?

[Alan Anderson]

Originally Posted by Doctorwho

As seen in last weekend's regional competitions the electro-static discharge caused by the rover wheels and the floor can fry speed controllers, driver stations, and even knock the field systems out of whack.

I'm aware of many Driver Station issues, ESD sensitivity among them, and I hope appropriate corrective measures can be determined before too many weeks of competition go on.

Where have you seen reports of ESD frying speed controllers?

The data logs from the field electronics don't seem to show anything specifically ESD-related, with the understandable exception of a missing ground connection causing issues until reconnected.

Originally Posted by EricH

How about grounding the airlocks? Teams can't do that, but if FIRST figures out how to do it, then the issue won't exist anymore. At least, not as much.

Grounding them wouldn't seem to be as useful as insulating them. Simply taping over the airlock metal to attenuate the spark when a robot bumps into it ought to be a good solution.

Originally Posted by Doctorwho

I don't know how much it would affect traction, or if it would at all as the spray's viscosity is almost the same as water and it dries without leaving any sort of residue or film on the rover wheel plastic.

If it leaves no residue, it can't really affect anything, including static electricity. Obviously it must be leaving something behind.

As I said in my first post you could also spray it on the more sensitive parts of your electronics and control board to reduce the likelihood of releasing the magic smoke.

That's not how it works. You can't just apply a magic static-insensitivity solution to electronic components. What the spray does is reduce the ability of exposed surfaces to accumulate electrons and charge the system up to voltage levels where ESD is a problem. It doesn't work in many situations, though.[/quote]

[GaryVoshol]

Originally Posted by Tom Bottiglieri

The FRP is non conducting, so there is no path from the robot to the ground while it is driving around. If you are driving full speed into a wall or airlock, there may not be enough contact with the carpet to discharge the build up into the ground before it contacts the field frame.

My thoughts as well. People were not reporting getting shocks when the robots were touched at the ends of the rounds. So any electrostatic charge that had built up was still there until grounded. The people on the FRP weren't grounded either.

[Wayne C.]

I have to jump in here-

during build season our team had horrible issues with static frying the ethernet ports on our driver stations. We had hooked up the cRIO on an old drive base and used it for programming while the competition robot was in the shop. We have ALWAYS had static charge accumulation on our chassis from our large rubber wheels running on carpet to the point where we would drag a grounding strip below most of our machines (with a sign that says "if you can read this we are screwed")
What we found was that even if we grounded the driver station to the nth degree if we tethered the robot to the station to dump code it would wipe out the ethernet port. We did this twice in the build season and Andymark graciously did a quick resupply of components for us.

Our solution to programming once we determined the problem was to dump our code remotely and we simply had no more problems with the driver station.

That is until NJ....

Obviously you cannot program remotely in the pits at the event. Therefore we were required to tether the robot. Almost immediately driver station issues began and we solved them by adding a switch in the line between the driver station and the robot. Doing that prevents the driver station destruction but we already have blasted one of the ports in the 5 port switch.

During calibration of the camera on the field we also had a driver station power supply blow out for no apparent reason and only a trip to Radio Shack and $30 was able to fix it. (there aren't resupplies in the pit area or on the Andymark page!)

Those at NJ may have noticed that our pit is fanatical about static charge now. We wear Static Guard like cologne. Nobody touches the robot or controls without a ground discharge procedure. But there are times when connection between the robot and the driver station is necessary and at those times we keep our fingers crossed and a new driver station ready.


But perhaps what is the most frustrating of all is the response we keep getting from FIRST - " OH we haven't heard of any problems" . I'm sorry but I hear a roar of problems when I talk to teams and I am not making this all up.

All we want is a control system with the reliability we have had in the past. I like the cRIO unit well enough. It is the peripheral parts that seem to be "less than satisfactory". And it would have been nice to have as greater degree of testing and ready support for this system before were received it in the AS WAS state it went out in.

WC

[Steve Compton]

Hey folks,

Not sure if all your static issues are wheels and airlocks; our (1391) experience at Jersey was something else altogether. Almost all of us are spinning some sort of insulator (rubber, plastic, urethane, etc.) around - quite often - another insulator (PVC or ABS rollers) and when they aren't enough alike .... whoops. We have created VanderGraf generators that send spike charges from the rollers into someplace or another that finds its way to where we don't want it to be.

During practice rounds, we watched our robot run for 25 seconds, then stop as the CRIO rebooted, then run another 10 seconds, reboot, etc. This was early on and no one else had run into this, so we began from ground (no pun intended) up back in the pits. Curiously, static wasn't considered early - we looked at current draws, 24V supply, voltage differentials, code, etc - anything that we thought might stop he processor cold. Eventually, at 7:45 in the evening, I disconnected everything, including motors, ancillary code, and hand manipulated our belt collector - bam! same behavior as all day. We could shut off the CRIO with me as the motive force.

By next morning we had: 1. rubberized our PVC rollers with DipIt spray paint (to make the roller more similar to our belt); 2. put a 3/8" aluminum rod across the frame that touched the roller (to dissipate charge rather than having it build up and spike), and 3. begun to spray our belt prior to each round with Static-Guard (yep, the grocery store solution.)

No more problems. Ends up the static spikes were traveling through PWM cable connections - can't expect any processor to handle that, other than to reboot. We built the static generator, after all. All the ideas mentioned previously won't deal with the delivery of an internal spike to the processor, so think through your observations carefully. I really don;t think frame charge is the issue - you did insulate your processor board after all, right? The processor was just doing what it was designed to do to avoid damage. The clue we finally had that it was PWM was that even when the camera was turned off, and we had disconnected the wires to the Victors (but not the PWMs), the camera's servos were 'twitching' the camera for a couple spikes before the CRIO cut out.

Hope this helps.

[Doctorwho]

At Manchester people were having issues with driver's stations frying themselves when running in tethered mode on the practice field. At the end of the first day they had teams searching for spares. It just seems to me that while the new system is fancier and more advanced it's not as durable as the old IFI system.

[David Brinza]

There are some of us in FIRST who do understand the importance of ESD control.

If you work on or near sensitive electronics hardware ESD controls are generally the rule. In my experience involving spacecraft hardware at NASA/JPL, there are very tight restrictions and mandatory training to avoid ESD issues. Dave's "other cars on Mars" (Spirit and Opportunity) were built with great care to avoid ESD.

We have requirements for use of grounded equipment, wrist straps, conductive garments and work surfaces (including floors), ESD-safe chairs with chains that drag on the floor, minimum relative humidity (>30%), air ionizers, avoidance of static-producing materials (i.e. no paper, styrofoam, teflon, adhesive tape or other non-conducting items) within one-meter of critical hardware. We use bleed resistors (10-100 MOhm) between electronics chassis and power/return line to avoid static charge build-up.

One of the tricky issues with ESD is that it can cause "latent" damage. A piece of equipment might continue to work after a "zap", but in reality some internal damage may have occurred. The next zap - even a tiny one, can cause a permanent failure.

I think we're learning lessons this year in the importance of ESD control. Basically, we've got six van de Graaff generators running around on a good insulator with equipment that is likely more susceptible to ESD than what was used in the past. The fact that we're seeing DS and robot resets attributed to ESD is frankly frightening to me. The guidelines from FIRST to deal with this threat needs some beefing up.

There's another thread dealing with this matter as well: Field Static Solutions

That thread should be merged with this one. Those out there with real-world experience in ESD control should post recommendations for teams. FIRST needs to take the appropriate measures with the field (some of which are already in place, like the earth ground at the alliance stations).

[Mike Betts]

All,

I'm not saying we don't have a static problem. I'm suggesting that some people are jumping to conclusions here and what we need is some level thinking...

I found Steve's post about his team's roller system most illuminating...

I also agree with Gary and Tom that we are not getting the complaints of static from the robot operators and field reset crews that we did in 2004 ( http://www.chiefdelphi.com/forums/sh...ad.php?t=27912, http://www.chiefdelphi.com/forums/sh...ad.php?t=27914, et cetera).

Also, It would not appear that the floor and wheel material are far enough apart on the triboelectric series to be effective as static generators. Although I'd love to hear the input of a materials engineer on this...

On a slightly deviant note, it is interesting that we are reporting problems when tethered on the practice field. My team also runs untethered at the school... If this is true, I would think that this scenario (running tethered) should be reproducible in any of our classrooms when we are practicing.

I plan to look into this last point tomorrow...

Regards,

Mike

[Steve Compton]

Glad to be illuminating; more often the kids on my team will tell you I generate heat instead. One more thing - we ran for two weekends in our gym untethered (and tethered in our shop) without ever seeing this issue. That's why we were confounded about it rising in the regional. I think it ended up being a difference in atmospheric conditions (underneath the floor in Jersey is a solid-ice hockey rink) that made it far more dry than where we originally designed and ran our machine.

[Daniel_LaFleur]

Originally Posted by Steve Compton

Hey folks,

Not sure if all your static issues are wheels and airlocks; our (1391) experience at Jersey was something else altogether. Almost all of us are spinning some sort of insulator (rubber, plastic, urethane, etc.) around - quite often - another insulator (PVC or ABS rollers) and when they aren't enough alike .... whoops. We have created VanderGraf generators that send spike charges from the rollers into someplace or another that finds its way to where we don't want it to be.

During practice rounds, we watched our robot run for 25 seconds, then stop as the CRIO rebooted, then run another 10 seconds, reboot, etc. This was early on and no one else had run into this, so we began from ground (no pun intended) up back in the pits. Curiously, static wasn't considered early - we looked at current draws, 24V supply, voltage differentials, code, etc - anything that we thought might stop he processor cold. Eventually, at 7:45 in the evening, I disconnected everything, including motors, ancillary code, and hand manipulated our belt collector - bam! same behavior as all day. We could shut off the CRIO with me as the motive force.

By next morning we had: 1. rubberized our PVC rollers with DipIt spray paint (to make the roller more similar to our belt); 2. put a 3/8" aluminum rod across the frame that touched the roller (to dissipate charge rather than having it build up and spike), and 3. begun to spray our belt prior to each round with Static-Guard (yep, the grocery store solution.)

No more problems. Ends up the static spikes were traveling through PWM cable connections - can't expect any processor to handle that, other than to reboot. We built the static generator, after all. All the ideas mentioned previously won't deal with the delivery of an internal spike to the processor, so think through your observations carefully. I really don;t think frame charge is the issue - you did insulate your processor board after all, right? The processor was just doing what it was designed to do to avoid damage. The clue we finally had that it was PWM was that even when the camera was turned off, and we had disconnected the wires to the Victors (but not the PWMs), the camera's servos were 'twitching' the camera for a couple spikes before the CRIO cut out.

Hope this helps.

Just as an anecdote to this:

While we didn't have any shutdowns or 'no comm' failures during our regional we did have 2 opponents robots shut down while we were in contact with them.

Our robot, with it's propellers, generates a large static charge. Both robots that shut down had just intruded into our ball pickup section (we were in the act of pinning them ... niether robots were near the airlock). Niether team ever figured out why they shut down ... but I suspect static discharge. Our electronics system is completely isolated from our chassis.

[Ian Curtis]

Originally Posted by Mike Betts

I also agree with Gary and Tom that we are not getting the complaints of static from the robot operators and field reset crews that we did in 2004 ( http://www.chiefdelphi.com/forums/sh...ad.php?t=27912, http://www.chiefdelphi.com/forums/sh...ad.php?t=27914, et cetera).

Tim Baird mentioned getting shocked every time he unhitched a trailer at the end of a match.

[dlavery]

Originally Posted by Bharat Nain

Just out of curiosity, are you still questioning the fact that teams have had problems with the control system?

To the best of my knowledge, I have never questioned that. If you can point to a specific statement where I have done so, please let me know and I will correct it. If you cannot, I trust you will correct your statement and your insinuation.

To the contrary, I am particularly concerned about making sure FIRST and the control system designers are able to gather accurate, factual, and correct information about the performance of (and where appropriate, lack thereof) the new control system. We are all intently interested in hearing first-hand, direct experiences from those that have had issues with the system, in as much specific detail as possible. Gathering as much of this sort of information as is available is the only way that the problems can be tracked down, diagnosed, and corrected. Posts like the one above from Steve Compton are full of great information and particularly useful. **

Conversely, unverified third-hand stories about how "I think my friend's uncle's cousin's Little League coach's team might have had a problem with a garstuckle that was ever so slightly out of plumb" are not particularly helpful. Frequently, they are actually detrimental to the process of getting the problem solved, as they cause a lot of energy to be expended chasing down false leads. So, it is important to identify and understand the difference.

-dave

** and toward that end, I would urge everyone with real, first-hand experiences with problems with the control system to please, please, please let the appropriate people know. Simply posting a story here on CD is not good enough. FIRST (in particular, Chris Jennings and Matt Pilotte) and the folks at National Instruments, Luminary Micro and KwikByte, have to know what is going on. They have to get real data on the performance, experiences, and problem reports associated with the control system. Please make sure you get your information and direct observations to them. One of the best ways to do this is to use the 2009 FRC Control Systems Forums.


.