Archive for January, 2012

Arduino PID Autotune Library

Saturday, January 28th, 2012

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

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.

Attribution

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 by William Spinelli I was good to go; My company had no problem with me porting and augmenting and existing open source project.

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.

The Theory

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.

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.

The method used in the library is known as the relay method. here’s how it works:

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.

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:

The Implementation

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

Problem #1: When to step?

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:


The 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.

Problem #2: Peak Identification

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:

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.

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.

When the flagged point switches from being a max to a min, or vice versa, the previously flagged point is confirmed as a peak.

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.

You should also know…

  • The number of cycles performed will vary between 3 and 10. The algorithm waits until the last 3 maxima have been within 5% of each other. This is trying to ensure that we’ve reached a stable oscillation and there’s no external strangeness happening. This leads me to…
  • I’m not the biggest fan of Autotune. I’ve often said, and still believe, that a moderately trained person will beat an Autotuner every day of the week. There’s just so much that can go wrong without the algorithm knowing about it. That being said, Autotune is a valuable tool to help the novice get into the ballpark.

flattr this!

Collapsible Knitting Needle

Sunday, January 22nd, 2012

I needed a break. I’ve been working hard on the osPID for several months, and I just needed to not look at code or control algorithms for a little bit. Nothing says “break” like an out-of-left-field project.


I only started knitting recently. Something that’s been bothering me about it is the length of the needles. They’re 14″ long, and I’ve been worried they’ll be bent while riding in my backpack.

It occurred to me that some sort of collapsible needle might be useful in this situation. Taking my inspiration from elastic tent poles, I got to work on my “not PID” project.

construction



The first thing to do was cut the needles in half. I used a pipe cutter for a nice clean cut, then cleaned up the seam with a drill.


With the needles prepped, I then used a lathe to make the supporting inserts.


I didn’t quite get the diameter of the inserts right, so I touched things up at the sanding station.



To get some decent springiness, I looped 3 rubber bands together, then doubled that over. This was pulled through the insert and locked in place with a piece of paperclip. I then super-glued the insert into the pointed half of the needle.



The last thing to do was anchor the other end of the rubber bands in a hole drilled in the cap.

Results



I’m really happy with how these turned out. The weight increase was negligible, and the seam is almost invisible. It puts a slight drag on the yarn, but nothing major, and I haven’t had any hangs yet. Also, because the halves are connected, you can fold the needle with your knitting on it, without worrying that things are going to fall off.

flattr this!

PID-Controlled Espresso Machine [PID Showcase]

Monday, January 16th, 2012

It is to my great delight that I can confirm that this Kick-ass, Kickstarting, Open Source Espresso Machine is using the Arduino PID Library.

They seem to be using a stand-alone commercial pid controller for at least some of the control. Perhaps this could be replaced with an osPID for a 100% open experience?

flattr this!

Introducing the osPID

Tuesday, January 3rd, 2012

About 5 months ago I sent an out-of-the-blue email to RocketScream electronics asking if they wanted to help me build an open source PID controller. It’s been far more challenging than I expected, but today I get to announce the release of my first open source hardware project: the osPID!

(pause for applause)

The goal was to make an open equivalent to the PID controllers you can currently buy. To do this we combined the Arduino, my PID library, some open-source auto-tune code, and RocketScream’s Reflow Oven Controller Shield.

In some areas we fell short: The case, for example, isn’t nema rated. If this thing becomes popular however, there’s no reason we couldn’t fix that.

In some areas we hit our mark: form factor, interchangable I/O cards, Autotune, onboard user interface.

…And in some cases we hit out of the park: It has a java trending/configuration Application, and it costs… wait for it… $85.

I’m really proud of the work we’ve done, and there’s more to come. Let me leave you with some videos I created to help introduce this release.

Beginner:

Intermediate:

Hacker:

For more information check out the (slightly rough) website we’ve created at osPID.com/blog.

Enjoy!

flattr this!