7 ms·

Possibly useful: A header-only proportional-integral-derivative (PID) controller. https://github.com/RhysU/helm https://github.com/RhysU/helm

• stefan_ 3y ago
  It's a nice theoretical implementation but few practical examples would be found using floating-point math, running as they are on systems that don't support it.
  • sgtnoodle 3y ago
    Maybe that was true up until the 90's, but doing anything but floating point for a PID is just a waste of development time, even on an 8-bit AVR.
    • jbay808 3y ago
      Absolutely not! The choice of fixed- vs floating-point for a controller should be based on domain knowledge of the problem, and the right choice may vary depending by operation. For example your PID's integrator needs to accumulate a running sum. Fixed-point addition is well-behaved for addition, with only the need to deal with overflow (which can be dealt with; the integrator likely needs to saturate anyway to respect a physical limit, so you choose a datatype that doesn't overflow before then). Floating point addition has much more nuance; adding a small value to a large one can result in no change at all to the output, causing a controller's small-signal transfer function to change based on the system state. This can lead to all sorts of unexpected bad behaviour, like vibration and limit cycles, which might happen only in edge cases after the controller has been running for some time, and so are very hard to catch in testing. There are also many cases where floating point is the clear winner, but again, you should think about it and not just choose floating point reflexively because it seems easier. Its convenience makes it very easy to sweep errors under a rug, and they always come back to haunt you later.
    • sheepshear 3y ago
      I assume you're referring to applications where it's not important to do proper floating/fixed point design in the first place? Or do you have some other way of avoiding numerical problems?
  • the__alchemist 3y ago
    Cortex-M4s/M7s/ESP32s/Nordics are cheap and ubiquitous. They all have hardware floats. M0s are available fast enough to do soft floats.
  • Espressosaurus 3y ago
    I've had about as many floating point PID implementations running on the attached core of an embedded ASIC as I have fixed point implementations (running fully within the hardware). Both are useful.
  • nullc 3y ago
    Even where the hardware is available, it can be harder to prove properties about the behavior of the floating point versions. It's no fun when everything turns to NaNs because of surprise cancellation in subtraction.
    • the__alchemist 3y ago
      Check every division.
    • junon 3y ago
      And isNan is a BAND and JNE effectively. It's cheap.
      • nullc 3y ago
        NaN is only one of the most obvious. Catastrophic precision loss from cancellation can leave you oscillating for no obvious reason.
        • patrec 3y ago
          Isn't the only reason you might run into this with floating point but not with fixed point for the same task that you basically "waste" 10 bits or so on range which you could instead have used on precision (assuming all quantities of interest can be sufficiently well represented in a single range)?
          • nullc 3y ago
            Also because when you have operations with very differing range you they end up computed at the worst precision level without regard to the effects. In a fixed point implementation you would make the two scales different types and when doing computation involving both get an opportunity to preserve the precision. E.g. by dividing down the larger range one first rather than letting the smaller range one get crushed by the worst precision Often these issues can be handled with very careful floating point order of operations (so long as -ffast-math isn't used...) but since its all implicit it's very easy to get wrong, while in fixed point you're forced to confront the scalings of different variables explicitly.
  • junon 3y ago
    This isn't true at all. We use them in scientific firmware all the time. Arduinos, pis, cortexes, you name it.
  • Philpax 3y ago
    Not all PID controllers are destined for embedded. They’re quite useful in gamedev, for example.
    • ghotli 3y ago
      If you're willing to expand on this, color me interested.
      • sho_hn 3y ago
        I encountered an example recently in a Star Citizen changelog entry about the PID controller governing the interaction of an NPC character pushing a trolley, and tuning the constants for it. My reaction was a similar "Huh - makes sense".
      • waste_monk 3y ago
        I'm not a gamedev myself but have played a few games (Stormworks, Garry's mod with Wiremod, From The Depths, at least one or two more which I can't think of the name right now) that allow PIDs to be used in player-designed contraptions. Quite useful for building stabilised gun platforms and things. I would be sure there's plenty of applications for PIDs in a game engine itself - a quick search turns up things like self-balancing physics objects, making game entities turn to follow a mouse pointer, and so on.
        • junon 3y ago
          GMod has built-in PIDs now??
          • waste_monk 3y ago
            The Wiremod add-in for Garry's Mod does, alongside with programmable chips and all sorts of neat stuff... although having a look (it has been a number of years...) the PID controller was in the "extras" extension to Wiremod.
      • Karliss 3y ago
  • galangalalgol 3y ago
    Is this still true? It seems like most IoT stuff has chips that easily eclipse the capabilities of my Amiga1000 and are 32bitbwith hardware floats. Looking around, I'm having trouble finding something that isn't a 32bitHF in my house. Possibly my Keurig machine? Even using digital instead of an RLC implementation in a coffee machine seems like a waste, but I'm old.
    • TD-Linux 3y ago
      Cortex-M4/M33 are pretty widely deployed on microcontrollers with control hardware, for example the STM32G4 and Reneasas RA series. There's still a few reasons not to use it, though. Saving and restoring the float registers adds interrupt handling overhead. If you can fit into 16 bit integers, you can also use the 2 way SIMD instructions and get at least double the throughput. Finally, floats themselves have a lot of footguns. You have to be very careful about propagating NaNs etc into control loops. It's also really easy (in C) to accidentally promote to double.
    • goku12 3y ago
      Even if you could, floating point may not be the best representation for control applications. There are a lot of problems, like NaN, as somebody pointed out. Even neglecting that, a fixed point representation may be better. You don't need the fine precision or large range that floats have (we get those using exponents). Signal variations below a certain threshold are drowned out by the noise floor. Signals in control systems also have an expected maximum bound. At other end, stability calculations based on quantization noise may be difficult with floats, since their least count changes with exponent. Fixed points have a uniform LC throughout its range.
    • not_the_fda 3y ago
      Most PID applications are not IoT. Many use a cortex M0 which doesn't have hardware float support, or non Arm, even 8bit. When you are selling millions it pays to use the cheapest part you can get away with.
      • galangalalgol 3y ago
  • cellularmitosis 3y ago
    I find this hard to believe. Even a humble arduino can do 34,000 software float divides per second. https://gist.github.com/cellularmitosis/506c878631f806cfe6f8c76d43b21c11 https://gist.github.com/cellularmitosis/506c878631f806cfe6f8...
    • distract8901 3y ago
      It can but that doesn't mean it's a great idea. Unless your chip has a hardware floating point unit, you're stuck using software float operations. They're slower, though not extraordinarily so. But the main drawback is the floating point library can massively inflate your code size to the point that it no longer fits in available memory. If you can get away with it, it's fine, but when you can't it's a huge problem.