cRio Communication Errors

[icecube45]

Hello,
starting about three days ago, after we finished wiring our robot, we encountered a communication error with our robot.

We can connect just fine, but after about 30 seconds of solid communication, the robot code light will start flashing, communications going in and out, until we eventually loose all communications, but are still connected to the dlink.

After about 15 minutes of waiting, the communications will come back, and the cycle will begin again.

What we have tried:
Reflashing the dlink
reflashing the cRio
swapping the crio
swapping the dlink
switched to barebones code
tried on another robot
tried other, non dlink routers
switched the dlink to a less populated wifi channel
setting up the dlink as a bridge to a router connected via lan to the DS.
swapped the power supply to the dlink
plugged the dlink into a wall socket
tried another driver station (went to a classmate, along with another laptop)
tried 5 ghz, get a watchdog error, which is caused by communication (acts the same exact way, and we killed the watchdog in code)




Essentially, we have no freaking idea what has gone wrong,


an interesting thing to note though, is that When tethered, we have no communication errors at all

We can't do everything tethered, and would love for any help you guys have.


-icecube45
team 114

[Greg McKaskle]

Can you post the log file, or a picture of the log file? The driver station charts tab has a button that launches the viewer. Then choose the log file that shows the issue. It may also be useful to watch the drink closely as this happens. Does the blue LED on the front change orange? Does it go out, etc?

You may also want to have another computer join the drink AP and see if it can still ping the cRIO, the AP, etc. Do you have lots of wifi APs nearby that may be causing issues?

Greg McKaskle

[icecube45]

Originally Posted by Greg McKaskle

Can you post the log file, or a picture of the log file? The driver station charts tab has a button that launches the viewer. Then choose the log file that shows the issue. It may also be useful to watch the drink closely as this happens. Does the blue LED on the front change orange? Does it go out, etc?

You may also want to have another computer join the drink AP and see if it can still ping the cRIO, the AP, etc. Do you have lots of wifi APs nearby that may be causing issues?

Greg McKaskle

My team is currently PID testing, so I can't post the log file atm, but from viewing them in the past, all you see are dropped packets when the communication goes down.
No crio cpu spikes, or anything like that.

The dlink stays constant, and we never lose actual wifi connectivity.

We have had a computer pinging it, and when we lose robot code, it will stop receiving a ping for about 1 or 2 pings, then it will receive one, lose one, as the communications go in and out


as for other wifi hotspots, we did a packet sniff, and changed our ap to the channel that was less populated (all the other wifi aps were on channel 11, we went to 1)

[Greg McKaskle]

I"m curious whether there was excessive loss or lag before the drop. Also, the DS pings anytime anything happens to the comms. It pings and logs any changes to the four possible devices. This helps determine if the radio is still there and reachable and only the cRIO is down, etc.

If the radio is really there and only the comms or code lights go down, that indicates that the code is bringing down the cRIO. What language? Does this correspond to any particular robot feature like vision processing, etc?

Greg McKaskle

[icecube45]

Originally Posted by Greg McKaskle

I"m curious whether there was excessive loss or lag before the drop. Also, the DS pings anytime anything happens to the comms. It pings and logs any changes to the four possible devices. This helps determine if the radio is still there and reachable and only the cRIO is down, etc.

If the radio is really there and only the comms or code lights go down, that indicates that the code is bringing down the cRIO. What language? Does this correspond to any particular robot feature like vision processing, etc?

Greg McKaskle

The funny thing is, this was working just fine until we did some cable management on our robot, now it doesn't work on any robot.
We are using java this year, but we have gone back to barebones code, confirmed working, and have the same problem.
We also switched to some very basic c++, same problem.

It doesn't correlate to anything, and is just plain weird