Would you guys recommend using the built in wpilibj PIDController?

[Mahim]

Is there anything I should worry about using the built in one instead of making my own? Are there issues with threading?

[MrNick]

Good question! I’m wondering the same thing myself.

There are some functions on the robot where I would like greater control than every 20ms and was hoping I could get that through a PIDController with a period less than 20. 5ms would be good for my purpose. Is that how “period” works? If I set the PIDController with a period of 5ms are pidGet and pidWrite called every 5ms?

[krf]

As-is, absolutely not. it’s not easily understandable and the syntax is fairly obtuse. There was a rewrite of it that the WPILib folks wrote but didn’t get finished in time for 2019. It should be there in 2020, deprecating the old one.

if your team needs to use a PID controller that’s a little less complicated / can be synchronous, take a look at Team 254’s SynchronousPIDF.

[Waz]

We have successfully used the PIDController class on multiple occasions over the years. The period on the constructor does change the rate of pidGet and pidWrite. Note that the period is in seconds and not milliseconds, so 5ms would be 0.005.

Steve

[notmattlythgoe]

@krf

There was a rewrite of it that the WPILib folks wrote but didn’t get finished in time for 2019. It should be there in 2020, deprecating the old one.

It would be great if this could be released sometime in the offseason instead of at the beginning of the season.

[ExploitSage]

My team used them this year for our lift mechanism and they worked out fine. The PIDSubsystem is also actually just using a PIDController object behind the scenes.

You can review our code here: https://github.com/frc3468/DeepSpace

[Mahim]

I agree somewhat, having to create classes to read sensors and output the pid output is somewhat annoying especially for basic things, other than that I think its a pretty good way to quickly do anything PID related, I just realized this year anonymous classes were a thing which basically gets rid of that problem:

 // Command constructor
 public SeekCargo() {
    requires(drivetrain);
    requires(intake);
    Limelight.setPipeline(Constants.Piplines.CARGO);
    turnController = new PIDController(kP, kI, kD, new PIDSource() {
        @Override
        public PIDSourceType getPIDSourceType() {
            return PIDSourceType.kDisplacement;
        }

        @Override
        public void setPIDSourceType(PIDSourceType pidSource) {}

        @Override
        public double pidGet() {
            return Limelight.getXOffset();
        }
    }, output -> drivetrain.drive(-output, +output));
    turnController.setInputRange(Limelight.TX_MIN, Limelight.TX_MAX);
    turnController.setOutputRange(-0.5, 0.5);
    turnController.setAbsoluteTolerance(0.3);
}

I just wanted to know why teams find it necessary to make their own

[krf]

It’s actually in an experimental pull request that you can add to your project and use now. See here.

[notmattlythgoe]

@krf

you can add to your project and use now

It would be nice if the calculator could be separated from the control loop in some way to allow for cascaded loops.

[Mahim]

wow, it would be amazing to use lambdas instead

[msoucy]

If you find yourself writing that PIDSource as a wrapper a lot, it might be worth creating a class that accepts a DoubleSupplier as its parameter and acts as a kDisplacement PIDSource. That can help cut down on repeated code. (Shameless plug for the one 166 has as a reference)

[notmattlythgoe]

We’ve successfully used PIDCommand instead of PIDController for doing things in the past. The fact that it implements PIDSource and PIDOutput itself makes it package pretty nicely.