"No Comms"

[sabruce01]

Has anyone experienced this during competition? I know in OKC there were a few that had problems. Our team lost communications 5 of the 8 qualification rounds. Our bot would simply quit in the playing field. I spoke with nearly everyone there and got nowhere. Everything they told us to check had already been replaced in the pit. Auto would be fine, then about 1/2 way through tele, we would loose communication. During our last elimination round we didn't even have an auto which caused us to be eliminated. There is no way we were loosing power to the receiver. We troubleshot that to death and could not get it to fail. But that always seemed to be the default answer I got when asking around.

Any suggestions??? Anybody experience the same?

[big1boom]

Sounds like the problem a few teams were having with the Drivers Station. The Ethernet ports on the DS seem to break easily, so once one breaks, make sure to tape over it. We had Port 2 break.

[#1packerfan92]

this happened to our team at the NJ regional. We beilieve it was the server on the fields fault because it happened to numorus teams on each alliance over the three days

[GBIT]

At GSR they re-ran about 12 matches and were down with comms problems for most of the morning thursday.... Our robot lost about 3 times cause of comms issues....

HERE IS HOW THEY FIXED IT!!!

1. Plug in your DS and wait for it to fully load....
2 THEN turn on your robot and wait for it to get comms

Also make sure that your gateway isn't tucked inside your robot somewhere that caused half of our problems.

Also at GSR they ended up sprinkling water in the driver's box to help cut down on static...

So be careful of placement of your gateway and such and you should be fine..

Oh and one more thing:
With the new DS update given at the competition it actually says "no comm" not "no comms"... Just saying

[MrForbes]

Originally Posted by GBIT

Also make sure that your gateway isn't tucked inside your robot somewhere that caused half of our problems.

I was wondering if this would be a problem. Also does the orientation of the gateway seem to make any difference? we had some problems during testing before ship, and ended up putting the thing on a top surface of the robot.

With the new DS update given at the competition

Is that "new" update the one that has been on the FIRST site since Feb 10th or so?

http://usfirst.org/community/frc/content.aspx?id=10934

we found it the day before crating up the robot, it kind of messed up our plans for autnomous control.

[Dmentor]

Originally Posted by GBIT

1. Plug in your DS and wait for it to fully load....
2 THEN turn on your robot and wait for it to get comms

In pit testing via tether on Thursday morning, we would often see the described problem if we started the cRIO before the DS. We got in the habit of always starting up the DS first when testing in the pits and didn't have any more problems until we started practicing on the field... In several of our matches the robot worked without problems, in the others however we would encounter odd failures associated with the digital IO controls that are relayed through the DS. We would bring the robot back to the pit and go through our checklist only to discover no problems. After a while of head-scratching, we connected the data points by guessing that there might be a startup order dependency that the driver team wasn't aware of. Once we determined this we were able to recreate the odd behavior (DS digitial IO failures) in the pit via tether. Our driver team implemented the startup procedure above using hand signals to ensure that we would always be able to run reliably. We were pretty scared until we discovered this though since debugging unpredictable behavior is tricky.

On a related note (perhaps obvious to most folks) but since the practice sessions have two portions, we needed to reset the cRIO between the portions in order to ensure proper software initialization of states. Otherwise we ended up with the system carrying over states from the first portion into the second.

FYI. We are using the Labview basic framework so I'm not sure how much different the Labview advanced framework or C++ implementations would be.

[GGCO]

Might be that annoying VxWorks bug showing it's ugly head again...

That happened to a few teams at Traverse City. Make sure you have all of the latest updates for your hardware and software.

[billbo911]

Originally Posted by squirrel

Is that "new" update the one that has been on the FIRST site since Feb 10th or so?

http://usfirst.org/community/frc/content.aspx?id=10934

we found it the day before crating up the robot, it kind of messed up our plans for autnomous control.

Jim,
Can you please expand on, or explain, this comment. I'm not sure I understand how updating the DS impacts Autonomous. Inquiring minds want to know.

[Daniel_LaFleur]

Originally Posted by sabruce01

Has anyone experienced this during competition? I know in OKC there were a few that had problems. Our team lost communications 5 of the 8 qualification rounds. Our bot would simply quit in the playing field. I spoke with nearly everyone there and got nowhere. Everything they told us to check had already been replaced in the pit. Auto would be fine, then about 1/2 way through tele, we would loose communication. During our last elimination round we didn't even have an auto which caused us to be eliminated. There is no way we were loosing power to the receiver. We troubleshot that to death and could not get it to fail. But that always seemed to be the default answer I got when asking around.

Any suggestions??? Anybody experience the same?

We did not, but a lot of teams at GSR did. Here's what we did, that may have contributed to our seeming immunity to the comm issues:

1> Mounted the Wi-Fi on the robot away from all high EM fields (motors) and Faraday cages (steel). Orientation does not seem to be an issue but location is important.
2> Kept good care of our ethernet connectors (both on the DS and on the robot). We inspected them for bad spring pins, made sure we inserted the connector straight, and made sure no debris got into them.
3> Grounded the DS chassis as requested by FIRST.
4> always had our DS fully booted before booting the robot.
5> all electronics are mounted on non-conductive surfaces.

After some observations, I believe that #5 above is the culprit for most teams. Our robot (with it's propellers and wheels) generates a tremendus amount of static when on the regolith. We saw at least 2 machines have a 'No Comm' failure after an impact with our robot. My recomendation to all teams is to ensure that the robot chassis is isolated from all electronics.

[BradMello]

Originally Posted by GBIT

At GSR they re-ran about 12 matches and were down with comms problems for most of the morning thursday.... Our robot lost about 3 times cause of comms issues....

HERE IS HOW THEY FIXED IT!!!

1. Plug in your DS and wait for it to fully load....
2 THEN turn on your robot and wait for it to get comms

Also make sure that your gateway isn't tucked inside your robot somewhere that caused half of our problems.

Also at GSR they ended up sprinkling water in the driver's box to help cut down on static...

Yeah, at GSR a good amount of qualifying matches ended up being replayed becuase of this problem. They came to the conclusion that it was static electricity and put conductive tape on the metal grate which the moon rocks rolled into in the corners of the field, and it seemed to work. They also sprayed water on the carpet in the corners of the field. After they did that I can't recall one match where anyone lost comms.

Nothing like being behind the glass and seeing Dean Kamen on the field spraying water on the carpet between matches

[David Brinza]

"No Comms" is not a DS problem - it's a failure of the link between the robot and the field wireless access point. Unless ALL of the robots lose their links in a match, the problem lies within the robot.

Here are some likely causes of the problem: unplugged or intermittent power/ethernet connections, burying the adapter in the robot, problem with the wireless adapter +12V supply from the PD module and mounting the wireless adapter such that the security button gets pushed as the robot is bumped.]

If you momentary lose the wireless adapter, it can take up to 45 sec for the robot to get synch'd with the field - very painful!

[pitzoid]

The ultimate conclusion is still being investigated, but I'll tell you what I know:

Robots spin wheels on FRP, plastic on plastic with a metal frame to attract the charge. robots build charge, like helicopter, get near field border, being its metal, grounded, you get EMP. DS seem susceptable to EMP.

So for all you people who saw a robot hit a field end and DSes reset and you thought it was because the physical impact knocked a connection, doesn't seem to be the case, it was the EMP discharge. This would happen anytime a robot had been running around in the middle of the field for a few minutes and then got near a field border.

All the FMS equipment is sheilded for this, I check my engineering logs on fields like BAE, no issues I could find. I run QOS on all the switches, sat and watched the field end switches for a while at BAE while matches were running, no issues I could see.

A suggestion to help. If you have your DS mounted in a control case. run a ground wire from the DS mode FIRST already mandated to a grounding connection that contacts the drivers table when you set your drivers station on the table, this will help to establish a faraday cage around your DS internal circuitry. If your DS sits directly on the table, it should ground.

We're still looking into whether the EMP being caught by the DS to SCCE ethernet cord and traveling the cord to the DS is resetting it. It looks like it doesn't affect the SCCE switches as they are industrial switches sheilded for this and I can't find issues in their logs.

The link up issues seems to be this (still being investigated):

When the WGA bridge starts up in security mode, if it doesn't see its SSID within a certain amount of time, it times out. So the general rule with this should be, DO NOT turn on your robot till you see your team number on a team station. Reason - this means the scorekeeper already activated the network configuration for your match, i.e. FMS is or has written your SSID to the Access Point, and by the time your WGA bridge boots up, your SSID will be present and it will be able to connect without timing out. This is why it seems once things got rolling, things went more smooth, but when trying to restart in the morning or after lunch where things would get out of "sync" there were issues.

These are all my theories currently
YMMV

Will keep investigating problems.

[dragonrulr288]

AT Traverse City, the RObodawgs and Robodawgs O.T.L. Expierienced lots of this!

[GBIT]

Originally Posted by David Brinza

"No Comms" is not a DS problem - it's a failure of the link between the robot and the field wireless access point. Unless ALL of the robots lose their links in a match, the problem lies within the robot.

Here are some likely causes of the problem: unplugged or intermittent power/ethernet connections, burying the adapter in the robot, problem with the wireless adapter +/-12V supply from the PD module and mounting the wireless adapter such that the security button gets pushed as the robot is bumped.]

If you momentary lose the wireless adapter, it can take up to 45 sec for the robot to get synch'd with the field - very painful!

There were instances at GSR i know cause it was our robot where ours and only ours died and they ended up replaying the match due to a field error not our robot....

[MrForbes]

Originally Posted by billbo911

Jim,
Can you please expand on, or explain, this comment. I'm not sure I understand how updating the DS impacts Autonomous. Inquiring minds want to know.

The older version of the DS software would "see" DS digital inputs in autonomous mode, the newer version does not. We had a set of switches connected to the DS to control autnomous, but now those switches need to be moved to the robot, and the program changed. There was no time to do that before ship.

We also did not withhold our control system to work on programming...based on our experience of making some simple changes in one place, and several other things not working as a result, all during build season. We put a mostly working robot in the crate, hopefully we'll make all our practice matches, and fix the programming problems one at a time as time allows at the competitions.