I’m reading a certain amount of misinformation on the forum regarding electro static discharge, its effect on the robots and the “fixes” that may or may not work. Whilst I am by no means an expert in this area I wanted to lay out a few facts so we are all on the same page. The following represents my own thoughts and are unofficial.
**What is causing the static?
**
The robots are building up a static charge due to the Triboelectric effect. I’m going to quote wikipedia here as it’s as good an explanation as any.
In the case of VEX robots we have wheels using some type of rubber (??) roller (I’m focusing on mecanum and omni wheels here) rubbing against the foam playing surface which I assume is some type of Ethylene-vinyl acetate (EVA ref) a polymer of ethylene and vinyl acetate. I cannot find a reference showing where EVA is on the tribioelectric series, the closest reference I can find is here but it is sufficient to say that the rubbing of the wheels on the playing surface is causing a charge to build up on the robots.
**What does the anti-static spray do?
**
Well, the available information says that the anti-static treatments reduce the surface resistance of the treated material. I’m not sure how exactly this is working on the playing surface but suffice to say that the triboelectric effect is reduced.
**What does the static discharge do to the robot?
**
The static discharge can interfere with the operation of the cortex, specifically the micro-controller inside the cortex. Robots using the IMEs are particularly susceptible to the effects of static discharge for a couple of reasons.
The IMEs are powered from the same source as the micro-controller, older sensors are all powered from a separate regulator.
The IMEs contain their own micro-controllers and use a complex (relatively) method of communicating with the cortex.
The standard digital ports have a series 1K resistor making them less susceptible to ESD.
We have seen two main problems caused by static discharge.
-
The user processor inside the cortex (the micro-controller runing EasyC or RobotC code) can crash (the definition of crash being that it stops running the code correctly for whatever reason, bad memory access, un-handled exception etc.). Once this happens control of the robot is lost with motors running at their last commanded speed due to a bug in the master firmware.
-
IMEs either lose communication causing the encoder count to freeze or are they re-initialized so they return unexpected encoder counts.
Condition 1 is very rare, I have never experienced it, there is one video on youtube that I think does show it well, it was posted by team 675B back in January here. Near the end of the match the robot touches the field perimeter and causes the video display to blank as well as the robot crashing. I’m 99% certain this was static discharge through the field perimeter.
[ATTACH]7320[/ATTACH]
Condition 2 occurs much more frequently, the effect to your software will be different depending on whether EasyC or ROBOTC is being used. There is more discussion in this thread but the two working theories I have are a)IME cpu crashes causing I2C bus renegotiation, encoder count freezes then goes back to 0, b) I2C communication receives an unexpected event (start bit, stop bit, ack or something out of sequence) that causes I2C bus renegotiation, count freezes the back to 0. EasyC does not renegotiate so the program simply sees the encoder count freeze.
**Are the exposed pins at the end of the IME daisy chain the problem?
**
No, I don’t think so.
**Will electrical tape on the IME connectors help?
**
Only in helping secure the cables, no effect on ESD issue.
**Does insulating the cortex from the robot help?
**
The cortex is in a plastic enclosure, it’s already insulated.
**Why does it appear that ROBOTC crashes more than EasyC?
**
ROBOTC communicates with the IMEs much more frequently than EasyC, a bad communications event is more likely to occur due to the increased communications.
**What can I do to reduce the static problem?
**
The fields at worlds will be treated with anti-static spray, I think static will be a non issue, however, for the ROBOTC users…
Upgrade to V3.60, spurious I2C communication issues have been reduced by a factor of 10.
Again, upgrade to V3.60.
For the EasyC users, switch to ROBOTC 
V3.60 will also help with condition 1 above as it contains a watchdog timer set to 750mS, if the cortex crashes the code will be reset and control may be regained, however, note the warning here.
In addition, write software that can tolerate imperfect IME operation, always use a timeout when driving based on encoders, monitor the encoder values if you see a large negative (or positive) jump when there should not be one then take some alternative action. Some of these types of things I covered in this post, although that was not specifically aimed at IMEs.
