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.

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.

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)

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!

As per the request by the Arduino Team, I’ve moved the Arduino PID Library to GitHub. I’ve also used this opportunity to:

• Make the Library Arduino 1.0 compliant
• Release the Library under a GPLv3 License

The google code site will still be there, but there will no longer be updates.

But I had to try. I had a great idea: a fairly understated bottle opener with different color text embedded on each side. To the uninitiated it’s a neat little thing, but to people who know 3D printing its a: “wait, what? how did you do that?”

Well, here’s “how I did that.” It took a LOT of time. I didn’t call it “The Saturday Killer” for nothing.

The Basic Idea:

Create a bottle opener with some multi-color text on the side. I chose a reference to the classic Simpsons line: “Beer. Cause Of. Solution To. Problems.” I knew it would be a complicated task, but it turned out to be even more complicated than I thought.

Step 1: Generate a separate STL for each color

Having already created the opener in OpenSCAD, this step was straight-forward. Position text on the sides (more on the font later,)

…use the Difference Command to create an opener with word holes,

…and use the intersection command to get a text object to fill each of those holes.

Step 2: Split each STL into printable segments

For the different colors to dovetail correctly, they can only be printed 2 layers at a time. To split the objects from step 1 into two-layer slices I used the difference command to remove all but a 2 layer section.


I then Generated an STL, moved the cubes, and repeated until I had all my slices.

Step 3: !#@$%@#$: Realize that this is way more complicated than you first thought.

Because you’re interlacing two or more STLs, how things are skeined becomes really important. If you’ve got a curve in the Z direction, or a transition that happens within a layer, things may skein one way for one color, but in a different way for the mating color.

So I needed to do a LOT more work, mainly on the text. I tried using a stock thingiverse font at first, but all the rounded corners were a killer, and I couldn’t get it to size correctly to an even number of layers. So I rolled my own:

If you look closely you’ll see that the text is blocky. This was done to confuse Skeinforge a little as possible. There are no diagonals or curves anywhere, and all transitions and openings take into account the layer thickness, as well as the width of the extrusion. This way there’s less confusion about how much plastic goes where, and the different colors are more likely to dovetail correctly.

Another thing that I added was a solid bar behind all the text. This caused the tool path to be much more continuous, resulting in nice, smooth letters.

Step 4: Actually Print

Now that all these parts were created they just needed to be printed out sequentially, with the Z-offset being adjusted at the appropriate time. My main aha moment during this process was that you need to turn off raft when skeining all but the first print, otherwise you get way too much plastic laid down.

I -of course- learned this the hard way. I first tried printing 4 openers at a time, and by the time I got to the middle of the opener there was so much plastic that the extruder started to catch leading to misalignment.

I scrapped that print and started printing a single opener, realizing the raft thing just after I started. The results were much better:

Step 5: Enjoy

I’m really proud of this thing, but I spent WAY too much time creating it. Hopefully this quick post did a good-enough job of explaining the process. I wanted to share this project, but for my sanity I just need to be DONE.

opener: http://www.thingiverse.com/thing:12592
font: http://thingiverse.com/thing:12618

Up to this point, all my openers have been single color. But combine the fact that I’m jealous of the new dual extruder with the fact that Matt was my Best Man, and I decided that this time I would go the extra mile.

The procedure was straight-forward, and a huge pain in the butt:

• First I printed a blank opener in the base color
• Then I adjusted the Z-Height of the Thingomatic by 5.76mm (the height of the opener base)
• When I switched the color to blue and printed the tail, the printer deposited the plastic on the white base as if it were the build platform
• After switching colors AGAIN, I printed the W and the opener was done

This was a fairly simple multi-color design, but by breaking up the model ahead of time, this technique could be used for any part.

• I walk into the paella line on friday to hear Jimmie Rodgers say “…and there he is!” He’s talking with the Lower East Kitchen people, who use the PID library in their sous-vide kit. We wind up having a conversation over dinner that somehow winds up at plasma physics.



• I get to see the dual extruder thingomatic for the first time. The next morning on the train to the Faire I design a two color version of the pocket coin-op bottle opener. They take my design – the second 2-color part to be user-submitted to thingiverse – and print the hell out of it.



• While volunteering in the soldering area, I ask a group of people if they need help with their Brush Bots. There’s a tricky little step where you’re supposed to tape the the battery leads to the motor. A girl in the group, maybe 11 years old, tells me that they don’t need help; she has found a much better way to do it. And it is better: forehead-smack better. I have her teach another volunteer the technique, and when I come back 2 hours later everyone is doing it her way.

As you can imagine, I thoroughly enjoyed myself. I will definitely be doing this again.

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.

Because I did the model in OpenSCAD, it turns out to be really easy to create personal, one-of-a-kind gifts for my friends. In this post I’ll go through the steps I took to make an opener for my friend deWit. He skis, and he’s pretty good:

Ok, maybe he’s really good. Anyway, this has been my favorite skiing picture since it was taken a few years back. I thought it might be nice to capture some of this awesomeness in opener form.

Step 1: Get the image into Inkscape

The first thing I did was use the Windows snipping tool to copy into Inkscape just the section I wanted.

Step 2: Trace

Using the Bezier tool I then created a rough outline of what I wanted to print. This was going on a pretty small area, so I couldn’t get that much detail. Also important to note, I only used straight lines. No splines; they don’t seem to work in the upcoming steps.

Step 3: Save as DXF

Having served its purpose, I deleted the image to leave just the outline. I then saved the file as a DXF into my OpenSCAD directory.

Step 4: Import into OpenSCAD

This was the only painful part. Getting the DXF into OpenSCAD is a simple matter of calling the linear_extrude function. The problem is that the scale, position, and rotation of theDXF were way off. As a result I also needed to add scale, rotate, and translate commands to get the DXF stuff into place.

The code selected in the image above moves the part by [-89,86,thickness], rotates it 90 degrees, and scales by 70% on the x and y axes.

Once I was happy with the placement I exported to STL and moved over to ReplicatorG.

Step 5: Check the GCODE

Just because I drew this outline didn’t mean that that’s exactly what would get printed by the Makerbot. We’re working with a 0.5mm stream here, and some details may have been lost. Luckily you can visualize the gcode before the part gets printed.

In the Skeinforge profile, I made sure that SkeinLayer was turned on. This brings up a tool path visualization after the gcode is generated. Going to the last layer showed me the tool path I was interested in:

So here we can see that I lost some important detail. The ski-poles and backpack straps are missing. Time to tweak!

Step 6: Tweak

When I traced out the poles and straps I made them too thin. As a result Skeinforge just ignored them. By editing the nodes on my path I was able to make the tin spots a little thicker. I then repeated steps 3-5 and was rewarded with this:

OK! Printing time.

Step 7: Print!

Aaaand done. Pretty cool right? Maybe not as cool as hucking air off the wall at Kirkwood, but I’m pretty happy with the results. As you can see the detail is pretty poor, but that’s the nature of the medium and the size of the canvas.

This one is really pushing the limit of what you can fit into that tiny space. Here’s two more that I did that might give you a better idea of what can be accomplished if you choose an image that doesn’t require as much detail:

I’ve been having a lot of fun making these. It’s feels great to be able to give an inexpensive gift that’s personal and useful.