I came up with this idea when I was struggling with tuning PID values. And it worked out well.
I knew that the red zone in the next picture is causing oscillation. I can decrease it by making the slope less steep but it would be slower in motion
So I squared the error to make this curvy line to achieve less steep as it goes to the desired point.
Even though I made the kP really high like 10000, it never oscillated.
Hope this helps.
Are those two lines in the if and else equivalent?
Cant you remove the conditional entirely? Both branches maintain the sign just fine on their own since you’re doing
n * abs(n) instead of just
Glad to see i wasnt the only one thinking it
What a neat concept! I’m not sure what the physical implications of this are, but it’s definitely a nice little trick. I might have to try this sometime to see how it compares to my usual methods.
Yeah, and I also got rid of kD because I didn’t think I need it which actually was correct. So it is easier to tune because you only need to tune kP.
This is pretty interesting! My guess is that irl they use linear PID control to help keep the system linear (which is useful for things like transfer function analysis), but since we don’t need to do that in FRC I’m interested to know how it compares.
This smells similar to gain scheduling
kP near the setpoint. Squaring the error probably does weird things at large error, but I assume the control effort is saturating pretty early on anyway to where that difference won’t matter.
Anyway, cool discovery, and glad it works well on your system!
Interesting, this seems like it could be very useful, do you think this could work in some sort of generic non-linear pid class, and what usecases would you use it for?
I think it would saturate for a large portion of the output, though the kP would be the determining factor on how much. I do kind of like the more gradual slope at the end, it like a built in kD to some degree. Maybe we call this a quadratic PID? It isn’t quite a motion profile as it doesn’t handle ramping up but it is approaching that category.
Right. The general assumption here is that the underlying system involves “lots of control effort away from the setpoint, only a little needed near the setpoint”. There’s lots of control architectures which could accomplish this (including feed forward from a motion profile as you mentioned). Squaring the error with control effort saturation is another.
The folks with math hats might cringe at the notion of tossing a power of two somewhere in the mix (something something linear systems). But if it works on OP’s bot and helps them score points, I say to heck with the concerns.
I’d have to see some plots of setpoint, measurement, and control effort over time before I can pass judgement.
I used this in my swerve code for motors that turn wheels (the ones that change the direction of wheels). I was using the linear general PID and had an oscillation problem even though the max voltage of the motor was like 8v. But when I used quadratic PID, I could gain up the kP really high like 160 and the motor was running at 12v right before it reaches without any oscillation. I think you can use this for any type of simple motor control.
I played around with this in @gerthworm 's frc-docs turret pid sim.
It is slower to converge but converges for a larger range of P. The biggest issue with this control method is it is dependant on the input units used. For example, if the input was switched from inches to cm, the model would perform wildly differently.
With a squared error for P, the output for errors < 1 are decreased, which can decrease oscillations, but the output for errors > 1 are increased, which can increase oscillations if your motor cannot slow down in time. I think for this type of tuning to work, you’d have to carefully select / invent an input unit that has a desired error above 1 and below 1 regions.
In the case of a swerve drive steering motor, a wheel is fairly light, it as a low moment of inertia, and it has friction against the ground actively trying to stop it from moving. So specifically in this “very easy to slow down” system, I think this could be effective. But, I would hesitate to use this in any situation that doesn’t meet those criteria.