Match Length Question

[PowerfulKitty]

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

[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]

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.