[zubspace]

The site explains the three parts of PID's very well.

On one hand I like PID controllers. It's a reusable concept which you can apply to a loot of stuff. On the other hand, in my experience it can be very tricky and cumbersome to tweak them.

In the given example, a PID makes perfect sense. There's a single, static target location you need to approach. Adjust velocity with a PID and you're done.

But what if the target location is not static? Imagine that the character needs to move to your mouse pointer? Do PID's still hold up? How do you handle the I and D term then?

It gets even trickier if you move to 3D. You maybe say, hmm, let's use a rigidbody this time instead of a kinematic body for the player character and use PID's to adjust forces to steer velocity and rotation.

But I never found a good way to do that, because in those other cases the error depends on the goal you need to reach, and if the goal constantly changes, I and D are kinda useless...

[YZF]

Your example is really a classical real world PID where a motion system tracks a motion profile. The short answer is yes, PIDs work just as well when the target changes. The stability of a PID depends on the open loop response which command or error are not part of.

The theory isn't that simple (you can take a course in Control Theory which would cover that) but I think many/most people that use/tune PIDs in the real world just use rules of thumb and standard approaches to tune the different components of the loop. Somewhat more advanced, but still non-theoretical tools, are actually measuring the open loop response which lets you pretty much see the margins you have. Optimizing PIDs is really trying to get the loop to respond quickly without becoming unstable.

Another interesting thing that's used in the real world is feed-forward. That is if you have some estimate of how to perform the function of the PID directly you can just feed that to the output and add the PID in parallel. The motion control analogy of this is called acceleration feed forward. If you know the target acceleration you can basically multiply that by some constant and feed it directly to the output (which is generally current to the motor which is more or less linear to acceleration given a constant load). This dramatically improves the performance of your control system because the PID now just corrects the much smaller residual error.

[amatic]

A tuned PID loop should follow a moving target with no issues and no advanced control theory. Here is a similar example from a Lego robot with a pixi camera [1]. The pixi camera recognizes the ball location in 2D, sends to arduino. There are two independent loops, one keeping the ball in the center of the horizontal visual field, by rotating the camera left-right, and the other is keeping the ball in the center vertically, by tilting the camera via two levers. One thing you might notice is that the ball sometimes goes too fast for the robot to follow - this is due to the limitations of the power of the motors, and the rate of sampling in the loop. Games usually don't have the limitation of the power, but I suppose the rate of sampling and updating the loop could be limited by the game loop. In that case, it might be useful to update the PID multiple times per loop.

Other than that, there are some tricks to make the loops more stable. Limiting the error can be useful. Limiting the action of the actuator. Smoothing the action of the actuator is very useful. I tend to think of PD loops as damped springs. The P term is like the spring constant, and the D term is like friction or viscosity. The first one determines the speed of reaching the goal, and the second one reduces the oscillations when reaching the goal. I rarely use the I term.

[1]https://www.youtube.com/watch?v=7_IZb0RJN_U

[ilayn]

> the error depends on the goal you need to reach, and if the goal constantly changes, I and D are kinda useless...

Why do you think that? the error is the difference between actual and desired at every instant. If you move the desired then you enlarge the error term and PID reacts to close that gap, it might never reach if you are changing the goal too fast but that's something related to the concept of "bandwidth". OTherwise you are quite right and all is OK.

If you have multiple axes then the typical solution is to have n PID loops for n axes. This assumes that the dynamics of the system is decoupled. In english, if I do something in one axis it will not affect the other axes. Then you can tune the PID loops independently. Otherwise, dry math.

[x86x87]

Lol. There is an entire field dedicated to this question. It's called Automatic Control. Yes, you can do all of the above. You need to model it with a multivariable system. Google control systems and systems theory.

Usually in a physical control system (that is driven by a PID controller) your limiting factors are the execution element (how fast can you change the input) and your sensors (the resolution of the transducers/sensors dictate the resolution of what you can achieve). A lot of times the PID controller will have a way that it can autotune itself as it's extremely rare to be able to measure the properties of the physical system precisely and for those properties to not vary with temperature and with wear and tear.

[zubspace]

Well, you kind of prove my point, because you made me jump from a 5 minute lecture about PIDs to a study about control systems.

Yes, probably there are all kinds of systems to control and autotune a PID. But that's the problem. In gamedev, PID's get constantly recommended for so many things, but when you play around with them you soon realize, that they are quite hard to get right. So then there's two ways: you dive into control systems or you just lerp the value and call it a day.

[x86x87]

yup. i get it. it's a steep learning curve. and it's hard to grok if you don't understand what the theory behind them is.

My bigger point is that the articles like the one linked here just barely scratch the surface and you cannot really jump into it and get an intuitive understanding by just looking at it. that being said, if you want to learn more you can and they can be applied to a large range of problems.

[ilayn]

Control theorist here. The articles are pretty good. There is nothing wrong with them.

What you are insinuating is not always correct that if you model stuff you'll get a better result. Sometimes PID is more then enough and in fact better since your model can get arbitrarily complex and you don't have any tools to deal with that behavior. It's a bit snobbish that you need to have math and all the shenanigans. The rest of the manufacturing world disagrees with your premise that is very common in academic circles.

[x86x87]

Maybe you need a controller for how you interact over here?

Nobody was insinuating anything. I was pointing out that going past an intuitive understanding may be a harder leap than expected.

[ilayn]

How about you don't kick off with a lol then? Maybe you set the tone of engagement.

[nightowl_games]

I've done character controllers and AI with rigid bodies and I just tune damping values and naive functions until it's good enough and I achieve great results. Ie: players doing backflips with torque, AI steering and slowing to a stop within a small radius of a destination.

It's just a game!

[zubspace]

Simple example: You want to control torque with a PID to reach a target angular velocity. What if the player suddenly negates the target angular velocity (by going from left arrow key press to right arrow key press for example).

How do you handle the I and D term then?

What if the player can also use a gamepad and go from left to right gradually?

The fundamental problem is that the error accumulates while you try to reach the target. But then the target suddenly changes. Do you just drop the previous error? Do you create an upper bound on the error? Or something else? This is the question no PID post ever answers.

I don't say, that this is impossible, but just that PID's in this context are harder to use than they first appear.

[applied_heat]

Yes drop the “previous error” by setting the integral to zero when the setpoint changes such that the sign of the error changes.

If the derivative is on the error when the setpoint is changed all of the sudden the error is increasing instead of decreasing so it works as desired.

There are many books on control systems that cover different forms of the PID algorithm and what applications they suit.

I prefer the velocity form or double derivative form for the simplicity of managing the integrator and applying real world limits on maximum and minimum outputs and rate of change of output. I basically never need such a fast response that it is worth bothering with D.

A mathematics professor solved the differential equations governing my processes so now I can calculate the exact correct gains for critical damping and simulate the response for different limitations such as input sensor resolution and measurement delays. It is wonderful.

[krisoft]

> How do you handle the I and D term then?

You recalculate the D term every iteration, so it doesn’t matter?

The ugly truth about the I term is that in practice people very often leave it at zero. We sometimes call these controllers PD controllers.

Especialy in a game where you don’t have sticky actuators and miscalibrated sensors this is usually more than enough for hapiness.

[nightowl_games]

Seems like you misread my post. I don't use PIDs. I just tune random functions until the forces are good enough.

PIDs sound cool though. I should try em.