You are correct - connectivity drops that short are not indicative of a robot power issue. Here are the things I would look for if I was FTAAing and you came to me with this.
- Error logs stored on the DS (there's a tab in the log viewer to show these). It's possible that some of your code is taking too long to execute and tripping a watchdog, disabling you briefly. This should be logged for you to go back and look at. This is more likely to explain the second, shorter disconnect.
- It's hard to tell from the video where/how your bridge is mounted. The antennas run the long ways down the bridge, and that should not be parallel to metal and the bridge shouldn't be near any forms of RF interference (power wires, motors, etc.). This could lots of dropped packets depending on your robot location/proximity to the field AP/current wifi situation. The DS logs should show packet loss, and if this is the problem, you'll probably see it throughout the match, just maybe not as bad.
- How's the ethernet port on your DS laptop? The ports tend to not be very resilient to the constant plugging/unplugging of field connections, especially if it's an older laptop. Ethernet pigtails are a good investment. If something is stuck in the port, or if it's worn out, it's possible you could momentarily lose connection.
- What other software is running on the DS? Is there a firewall? If so, that's most likely the cause - they like to block DS traffic and cause disconnects. My recommendation is to totally disable it (that way you know it's not interfering with anything). If you don't want to do that, make sure that the Driver Station program and the NI mDNS Responder are whitelisted.
- Is your DS laptop used for anything else? I've seen instances where other programs that require an internet connection (Dropbox, the Autodesk updater thing, other update services) interfere with DS communication in just the way you described - momentary losses while the ping for updates. Killing their processes in task manager is the quick fix, uninstalling the thorough fix. If you can, have a laptop totally dedicated to being a DS, with as few other things running as possible, so there are minimal causes for niggling issues like these.
That's about all I can suggest without seeing more info. Post the logs when you get a change, and I'll be happy to take a look.
Quote:
Originally Posted by tr6scott
I have not done much with the driver station logs, as we typically try to log what is important to us on the bot itself. Can you point me to a doc that describes driver station log files, and how to read the data?
|
Here's an overview for the log viewer:
http://wpilib.screenstepslive.com/s/...og-file-viewer
It has some examples of logs indicating common failures, which would be good to compare yours too.
Quote:
Originally Posted by tr6scott
A couple other questions for my general knowledge, what determines if who is at fault on a FRC field, when a glitch occurs?
What data determines this, and do we have access to this?
|
This is a decision made by the FTA. Sometimes it's obvious, sometimes it's more of a grey area. Replays are typically granted if the most likely cause for a connectivity issues was field-related (this is a judgment call; again, some are easier than others). There are a lot of factors that to into making the call, and it's very dependent on the specific situation. Since I'm not an FTA, I'll let those who are fill in the details.
The main data points we use on the field are:
- Watching the Field Monitor and area lights for indications of robot issues. Read the section entitled "What Information Does FMS Log" in the
White Paper. It's a little dated now, but the list of items logged is basically the same. The Field Monitor looks like a table, with one row for each of the 6 robots and has the following columns: ethernet links (is something plugged into the player station), DS connected (is the DS communicating with FMS), radio connected, robotRIO connected, battery, bandwidth usage, and packet trip time. You've probably seen this up on a monitor at the scoring table. If you ask one of the field staff to take a look with something specific to check, they'll usually show you what's logged.
- Status lights on your robot, both radio and roboRIO. Make them visible from across the field, it's unbelievably helpful. If we can't see the status lights, it's much harder to diagnose issues, which means you'll be less likely to be granted a replay.
- DS logs. Data there is logged more frequently than on FMS, so often those are the most helpful. Check for logged errors, battery drops, packet loss, things I mentioned above.
- Looking at your physical robot. Is everything plugged in properly? Are any wires loose? Are the PDP fuses in all the way? Are you sure they are?