Match Length Question

[magnets]

I'm asked a question a programmer on our team emailed to me.

"The teleop period appears to be 2 minutes and 18 seconds long instead of 2 minutes 15 seconds. Do you know how this works with the time returned from from the getMatchTime method? Does the field start with 138 seconds on the clock, does it reach zero early, or are the seconds longer than a second?"

If nobody knows (which I think is likely), then he plans on running his own match timing. I'm not sure why our code has issues if the match is too long, but he asked me to look into this for him, and I figured somebody here might have seen this before.

Check out this match to see an example of the match length

https://www.youtube.com/watch?v=PGnm...etFNvMSKst-Vt0

The transition to teleop happens during 1:43, and the match ends during 4:00.

[PowerfulKitty]

I'm not a programmer but there's often a delay between auto and teleop.

[Pretzel]

Originally Posted by magnets

The transition to teleop happens during 1:43, and the match ends during 4:00.

I believe the error here is that you're assuming the teleoperated period starts when autonomous ends. There's actually a delay in between the two, and teleoperated doesn't actually start until about mid-way through the 3 bells that signify it's start. I know this because, as a driver, if you step over the line and grab the joystick before the bells to start teleop ring the robot won't actually do anything (because it's disabled at that point in time).

If memory serves me correctly the robot enables into teleoperated mode right around the second bell or so in the sequence of three, in which case there doesn't appear to be any issues since the second bell rings at 1:45 in that video, which would line up correctly with the 4:00 ending time.

EDIT: One other thing to remember is that the clock on the webcast (the one seen in the video) is not the official clock. The official clocks are located near the team numbers on each side of the field, and I've seen the two clocks off from each other by up to 5 seconds before. That could also be a contributing factor when watching the video. It's enough of a difference that most referees will actually bring it up in the driver's meeting at the start of a regional, telling you to not go by the clock on the big screen, but the one across the field from you instead.

[compsuppjk]

I think that the RSLs on the robots are good indicators here. They can clearly show us when the robot is in the "teleop disabled" mode, and when it transitions to "teleop enabled" mode.

It appears that when the timer reads "135" on the audience display, this is acting as a placeholder for the 'teleop disabled' period. One would think that the only time that the timer would be valid at "135" would be at time 135.00000, meaning that the timer is never really valid at 135.

Using that logic, we would expect that the robots would be enabled as the timer counter is changing to "134" (1:44 YouTube time) - however, using the video you've provided as evidence, we can see based on the RSL status that the robots are clearly enabled at the beginning of the "135" counter, or at 1:43, as you've suggested. We can see (not in the video that you've linked due to camera angles, but others, such as this one https://www.youtube.com/watch?v=fI8r...st-Vt0&index=9 ) that the robots are enabled through the "0" second. This would lead me to believe that matches are actually 2:16, not 2:15.

*** DISCLAIMER - the audience display is provided only for convenience of the audience, the field timers are the only valid clock on the field.

What would be interesting would be to look at some DS logs of matches, and compare those to DS logs of the "Practice Mode" function of the DS software.

[cglrcng]

I showed by the internal time clock 15 (:15)Auto+135(2:15) at beginning of Teleop=Total 150 seconds. (2:30). I'd go by this clock, but there is a momentary delay switching from Auto to Teleop. You can see that from clock hitting zero in Auto to starting @135 in Teleop by repeatedly watching the video closely. (So is there a 1 second or thereabouts switchover between Auto/Teleop when nothing is actually happening?) If so, then actual match timing is correct.

By the actual youtube video clock, match starts at 1:29, Ends at 4:01. 60X4=240-89=151 Seconds=(2:31) Seconds (That has to be something in the way the formatting of the actual video was done and what with, and video compression happens. (I'd still go by the offical first game clock, unless you see something in the Driver Station logs that shows it really isn't true to form).

If you do, you should notify FIRST immediately.
_______________________________
You may also be correct as the vid could end @ 4:00 which would make both clocks exactly 150 Seconds, & exactly match. (2:30 Minutes Total) Switchover @ 1:43 between Auto/Tele also confirmed though. Something could appear off there by my math. (Just ran free stopwatch on the video and came up w/ 2:32:01 but impossible to be perfect there as to start/stop by finger clicks). Then I ran it on the 135 second segment of Teleop...Easier to get timing of the stop watch start/stop clicks right there, and it came up 2:17:50...Your programmer appears closer to correct! (It is by the game clock and vid almost 2:18 long for teleop). I could easily be off by 1/10th of a second, but not by nearly 3 seconds. Ran it again on another vid on teleop, same event, later vid in the order Tele was 2:18:12. But the game clock showed fluctuations in the countdown in numerous places along the way too w/ 2 of us watching both timer and stopwatch. Mobo battery is probably low or unit had some heat in it (running the FMS), or some other problem. Your programmer actually found something as multi runs is showing almost a constant Teleop period of 2:18. Smart kids!

The Auto was :15 as I counted it down to zero (15 clicks), then the game clock switched to 135 seconds (150 seconds is 2:30 or 2 Minutes, 30 Seconds).

[cglrcng]

Originally Posted by compsuppjk

I think that the RSLs on the robots are good indicators here. They can clearly show us when the robot is in the "teleop disabled" mode, and when it transitions to "teleop enabled" mode.

It appears that when the timer reads "135" on the audience display, this is acting as a placeholder for the 'teleop disabled' period. One would think that the only time that the timer would be valid at "135" would be at time 135.00000, meaning that the timer is never really valid at 135.

Using that logic, we would expect that the robots would be enabled as the timer counter is changing to "134" (1:44 YouTube time) - however, using the video you've provided as evidence, we can see based on the RSL status that the robots are clearly enabled at the beginning of the "135" counter, or at 1:43, as you've suggested. We can see (not in the video that you've linked due to camera angles, but others, such as this one https://www.youtube.com/watch?v=fI8r...st-Vt0&index=9 ) that the robots are enabled through the "0" second. This would lead me to believe that matches are actually 2:16, not 2:15.

*** DISCLAIMER - the audience display is provided only for convenience of the audience, the field timers are the only valid clock on the field.

What would be interesting would be to look at some DS logs of matches, and compare those to DS logs of the "Practice Mode" function of the DS software.

_______________
That vid, the official clock jumped a lot in teleop, stopwatch showed 2:19:22for tele period. I don't think you can do it this way because vid compression may be changing actual match timing too much. DS logs, or live match stop watch timing should tell you more than this is...But, I'm bringing a stopwatch now to champs just to see.

[Jared]

Magnets is correct about the match length being wrong.

To be extra sure, I took the time from when our robot went to teleoperated enabled to teleoperated disabled in a match, and it worked out to be 137.8 seconds. I did not include the time between auto and teleop.

When I have the log viewer display 137.8 seconds of match play, the teleop status continues off of both sides of the screen.

However, do the extra 2.8 seconds really make a difference?

[Daniel_LaFleur]

Originally Posted by Jared

However, do the extra 2.8 seconds really make a difference?

It would if the 2.8 seconds was not consistent.

[magnets]

Originally Posted by Daniel_LaFleur

It would if the 2.8 seconds was not consistent.

The matches seem to be consistently 2 to 3 seconds long. I have videos on my cell phone, which I can't time accurately enough to know if it's exactly 2.8 each time. Our robot had a mode to shut everything off after 2:15, to help with driver practice, and we noticed it shutting off before other robots at our event when we accidently enabled this mode during a competition match.

Personally, I believe that this 'issue' isn't something to get upset at, but if the FMS can't time 135 seconds accurate to more than 2.8 seconds, there is something very wrong with how it's written. The hardware is more than capable of doing it more accurately, and it's not impossible to write software that will be more accurate (see cheesy arena).

[seg9585]

There might be something to this.

I checked data logs from our Driver Station from 2 different matches, and in both cases the DS reported robot in TeleOp Enabled for almost exactly 2 minutes and 18 seconds. Outside of this window, the timeframe between Auto and Teleop is clearly indicated (approx 1 second).

Now I'd love to know what your team's code is doing that will cause problems with an extra few seconds on the field. Did you set some sort of robot tote autorelease at 2:14 to ensure totes aren't stuck in the bot at the end of a match?

[engunneer]

Originally Posted by magnets

The matches seem to be consistently 2 to 3 seconds long. I have videos on my cell phone, which I can't time accurately enough to know if it's exactly 2.8 each time. Our robot had a mode to shut everything off after 2:15, to help with driver practice, and we noticed it shutting off before other robots at our event when we accidently enabled this mode during a competition match.

Personally, I believe that this 'issue' isn't something to get upset at, but if the FMS can't time 135 seconds accurate to more than 2.8 seconds, there is something very wrong with how it's written. The hardware is more than capable of doing it more accurately, and it's not impossible to write software that will be more accurate (see cheesy arena).

The Driver station provides this mode (Practice) automatically, so you don't need to write your own (which as you saw has a risk of being accidentally included on the robot!).

[magnets]

Originally Posted by engunneer

The Driver station provides this mode (Practice) automatically, so you don't need to write your own (which as you saw has a risk of being accidentally included on the robot!).

The auto shut off also opens up our intake so we aren't contacting a tote before the match ends.

One student's project was a 'match manager' that does various things depending on the time remaining in the match. Once auto ends, the robot prepares to start building the first stack automatically. At fifteen seconds left, if it detects we're in a cycle of stacking, it begins preparing to place the stack, and just before the match ends, it makes sure the intake is open.

We want to know if there's a way for the robot (or even teams) to know when the match will end. The answer to this question appears to be NO.

[Caleb Sykes]

Originally Posted by magnets

We want to know if there's a way for the robot (or even teams) to know when the match will end. The answer to this question appears to be NO.

If your team uses C++ or Java, the best way to determine how much time is left in the match is to create a Timer object and start the timer ticking at the beginning of teleop. Then, when the timer reads 135s, you will know that the match has ended. I assume LabVIEW has similar capabilities.

[Jared]

Originally Posted by Caleb Sykes

If your team uses C++ or Java, the best way to determine how much time is left in the match is to create a Timer object and start the timer ticking at the beginning of teleop. Then, when the timer reads 135s, you will know that the match has ended. I assume LabVIEW has similar capabilities.

The problem is that some matches are 138 seconds, but we don't know if it's all the matches.

[Caleb Sykes]

Originally Posted by Jared

The problem is that some matches are 138 seconds, but we don't know if it's all the matches.

My apologies, I didn't read the previous posts closely enough. I thought that the discrepancy came from the short disabled period between auto and teleop, but now I see that is not the cause of the extension teams are seeing.