Archive for the ‘PID’ Category
You may remember the espresso machine that was on kickstarter earlier this year. You know, where they asked for $20k and got $369k instead?
Well it looks like the PID Library has made it on to another wild Kickstarter ride. This time it’s with the Nomiku: an ingenious sous-vide solution. I’m a sucker for forehead-smack ideas, and this product is a great one. Rather than sell you an entire bulky unit, the Nomiku a small, easy to store, device that clips to a pot you already have.
The icing on the cake is that I know these guys. I met them at makerfaire last year and they’re great; very passionate about this stuff. Actually, it seemed like they were just passionate. about everything. I’m really glad that this is working out for them!
This is what I love about working on base-level components. I only have to do the work once, and then I get to see it crop up in tons of cool stuff. It makes me proud to know I helped those people along a little. I can only imagine how the Arduino team feels.
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.
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?
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)
I haven’t done many PID posts in the last couple months. Rest assured I haven’t been sleeping on that front. I’ve been working closely with RocketScream on an OSHW project that should be released soon. Here are a couple teaser pictures to (hopefully) get you drooling.
As I post this I’m on my way to Makerfaire NYC. I’ll have this with me if you’d like a closer look.
There have been many sous vide projects floating around the tubes recently. The one I’m showcasing here was first brought to my attention by the Adafruit blog. I found out from the developer that he was in the midst of a full write-up, so I held off on posting. Now that the write-up is done, we can see that he’s put together an impressive little project.
Great documentation, excellent implementation of the PID Library, delicious, delicious meat? What’s not to love? I’m also looking forward to subsequent posts, where he promises to show “how to calibrate the beast ”
Recently there was a suggestion posted to the Beginner’s PID Series. The contention was that if you solve things in the Laplace domain, it specifies a different way of executing the Integral Term. Rather than looking at the sum of error for THIS point, the commenter suggested, you should look at the sum from the last point.
So the current code is this:
/*Compute all the working error variables*/ double input = *myInput; double error = *mySetpoint - input; ITerm+= (ki * error); if(ITerm > outMax) ITerm= outMax; else if(ITerm < outMin) ITerm= outMin; double dInput = (input - lastInput); /*Compute PID Output*/ double output = kp * error + ITerm- kd * dInput;
and the suggestion was this:
/*Compute all the working error variables*/ double input = *myInput; double error = *mySetpoint - input; double dInput = (input - lastInput); /*Compute PID Output*/ double output = kp * error + ITerm- kd * dInput; ITerm+= (ki * error); if(ITerm > outMax) ITerm= outMax; else if(ITerm < outMin) ITerm= outMin;
I had never seen it done this way, but I figured I’d give it a shot. The test I devised was a simple setpoint step, followed by a ramp down.
With the controller set at the default sample time, the difference was imperceptible. To try and highlight the difference between the two methods, I decided to bump up the PID sample time from the default of 100mS to 5 seconds.
Ok so here we can see a clear winner. The existing PID code performs better than suggested, probably because the integral term gets to react to process changes 5 seconds sooner. But just to make sure I wasn’t missing anything, I decided to do another test. Instead of a setpoint change, I induced a load change in the system.
Once again, the existing PID code performed better, handling the load change more quickly.
So the verdict? While this was a fun excersize, I think the results are clear. I’ll leave the code as it is.
The reason I created the PID library was to make it easier for people to integrate PID control into their projects. Surprisingly, it’s actually happening! I’m starting to see a lot of really cool implementations out there. As a result, I’ve decided to start a new category of post: the PID Showcase. These are projects that make me feel that all that work was worth it.
So… here’s the first one: the Reflow Oven Controller Shield from RocketScream.com
It integrates all the components necessary to turn a toaster oven into a reflow oven. Thermocouple Chip… LCD… buzzer… awesome. But the part that I love is how they completely owned the PID part of this project. Look at this reflow curve:
They made use of setpoint ramping to get the heating rates just right. The output is phenomenal. This came out of a toaster oven: