Shuffleboard sendablechooser makes autos act weird

So when I set the autonomous command manually like this, the autonomous modes work just fine:

public Command getAutonomousCommand() {
    return new TwoBall1();
}

but when I set the autos in a sendable chooser in smartdashboard/shuffleboard, like this, it makes the robot run a different autonomous mode and way faster than it should:

public Command getAutonomousCommand() {
    return mAutoChooser.getSelected();
}

I have no clue why this isn’t working. Do I need to be resetting the sendable chooser somewhere?

Thanks!!

gitlab link: Elliot Scher / QJ Pathweaver · GitLab

2 Likes

Make sure that the chosen value is sent. The dashboard should have some sort of green checkmark indicator or something (Glass does, I don’t remember about Shuffleboard).

it does have the green check mark

The order shouldn’t matter, but maybe try sending the chooser to the dashboard after adding the options rather than before?

sadly still nothing.

1 Like
mAutoChooser.setDefaultOption("NONE", null);

Does the auto it runs match anything you have provided? If not, maybe try a non-null default here?

What do you mean by this? Is the robot literally moving faster?

yes the robot is literally moving faster.

I’ll try that!

Something that’s probably an issue is you are resetting odometry on when getCommand is called, instead of when the command starts. This makes it so after the robot initialization, the robot will think that it is at the start location of the last path that you initialized.

To prevent this you can use something like

new InstantCommand(driveTrain::resetOdometry).andThen(ramseteCommand)
6 Likes

For your

SendableChooser<CommandGroupBase> mAutoChooser = new SendableChooser<CommandGroupBase>(); // defining autochooser smartdashboard widget

if all your commands are sequential (from a quick check they seemed to be) you could try SequentialCommandGroup. Maybe there is something in that class that you are relying on.

1 Like

I suspect @ohowe is on the right track.

Also, I have seen similar issues in the past, and while I do not remember the exact details, it generally had to do with the subsystems used by the auto commands not having fully settled with regard to initialization when the auto commands were created. For example, an gyro that has not fully completed its calibration or a delay in getting the final setting or status communicated across the CAN bus. The creation of an auto command should not depend on this sort of thing, but I have seen it.

If the @ohowe suggestion does not fix it, try defining your chooser not as a provider of a command but rather as a provider of a command supplier (Supplier<Command>). In this way the auto command is not constructed when the chooser is created but later when getAutonomousCommand() is called, just like your hard coded case that works.

3 Likes

That fixed it! Thanks!!

That was a great catch by @ohowe. We are learning about command-based and will remember this important point.

My team has another way of mitigating the timing problem. We use Strings to select the auto mode. In disabledPeriodic() we use switch/case on the selected String so only the desired auto command is instantiated. This also has the advantage of not instantiating commands that are not needed or potentially cannot be instantiated because of some robot component failure. And we don’t waste time in autonomous building commands - they were built while disabled. The code isn’t as pretty with the redundancy and isn’t as simply structured but it’s more robust.

that’s really clever!

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