Test mode not cooperating

Technical Programming
#1

Hi, I’m trying to do live PID similar to this post: Setting PID Controller values in shuffleboard.

We’re running the robot in test mode, but we both can’t run any teleop code (even though we’re calling teleopPeriodic in testPeriodic + teleopInit in testInit), and we’re experiencing the same error as the aforementioned post where the adjusted numbers immediately reset when we try to change them.

We are using PIDControllers, not PIDSubsystems or PIDCommands (though we did try pidCommands to no effect), so that might have something to do with it. I’m really at a loss. Has anyone else had that issue/have a solution?

#2

How are you adding them to Shuffleboard? If I remember correctly, I also had trouble with this, so I ended up making my own solution so I could change those values whenever I felt like it. If I remember correctly, to get this working without doing that, you should add them to LiveWindow and change the values in the Live Window tab while in test mode.

Maybe someone who is more familiar with the limitations put in place can comment on this. I never really liked that the robot had to be in test mode to change this stuff.

#3

Yes this is a known bug. PIDSubsystem doesn't run in test mode · Issue #2792 · wpilibsuite/allwpilib · GitHub Its been around for some time.

#4

I don’t think this would be the same issue. That issue is specific to the new command framework and PIDSubsystem. The OP said they are using PIDController directly, so that issue wouldn’t apply.

@CoByte can you provide more details on your code? A simplified test case would be very helpful.

#5

Thanks, My tunnel vision got me. That issue was mine so when I seen the post I stopped processing information.

#6

Sure. We’re currently working with a command to send a turret to a position, with this code (with fluff removed):

public TurretToPosition(Turret turret, double targetAngle) {

addRequirements(turret);

pid = new PIDController(0.01, 0, 0);
pid.setTolerance(0.2, 1);
pid.setName("turret angle pid");

}

@Override
public void initialize() {
pid.setSetpoint(target);
}

@Override
public void execute() {
turret.setPower(pid.calculate(turret.getAngle()));
}

This is just a snippet, but I think it gets the idea across. When we run it in test mode, the LiveWindow is autopopulated with the PIDController as it should be, but any attempt to change the numbers is instantly overwritten, as previously mentioned.

This could be related to the error that @cpapplefamily mentioned, but I’m not sure where exactly PIDCommands are run in the new framework, or how I would fix it (call CommandScheduler.enable() in testInit()?)

I hope that information is helpful, and thanks so much already

#7

Yeah, try calling CommandScheduler.enable() in testInit(), and make sure that you have CommandScheduler.run() in robotPeriodic() or testPeriodic() (or a method you call from them).
Is your code on github or something?

#8

It is, link is here, but it is a bit of a mess. There’s a livepid package in there, but it’s not what we’re using, so it can safely be ignored. We tried adding the enable and run, which did allow us to run the robot properly, but the live pid is still having the resetting issue.

#9

The other thing to do would be not do this in Test but in teliop. Then with a few SmartDashboard Widget you could set the PID

public void initialize() {
    SmartDashboard.putNumber("kp", 0.110));
    ...
}     

Then in 

public void execute() {
   pid.setP(SmartDashboard.getNumber("kp", 0.010));  //Get the current value of "kp" or default to 0.01
}
#10

I see a couple of things. You’re creating new instances of the TurretToPosition command when you set it as default command each time teleopInit is called. You’re also setting the name in the TurretToPosition command so all instances have the same name. I suspect all instances are fighting with each other when you change the PID value.

When I moved setting the default command to robotInit, so it only occurred once, I was able to change the PID values in test mode.

1 Like
#11

Welp, I guess this is what I get for taking shortcuts. This worked, thanks so much!