{"id":1893,"date":"2012-01-28T14:41:56","date_gmt":"2012-01-28T18:41:56","guid":{"rendered":"http:\/\/brettbeauregard.com\/blog\/?p=1893"},"modified":"2024-06-03T15:50:45","modified_gmt":"2024-06-03T19:50:45","slug":"arduino-pid-autotune-library","status":"publish","type":"post","link":"http:\/\/brettbeauregard.com\/blog\/2012\/01\/arduino-pid-autotune-library\/","title":{"rendered":"Arduino PID Autotune Library"},"content":{"rendered":"

At long last, I’ve released an Autotune Library<\/a> to compliment the Arduino PID Library<\/a>. When I released the current version of the PID Library, I did an insanely extensive series of posts<\/a> to get people comfortable with what was going on inside. <\/p>\n

While not nearly as in-depth, that’s the goal of this post. I’ll explain what the Autotune Library is trying to accomplish, and how it goes about its business.
\n<\/p>\n

Attribution <\/h3>\n

For A couple years I’ve wanted to have an Autotune Library, but due to an agreement with my employer, I wasn’t able to write one. BUT! when I found the AutotunerPID Toolkit<\/a> by William Spinelli I was good to go; My company had no problem with me porting and augmenting and existing open source project. <\/p>\n

I converted the code from matlab, made some tweaks to the peak identification code, and switched it from the Standard form (Kc, Ti, Td) to the Ideal form (Kp, Ki, Kd.) Other than that, all credit goes to Mr. Spinelli.<\/p>\n

The Theory<\/h3>\n

The best tuning parameters (Kp, Ki, Kd,) for a PID controller are going to depend on what that controller is driving. The best tunings for a toaster oven are going to be different than the best tunings for a sous-vide cooker.<\/p>\n

Autotuners attempt to figure out the nature of what the controller is driving, then back-calculate tuning parameters from that. There are various methods of doing this, but most involve changing the PID Output in some way then observing how the Input responds. <\/p>\n

The method used in the library is known as the relay method. here’s how it works:<\/p>\n

\"\"<\/a><\/p>\n

Starting at steady state (both Input and Output are steady,) the Output is stepped in one direction by some distance D. When the Input crosses a trigger line, the output changes to the other direction by distance D. <\/p>\n

By analyzing how far apart the peaks are, and how big they are in relation to the output changes, the Autotuner can tell the difference between one type of process and another. As a result, different systems will get custom tuning parameters:<\/p>\n

\"\"<\/a><\/p>\n

The Implementation<\/h2>\n

This works well in theory, but real-world data isn’t very cooperative. The input signal is usually noisy, which causes two main problems.<\/p>\n

Problem #1: When to step?<\/h3>\n

Since a noisy signal is choppy, it’s likely that the trigger line will be crossed several times as the Input moves past it. This can cause mild chatter in the output, or if severe, can completely destroy things:<\/p>\n

\"\"<\/a>
\nThe way I chose to side-step this issue was to have the user specify a noise band. In effect, this creates two trigger lines. Since the distance between them is equal to the noise (if properly set) it’s less likely that multiple crossings will occur due to signal chatter.<\/p>\n

\"\"<\/a><\/p>\n

Problem #2: Peak Identification<\/h3>\n

In a simulated world, identifying the peaks is easy: when the Input signal changes direction, that’s a minimum or a maximum (depending an which change occured.) In a noisy world however, this method fails:<\/p>\n

\"\"<\/a><\/p>\n

Every noise blip is a direction change. To deal with this issue I added a “look-back time” parameter. It’s an awful name. If you can think of something better let me know.<\/p>\n

At any rate, the user defines some window, say 10 seconds. The Library then compares the current point to the last ten seconds of data. If it is a min or a max, it gets flagged as a possible peak.<\/p>\n

When the flagged point switches from being a max to a min, or vice versa, the previously flagged point is confirmed as a peak.<\/p>\n

\"\"<\/a><\/p>\n

Another way of explaining the look-back time is that a point will be identified as a peak if it is the largest (or smallest) value within one look-back into the future or past. Like I said: awful name.<\/p>\n

You should also know… <\/h2>\n