getMatchTime docs not correct
 

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.

Re: getMatchTime docs not correct
 

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.

Re: getMatchTime docs not correct
 

Hi

Thanks... Useful information.

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

Philbot.

Re: getMatchTime docs not correct
 

Have you looked at the hasPeriodPassed method of Timer?

Re: getMatchTime docs not correct
 

Yeah, nice to see you over here too.

Re: getMatchTime docs not correct
 

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

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