Differential drive not updated

This happens once on start up of the teleop. When using our auto code it does this very often, 2 times a second about. No idea why as i have subsystem.feed() on every subsystem and differentialDrive.feed on my drivetrain.

Once on Startup is normal. We’d need to get a link to your code to see what else you’re doing.

1 Like

What are you trying to do when it’s giving the watchdog?

Your code is kind of hard to track what it’s doing overall, for example, the AutoAngle command instantiates a separate PIDCommand child, that doesn’t require the subsystem.

Why not just have AutoAngle by the PIDCommand?

Things like that are a bit confusing to me. Overall though, in your autoangle -> turntoangle PID commands you’ve got enough printlns that you may be overrunning the 20ms scheduler loop.

I do that so I can have a turn to angle for another command that needs it. My robot periodic is . 06 last time 8 checked, would all my prints be causing this? How taxing is a print, seems like a lot

I don’t think you need all these feed() calls everywhere. It’s implicitly called under, for example, arcadeDrive().

I see you have in RobotContainer.java:

public Command getAutonomousCommand() {
    // Must be aligned to the bottom left corner; middle wheel on the initiation
    // line.
    CommandGroupBase.clearGroupedCommands();
    return new AutoDriveBackCommand(driveSubsystem).andThen(new WaitCommand(.2)
        .andThen(new ShooterCommand(shooterSubsystem)).alongWith(new IndexWheelCommand(indexSubsystem).withTimeout(7)));

  }

I wonder if what it happening is that the SequentialCommandGroup you are creating here has the union of the requirements of the component commands, so the drive subsystem is not returning to the default command until the end of the autonomous group, and therefore nothing is calling feed() on the differential drive.

Note that you can tweak the frequency of these messages by calling setExpiration().

EDIT: Just noticed something else. In AutoDriveBackCommand.java, you have:

public void end(boolean interrupted) {
    driveSubsystem.arcadeDrive(0, 0);
}

Instead of setting the power to zero in random commands, it would be better practice to create a stop() method on your drive subsystem that calls stopMotor() on the differential drive.

What’s stopMotor?

Sets the power to 0, but it’s a way to know exactly what is going on when your motors stop.

Oh ok, thanks. Still have no clue why it’s over running the periodic loop, though. I’ll see if getting rid of all my prints does something.

1 Like

Prints are ridiculously taxing in an FRC robot. That’s probably the issue.

Nope, reduced the periodic ,though-- and we still overrun the .02 sec loop which is weird. In auto ,now, when it drives back there are no errors, yet when we stop to shoot it spams the not fed error.

Haven’t had a deep look at your code, but I noticed;

AutoDriveBackCommand(driveSubsystem).andThen(new WaitCommand(.2).andThen(new ShooterCommand(shooterSubsystem)).alongWith(new WaitCommand(1).andThen(new IndexWheelCommand(indexSubsystem).withTimeout(7))));

My guess is that after the AutoDriveBackCommand finishes, none of the other commands are telling your differential drive to do anything, hence triggering the not fed warning.
(Constantly telling it to do nothing counts as something and will make that message go away.)

However in the worst case, if you don’t want to be driving, you can just ignore the message. It’s just telling you it stopped the robot for you. It does spam prints though.

Yea, I didn’t commit this but i changed the end() to diffdrive.stop(). do you think that would be better?

So when you chain commands together with andthen you create a SequentialCommandGroup. This group is itself a Command, however it’s requirements are the union of all requirements of its constituent components.

Since one of the commands (AutoDriveBackCommand) requires driveSubsystem, the entire command group will require the driveSubsystem while it is running.

This means your default command for driveSubsystem won’t be scheduled while the command groups is running.

Since none of the other commands in the command group tell your differentialDrive object to do anything, for the remaining duration of the command group, the differentialDrive object will complain.

2 Likes

Good answer, is there a fix to it or do I just have to deal with the print stream.

1 Like

You could run another command in parallel with the rest of the commands that just tells your drive base to do nothing.

Edit: You could also just disable the safety, but I don’t recommend that as the solution to this issue.

I’ll just leave it as is, but sometimes our robot skips over our drive back command, and goes to the shoot part, now that is very annoying.

Is this a common issue you can reproduce?

If so (or even if not) add some statements to monitor your average encoder value from the command. The only reason that should exit is if the isFinished method returns true. (Or if it gets interrupted but I don’t think that is the case or the entire group would be interrupted)

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