|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
Pitzoid, if a log of each match with of all of this information is available the field staff doesn't know how to get at it, because every time a robot stops running they usually have no clue idea why. If you have put in place the tools to monitor the DS, Bridge and the cRio individually that capability is not being utilized.
I have never herd someone on the field say "The log indicates the bridge stopped responding 1min 35sec into the match, but the driver station was still responding." or "The robot stopped communicating with the field at 1min 36 seconds the bridge and the DS were still responsive, at that time the console log shows the cRio sent out a message that FrcUserProgram.out had a stack dump." All I've herd is the "Your robot disconnected, but the lights on the bridge are still blinking" or "The light for your robots disable light was flashing every now and then I don't know why" Later investigation led to the user watchdog being to aggressively set and a image processing task was taking a little long to complete and the robot ran despite the disable light flashing. Last edited by Kingofl337 : 25-03-2009 at 20:39. |
|
#2
|
||||
|
||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
Quote:
![]() We try to make things like the robot match logs (which by the way was never easily available from IFI) as intuitive as possible, its in the training, why they don't get it I don't know the isolated reason. BUT, in Match Review, in FMS, when a match is completed (i.e. commit score has been pressed for that match) the robots listed for that Match will turn into either a blue or a red button (depending on alliance, if the match is "not completed", the bots are just listed on a white background), press it (in Match Review) and it pops up the robot telemetry log for the match. The log only records while the match timer is running. Bots can drop for a number of reasons during a match, hard to say any 5 things are the possible reason. Could have to do with bad code (seen lots of stops in code), low batteries, loose connections, radio placement, the Static discharge issues, etc.... The log does record the FMS connections status alongside the robot telemetry, I've yet to find data that shows FMS connections dropping when robots did (i.e. how we isolated some of the DS issues so quickly), all field equipment runs QOS logs. Telemetry now is still somewhat limited to just communication stuff. I had a talk with some NI folk the other day about bringing out data on every resource a team is using on the cRios and then figuring out a way to distribute this to teams post events. We have big plans for FMS, time and resources will tell what comes to realization. I think this thread is flying off the track now, if you guys want to start an FMS technical thread we can, we talked about one in the official FIRST forum, but I don't know if anyone would pay attention to it there ![]() |
|
#3
|
||||
|
||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
Well, how about the ability to dump that data to a thumb drive via a simple click. If a robot stops working a team can request field data review the data back at the pits?
edit: I think all teams want is to be able trouble shoot issues they encounter on the field. If a team spends the money to goto Atlanta and their robot stops and the answer is "I don't really know" that will be unfortunate. Also, with the IFI system all that was needed was packet loss and battery voltage. Plus, they sent a rep to every event that knew the system inside and out. Last edited by Kingofl337 : 25-03-2009 at 22:01. |
|
#4
|
||||
|
||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
Quote:
Maybe next year we can have a way to do this, the hurdle with FIRST is always resources. And to be honest, with the economy going the way it is, who knows what will happen next year? We're all facing economic challenges. But, remember why its important to keep the matches running on schedule, regional committees bring in officials to do speeches and such (which many pay for the event), and certain venues will have monetary penalties if the event runs late, so there are many many tradeoffs.... I'm all for providing teams more resources, just have to figure a way to get them paid for. Everyone write Obama and tell him FIRST needs stimulus ![]() |
|
#5
|
||||
|
||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
Quote:
Quote:
Quote:
As for enable/disable, until the scores from the previous match are committed, the next matches driver stations are enabled. When the team numbers change to the current match, the DS is disabled. There were a few instances where some robots on the field had already booted and their motors jumped for a split second when the field switched matches. Quote:
|
|
#6
|
|||
|
|||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
A couple notes on the data I posted:
1) It is data from the qualification matches only. 2) It was not intended to prove that there were problems at any regional. I noticed this discrepancy and merely posted the data to stimulate some discussion. I have a question though, after reading through this thread. What can a team do when they have a pre-match checklist, go through and make sure everything is plugged in and it all checks out, and then get on the field and can't establish communication? I know this was the case for our team in our last qualification match at station Blue 2. The "solution" was that our robot was disabled before the match and the match was played. In fact, the field team at Chesapeake seemed to be assuming that communication problems were robot-side. Our team couldn't do anything to prevent and/or fix the problem and the people running the field can't be expected to troubleshoot every robot that can't establish communication. What can we do in this kind of "no-fault" situation that left all of the students on our team feeling dejected and helpless? Also, if anyone has comprehensive scouting data for the Chesapeake event, I would like to take a look at it. I would need the points scored by individual robots (not teams, would like to eliminate HP points) correlated to a match number. From there, I could look for correlation between non-functioning robots and the station they were at. |
|
#7
|
|||
|
|||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
Quote:
I am very sympathetic to your plight (kids on my teams have failed to start in a finals match three times in the last two years), but I don't know what else the field crew can do when all the diagnostics are reporting "Good" but the robot doesn't move. I DO know that the FTAs in Seattle sometimes spent five minutes trying to get a single robot working before some matches, and were always disappointed when a 'bot DNS'ed. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Waterloo 2008, | bilal1219 | Regional Competitions | 77 | 24-03-2008 09:07 |
| FF Waterloo | Steve Howland | Fantasy FIRST | 80 | 26-03-2006 16:23 |
| Waterloo Regional | Robohawk-master | General Forum | 4 | 12-04-2004 16:55 |
| Competition Documents File Size Discrepancy | Greg Ross | General Forum | 4 | 09-01-2004 23:17 |
| Clarification for FIRST manual/blueprint discrepancy | Petey | Rules/Strategy | 1 | 13-01-2003 19:20 |