It appears the FMS does not properly measure time during the matches. It seems to add about 5 seconds to each 2-minute match. I noticed this while watching a webcast of the Milwaukee Regional and doing some timing measurements for something unrelated on my computer, and confirmed it while I was at the Midwest Regional this past weekend (to make sure it wasn’t somehow related to the webcast).
I don’t really think this is a big deal or anything; it’s more of an interesting curiosity. However, I wonder how many matches teams have lost due to something that occurred in the last 5 seconds when the match should have been over? I’m pretty sure this has happened to us more than once. It’s a little irritating to think that we may have won some of those matches if FIRST had followed their own rules… (I know, we’ve probably won some in those last 5 seconds too so it probably evens out…)
This is interesting. Does this happen every time or does it happen only occasionally.
The reason I asked is that I have just asked our coders to implement an automatic brake feature that puts the brake on our winch with 3 seconds left - I don’t like depending on our drivers to remember in the heat of battle if it is easily fixed. From what our coders have been able to discover, there is no “what is the match time” function available on the cRio – on the Classmate, yes, but not the cRio. So… no problem. We can watch for the first enable after Auton Mode and start counting seconds. When we get to 117, time to throw the brake with 3 seconds to spare…
It seems to happen every time. I checked a few matches live during Midwest and Milwaukee, and confirmed it at other events by spot-checking a selection of videos from TBA. You can check yourself by going to TBA and selecting a random match video - just take note of the time in the playback bar when you hear the 3 bells to begin operator control and then fast-forward 2 minutes. In every video I’ve checked, I’ve found that exactly 2 minutes later you’ll hear the announcer saying “5 seconds left!” I just checked and it appears (based on more TBA video) that this bug was introduced between the 2008 and 2009 seasons.
The reason I asked is that I have just asked our coders to implement an automatic brake feature that puts the brake on our winch with 3 seconds left - I don’t like depending on our drivers to remember in the heat of battle if it is easily fixed. From what our coders have been able to discover, there is no “what is the match time” function available on the cRio – on the Classmate, yes, but not the cRio. So… no problem. We can watch for the first enable after Auton Mode and start counting seconds. When we get to 117, time to throw the brake with 3 seconds to spare…
…except now do we have to wait until 122?
I wondered if anyone was doing anything like that with timers that would run the length of the match… obviously for anyone trying that this bug is a little more serious. I can’t think of any easy way off the top of my head to know how much time is remaining in the match other than what you’re doing, so yes, I guess you’d have to wait until 1:22… (think of the upside though - maybe this means we can all be 5 pounds overweight!)
Wow… I was first going to ask if you added the time between auto and teleop. But you didn’t, I just confirmed this by watching some of the FLR videos. Very interesting.
I know if you are using labview you can return an elapsed teleoperated time as a variable (which may be more “official”) you can reference in your code. I don’t know if it is the same for C++ and Java but you should look into it.
This is very interesting. I will time some matches during the Boston Regional to confirm this “on the ground”. Watching recorded matches may introduce issues with different frame rates due to re-encoding, but it sounds persistent.
Is this a bug that should get squashed before this year is up? I know the obvious answer is yes, but technically it would be unfair to teams playing in later weeks…
From Dave Flowerday’s post, he timed matches in-person at the Midwest Regional, confirming his observations from the Milwaukee webcast. From the perspective of fairness, if all the matches run the same duration, no advantage is gained or lost* by any teams.
Maybe FIRST will discover a mini-black hole in the FMS that dilates time and create other problems with the field?
*Unless, of course, you don’t trust your drivers and have automatic timing features in your code that effectively ends your match earlier than the rest of the field. (Sorry, Joe!)
First, putting the brake on is not “ending the match early.” The code I want to implement will allow the winch to go UP but not DOWN during the last 3 seconds of a match.
Second, I trust my drivers. BUT if there is a way that I can unload them from having to think about details during a match, I’m going to do it, especially given that we have not had enough quality time with the robot to practice these kind of things.
From years of experience, I can tell you that drivers get overloaded pretty easily. There is a LOT going on out there on the field. On something as critical as this, I think an auto engage is a good idea.
Anyways, this is an interesting issue… never considered that time would be off… Its curious how (supposedly) this bug was introduced in 2009, and not detected until now. As has already been stated, maybe the best route at this point is to let this bug live its life for the remainder of this year, and kill it next year.
This is very interesting. I know that a problem similar to this existed in 2004 as I personally timed matches at the CT regional in Hartford that year.
The 2004 peoblem seems to have been a bit worse as each match was an unperdictable length (some longer and some shorter than 2 minutes, with some off by as many as 12 seconds!)
I would say that if the timing is off in a consistent manner this is less of a problem that is matches have inconsistent length.
I wonder how the FMS calculates time…(not a programmer so that may be a rhetorical question…)
I don’t know if this is unrelated or not, but when you start a practice match on the Classmate, about 5 seconds (just remembering here) is elapsed before it enables the robot for autonomous.
They are probably not related because the DS practice mode was written without knowledge of or access to the code of the FMS. The practice mode defaults to having a five second countdown – the DS ticks down the seconds, before it starts the sound effect and the auto period.
Is that the five seconds you are commenting on? If so, you can change it in the setup tab.
(I know, we’ve probably won some in those last 5 seconds too so it probably evens out…)