PID control help

[cstelter]

Originally Posted by KosmicKhaos

We are trying to have each motor at the same speed and if the encoder notices that the speeds aren't the same we would like for the slower one to speed up or the faster one slow down so the speeds are equal. We were thinking that the motors start at the same speed but after a little while of running the speeds my get off, if they do we want to make them equal again. The loop essentially keeps the motors the same speed These motors are controlled by the driver and both with one button.

Then I would recommend you run each motor/pid as a separate subsystem. You can make each a PIDSubsystem that will automatically set things up with functions for usePIDOutput and returnPIDInput. But the enabling/disabling of PIDSubsystems has been observed to be a bit odd (the pids run when disabled it seems, causing i to build up).

Alternatively you can use two PIDCommands which will also then have methods onthem for usePIDOutput and returnPIDInput. You can set those to access return values from the subsystems. (i.e. usePIDOutput in one command sets the motor on one subsystem and returnPIDInput in that same command returns the encoder rate on that same subsystem.

However you do it, you end up with a PIDController object (either managed by the PIDSubsystem super class or by the PIDCommand super Class).

Once the PIDControllers are tuned (if the mechanisms are largely similar, they will likely have the same PID vaues), you can call setSetPoint() on the PIDController/PIDSubsystem and when they are enabled, they will drive at a particular rate. Each will function independent of the other, but both will rely on the respective encoder to maintain the rate.

Note, there are two approaches for usePIDOutput for a rate PID. One is to treat it like a positional PID in which case as you approach your set rate, you try to apply 0V, which of course will actually be trying to slow down your motor, rather than drive it at a constant value. Also in the application of something like a shooter where the motor may be spinning very fast as opposed to a very geared-down application, if the rate gets a bit large, you may try to apply negative voltage to a motor with a very strong forward momentum.

The other approach iirc is to change usePIDOutput to maintain a last value sent and add/decrease that last value sent by the output. If you search CD you can find some good articles and all the math behind them to support
something along the lines of

class PIDCommand {

double m_output;
...
public void usePIDOutput(double output)  {
    m_output += output;
    motor.set(m_output)
}

I'm going off memory for the above, but you can still tune PID, but now as you arrive at your setpoint, you just send the accumulated value for m_output.

I'll be honest, we use encoder/talon pairs for our drive train this year and did so all last season. Last year we originally used positional and the discovered the rate formulation mid-season. We tried it, but either we implemented it poorly or didn't take enough time to properly tune it, but it did not seem to behave as nicely for us as the original positional formulation.

I think the rate formulation is more correct, but I can only say that the positional formulation got our team through an entire season with no observable problems, though after driving 10 minutes or more our cims did get quite hot. That was more due though to poor cooling-- when the cims were exposed to air on the practice chassis it was not a problem, but when they were somewhat enclosed by electrical above and a pan below, they would get hot. I suspect a rate formulation may have helped with this.

But regardless of how you do this-- PIDController, PIDSubsystem, rate formulation or positional formulation, the concept is the same. Drive each motor based on feedback from its respective encoder to adjust the motor speed. You will find that each independently will then maintain the same rate. We did find that some small tweaks to DistancePerPulse might be necessary to tune the two encoders to one another, but even without such adjustments the rates will be relatively equal-- much better than otherwise.