Re: FTC- preventing ESD
 

Yeah, the NXT controller locking up during competition is an odd anomaly. I use to blame static as the cause of the NXT locking up, primarily because once we sprayed anti-static spray on the floor mats the teams with the lockup problems would significantly reduce. We also thought the NXT itself was to blame, and teams this year who were having lockup problems literally replaced the NXT for NXTs that never had the lockup problem, and lo and behold the lockup would show up on the new controller the very next match.

My FTC team this year did everything that is recommended by all the "best practices" documents - mounting electronics on lexan, insulating everything, yadda yadda, and we still ran into NXT lockups this year. Our lead programmer then tried to determine if there was a place in the code where the NXT locked up the most, or if it was random. Sure enough, he found a spot where if it was GOING to lock up it DID (meaning the controller only locked up when it hit a particular piece of code - though locking up was not guaranteed, the controller only seemed to lock up at that point in the code). We use LabVIEW, so there's no "crazy" pointer manipulations or NULL references (in our code) or what have you, but the lockup was actually in setting the motor speed. The crazy part was if we just deleted that command in the code, the lockup stopped happening, and even when we added it back the lockup did not happen. However, pulling the original code out of source control and running allowed us to reproduce. LabVIEW compiler error was all we could come up with, though the VIs in the reproducing case and the non-reproducing case were perfect matches.

I then wanted to blame LabVIEW, but it wasn't limited to LabVIEW. Teams using LabVIEW and RobotC had the problem just as much (almost equally so). I almost now want to blame firmware, but I have no basis to make that claim.

I'm really hoping the EV3 solves this problem, if in fact FTC is moving to the EV3 (which blog posts seem to claim, but the same blog posts claim there will still be support for the NXT next year).

-Danny

Re: FTC- preventing ESD
 

It's coming. Just not sure on the exact date yet.

Danny:
Did your programmer document their findings in any sort of way. If they did, I'd like to take a look at them.

We had a half dozen teams or more using the Matrix out of almost 150. Aside from initial issues in getting it up and running, they didn't have any of the normal issues, Al. The only thing is with the radio on it's own power supply, FCS reads it as bad but in fact on it's own source that one battery last all day.

Re: FTC- preventing ESD
 

Unfortunately we were all mystified by what we found, and we were more in a "how do we keep this from happening to us" mode rather than a "let's document this issue" mode. Now that FTC has ended for us, I will ask my programmer to document what we found, if he is able to reproduce again.

-Danny

Re: FTC- preventing ESD
 

Thanks. I wanna try and replicate it on a show robot. Just inbox me with the information.

Re: FTC- preventing ESD
 

IMHO this is ESD on the I2C lines. They're the single weakest point in the whole system and a really bad choice (dictated by the NXT) for motor control since these lines are high impedance and have a fairly direct path to the micro. Okay so there's some protection inside the NXT but it's going to be whatever a standard called for and likely 15kV plus when it happens data corruption is likely. If there's no error checking on the I2C bus transactions (and there isn't to my knowledge) who knows what firmware "issues" are lurking about unexplored and untested.
As a side note the VEX system introduced a new motor encoder in 2012(?) which connected via I2C. This was the first I2C sensor for use with the cortex based controller and what a disaster! It took quite a few firmware revisions before these became *almost* as reliable as the old quadrature encoders that just connected to I/O ports.

I don't see this going away with EV3 because it too is I2C.

Re: FTC- preventing ESD
 

Thank you everyone for your wonderful insight. We have some specific questions to ask:

1. Why would shortening the USB cable be of benefit?
2. If rubber doesn't conduct, why do the 'normal' friction wheels generate so much static?
3. Is there a way to neutralize static as it is generated?

Re: FTC- preventing ESD
 

I don't know who mentioned to shorten the USB cable, but shortening the USB cable won't necessarily do anything about the static itself. Unless the cable is rubbing against something that is causing charge static to build up on the cable, I think this is a red herring. However, keeping the USB cable as short as possible is always a good suggestion for FTC robots anyway. I cringe when I see robots with less than 1 foot of space between the NXT and the Samantha module (even considering bends and such) and using a 6' USB cable to traverse that length.

If rubber balloons don't conduct, why do "normal" balloons generate so much static when rubbed against hair? The answer to both questions is the same. I'm sure you can use Google to answer them, but be sure to include the term "Triboelectric Series" somewhere.

The primary way to get rid of static that has built up is to provide a path to a highly positive source. Like the earth. Aside from that, there's research being done to develop materials that can do that. Anything we can do on our robots? These guys seem to have figured something out. Here's also a series of videos they have in "building a better robot" where they talk about "grounding" plastic and shields to the robot chassis. The same team also claims to wipe down their robot with their homemade anti-static mix before each match to minimize static buildup. FIRST use to recommend the use of polycarbonate between the motor controller and the chassis to act as a dielectric, but they've since taken that document down (in the last 2 months). In practice, static electricity is a big "guessing game" of how to deal with it, you pretty much just have to create products that can "deal" with it (or else, zap).

-Danny

Re: FTC- preventing ESD
 

Please note that the video has poly sheet completely surrounding the wheels. As anyone who has worked with Van de Graff generators knows, the moving of materials in close proximity to each other produces significant static buildup. In designs where this is unavoidable, a wiper/brush rubbing on the moving surface and connected to the stationary surface would drain off accumulated charge. Remember that static does not need a conductive surface in which to accumulate as Danny pointed out in the balloon example.
I inspected an FTC robot this year that used a little USB jumper with Radio Shack ferrite cores at each end to prevent any interference. They claimed it worked, I was a little skeptical as the two cores were only an inch or so from each other. Ferrite will not prevent ESD but it does serve to reduce noise currents flowing on the surface of the wire around which it is placed.
The copper tape used in the video, if the 3M product I am familiar with, has conductive beads embedded in the adhesive layer. It is very good at conducting low frequency energy and shielding. It is awful for use at HF and above, making for a very poor RF radiator. (My first hand experience making an antenna using this product.)

Re: FTC- preventing ESD
 

A great set of videos which span a great many topics besides the static discharge events. Great find Danny and as always with these types of tutorials, user benefits may vary and one needs to do the work to learn the why of what is being suggested as a best practice. Don't fall into the trap of taking another team's/expert word as truth without reading and studying the issue yourself. They may in fact be promoting a sound practice but you need to understand the why and because of it if you want to earn points in the judge room. You can credit the source and back it up with your own solid understanding of the need/issue.

Caution, they support tinning wires which goes against the advice of Al.

I'm still promoting the use of these videos by FTC teams in my area as a tool for improving robot design.