![]() |
Small FMS timer bug
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...) |
Re: Small FMS timer bug
Quote:
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? Hmmm... Anyone have a more elegant solution? Joe J. |
Re: Small FMS timer bug
Quote:
-John |
Re: Small FMS timer bug
Quote:
Quote:
|
Re: Small FMS timer bug
Quote:
|
Re: Small FMS timer bug
Definitely let someone at FIRST know about this one -- post it to the official forums.
Greg McKaskle |
Re: Small FMS timer bug
Quote:
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. |
Re: Small FMS timer bug
The LV framework computes the time the same way as mentioned. It counts from the first Tele packet received.
Greg McKaskle |
Re: Small FMS timer bug
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.
|
Re: Small FMS timer bug
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.. ;)
|
Re: Small FMS timer bug
Quote:
Maybe FIRST will discover a mini-black hole in the FMS that dilates time and create other problems with the field? :p *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!) |
Re: Small FMS timer bug
Quote:
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. Joe J. |
Re: Small FMS timer bug
Quote:
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. |
Re: Small FMS timer bug
Quote:
~ |
Re: Small FMS timer bug
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...) Rob |
Re: Small FMS timer bug
Quote:
|
Re: Small FMS timer bug
If it's always a consistent extra 5 seconds, I have no problem with it. It gives the students 5 more seconds of play each match and maybe win.
|
Re: Small FMS timer bug
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.
|
Re: Small FMS timer bug
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. Greg McKaskle |
Re: Small FMS timer bug
Yes it is, thanks Greg.
|
Re: Small FMS timer bug
Quote:
Actually, I was thinking this weekend that the matches were too short, scores were too low, and how would strategy change if the drivers had more time... But that's a different question! |
| All times are GMT -5. The time now is 10:12. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi