Java Conditional Command

[Joe Ross]

In this particular case of the example, I think it would be easier to build the logic into a single command.

However, the pattern is definitely useful. We had cases last year where we wanted to start a parallel command halfway through another command (for a different subsytem). We sequenced them with waits, but a way to generically peek at the progress of the first command would be much better.

[SamCarlberg]

Originally Posted by Joe Ross

In this particular case of the example, I think it would be easier to build the logic into a single command.

However, the pattern is definitely useful. We had cases last year where we wanted to start a parallel command halfway through another command (for a different subsytem). We sequenced them with waits, but a way to generically peek at the progress of the first command would be much better.

If you just want a rising/falling edge trigger, you could just poll the isFinished() method of the previous command, though that would break the CommandGroup paradigm a little

[notmattlythgoe]

Originally Posted by SamCarlberg

If you just want a rising/falling edge trigger, you could just poll the isFinished() method of the previous command, though that would break the CommandGroup paradigm a little

I've written one off wait for specific value commands that basically do the same thing the initial thread was started about. Things like having the robot move at a certain speed and when it reaches certain distances fire off certain commands. Think 7 disc auto in 2013. Never needed to stop, but as you reached the certain distances you could activate a certain chain of events.

What is the CommandGroup paradigm for doing down a different command path based on a decision from a previous step? Think hot goals in 2014.

[SamCarlberg]

Originally Posted by notmattlythgoe

I've written one off wait for specific value commands that basically do the same thing the initial thread was started about. Things like having the robot move at a certain speed and when it reaches certain distances fire off certain commands. Think 7 disc auto in 2013. Never needed to stop, but as you reached the certain distances you could activate a certain chain of events.

What is the CommandGroup paradigm for doing down a different command path based on a decision from a previous step? Think hot goals in 2014.

Sounds a lot like an event/listener model.

That's not how CommandGroups were intended to be used, which is why it breaks the paradigm.

[GeeTwo]

My Java is a bit rusty, but won't this command in the DriveToLine instantiator:

        addSequential(waitUntil(drivetrain.getDistance(), GREATER_THAN, 50));

Get the distance from the drivetrain once during the instantiator, rather than sending a handle for the drivetrain.getDistance method to waitUntil()?

[MrRoboSteve]

Originally Posted by notmattlythgoe

    	addSequential(new DriveCommand(0.5));
        addSequential(waitUntil(drivetrain.getDistance(), GREATER_THAN, 50));
        addSequential(new DriveCommand(0));

How do I describe what the robot should do if the distance never exceeds 50?

[notmattlythgoe]

Originally Posted by MrRoboSteve

How do I describe what the robot should do if the distance never exceeds 50?

If you're expecting it to timeout you could just call the addSequential() that takes a timeout parameter also.