Problem scheduling a command in autonomous

We are having problems trying to schedule a command while within an autonomous command. We have an aimTurret command that works perfectly fine when connected to a button:

oi.driver_aButton.whenPressed(aimTurret);

But it won’t run when we try to schedule the aimTurret command from within our autonomous (an instant command) using either

aimTurret.schedule();
or
CommandScheduler.getInstance().schedule(aimTurret);

The same thing is true for other commands. We have a Shoot command that works fine when we bind it to a button, but we can’t seem to schedule it to run (or perhaps it gets scheduled, but never runs) within autonomous. Even if we instantiate a new instance of the command within the autonomous routine, scheduling it doesn’t seem to do anything.

We do have CommandScheduler.getInstance().run(); in our robotPeriodic. And we even tried adding that to our autonomousPeriodic() without any luck.

Is there something simple we are missing?

Any help is appreciated.

Here is a link to our 2020 GitHub repository:

Looks like you blended a number of patterns from both “old” and “new” command-based. Here’s the template the WPILib plugin uses to generate a new project: https://github.com/wpilibsuite/allwpilib/tree/master/wpilibjExamples/src/main/java/edu/wpi/first/wpilibj/templates/commandbased

Pay special attention to the RobotContainer::getAutonomousCommand method and the body of the Robot::autonomousPeriodic method

We are trying to use “new” command-based. Just stuck in some calls the “old” way when the “new” wasn’t working… it didn’t help. :neutral_face:

Where are you scheduling the aimTurret command?

We are scheduling it during our initialize method of our autonomous command. It just dawned on me that perhaps it is getting scheduled, but it won’t run until after the initialize is completed. Does that sound right?

And if we schedule it at one point of the initialize and then cancel further down in the initialize, it is looking to us like it isn’t getting scheduled, but in reality it did, but we cancelled it before it could run. Am I on track here?

John

Sorry to say this, but your AutoPlan* commands show a fundamental misunderstanding of how commands work which is odd since your other non-auto commands look good.

The AutoPlan* commands are trying to do everything in initialize() including Timer.delay(…) calls which are very bad in commands.

What you really seem to need is a command group, probably sequential, that runs a set of simple commands to accomplish the auto task. I believe there are examples of command groups in the wpilib examples that would help.

Looks like you’re breaking a lot of the Command rules, like using subsystems in a command but not requiring them. I’d suggest going through and rewriting your commands to be smaller, and have more of them.

Like for example, your Shoot command. I’d break that out into quite a few smaller commands. Start off with a PrepareForShot() sequential command group that uses a SpinShooter(velocity) command, followed by a series of InstantCommands for raising your turret. Like:

addCommands(
  new SpinShooter(1000),
  new InstantCommand(shooter::raiseHoodForShooting, shooter),
  new WaitCommand(0.4),
  new InstantCommand(shooter::extendHoodForLongDistance, shooter),
)

Timer.delay pauses the entire thread that is running, and since nowadays everything runs on the same thread unless you do some threading on your own, it’s basically stopping your code. Instead, use WaitCommand's.

Take those concepts, and extrapolate them out to other parts of the code. The most difficult part is going to be how you set a different speed depending on your distance from target calculations. That, I’m personally okay with how you’re calling methods on a subsystem but not requiring them. But only because it’s a read-only method from your turret asking for the current distance. Any time you are having an effect on a subsystem, you should require it.

1 Like

Got it. Thanks. Rewriting now.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.