Java wait Function

[2185Bilal]

What we want to do is to have our solenoids to open and then after like 0.5 seconds have it close automatically.

This is our code so far:

if (j_shooting.getRawButton(2)){ //FORWARD - BUTTON A
            flag = 1;
        }else if (j_shooting.getRawButton(1)){ //BACKWARD - BUTTON X
            cyl_shoot.set(DoubleSolenoid.Value.kForward);
        }else {
            cyl_shoot.set(DoubleSolenoid.Value.kOff);
        }
        
        if (flag == 1){
            cyl_shoot.set(DoubleSolenoid.Value.kReverse);
            try {
                Thread.sleep(500);
            } catch (InterruptedException ex) {
                ex.printStackTrace();
            }
            cyl_shoot.set(DoubleSolenoid.Value.kForward);
            flag = 0;
        }

**ignore the indentation, and the kForward and kBackwards, its switched

So my question is, is the code i have right now good and if not what other options is there to have the pistons open, pause for 0.5 seconds, and then close.

thanks

[Domenic Rodriguez]

Thread.sleep() causes the current thread to pause for a time. If you call this from the main thread, the robot will be unresponsive for those 500 ms while the thread sleeps. You could avoid this by moving the solenoid code to a separate thread.

A simpler option that I often use is to record a timestamp at the start and then subtract that timestamp from future readings to get the elapsed time.

Example:

double startTime;

if (j_shooting.getRawButton(2)) {
    // This will repeatedly be set until you let go of the button
    startTime = System.currentTimeMillis(); 
} else if (j_shooting.getRawButton(1))
    // This will override, but not reset, the timer
    cyl_shoot.set(DoubleSolenoid.Value.kForward);
} else {
    // Check the time to see if the pistons should be...
    if (System.currentTimeMillis() - startTime < 0.5) {
        cyl_shoot.set(DoubleSolenoid.Value.kReverse);  // ...extended, or...
    } else {
        cyl_shoot.set(DoubleSolenoid.Value.kForward);  // ..retracted
    }
}

This way you aren't locking up the rest of your program while you wait for the pistons to retract.

[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

[Bryan Herbst]

Greg,

I haven't done any real testing, but it does not appear that any sort of safety kicks in after 100ms in Java. Our robot definitely moved for more than 100ms with our sleep() calls.

You made me curious, though, so I started poking around. The Jaguar class extends SafePWM, which indeed defaults to disabling safety:

void initSafePWM() {
    m_safetyHelper = new MotorSafetyHelper(this);
    m_safetyHelper.setExpiration(0.0);
    m_safetyHelper.setSafetyEnabled(false);
}

This sounds rather silly for a class billed as "SafePWM" to me, though it does expose methods for you to enable safety if you wish.