PID controllers require more tuning, which becomes harder with more latency in the system. They are more susceptible to integral windup: https://en.wikipedia.org/wiki/Integral_windup
They require an MCU, whereas a bang-bang controller can be done mechanically (or with analog components), keeping them simpler.
I would concur, especially with control devices that can turn on to heat.
Although, a lot of more basic controllers only handle binary states for input. I'd argue that a calibrated (bang-bang with thermistor/thermocouple) on an analog control would be much easier to tune and easier to implement. That way, the hysteresis could be dynamically tuned out of the system with a constant input to stabilize losses.
I did something similar to that with I experimented with a peltier heated 3d printing bed. I fried the first batch of peltiers since I wasn't aware they *HATED* binary states, and would die in a crack of the ceramic matrix. My next round was to implement "Using PWM to Generate an Analog Output" ( https://ww1.microchip.com/downloads/en/Appnotes/90003250A.pd... )
Since when does a PID controller need an MCU? You can build one out of op-amps, resistors, and capacitors. Whether you should is a different story.
(I’ve never been convinced that a PID controller really makes sense for a heater where there may not be much natural cooling going on, but that’s a different story.)
> Drone PIDs are hard, and a lot of that to do with the quickly moving targets which is not the case in many (most?) scenarios PIDs are used.
You can write a flyable PID in a few lines, and a full PID in a few more. Set the error term to the range-mapped input - angular rate measurement, for each axis. (Assuming you have the control inputs, gyro/acc inputs, and motor output IO setup)
I'm talking industrial PID and other consumer goods. Drones are just one place PIDs are used, though probably the most frequent place for interaction for software engineers on HN.
As for them being hard for drones... PIDs are built into the software which is easy enough to write but the drone characteristic is specific to both the configuration of the drone and the flight preference of the pilot. It can be hard to find an optimal PID setting for both, which is where it seems that most people are finding PID settings to be difficult.
Indeed, most modern approaces to controlling drones use other more advanced techniques that (ab)use the computational power of modern MCUs, PIDs are used only near the actuators to keep the motor torque within an optimal range or things like that. For the flight trajectory fancy drones use things like model predictive control combined with convex optimization algorithms to avoid obstacles very reliably (see for ex. [1]).
And, circling back to your point about where to use the PID: I think that perhaps we need to split things more finely: The fancy part of that video was WRT overall flight trajectory planning. (See also your obstacle avoidance descriptor). You might still use PID for the angular rate control (or not), while feeding those target rates from a higher-level algorithm that commands attitudes, flight paths etc. (Or flight path -> attitude -> angular rates etc)
I went down a rabbit whole of constant angular jerk and time-to-correct targets for a while, but wasn't able to get it working.
So, there are multiple layers involved for something like in the video. A properly-tuned PID works well for manual angular-rate controls, and autopilot commands that reduce down to angular-rate controls. But PID tuning can be tricky; and/or can be done automatically; or replaced with something more sophisticated.
In what way?