Friday, April 18, 2008

Syringe Stirling

I just realized I've never done a post on Stirling engines. How can that be?? Stirling engines are so, so awesome.

Stirlings are a member of the class called "hot air engines". As a group, hot air engines work by exploiting the expansion and compression of a gas when it is alternately heated and cooled. There's a good explanation/animation here.

(That particular engine is a "true" Stirling because of those green cross-hatches. That's a "regenerator" that vastly improves efficiency. However, most people call all generic hot air engines, regenerator or not, "Stirlings".)

Stirling engines are awesome for a lot of reasons, but one of the best reasons is that you can use any source of heat. This isn't an internal combustion engine that can use only one type of fuel that's later impossible to wean away from. This is an external combustion engine. You could use natural gas or wood or ethanol or solar energy or geothermal energy. In fact, some satellites/probes use Stirlings to convert nuclear energy to electricity. That's right, Stirling engines in spaaaaace.

Anyway, back to Earth and me. Because Stirlings are so simple and efficient, you can make even a really crappy one run fairly well. They are very common first projects in machine tool classes, for instance, whereas building an IC engine from scratch would be...challenging for a beginner. However, I'm not even at the level of machine tool student, so even that option isn't open to me.

Fortunately, lots of people have been coming up with plans for engines that don't require machining. A few years ago, I tried one that used water-based pistons but I couldn't get it to run. I really have no idea what the problem was, probably multiple things. More recently, I found some "plans" for a test tube Stirling. It took me a while to actually get it going, because it turns out that glass syringes are incredibly finely made and also very rare nowadays. I actually had to buy one on ebay as an antique!

I think the functioning is clear enough to explain itself. (Note: This is technically not a Stirling since I have no regenerator, although I could stuff a bit of steel wool in there to fix that.)

After viewing the video again, actually that might not be so clear. Here's what is happening:

  1. Candle heats air inside left end of test tube.
  2. Air expands, pushing "piston" up.
  3. Marbles roll to the left, displacing the air to the right.
  4. Air cools down, contracting.
  5. Pulling piston down and causing marbles to roll right.
  6. Air displaces leftward.
  7. GOTO 1

Saturday, April 12, 2008

The Etching Calculator [EDIT]

A lot of things, many of them new to me, went into this project. We have "regular" programming, "device" programming, a communication protocol, stepper motor control, motor mounting, power supply design and the mathematics of drawing an optimal line on a pixelated display. Some comments on each.


I originally thought this was going to be the hardest part. "The rest is just sitting at my computer desk and either typing or handling tiny pieces of electronics" was my opinion. In fact, I just cut a couple spacers and then improvised mounting plates from....I don't know what that stuff is. It's like countertop covering. In any case, this part took maybe 45 minutes. It helps that one vital component of the mount is masking tape.

Connecting the steppers to the knobs went through some iterations. The motors had gears on the ends, but of course the EAS isn't geared. I tried various ways of coupling one to the other, but wasn't satisfied. (This turned out to be a power supply problem, which I talk about below, but I didn't know that at the time.) In the end I managed to remove the gears--they are just press fit, so you can knock them off with a nailset and a hammer. The shafts of both motors and the EAS were almost all the same size, which in turn was just a tiny bit bigger than the internal diameter of some plastic tubing. I just cut a short length as a sleeve and voila.

Stepper Motor Control

Physical Computing was invaluable. In fact, reading about how to control a stepper was what gave me the original idea of controlling an EAS1. (The guts of that section are online.) I originally tried to do the entire thing with totally generic components, i.e. plain transistors, but I soon gave that up. I unbent enough to use 2 dual H-bridges. Still generic, but you can't get them at Radio Shack (but what CAN you get at Radio Shack?). This compacts the wiring and anyway the motors need more current than a regular transistor can switch.

If this were a real product, I would definitely build/buy a stepper control board. Finer control isn't an issue, but sweet mother of crap this thing is loud. I think a board can ramp the amperage up and down to give a smoother movement that won't shake the house down.

"Device" Programming

The Arduino libraries include an object-oriented Stepper control library, but it wasn't really suited to what I was doing. The most basic fact it cared about was the RPM. The most basic fact I cared about was how many steps to take. So I wrote my own SingleStepper library. That makes me sound alphanerdy, but seriously, it was just a matter of copying and tweaking the existing library.

Another reason for writing my own was that the Stepper lib left the current on even when the motor wasn't turning. That's great if you need the torque to stay on, but non-great if you have a limited budget of amperage. So my library also turns the power on only long enough to move the motor, then turns it back off.

Communication Protocol

The stock Arduino serial comm library only supports reading a byte at a time. WTF ARDUINO ? Naturally I need to send coordinates larger than 255. The solution is conceptually not too difficult: Send a two-byte int a byte at a time and reassemble on the other end. This actually took a couple days to implement, though, because Python (on the other end of the wire) isn't geared towards working with binary data and then there's the question of negative numbers, twos complement, endianness, etc.

Also, in the case where a lot of coordinates are being generated very quickly, the internal buffer can overflow and the EAS goes haywire. So each coordinate has to be ACKed by the controller before the next is sent.

Line Drawing

Here's another place where I didn't go 100% from my own bootstraps. I actually did start deriving this myself, but soon realized that there were going to be special cases and stuff and I wasn't interested in debugging those. Instead, I just adapted a classic algorithm. I didn't use any of the optimizations on that page, since they are more for a digital display than position control. I did make one optimization of my own, though, which was to not move each motor a single step at a time if I could take 5 steps with one and then 1 with the other.

Theoretically, one could turn both motors on at the same time but at different rates to draw diagonal lines. But even if I had the electric power to do that it's just too hard to attempt.

"Regular" Programming

This is so dead simple that it's really not that interesting, but just for completeness: Generate a series of coordinates (either by hand typing in your own or using some equation) and send them out the serial port.

Actually, I should explain that a bit. I chose to implement this as a display-like device. You give it a coordinate pair X,Y and it moves there. The Arduino handles everything after being handed the values. So for instance the sine wave is being calculated as a series of points in Python on my computer and then sent over to the microcontroller for plotting.

Power Supply

Of these all, the one that I figured out last was the power. The EAS isn't really made with computer control in mind. The controls are surprisingly sticky. At first I thought the coupling between motor and EAS was slipping, but I eventually eliminated that. The power supply I bought is rated up to 1.5A, but only puts out 5V, so the motors only drew about 700mA. Turns out that wasn't quite enough to consistently turn the knobs. By bypassing the power supply, I was able to feed 1A directly to each motor (one at a time) and that was enough.

It may still be a little short, though, because I still get the occasional glitch. But I don't have a wall wart that puts out more than an amp at more than 8V.


The steppers I got out of a broken inkjet printer. (I really lucked out on that, I later realized. Two other inkjets I disassembled had steppers but they were tiny.) I already had the mounting stuff and the Arduino, as well as wires, resistors, etc. I had to buy the H-bridges, the power supply, a heatsink and some power resistors. That probably adds up to $20 or $25. But I can and will reuse it all, especially the power supply, which was the most expensive single purchase.

Oh yeah, and I had to buy an EAS. But one of my design goals (as well as an instruction from my seven year old) was to not alter it beyond being used by humans afterwards. So I consider that a capital investment as well.

1Gave me the idea, but I wasn't actually spurred to do anything until I saw the EAS clock. The auto-erase functionality of the clock would be really nice to have, but I'd like to point out that the ability to draw curves is even nicer.

Per request, here's a closeup of a diagonal line. You can't see the "pixels".

That said, you actually can see the "pixels" in some curves. I think that's because of the (mathemetical) stepping involved in going from floating math to integer.

Tuesday, April 1, 2008

The Future Was In 1956

tps12 has been doing 3D photos recently and pointed me to a pretty simple tutorial.

Where the magic happens (spoilers ahead):

This looked really mind-blowing in Gimp, pretty great as a jpeg and not so awesome online. Good ol' lossy compression!