Here are some stats on field turnaround.
Each event centers around the match times they set for themselves. Some events target 7 min per match while others scheduled 8 min per match, so a high number is not necessarily bad.
Queuers, drive teams, field reset, refs, scorers, FTA/FTAA, inspectors, etc. all contribute in working together to get teams the most matches possible.
High penalty counts, ref discussions, team/field issues, team disorganization, initial field crew training - all can slow things down.
Avg match cycle - # teams - # matches - Matches per team - Event - Week
Thanks, Mark, for posting this information. Having two people on the AndyMark staff (Mark Koors and Jerry Budd) who are FTA’s, this information is very good to see.
While this information is very valuable, I also think that other information is needed to be considered, along with match cycle time, to get “bragging rights”. It would be nice to get this information:
How many robots were able to connect to the playing field by the end of the Practice Day
How many robots, on average, ran each match
I believe that a combination of these things gives the field crew bragging rights, not just match cycle time. If one regional had a cycle time of 6:31 and had 4.5 robots run each mach, while another regional had a cycle time of 7:00 and had 5.2 robots run each match, I would give more credit to the second regional crew for getting more robots running for each match, even though they ran a 30 second slower cycle time.
It would be nice if FMS would spit out an “average robots per match” number along with this cycle time number. Is this possible?
I can’t remember having any connection problems on Friday or Saturday at Pittsburgh once we all got the updates correctly on our robots on Thursday. It was a very smooth event.
The WPA kiosk keeps track of who hasn’t setup their robot bridge.
FMS keeps track of who hasn’t successfully connected by the end of practice day.
FMS knows who was bypassed in each match, but not why.
Those kinds of stats aren’t part of the published official record though, so FIRST has them, but I don’t know if they get uploaded to the HQ servers, or are still traveling the world stored in the individual field systems.
More detailed notes are usually hand kept by the FTAA, because of the variety of problems and causes that are usually tracked.
All the fields I worked delayed matches as long as necessary to get all robots working. Long Island didn’t start a match with a robot that failed to connect, unless a robot issue was identified that needed time-consuming repair, dead batteries, etc.
I have those stats for Long Island because I worked it, but not for other events.
The hand records maintained by the FTAA every year are really useful for follow-up with the teams in the pits (and for debunking conspiracy theorists from the stands).
Mike (our FTAA) keeps track of robots that didn’t show up, robots that failed on the field and the reason (sometimes supplied after a pit visit), connection issues, unusually low battery or bad battery conditions, slow packet transit times, and anything else unusual that needs to be followed up with the team in the pits.
At the end of the day on Thursday we make everyone who either had connection problems or who hadn’t connected yet, come to the field for a special connection party. That’s true for each of the events I’ve been to so far this season (NJ, WPI, LI).
There’s always one or two robots that still don’t come…
Hey, don’t forget the inspectors, making sure the radios are configured correctly and helping to prevent the smoke and fire, which would definitely slow things down.
John Vriezen
Team 2530 “Inconceivable”
Mentor, Drive coach, Inspector
In Seattle, “Cascade” seemed to be consistently ahead of schedule relative to “Olympic”, so I’m still trying to wrap my head around the data. The volunteers did a tremendous job considering the huge pit area and the simultaneous queueing announcements on the PA system. Thursday turned out to be an extended long day (til 9pm), with everyone feverishly working to get either field sync’d and/or inspected. Kudos to all the volunteers!
Also, a big shout-out to the Oregon crew… bragging rights for now!
Same comment re: St. Louis in Week 3. With only 28 teams participating (probably because most teams from outside the area would much rather come to St. Louis about a month from now!), we ran 11 seeding matches per team, at a 9 minute pace. Had to hold the field crew back to stay that slow – added some dancing, etc.
Re: Andy’s comment earlier, I agree field crews should brag more when they get 6 robots out there for a match. That sometimes requires support from the pit side as well; inspectors, teams, and experts on site all contribute.
I was the scorekeeper for Olympic, and as stated in some of the other posts, much of the data is never made public, beyond match times and such.
According to my notes, we only bypassed about 6-7 robots in those 84 matches, and none in eliminations. And we only ever bypassed when they had no code, low battery, etc, things that are not quick fixes.
As for cycles, we did get down to a 4:39 at one point Friday. I think it really helped that we stayed on Thursday and had everyone connect.
Teams: Remember to have 2.27.2011 as your DS (yes, even if the other one is “OK”, just get the newer one anyways.) and make sure you have v28 of the cRio!
But I agree, it would be nice to know some of the additional data, but I doubt we will see that before long.
I was watching some competitions on webcast where the match turnaround was fantastic - some of the best field crew work I’ve ever seen, and the turnaround average in your list looks pretty poor for that event. I’ve seen events with great crews where one robot comes out and won’t connect and throws a 20 minute outlier into the mix.
I was wondering if there would be a good way to separate out the outlier matches from the bulk of the matches that went as planned.
Here’s a spreadsheet of the data if you want to play.
All match times are calculated, so you can filter or just see outliers.
You can check it for errors too while you’re at it. I haven’t gone back over it to verify yet or to make sure it’s scored consistently.
Send any corrections/additions back and I’ll include it in future updates.
I think all rematches are accounted for by leaving them out and using the elapsed time of the original matches, since it isn’t in the official record, but an incorrect calculation could easily have been missed.
There are some obvious outliers that I may or may not have included. It’s hard to remember. Single outliers didn’t have a great impact on the overall time, and some events seemed to skip lunch to play catchup.
The crew that I worked with at Pittsburgh and SBPLI Long Island were both absolutely fantastic! At both Pittsburgh and Long Island like Mark said, we had the general policy not to start a match until all robots connected to the field, or we at least knew why the robot was not connecting (cRIO not getting power, something of that sort). At Long Island before every match you would see some combination of Mark, Bharat Nain (our FTA), Mike Massa (our FTAA) and myself walking the field checking on every robot making sure radios were plugged in and connecting during the start up sequence.
We also monitored robots during the event so if one stops moving we would go and try to see why. This gives students the best experience at the event and also allows us to do “conspiracy theory control”.
A few extra things to point out. There are times where other factors limit turn around time … for example, at Pittsburgh we were running too fast and getting too far ahead, so we had to add in a few dance breaks to not have a huge gap before alliance selection
Teams being punctual and responsible also make a huge difference to overall turnaround times. So I need to thank all the teams for their amazing effort at SBPLI! And obviously, huge thanks to all the field crew that I worked with to make Pittsburgh and Long Island awesome events!
I think New Jersey was striving for an 8 minute match cycle? (don’t quote me on that though) so seeing that we had 7:30 is pretty awesome, ESPECIALLY since we were a week 1 regional. Judging from the data we did pretty well (only 2 other week 1 regionals were faster).
It’s also awesome to see that the numbers are going down the further into competition season we are going.
About the St. Louis Regional:
Last year, if a robot did not connect, you were bypassed and the game started (happened to us)
This year, the field crew would help you out, trying every solution you could think of, even getting a new DS for a team on the first qualifying match on Friday (I know because as a driver on the same alliance, I was right next to the crew).
The crew would even spend time waiting for robots that were in the middle of repairs or had two close (time wise) matches.
Sometimes, these delays were slightly stressful (like when using a battery with questionable charge) or were beneficial (a delay allowed a battery to get to full charge, just in time for the next match)
Despite these delays, we still would average around 10 minutes ahead of schedule (sometimes we were told they were delaying to get closer back to schedule, like before the first final match)
My thoughts: Although occasionally annoying, delays and longer field reset is not necessarily bad, just means that a regional with less people can be less rushed and give a competitive atmosphere to the teams, with breaks for the fans and even drive teams (because you usually need to go to the bathroom at points other than during lunch). Would I want to have had a faster time at St. Louis, no, keep up the good work and I hope next year we can also wait for robots to connect.
Even after telling all the teams in LA what software versions were required there were teams that still had the wrong version on Saturday. I think next year I take screen shots of how to check the version and how to wire the radio and show it to each team as they get their radio configured. I think telling them is just too much information for some of the team members to absorb while their radios are configured.
I went to every team in the LI pits and inspected their software versions personally, then stood there while they updated to the latest.
Always get a few “we have the latest version,” but it’s only the latest version they know of.
Still on Saturday, Ken had a team appear at the field with a new laptop using older Driver Station software.
Kansas City was pretty good Saturday and Friday. Thursday it was looking pretty bleak but we got it together pretty fast the next two days, which I thank everyone who contributed. I guess these could be used for next year to try to beat the times of the regionals and make things more efficient and make the events even better. But look on the bright side gives more chances to have the refs dance!::safety::
I am confused, last year the Israeli regional was very slow because of communication problems you all know, but this year there were not any problems and the matches were running smoothly, so how it can be possible we are the last in a big difference?
How the other regionals are quicker?
