ESD - my thoughts

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.

  1. 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.

  2. 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]
675Bcrash.jpg

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

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.

1 Like

Perhaps I’m missing something here (static electricity was not my favorite unit in Physics), but what causes the ESD in the IMEs to cause total robot failure? I’ve seen tons of reasons as to why the IMEs fail and how the robot reacts to the IME failure specifically, but nothing on why the entire robot would fail, rather than just the IMEs.

There was some explanation is this post

https://vexforum.com/showpost.php?p=325945&postcount=46

However, let me try and explain again.

First, you need to understand a little about the architecture of the cortex, here is a (very) simplified block diagram showing the cortex, one motor connected to a motor controller 29 and one IME.

cortex_2.jpg

You can see that in the cortex there are two micro-controllers (discussed many times before), a master cpu that handles things like VEXnet and a user cpu that is running the ROBOTC or EasyC software. The two micro-controllers communicate using synchronous serial communication, this is what we call the SPI (serial peripheral interface) bus. About every 15mS the user cpu sends motor control values for ports 2-9 (going to ignore ports 1&10 here, they work a little differently) to the master cpu whilst receiving information about joystick controls, the user cpu is the SPI master and initiates all communication.

The IME is connected directly to the user cpu, it uses a communications method known as I2C (inter integrated circuit). I went into some detail about how this works in the post I referenced earlier here.

So what goes wrong

  1. The user cpu stops running its software correctly, this is caused by ESD, how and why it stops running I don’t exactly know. I have observed that even with V3.60 a disturbance of the I2C SCL (clock) line can still cause problems but the underlying mechanism is unknown. Last year (with V3.08) the problem was an interrupt generated by an error that was not handled properly, the interrupt fired but the interrupt handler did not clear the source of the interrupt so every time the interrupt handler finished it would immediately fire again. That problem was solved 12 months ago and is not connected to anything we have seen recently. Anyway, whatever happens to the user cpu it stops running code correctly and communication over the SPI bus with the master cpu is stopped.

  2. The master cpu stops receiving information on the SPI bus from the user cpu. The pwm (pulse width modulation) signal for the motors is generated by the master cpu, when communication on the SPI bus is lost the master cpu does not update the pwm control and the motors continue to run at the last commanded speed. The master cpu receives the field controller information and should be able to disable motors when the robot is disabled by it, however, due to a bug in the master firmware this does not happen. At this point control of the robot is lost until power is removed.

This is the explanation of what I referenced as condition 1 below and is a very rare event. This problem has much more to do with the user cpu crashing rather than a problem in the IMEs. The issue in having the IMEs connected is that there is an electrical path directly into the cortex via the SDA and SCL lines and also into the micro-controller sub-system via the 5V power for the IMEs.

Condition 2 below has more to do with either the cpu inside an IME reseting or the I2C software that is part of the ROBOTC or EasyC firmware ending up in an undefined state where normal communication with the IME is lost.

ROBOTC V3.60 addresses condition 1 by the use of the watchdog timer. It addresses condition 2 by improvements to the underlying I2C communications firmware.

1 Like

We had experienced lost communication between robot and remoter once after our robot hit premeter fence hard during drive control.

A bouncing USB stick can cause the same problem.

…or bouncing battery. We’ve had that one before.