Java wait Function

[cgmv123]

Timer.delay() is supposed to leave outputs set where they are as well, but I've had more success using Timer.getFPGATimestamp() in conjunction with a loop.

[Bryan Herbst]

Originally Posted by cgmv123

Timer.delay() is supposed to leave outputs set where they are as well, but I've had more success using Timer.getFPGATimestamp() in conjunction with a loop.

This is critical to understand.

Our team had similar requirements surrounding our catapult (do X, wait half a second, then do Y). Originally the programmers implemented this using Timer.delay().

The result was that when the drivers tried to perform the action while moving, but then stopped moving or changed directions during the action, the robot would keep moving.

Though .5 seconds doesn't sound like much, it is plenty of time for your robot to go just a little too far and injure someone, break something, or get you a penalty for going too far outside the arena.

Use Timer.delay() with caution.

[Ether]

Originally Posted by Tanis

This is critical to understand.

^This.

Year in and year out I see programmers bumping up against this concept.

I think it's probably fair to say that some (many?) of them receive advice on how to fix the problem, but never really understand why there was a problem and why the fix fixed it.

Does anyone have a link to a clear, simple, well-written tutorial on concurrent processing for FRC that covers threads, state machines, and interrupts?

[ProgrammerMatt]

This is what I have done.

Inside op control:

if(INSERT SOMETHING HERE) {

new Thread() {
     public void run() {
          //Code to run here:
          Thread.sleep(time in ms);
          //More code
          }.start()
     }
}

What this does is every time the if statement becomes true it creates a thread and runs the code in run() {} then kills the thread. you can use Thread.sleep(); inside this and it will NOT affect your main code only whats in that thread.

This has worked well for me.

Hope this helps!

Matt

[fovea1959]

how does the thread get killed?

[AlexBrinister]

My understanding is that the JVM handles it. From here, it seems like letting the JVM handle could introduce race conditions if you access the same data from multiple threads like that...

Alex Brinister

[fovea1959]

ah. looked at it too fast. The thread completes normally when run() returns.

[Greg McKaskle]

Is safety configured for the drive base? I'd hope that the Java implementation would halt the drive motors when wait() or breakpoints delay for more than 100ms.

Greg McKaskle

[AlexBrinister]

I think this is only enforced if you have the Motor Safety Helper enabled. This feature is optional in both the C++ and Java libraries and can be disabled by the programmer. It is generally better to keep it enabled but to extend the timeout period using the SetTimeout() function in whatever motor controller class you choose to use (Talon, Victor, CANJaguar, Jaguar, etc).

Alex Brinister

[Greg McKaskle]

What I intended to ask was whether the Motor Safety Helper was enabled when the robot motors ran for several seconds during the sleep() call.

Greg McKaskle

[ProgrammerMatt]

I have not turned motor safety helper on or off. So what ever it defaults to is what it is set to and it still works for me.

[Greg McKaskle]

Does the default result in zombie robots? I'd hope not. It should take effort to produce a zombie robot.

Also, if you are turning off the safety config, please ensure that everyone running the robot knows how to disable or estop the robot. Personally, I'd only turn it off when the robot is on blocks and I want the motors to keep running while I'm at a breakpoint.

Greg McKaskle

[NotInControl]

Originally Posted by cgmv123

Timer.delay() is supposed to leave outputs set where they are as well, but I've had more success using Timer.getFPGATimestamp() in conjunction with a loop.

If I remember correctly, Timer.delay() is a wrapper and simply calls Thread.sleep().

This causes the calling thread to sleep, and thus will cause your robot to hang unless called from a separate thread.

Use time stamps as mentioned.

System.getCurrentTimeMillis, or the FPGA timer, or anything else in a loop,

or spawn a separate thread and call thread.sleep() in the new thread.

But do not call Thread.sleep or Timer.Delay in the same thread as your TeleOp/Auto periodic functions.

Hope this helps,
Kevin