We ran into some very strange behavior when tuning out PID controller at competition last week.
We’re using PIDSubsystem for our drivetrain, setting the PID values when the subsystem is created in Robot.java:
public static DriveTrain driveTrain = new DriveTrain(RobotMap.kP, RobotMap.kI, RobotMap.kD)
and are putting the PID controller on the SmartDashboard for tuning in robotInit() :
After tuning the PID constants using the SmartDashboard, we then hard code the values in RobotMap, where the driveTrain object is getting its arguments from.
After deploying the code, we verify that the PID controller is indeed using the new constants by printing out to the console ( System.out.print(driveTrain.getPIDController.getP); ) but weirdly, the PIDController output behaves the same as it did pre-tuning.
This happens over and over again, seems like the constants are being scaled relative to something else, but I’m at my wits end as to why this is going on.
Anyone seen anything like this before?
Did you pull out all of the code from the process of setting constants through smart dashboard? Perhaps smart dashboard is overwriting your robotMap values after you print them.
SmartDashboard is showing the new values, along with the sysout prints
Just spitballing, but have you tried changing the variables in smart dashboard to a different value and back to your tuned values to see what happens?
To be clear, what was it doing pre-tuning? Was the system acting like it was under PID control, but with different tuning, or just running at a constant throttle setting, or what?
Edit2: I’m wondering if perhaps you’re only setting the setpoint or only calling Enable() from the smart dashboard, and not from your regular robot code. If you can’t find the issue, perhaps posting your code and getting more eyes on would help.
Pre-tuning it was working under PID control, but with different tuning, so not reaching its setpoint.
I’m wondering if perhaps you’re only setting the setpoint or only calling Enable() from the smart dashboard, and not from your regular robot code. If you can’t find the issue, perhaps posting your code and getting more eyes on would help.
I don’t have the code on me right now, I’ll try to post the relevant parts the next time I have access to the team laptop. But I can try to answer your questions without it: Testing pre-, during, and post- tuning was all done through a command button on the smartdashboard. This command both set the setpoint and enabled the PID controller.
Before tuning, when this command is started from the SD, the chassis attempts to reach the setpoint but is sluggish.
After tuning in the SD, but before hard-coding the constants,starting the command results in the desired motion.
After hard-coding the constants, verifying that they appear in the SD and are being printed out to the console to be very sure, starting the command results in an attempt to reach the setpoint but again very sluggish, as before tuning.
I’m wondering if the PID constants need to be set after the PID controller is enabled? Seems like that shouldn’t be the case as the controller is able to take in constants when its constructed, but something to try.
have you tried changing the variables in smart dashboard to a different value and back to your tuned values to see what happens?
I’ll also give this a go next time we fire up the practice bot.
Are you using the Navx by any chance?
Are you using the Navx by any chance?
Yes we are, and are printing out the heading from the navx as part of our diagnostics on this issue, it seems to be operating consistently across all tests.
In place of using PID last weekend at Utah, we just turned at a constant speed until we hit the desired rotation, and just lived with the fact that we would slightly over or under-shoot the target by a couple degrees.
We had one issue a few years ago where we were using RobotPreferences to store PID Coefficients on our robot’s hard disk which were retrieved and configured into the PID controller at robot startup.
In the pits before competition we kept changing the “default” values in the code directly. It was driving us crazy because no matter what we changed, the PID controller kept behaving the same way.
We forgot that because there were PID coefficients saved to disk, that the values from disk were being used, not the defaults; the default values hard-coded in our code were only used if there was not data saved to disk. Our practice robot didn’t have RobotPreferences stored to disk, but our competition robot did, which led to the confusion.
Not sure that’s what’s going on here, but your description reminds me of that.