Quote:
Originally Posted by rspurlin
Start by noticing and writing down the status info provided to you on the classmate. Are you still showing comms? What is your battery voltage? Try to get the attention of the FTA to take a look at your drivers station and your robot. If you're on a field where I am scorekeeping, I've probably already radioed him to head your way if I see anything wrong.
The points of failure that are likely to affect only one robot (other than your classmate and the robot itself) are the ethernet wire and the port it is plugged into on the station cabinet underneath the center driver station. Past that point, network/radio traffic problems should affect either three or six robots.
At an off season event we ran last year, I had a team tell me there was a problem with the red 3 station after they lost robot controls. They cited that the team two matches previous had also lost controls so there was an obvious field fault. What they didn't know that I did is that the team in the previous match had their battery become disconnected. It's easy to make assumptions that don't turn out to be correct.
In an attempt to understand what might have happened, I looked at the match results from VCU. Team 435 played 3 of its 9 qualification matches in blue 2 and 1 of its 5 elimination matches in blue 2. Your post above indicates that 435 lost in quarterfinals, but VCU match results list 435 as being on the red alliance. Of the 4 matches 435 played in blue 2, did any of them work correctly? What am I missing?
|
Quote:
Originally Posted by Zach Purser
Oops, I meant to say our partners had issues in the semi-finals when we were on the blue side, my mistake.
It was match 49 where we had the issue ourselves, and aside from that one round we didn't have any other issues. After that round we had another team approach us and explain that they had the same problem in that DS shortly before us and suggested that other teams had also had issues in that DS. Yeah, I know, two datapoints and some anecdotes is not overwhelming evidence, but it just made us aware. Then when our partners had a similar problem in that DS in the semi-finals it really got our attention.
Now that I'm looking at the match results page I see that for semi 1-1 it lists us in blue 2, I was thinking 134 was in blue 2 both semi rounds. Maybe it was just Murphy messing with us if our partners were dead after auto from two different DSs.
Thanks for all your feedback. It will help our drive team to be better prepared in case something happens again.
|
I remember watching those matches at VCU (339, one of your alliance partners, was my high school team so I was watching them closely). During the first semifinal, 134 never moved outside of autonomous. Their DS light remained solid, however, indicating that communications were fine. I then heard one of 339's drivers say that 134, "never left autonomous mode." I'm not sure if by this she meant that the DS still showed "autonomous enabled," or just that the robot wouldn't move in teleop.
339, the alliance captain, tried to replace 134 with an alternate, but gave up after finding that the first 5 teams on the list had already packed up and left. As a side note, something needs to be done about this: at least the first and second teams in the bull pen should have their robot ready for play during elims. Otherwise the resource is useless.
During the second semifinal, an FTA stood directly behind 134 to help diagnose the problem if it occurred again. Despite what match results say, I can confirm that 134 was, in fact, still in the center DS for this match. And sure enough, they didn't move outside of autonomous. The FTA seemed to be looking through their DS diagnostic pages during the match. Unfortunately, he was distracted when, with about 25 seconds remaining, 339 lost communications (DS light was blinking). At the time, this made me even more certain of a field fault, but in hindsight, I can't imagine that one robot sticking in autonomous mode and another robot losing comms 1.5 minutes in are at all related.
After much discussion with the FTA, 339 told me that they weren't given a lot of answers, other than being told as usual that nothing was wrong with the field, and it was probably an error in 134's code. Out of curiosity, what type of code must one write to force a robot to stick in autonomous mode (DS says "autonomous enabled" during teleop)? I can't imagine how one could achieve this in the user program on purpose, much less by accident. Perhaps it's easier than I think.
I can't really come to any conclusions as to what caused the failures. On one hand, I can't imagine what code 134 could have written to cause the robot to intermittently stay in autonomous mode. On the other hand, I can't imagine a field failure that would cause one robot to stay in autonomous mode while everything else works fine. Maybe they were performing some task in autonomous that hogged the CPU, causing it to miss the notification that teleop had started. But wouldn't the DS still get this message and switch to teleop?
I do believe FIRST should allow teams to examine the FMS and DS code. Who wrote these programs, anyway? Was it WPI? I know that this year I found (an reported) several bugs in WPILib - and that's after teams have had a year of access to the source code. I'm not criticizing anyone, but merely acknowledging that no software is perfect, and the more eyes we have looking at it, the better it will become.
I certainly hope we can trust teams to be graciously professional enough not to exploit FMS flaws to give themselves an unfair advantage; a simple "no modification of DS software or interference with FMS operation is allowed" rule should take care of that. Furthermore, even if a team so completely against the spirit of FIRST so as to try such an exploit existed, I don't know how they could sabotage anything without being blatantly obvious. Disable opponent's robots? That would be fairly obvious. Control the robot during autonomous? Alliances can't touch their controls until teleop starts. Remotely alter the electronic score? The refs would eventually notice that.
Finally, if it is already possible (as the FTA says) for a team to force their robot into a mode other than the one the FMS is sending simply by altering the user program, it seems to me that exploits are already possible.