[FTC]: Static issues. Solutions?

[MattRain]

I have seen the thread made by Philbot in regards to static, but I wanted to see if any other teams are having this problem.

We have two teams at our school, 2844, and 8640. Each of these robots have been built completely different. If you want to see pictures, click the twitters below....

8640 is currently using a mix of Tetrix and Andymark motors. The Tetrix motors they are currently using are on the drive train, with two tetrix encoders. They have run into a large problem with static shock as they come down the ramp and on to the foam tiles. All of the electronics have been isolated onto a plastic sheet.

The problem though: During autonomous, they have noticed that the encoders on the tetrix motors are getting a small shock to them. Everytime that it shocks, the encoders seem to restart the last step in the autonomous program. This (re-starting of the step) only happens when they can see/hear the shock. They have been watching from the NXT screen on the computer. Has any other team seen this happen. There is no way to isolate the encoders though. They currently replaced the motor mounts for those motors with plastic versions, which has seemed to slow the shock rate down, but are still having the problem.

2844: They do not have as large of a problem. Their robot is fully Andymark motors. From time to time, it will shock, also resulting in a re-start of the last step of the autonomous code. So its not just the tetrix encoders.

I guess in short, has anyone seen a problem with static shock with the ramps, and how are you solving the problem..??(Other than static spray on the tiles.)

[TheThings5926]

Our team used the tetrix tracks last year and had many, many static issues. It was a great learning experince and here is what we have to offer-

1. Ferrite protectors, these devices snap on your USB cable and disperse any electrical shocks sent through the cord. They are only $1.03 at MyCableMart and they help a ton. We bought a bunch and handed them out at our tournaments. Here is the link http://www.mycablemart.com/store/car..._detail&p=2350

2. Use a shorter USB cable, we use a 4 inch cable. The USB cable acts as an antenna for the static. A shorter cable means less static communication issues. You can also buy these at MyCableMart

3. An expensive but good option, we used TechSpray Licron Crystal spray. It is basically a spray paint that you can paint the parts with to make them conductive. Use this on plastic parts, particularly ones that are moving or rubbing on the mat. It is rather expensive, but saved us from communication errors this year. I have a link, you can also buy it on Amazon.com but it costs more there http://www.techni-tool.com/754CH568

4. Static spray, wipe your robot down with this, it helps! We didn't come up with it Cougar Robotics did but we use it all of the time. We wipe our robot down before every match. Here is the link on how to make it http://www.instructables.com/id/Crea...-Static-Spray/

5. This is a handy tool also by Cougar Robotics that can detect if you have a lot of static build up, our team made them and gave them to our states FTAs and they look to see if there is a lot of static. Here is the link http://www.instructables.com/id/Stat...city-Detector/

All of these fixes are cheap except for the paint. They all will help you a lot, let us know how it works out for you. I hope it helps! Good luck with the rest of the season.

[TheThings5926]

You can also share our website if other teams are having the same problem.

http://www.thethings5926.org/got-static.html

[MattRain]

We have already done 1,2, and 4. Maybe try 3!.

Ok, I know I have seen it somewhere, and can't seem to find it. Where is the rule that says you can not drag a wire (lighting bot) on the bottom of the robot?

Thanks!

[Scott_4140]

Originally Posted by MattRain

Ok, I know I have seen it somewhere, and can't seem to find it. Where is the rule that says you can not drag a wire (lighting bot) on the bottom of the robot?

You're correct that you can no longer drag a wire. FIRST determined that the benefit was minimal. Not sure why they banned it.

The next best suggestion is to use the USB Surge Protector listed on page 17 of the FTC Robot Wiring Guide. If you haven't looked at this guide, it's available on the Team Resources page.
http://www.usfirst.org/roboticsprogr...team-resources

[maths222]

Originally Posted by Scott_4140

You're correct that you can no longer drag a wire. FIRST determined that the benefit was minimal. Not sure why they banned it.

The next best suggestion is to use the USB Surge Protector listed on page 17 of the FTC Robot Wiring Guide. If you haven't looked at this guide, it's available on the Team Resources page.
http://www.usfirst.org/roboticsprogr...team-resources

I can offer some explanations here. Dragging a wire was found to offer minimal benefit, but it caused problems when a team without a grounding wire touched a metal surface on an ungrounded robot, as this created a sudden, large static discharge event which often locked up one or both robots involved. Consequently, banning or requiring such a strap are the main potential solutions, and given the lack of observed benefit, the GDC went with banning it.

The USB surge protector is not the next best solution-it is the best solution. I am not aware of any teams using the devices at the events I have FTA'd at locking up. A ferrite bead is the next best (and cheaper) solution, and seems to greatly reduce the incidence of lockups. The cause of lockups appears to be ESD discharge entering the NXT through the USB cable, which a surge protector prevents. (Ideally the NXT itself would have better ESD protection on its USB cable, but we are using the NXT in a way it was never really originally designed to be used-a mostly plastic, slow moving, TECHNIC-based robot will generate much less ESD, and normally will not be run with the USB cable plugged in while running. I believe that the sensor and motor ports have better ESD protection, probably because they were inteded to be used while the robot is driving.)

By the way, talk to your state FTA's/affiliate partners and ask if they are using any sort of anti-static spray-it is currently recommended but not required by FIRST, but it definitely seems to help. Anti-static spray on your robot may help, but a USB surge protector is more helpful.

If you have any questions/concerns, ask!

[MattRain]

Originally Posted by maths222

By the way, talk to your state FTA's/affiliate partners and ask if they are using any sort of anti-static spray-it is currently recommended but not required by FIRST, but it definitely seems to help. Anti-static spray on your robot may help, but a USB surge protector is more helpful.

If you have any questions/concerns, ask!

I know AZ is using it, as we ran the first qualifier at our school this year.

We have both the surge protector and the choke on both of our robots. We have followed all of the items from the wiring guide as well, with insolated electronics on the robot, the only place we see a shock is when it comes to the tetrix encoders. We can watch it shock and re-start the last case/step in the autonomous programming. We were wondering if any other teams have seen a problem like this...

I hope FTC will go back to using wooden elements. These metal elements are just a pain. This is really the first year that we have had a problem with static discharge.

Do you guys know where exactly it says that you cant have the wire dragging, just for my reference when my other mentors ask?

[maths222]

Originally Posted by MattRain

I know AZ is using it, as we ran the first qualifier at our school this year.

We have both the surge protector and the choke on both of our robots. We have followed all of the items from the wiring guide as well, with insolated electronics on the robot, the only place we see a shock is when it comes to the tetrix encoders. We can watch it shock and re-start the last case/step in the autonomous programming. We were wondering if any other teams have seen a problem like this...

I hope FTC will go back to using wooden elements. These metal elements are just a pain. This is really the first year that we have had a problem with static discharge.

Do you guys know where exactly it says that you cant have the wire dragging, just for my reference when my other mentors ask?

If I understand correctly, your symtoms are different from any I have observed when working with Tetrix robots. That said, would you be able to post any pictures of the affected encoders. Also, when this occurs, I assume you are moving forward using the encoders to measure distance. Does it behave as if the encoders were suddently reset to 0, and it therefore needs to move the whole distance again? I have noticed that the Tetrix motor controllers are relatively sensative to ESD, although in my experience, the whole controller tends to lock up, rather than the encoder counter simply reseting. I assume that the ESD passes through the encoder cable, into the motor controller, and causes the motor controller to reset itself. Due to the way the motor controller is designed, the controller keeps the count since the last reset, and then the NXT just reads that. Therefore, if it resets in the middle of the action, the encoder is set to 0. If there is a pause, it is probably because the controller needs to intitialize and recieve the command to set the motor power from the NXT.

[MattRain]

Originally Posted by maths222

If I understand correctly, your symtoms are different from any I have observed when working with Tetrix robots. That said, would you be able to post any pictures of the affected encoders. Also, when this occurs, I assume you are moving forward using the encoders to measure distance. Does it behave as if the encoders were suddently reset to 0, and it therefore needs to move the whole distance again? I have noticed that the Tetrix motor controllers are relatively sensative to ESD, although in my experience, the whole controller tends to lock up, rather than the encoder counter simply reseting. I assume that the ESD passes through the encoder cable, into the motor controller, and causes the motor controller to reset itself. Due to the way the motor controller is designed, the controller keeps the count since the last reset, and then the NXT just reads that. Therefore, if it resets in the middle of the action, the encoder is set to 0. If there is a pause, it is probably because the controller needs to intitialize and recieve the command to set the motor power from the NXT.

Alright, interesting. Click on the link below in my sig, to the Trojan Robotics Twitter, it is currently the third picture on the page of the affected encoders. It is only during autonomous that this really applies. It just seems to reset the encoder, wether it be in the encoder itself, or the shock moving up through the wiring to the box. Our Autonomous is built on cases, which tell it to go a set amount of inches, until going onto the next case. Just seems to repeat the case when the shock happens. It only seems to happen while coming down the ramp or right off the ramp. The rest of the field, the robot seems fine.

Our next step is to rip out the tetrix motors, and replace with Andymark Motors, as the brother team, 2844, has them, and is shocking as well when coming down the ramp (2- or 3 shocks each time), but not being affected.

[TheThings5926]

Interesting, the conductive paint may help but I don't know how that will affect the encoders. I think if the encoders didn't have a plastic case you would't be having this problem so the paint might help. I think if you switch to AndyMark motors you wouldn't see this problem anymore. You could try wrapping bare wire around the encoder and connecting the bare wire to the frame. This will ground the encoder to the frame. Is the encoder actually hitting the ramp or the motor? If the encoder is hitting the ramp you could try a metal skid plate that is grounded to the frame too, this will take the shock and ground it into the frame and not your encoder.

Also, why do you use plastic printed motor mounts? For static isolation?

Best of luck!

[MattRain]

Originally Posted by TheThings5926

Interesting, the conductive paint may help but I don't know how that will affect the encoders. I think if the encoders didn't have a plastic case you would't be having this problem so the paint might help. I think if you switch to AndyMark motors you wouldn't see this problem anymore. You could try wrapping bare wire around the encoder and connecting the bare wire to the frame. This will ground the encoder to the frame. Is the encoder actually hitting the ramp or the motor? If the encoder is hitting the ramp you could try a metal skid plate that is grounded to the frame too, this will take the shock and ground it into the frame and not your encoder.

Also, why do you use plastic printed motor mounts? For static isolation?

Best of luck!

We are trying the Plastic motor mounts, and have seen a decrease in the amount of times its been shocked. We didn't know if the shock was going through the frame, as we have a 2x1 bar running across the robot that is about 3/8 of an inch off the ground... Just the way the robot was designed, as its a very open robot. The encoders and motors do not get close to the ramp/pads. See our twitter for the robot. Our team doesn't hold anything secret really.