We were watching this yesterday and noticed that 3005 appears to drive forward after the timer hits zero. I’m not talking about the screen overlay, or the buzzer sound, but the actual match timer that is attached to the player walls on the field.
This got us discussing: when does the match actually end? As in, when do robots actually get disabled? I was under the impression this is supposed to happen right when the timer hits zero, and it appears this is usually the case.
We can look to the stack lights above the player stations for some more info here. The double-solid lights turning off corresponds to robots being disabled. Scrubbing back through other matches, it does appear that the stack lights turn off right when the timer hits zero. Except for Finals 1, where the field seems to give everyone an extra half-second or so?
I’d like to stress I’m not posting this in attempt to call attention to the match itself, but out of genuine curiosity for the process the FMS uses to make sure robots all get disabled at the correct time, and just out of bewilderment for seeing robots stay enabled during T=0.
The FMS Whitepaper doesn’t really shed light on this past the basic “The FMS controls the driver stations which control the robots.” If anyone knows more about how that communication actually works between the FMS, the driver station application, and the robot, I’d love to know.
It’s also worth noting that the cameras used for TXCMP may have some inherent video output delay (very common in most consumer and entry-level professional cameras) over HDMI/SDI which is not caused by the capture system, giving the perception of delay between the audience display and the live field video.
In the video, the overlay and wall clock show 0 at frame 1145509.
The LEDs on the driver station turn fully white and the driver station stack lights start to dim at frame 1145537, approx 30 frames later (.93s).
Frame 1145535 or approx 3 frames (.1s) before the lights go out 3005 starts moving backwards to balance the ramp
Frame 1145546 (approx 1.2s after T=0 is displayed, and approx .3s after 3005 starts moving backwards) is when robots seem to get “disabled”, as displayed by 2468’s elevator starting to move down and the RSLs of all robots going from flashing to solid.
As someone who watched it live, it 100% looked like 3005 moved after T=0. (Not that I think they actually did anything crazy, you could be right and the timer is just not exact with the FMS)
I’ve done some analysis using the data I have on hand, this includes all of our matches from both of our Michigan districts, I’ll add our regional and district championship matches later this week.
First, based on this data, I’ve determined that both the match and autonomous end when T=0 is displayed, with the exception of some “extra time”.
As Mechanical Advantage made public last year, matches aren’t actually 150 seconds long. On average, we’re getting a little over 700ms additional time enabled per match then you’d expect.
To break it down a bit more, from the time that T=0 is displayed, both alliances on average get ~325ms additional time in autonomous, and ~350ms additional time in teleop. The red alliance gets on average ~20ms more than blue in both teleop and autonomous.
If we break it down even more, by driver station, you can see an interesting pattern appear.
Red still gets consistently more time than blue in autonomous, but in teleop it evens out except that red 3 gets on average 50ms more per match then any other driver station.
I’d love to have more data that disproves this, but there seems to be a clear pattern of “preference” for red, and specifically red 3 in both autonomous and teleop.
PS: 3005 was in red 3 during the match in question.
Is this similar visual data as you did in your previous analysis, or something else? Would you be willing to also share the raw data (or more stats). Curious what the distribution looks like.
Theres actually a really easy way to figure all this out. On your DS use either wireshark or pktmon to sniff port 1121. You can then look at byte 3 for the enabled state (0x04 is enabled) and bytes 20-21 for a timestamp of what was displayed on the field when that FMS packet was sent.
One other interesting thing this data would tell us. Its pretty well known the FMS sends out packets every 250ms. The part I’m unsure of is if the FMS only sends on those marks, or if match start and match end send an extra packet.
I’ve been asked kindly (read: told not to) by more than one FTA at this point not to run Wireshark on the DS at events… I’m not entirely sure why but that’s the nature of things.
Return the approximate match time. The FMS does not send an official match time to the robots, but does send an approximate match time.
At least in the video OP posted the time was equitable - we can see the RSL for both alliances blinked well past the buzzer. Momentum wouldn’t have anything to do with robots moving an extra half second or more in this match.
Due to the video processing latency of HDMI/SDI outputs on most cameras, you should not use the sound of the match buzzer as an indicator of when the match ended. The Audience Display application generates this sound and if there is any latency on the camera output it will cause this delay.
Instead I’d recommend using the DS stack light as an indicator of when the disable signal is given.
This season the buzzer began the heart-stopping 3-second grace period as we waited for our robot to settle on balancing. We were not aware but are now thankful for every extra millisecond we were given.
Its built into windows