Update: Thinking about it for just a moment, I realized the print quality would likely be higher if I printed in “launch position”. Doing so would greatly improve the wing quality while also, hopefully, improving tail quality in that there would be fewer really small layers (that cause the print head to slow way down, causing blobbing). The disadvantage would be a lot more support material, especially around the engines, and, thus, a potentially difficult, if not destructive, post print cleanup.

And it worked! I only lost one control jet off the back during cleanup, even!

There are more photos of the final printed piece and of the print in progress in my Flickr feed (link goes to a photo in the middle of the set).

I remember watching the first Shuttle launch way back in 1981. If you’d told me then that I’d be casually printing a small copy of the Shuttle on my own personal 3D printer 32 years later, I might have thought you were crazy. Or, at 11 years old, I probably would have have asked, “Why so long from now?”

3D Printed Shuttle

NASA has kindly dumped a treasure trove of 3D models available for free download.

Obviously, these beg to be printed. Doing so is a matter of jumping through a couple of file conversion hoops. The files start out as Autodesk 3DS files.

Meshlab can be used to import said files and then export them to STL. You might need to do some mixup after. Using netFabb, I found several errors in the model’s geometry and fixed it. I believe Meshlab can do the same, but I’m not familiar enough with the tool

Slicing for printing is tricky. The models give zero consideration, no surprise, for 3D printing. In fact, they are entirely sub-optimal for printing. For example, the shuttle’s cargo bay is empty, leading to a bit of a support mess, and it would print much better if the wings sat flat on the print bed. Thus, even the simple Space Shuttle model has a curved bottom. You’ll probably want to enable support when slicing. Some of the models, like the lunar landers, are unlikely to be able to be printed using an extruded plastic printer without support material that can be dissolved away afterwords (i.e print in PLA or ABS with PVA support material.

As a first print, I sliced using Cura with 20% infill, 0.2mm layer height, and support material turned on. It actually turned out better than expected!

B47af8930ab8a169e37c95534ab9945e large

For the Teensy Blaster, I used a Teensy v2.0 board from PJRC. It is a tiny board containing a not-so-limited AVR chip (32K of flash, >2K RAM, 1K of EEPROM, and a slew of I/O pins) and a mini-USB port with the ability to be USB bus powered. Tiny. Versatile. And cheap at $16/board! $24 nearly gets you nearly 4x the memory and nearly doubles the I/O ports.

Today, I ran across Teensy v3.0 on Kickstarter. In pretty much the same sized package, the Teensy v3.0 features a 32bit ARM Cortex-M4 board with 128K of Flash(!!), 16K of RAM(!!), 2K of EEPROM, and a slew of I/O options. If that weren’t enough, it includes support for IR, a high quality audio interface, an optional real time clock, 4 DMA channels, and support for touch sensor inputs. And more. Much more. Holy cow! Truly, a nutty amount of computing power in a 1.4″ x 0.7″ package!

And it can be used from both Arduino and C.

So, yeah, funded. No brainer.

8170026945a0f0462acf148cc38b69f5 large

Then, at the thank you for funding this project page, there is a thing you might be interested link that leads to the Digispark.

Wait. What? A board barely bigger than a USB connector that features an Arduino compatible CPU with multiple I/O pins, 8K of flash, PWM on 3 pins, ADC on 4 pins and many many different shields?!

For $8-$10 / board?!

Sign me up! (And I did!)

In my “spare” time (hah!), I hack on Arduino a bit. Mostly because there are tons and tons of 3rd party libraries that make hacking up a hardware solution mostly a bit of soldering followed by gluing together some pre-made software bits. The Arduino IDE is Java based and… well… not terribly awesome (to be fair — it isn’t awful, just quite lacking beyond the basics).

With the release of Mountain Lion, most Arduino installations were broken. Fortunately, this can be fixed by grabbing the latest bits from here and there.

  • Grab the latest for Mac OS X
  • Run it and it’ll insist on installing the latest Java VM. Do so.
  • If you use Teensyduino, grab the latest installer and install it. If Mac OS X (rightly) complains that the software is from an unidentified source and can’t be opened, you can ctrl-click on the installer, select “open” and it will present the option to bypass the security check. Do so, but not without a bit of misgivings.
  • Install the latest FTDI driver.
  • If all went well, you should see the device show up in /dev/ as something like /dev/tty.usbmodem12341.

    After nearly 5 months, the first run of herbs in the Aerogarden were finally tired to the point of no longer useful (I started with AeroGarden Gourmet Herb Seed Kit (6-7-Pod) and it worked really well — way more than $18 worth of fresh, tasty, results).

    Pods Installed (Basil Sprouted!)

    One of my goals with the Aerogarden is to gradually replace all the pieces until I’ve effectively created a homebrew Aero-Hydro solution that will eventually integrate with our atrium’s pond (fish poo fertilizer FTW!), use LED lighting, and, hopefully, be an interesting conversation piece.

    The next obvious step was to replace the seed pods and baskets. The seed pods/baskets are the one piece that needs to be replaced with each planting. The baskets — white plastic things that fit in the holes on top of the Aerogarden — can be mostly reused, but the original design is obviously optimized for cost, not effectiveness (they don’t actually fit correctly in some of the holes!). The seed pods, themselves, are little bundles of seeds in growing medium; Aero’s are good quality, but relatively expensive and the seeds are of unknown variety (i.e. generic curly parsley and not some particular strain).

    At left is the current phase; seed pods and growing medium replaced with Basil sprouts showing some signs that it is working!

    After a while with the Ultimaker, a series of notes on the various things one can do to tune the 3D printing experience.

    Some of this is specific to the Ultimaker, but most of it is not. Much of this is personal preference and, frankly, there is probably some stuff in here that is wildly sub-optimal. But, hey, it has worked for me and it worked better than it did when I started.

    I.e. feedback and corrections are quite welcome!

    First, a note on consumables. I have stuck with PLA (polylactic acid) exclusively. It is a plant derived material that requires a lower temperature and is quite thoroughly non-toxic (there are lots of articles about fume-venting ABS… not so with PLA). As well, when I screw up — which is often — the resulting garbage is biodegradable (however, I’m donating my “pile of PLA” to someone who needs input into a PLA scrap-to-usable-filament project).

    PLA also doesn’t require — though it can benefit from — a heated print bed. ABS, the other common material, seemingly really does (though one can live without).

    Thus, these tips are optimized to PLA.

    These tips are also somewhat ordered in the steps that they should be done to maximize benefit. In some cases, that is because the earlier steps have a bigger ROI than later ones. In others, it is simply that the later steps really require the earlier steps first.

    Evolution of a Design


    When I started this, as can be seen in the image at left, the case was two parts that fit together in a semi-complex manner (Actually, the very first version just had a little plastic square that covered the AVR, but nothing else). It was hard to print with any quality and, frankly, the front looked awful. So I simplified it such that the IR LED could stick out a small hole, as seen in the middle. But then it dawned on my that the translucent plastics might just be transparent enough to IR that no hole was needed at all.

    And sure enough, it just worked!

    Thus, the design is now even simpler (assuming you have translucent filament).


    Both professionally and as a couch surfer, I’ve found myself interacting with a great deal of devices that can be controlled via infrared remotes. Often, remotes lost in the depths of a couch or misplaced in the fridge (it happens). Clearly, I needed an IR blaster that could be controlled from a computer to both eliminate the “losing the remote” problem and to integrate control of multiple devices into a single UI. Conveniently, Arduino micro-controllers with integrated USB ports are commonly available and quite cheap. Adding an IR LED to an Arduino is trivial, as the ever popular TV-B-Gone project demonstrates.

    Thus, the Teensy IR Blaster was born. I started with the Teensy v2.0 AVR-based micro controller that includes USB support. It unofficially supports Arduino using the Teensyduino extension. To this, I added Ken Shirriff’s IRremote library modified fro the Teensyduino environment and

    Out of the box, the Ultimaker shipped with a stable, but relatively ancient, version of the firmware. This, combined with the stable, but relatively ancient, version of ReplicatorG available from the Ultimaker site was sure to produce useful prints with a relatively minimal of fuss, but nothing that remotely approaches either the blazing speed or amazing quality possible from this printer.

    To achieve that requires some significant upgrades to the software stack. And, in some cases, it requires outright replacing some of the pieces entirely.

    While this writeup is specific to the Ultimaker, there is a lot of general knowledge in here, and the various bits of software are largely universal to a number of printers. When my Printrbot shows up, I’ll write a revised version specific to that printer while generalizing this a bit.

    Note that this is all moving very quickly. When I first wrote this, it required about 3x more steps and was considerably more fragile. It is improving rapidly! However, there is still a long way to go before any of this is easy.

    Note: At the time of writing, you need to perform both of these upgrades simultaneously. ReplicatorG really does’ want to talk to the new firmware (of course, by the time I write this, it’ll likely be fixed).

    This is a short video of the printing of an Octopus I’ve been using as a test model. The Ultimaker is printing at 250% of normal speed. I started at 100% for the first layers until a solid base was created and then cranked the speed to 250%. It could go faster, I think.

    At that speed, the quality of the print suffers a bit. I believe, is mostly due to slop in my belts. I need to print some belt tensioners which will take up the slack nicely.

    The print quality is both better than the out of the box experience and tons faster.

    This is the result of a combination of upgrades:

    • Upgraded the Ultimaker’s firmware to the latest beta version. It has all kinds of features that enable both higher quality and higher speed prints.
    • Upgraded to using Pronterface to send the G-Code to the printer. It allows for communication at 250kbaud and doesn’t periodically pause like Replicator-G does if you forget and leave the temperature monitor panel open.
    • Moved to using SkeinForge-48 as the slicer.

    All three of these tasks were a downright pain to do. All three have been written up in another post.

    For now, enjoy some 3D printer music….


    Some build notes from my Ultimaker build experience…..

    Overall, it took me roughly 4 days to build the Ultimaker. The first two days were a couple of long stretches and the last two were much shorter. Tuning the device to yield usable prints has taken a bit more time, too, and I still have a long ways to go.

    At left is a print made using the default firmware with relatively default settings in ReplicatorG. Stringy as heck, but otherwise quite good! Software and hardware tuning are reserved for another article.

    This is some random build notes from the build and roughly correspond in order to the assembly instructions themselves.

    By and large, assembly was relatively straightforward. The only real disaster I had was with the cooling fan used on the extruder. When I tried to mount it, it shattered — literally disintegrated into dozens of pieces — in my hand.

    The Ultimaker arrives in a surprisingly small, heavy, box. No surprise; wood is heavy and the Ultimaker is largely a wooden box with some very crafty electronics built into it. Frankly, the laser-cut wood based construction is, in and of itself, a bit of a hobbyist kit revolution. Wood is cheap and very strong, yielding kits that can be quite precise, extremely durable, and still remain accessibly affordable.

    Random notes below the fold…

    Throughout the anticipation of the delivery of the Ultimaker (4 to 6 weeks — as are pretty much all 3D printers these days!) and the week of assembly (another post), I spent a bunch of time researching software and otherwise attempting to grok the toolchain without a tool to apply the chain to.

    In short, 3D printing requires a slew of tools and the tools are… ugh… unrefined, if not downright user abusive. Not that this comes as a surprise. Affordable 3D printing is a very new market and it’ll take a few years for the science to be nailed down enough that an easy UI can be wrapped around it.

    And it is moving rapidly. Thus, if you are reading this anywhere after about 3 to 6 months from now, it is likely that the landscape has changed.

    As well, this is a decidedly Mac OS X centric / Ultimaker centric view of the world. I’ll likely update again in a month or so after I’ve set up the Printrbot.

    To drive a 3D printer, there are quite a few stages of software that are employed. In the maker world, there are generally multiple answers to any given stage in the overall chain. If you are working with a commercial printer, it is likely that the stages closest to the printer — the driver, assuredly, maybe more — are fixed.