getMatchTime docs not correct

[PhilBot]

Measuring time in autonomous should be easy.

This is my first year using Java for FRC and it surprised me that it wasn't the case.

1: The sample "Getting Started" code uses loop counters to measure time... Really?

2: The description for the Timer class is simply wrong... it would lead you to believe that getMatchTime returns elapsed seconds... but it doesn't , it returns the countdown clock... which is extremely counter intuitive.

Plus, it only returns a valid time when running in "Practice" mode on the Driver Station. Nothing in pure Auto or Teleop modes.

The library getMatchTime() comment reads:

* This returns the time since the enable
* signal sent from the Driver Station At the beginning of autonomous, the
* time is reset to 0.0 seconds At the beginning of teleop, the time is reset
* to +15.0 seconds If the robot is disabled, this returns 0.0 seconds

I had to ultimately display the returned time on the dashboard to see why my code wasn't working. In Auto it starts at 15 and counts down.

So, it would appear that if I want a generic timer that I can reset to zero in each mode, I need to use getFPGATimestamp() to get a hardware time, and great my own "ElapsedTime class to be able to tell how long I've been running.

Simple enough now I know I need to do it, but really.......
Not making it easy for beginners.

[mikets]

You don't even need to call getFPGATimestamp() to get time. Java has the generic System.currentTimeInMillis() that is platform independent. The only reason you want to call getFPGATimestamp() is if you want a resolution higher than milliseconds. If you just want to get game elapsed time, you can just call System.currentTimeInMillis() at the beginning of the game as the start timestamp and you can calculate elapse time by subtracting start time from current time. We don't depend on WPILib to provide elapsed time. Our framework has a runPeriodic(double elapsedTime) method that gets called periodically and elapsed time is a parameter in this call.

[PhilBot]

Hi

Thanks... Useful information.

Hey... don't I know you from the FTC forums

Philbot.

[Joe Ross]

Have you looked at the hasPeriodPassed method of Timer?

[mikets]

Originally Posted by PhilBot

Hi

Thanks... Useful information.

Hey... don't I know you from the FTC forums

Philbot.

Yeah, nice to see you over here too.

[Arhowk]

The Timer class actually wraps the DriverStation.getMatchTime() which has this documentation

/**
* Return the approximate match time The FMS does not send an official match
* time to the robots, but does send an approximate match time. The value will
* count down the time remaining in the current period (auto or teleop).
* Warning: This is not an official time (so it cannot be used to dispute ref
* calls or guarantee that a function will trigger before the match ends) The
* Practice Match function of the DS approximates the behaviour seen on the
* field.
*$
* @return Time remaining in current match period (auto or teleop) in seconds
*/

This might've been inverted this year on the DS side but it wasn't inverted in the Timer class