|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||||
|
|||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
Quote:
![]() For those of you complaining about the time it takes for the 2009 FRC control system to "link up with the field", my observation is that it's really a very quick process, on the order of five or ten seconds. What takes time is the cRIO booting up and starting to run the user code. The WGA is fully active and in the loop long before the cRIO even starts looking for the DS. I doubt that the FMS can tell that a team has managed to leave the network cable disconnected between the cRIO and the WGA until 30-45 seconds after the robot has been powered on. It isn't the FMS you need to be focusing your attention on; it's the cRIO. (Maybe the boot time can be reduced in the future by implementing something like a "hibernate" mode, or even a precomputed RAM image deployed as part of the program load process.) |
|
#2
|
||||
|
||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
I'm not talking about the 20 minutes of power outage - I can't believe anyone would think I'd blame that on anything other than the burned up breaker that caused it. I'm talking about the 45+ minutes afterwards that the field could not be restarted and wouldn't work, despite the obvious multiple restarts of the whole system by the field crew (who did an excellent job dealing with the situation).
|
|
#3
|
||||
|
||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
This thread was somewhat painful to read. Teams are pointing at FMS/Volunteers, Volunteers are pointing at Teams/FMS, FMS is pointing at teams, etc.
I know some posters have been more forthright and accepted responsibility, but in general people are making much more sweeping generalizations than they should (including my intro). Like most difficult problems, this one is multi-headed and problems exist in each area. Teams: Ultimately the ball is in your court to make sure your robot is ready. I know about and I feel the pain of having a knew control system, long labview downloads, and having another series of items to have to worry about each match. And I wish every event had the time and crew that would allow for the event to be streamlined and fair. But the simplest way to make that happen is to take care of stuff on your end. Write a pre-flight checklist. Run through it before each and every match. Find ways that work to make sure your robot can sync with the field quickly and flawlessly. Help out your alliance partners (and preferably each and every team in FIRST) to do so as well. Field Reset/FTA/Volunteers: Your job is not only to help the event run in a timely manor, but to also help the teams get the most out of the event (though that applies both ways, nobody like events that run 4 hours over). I know this is hyperbole, but you could run 80 matches in 3 hours if you allowed 0 minutes for teams to get on the field in between matches. Yet nobody would be happy with that. Running on time is great, but so is having teams running. Try to help teams ensure they're ready to go by the time they're setting their robot on the field. Queuers and reset volunteers can ask the teams who are in queue if their radios, DS, and batteries are plugged in. You can post signs by the entrance to the field to help remind teams of the same thing. FMS/FIRST/Other affiliated Parties: Yes this is a new system. Yes we all expect it to have its kinks. Yes, it can run well when everything goes right and the teams do everything right. But this is the real world. Not everything will go right, and the system needs to be designed to incorporate that. We need ways to help fix and diagnose connection issues and controls issues (both from the field and robot perspective) quickly and efficiently. Whatever of these can be implemented DURING the season (once properly tested), should be. We shouldn't wait until next year. We need to find ways for the robots and field to connect faster/cRio boot faster. We need to find ways for the field to be reset faster so the teams can start booting and connecting their robots sooner. We need to make this whole process more team friendly, and find better ways for teams to fix whatever issues they can BEFORE they get on the field. Pointing fingers isn't going to solve anything, and neither is getting your feelings hurt. Determining solutions and being pro-active is required, but so is determining what isn't working currently. No party should be happy with the current situation, or any situation like it. Every party involved should be working to make the process better, pick up their end of the bargain, and work WITH the other parties instead of against them. |
|
#4
|
||||
|
||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
I do think the efforts of the NASA/VCU field crew should be applauded! It's great that they were able to support so many teams and still run a timely event.
I understand it is difficult, and where to draw the line between team responsibility and teaching a lesson is blurry at best. But all being said, a little leniency for the teams who I think have been incredibly patient adapting to this entire process is in order. I wasn't on the field the entire time in Chesapeake, but I was there on the sidelines the 3 different qualification matches where one of our partners was disabled by the FTA. In two matches, everything was hooked up correctly as far as everyone could tell. The robots could not communicate so they were disabled. After some follow-through by our programming mentor & them not working the next match, it was determined one team had a radio problem. Another was never solved. But red or blue, to allow plug in or not, there are a couple things that did disturb me: - In our other match, the team had not plugged in their radio after being tethered in the pit. It was discovered once the field was set and all other teams linked and ready. The team was called back out on the field, shown the problem, allowed to plug it in, and then the scoring table was told to disable them. It certainly wasn't a time saving measure! Why not let the kids play? Why embarrass them like that? I'm sure they felt bad enough. This was done repeatedly when these problems happened. - Teams have no way to troubleshoot problems, particularly with wireless. They are only allowed to tether in the pits and then they step on the field and are told "it's your robot".... Well their only defense is "it worked in our lab" because it's their sole point of reference. I totally agree with Adam's point of getting some more diagnostic tools in so field staff can say "it's an issue with your XXX" and teams have a chance of fixing it! How can you make a checklist when no one knows what you're looking for, and much of it can't be tested? In general, teams were told to turn on the robot and leave the field immediately (some at the threat of disablement).... no 'gates down'. While I can certainly appreciate the consistency with which the field was run, I don't think it served the interest of teams or time-saving. I personally am willing to give FIRST the chance to work out the bugs of all this new stuff, but I do think those representing FIRST (paid, volunteer, etc) need to show teams the same bits of compassion. I congratulate the events that have found the way to balance all perspectives on the issues! |
|
#5
|
||||
|
||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
Quote:
![]() |
|
#6
|
|||||
|
|||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
Quote:
![]() Place Robot Hitch Trailer Securely Battery Strap buckled Plug in Battery Check battery cables—bumper perimeter Align Turret Load Balls Field says 1726 over our Driver Station Power ON Check Router for power/comm. Electronics Cover secure Comments? |
|
#7
|
||||
|
||||
|
Re: Discrepancy at Chesapeake, Israel, Waterloo?
Quote:
DS is 10 to 20 seconds depending on how fast it identifies its USB devices cRio can boot in as fast as 10 seconds (what I've seen in the shop, mine don't have a bunch of user code in them though) I've seen WGAs link with the field AP in <2 seconds, and then I've seen them take as long as 20 seconds in the field, and I've seen some that don't link at all It all comes back to how much RF interferrence the WGA is getting from the robot. I.e. where the radio is placed in relation to metal bulkheads, motor controllers, relays and a multitude of other RF noisey things on the bots. this has been a common theme in many of my posts. I saw someone used my "it worked in our lab" comment, and the fact is, maybe it did work in your lab, but was marginal "in your lab", get out to the competition field with other RF competing devices and maybe it won't work..... That was the point. If you have one point of referrence and you know someone else that literally had hundreds, I'd go with that advice. RF is voodoo, many things can affect it, treat with as much respect as you can..... Last edited by pitzoid : 25-03-2009 at 20:24. |
|
#8
|
||||
|
||||
|
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. |
|
#9
|
||||
|
||||
|
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 ![]() |
|
#10
|
||||
|
||||
|
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. |
|
#11
|
||||
|
||||
|
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 ![]() |
|
#12
|
||||
|
||||
|
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:
|
|
#13
|
|||
|
|||
|
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. |
|
#14
|
|||
|
|||
|
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 |