I posted this on thisthread, but I thought that is deserves its own post.
After spending 7 hours working on the robot today, we found a solution to our problems.
First some background:
We heard that the system watchdog issue was cause by communications lag between the driver station and the robot. I know that wireless lag is often caused by interference and other devices using the same channel. We are working in an area that has many other Wi-Fi access points. The Linksys router we got in our kit is not dual band and only operates on the 2.4Ghz frequency. The instructions from FIRST said to set the router channel to Auto. This is bad practice in my opinion. I think it’s better to know your Wi-Fi environment and set a fixed channel accordingly.
How we fixed it:
We used a program called InSSIDer to scan for access points in our area. It gives a nice graph that shows which access points overlap each other. Channels 1, 6, and 11 are the best because they do not overlap. Channel 1 had the least access points so we set our router to use channel 1. After changing the channel we no longer experienced the watchdog issue.
The short version:
Try changing your router wireless router channel to 1, 6 or 11.
Nate (the great) from Team 3357
We also disabled the watchdog and made sure to kill it in the autonomous() and operatorControl() functions. Hope that helps!
I’m pretty sure you are supposed to ONLY operate on 5GHz. I don’t think you’ll be able to connect if you use 2.4 GHz at the competition. Does that mean you have your Wireless Game Bridge set up for 2.4GHz?
The watchdog serves an important purpose. You should have spent 7 hours restructuring your code so that it does not fire instead of turning it off.
The timeout is much longer than the normal interval between messages, around 100ms I think. It is OK to turn it off while debugging since numerous print statements, stepping through code/VIs etc will sometimes trigger it. But if it is firing in your final code, it is a BIG problem. It means your software is spending large amounts of time doing something between the calls to pet the watchdog. This is normally an indication that something else is seriously wrong, the kinds of things that can make servos act funny, cameras not respond, communications fail etc if not fixed.
I think. It is OK to turn it off while debugging since numerous print statements, stepping through code/VIs etc will sometimes trigger it.
This issue(I believe) was about the system watchdog, which is a part of the firmware and cannot be easily disabled. That said, while disabling the “user” watchdog is sometimes needed for debugging, one needs to keep in mind that disabling this means turning off the primary safety system on the robot. Especcially when you can specifically see that the Watchdog is dying, you should be very cautious when running the robot without it enabled.
Rookie teams were given a WRT160N router which only supports 2.4ghz. They were instructed to set the bridge to 2.4ghz. I assume that at competition they will configure it to 5ghz, probably at the same time as they do the WPA key.
So they’ll be running on an untested system for the entire development period? Doesn’t this sound like a bad idea to anyone else? How are teams going to know they don’t have a defective gamebridge until then? That’s just ridiculous.