Watchdog and Communication Issue

[Willn147]

Hello, I am the head programmer for team 168. We have been having problems with communication. Every so offten we lose connection to the robot wirelessly. We built a test robot and are experencing the same problem. I have tried both my custom LabView code and the basic Arcade drive code that FIRST provides. We are using our own laptop this year. Any help would be apriciated. Thanks,
William Nichols

[dellagd]

Are you using a 2CAN?

[Alan Anderson]

Run a WiFi sniffer program like inSSIDer, looking for other wireless networks that might be interfering with the one your robot is using.

[Willn147]

No, we are not using 2CAN. I downloaded inSSIDer and I don't see anything that would be interfering. There are only two other Networks: hpsetup and the weak school wifi. They are both on different channels then the one that our robot is on.

[Tom Line]

Is this when you have permanently deployed code to the cRio, or are you running the code from a computer?

If the latter, we've often seen this issue. It is related to the latency in your network, and may go away when you permanently deploy.

In addition, check your CPU utilization on the tab in the driver station. It will also show packet loss, and should be a good indicator of where the problem might be.

[Willn147]

We are using deployed code, right now I am having trouble even connecting to the robot. I can see the network, but it looses connection. The CPU% is flatlining, but overall it seems a bit high (a little bit over 50%)

[the programmer]

A few things to check:
- How fast can you ping the robot (in CMD ping 10.xx.yy.2)
- If the pings are averaging more than ~4 msec then you're debugging a problem in networking, if not then you're debugging a problem with software

If it's a networking problem I would try to isolate what link is causing the problem (computer ==> DS radio, DS radio ==> robot bridge, robot bridge ==> cRio) this should get you started on diagnosing and fixing the problem.

If it's a problem with software, I would reimage the cRio making sure you have the current firmware and check to make sure the DIP switch settings are right.

[Alan Anderson]

Originally Posted by Willn147

We are using deployed code, right now I am having trouble even connecting to the robot. I can see the network, but it looses connection. The CPU% is flatlining, but overall it seems a bit high (a little bit over 50%)

50% is not high. In my experience, the default LabVIEW code runs about 60%.

Let's try some basic troubleshooting. Where is the D-Link mounted? Is it next to any motors? Is it adjacent to metal? Are any speed controllers or power converters nearby? How's your wiring? Please describe specifically where the D-Link gets its power.

[Willn147]

I pinged 10.1.68.2. All packets were received but im getting an average time of 652ms. The D-Link is wired to the power converter, which is wired to the PD. I checked the voltage coming off the Power converter and its ~5v. Its mounted on plexiglass near metal, but I pulled the D-link off the robot and it didnt change the problem. It sounds like the problem is the 652ms.

[nighterfighter]

We had a VERY similar problem at our school.

Our router was set to the 2.4Ghz setting, and usually it had no problems.

However, we are located next to a gym, and one day we were getting ping times ranging from 2ms to 800ms.

It turns out there was a basketball game going on in the gym, and their equipment was interfering with our router.

We switched to 5Ghz and didn't have a problem.

[Jon Stratis]

When you lose connection, how long does it stay out?

When you lose connection, what are the status lights doing?

Is there anything common you're doing with the robot (like accelerating to full speed from stop) most of the times you lose connection?

Where on the PD board is the converter hooked up to?


Answers to all of these questions can help us to get a better idea of where the problem might be.

[Willn147]

The main thing I am worried about is the Boca Competition next week. Is this something that will go away once we get to competition, when the D-link has it settings changed and/or there is less interference? It would be nice to test the test robot now, but it isn't essential; we can test with a cable. I’m looking into whether or not our computer has 5.00ghz capabilities.

[nighterfighter]

Originally Posted by Willn147

The main thing I am worried about is the Boca Competition next week. Is this something that will go away once we get to competition, when the D-link has it settings changed and/or there is less interference? It would be nice to test the test robot now, but it isn't essential; we can test with a cable. I’m looking into whether or not our computer has 5.00ghz capabilities.

Most newer computers have 5Ghz capability.

Another thing you can try though, is move locations. If you don't still get the lag and dropped comms, then there might be interference in your location.

[Willn147]

The connection is intermittent at best, it fully loses connection about every 30 seconds, but both the robot code and communications LED on our laptop flickers every ~.5seconds. They don’t turn off and on in unison; it seems random as far as I can tell. This is not always the case: sometimes the connection can be perfect for a while (max 2 minutes), but this is rare. I have not found any correlation between location and connection. The robot jerks from full speed to stop at the same time the communications LED turns off. There isn’t any noticeable lag in the communication, it just isn’t sending any directions when the communication breaks off. The power converter is connected to 30amp max section of the PD, and we are using a 20amp breaker. We tried connecting the D-Link to a wall socket and this didn’t change the problem, I don’t think it’s a power issue.

[Jon Stratis]

Originally Posted by Willn147

The power converter is connected to 30amp max section of the PD, and we are using a 20amp breaker.

This could be the issue. Connect it to the regulated 12V output on the end of the board (next to the 24V output for the cRio), instead of through a breaker.

The regulated output will continue giving 12V to the power converter until your battery hits about 4.5V. The breakers, on the other hand, simply pass through the apparent battery voltage. When you're driving your CIMs and other motors, you'll see this battery voltage will drop below 10V frequently due to the load, and when it drops low that power converter can't work properly.

I saw this exact same issue with a team up in Duluth. They pushed their robot forward full power, and comms dropped out for 30 seconds or so. We could tell from the FMS that it was the radio, and when I went to their pit that was the first thing we looked at. After fixing it, they didn't have any comm issues for the rest of the competition.