When does the match actually end?

Check out the end of finals 1 at Texas state champs (10:36:27):

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.


Looks to me like they “hit the gas” just before the light and what you see is an extremely fortunate amount of momentum.


Run a timer during auton and during the match. You’ll learn interesting things.


To make it more clear, let’s look at a couple examples from Texas:

F1 (the example posted above): FIRST in Texas - FRC State Championship 2023 - Day 3 - YouTube
F2: FIRST in Texas - FRC State Championship 2023 - Day 3 - YouTube
M13: FIRST in Texas - FRC State Championship 2023 - Day 3 - YouTube
M12: FIRST in Texas - FRC State Championship 2023 - Day 3 - YouTube

Compare the stack lights to the on-field timer on the alliance wall (which can be read if you turn up the video quality) in these examples.

6328 did some great research on this topic last year. FRC 6328 Mechanical Advantage 2022 Build Thread - #112 by jonahb55

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.


Just to state some facts;

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.


Assuming you’ve learned some things already, can you dive into them at all for those who dont have a robot and official matches at their disposal?


Someone else linked the 6328 thread.

1 Like

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’m assuming momentum for sure as in one of 6800’s (Valor) matches, their robot kept rolling across their Community a good 1.5 feet after the buzzer

1 Like

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.


This is using data logged from AdvantageKit, here is the spreadsheet I used to generate these graphs.


So run pktmon :smiley: Its built into windows


Is this packet structure and frequency documented anywhere? I would love to know more of the actual mechanics for how this communication works.

1 Like

Maybe not. The Timer class has getMatchTime() which I presume is this timer and it makes no claim to be official.

public static double getMatchTime()

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.

1 Like

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.