It’s been awhile, but I’ve finally gotten around to creating a WordPress plugin that I’m calling Thingiverse Embed.

Usage

The plugin has two features. First, you can embed a little “wallet-sized” view of a Thing into an individual blog post or page, with the Thing’s title, creator, image, description, and links back to Thingiverse with a simple shortcode:

[thingiverse thing_id="1046"]

Becomes:

Whistle by Zaggo

Better Living with MakerBot, Episode 2
You probably all know this situation:
You're supposed to ref a soccer game in less than 1/2 an hour and you cannot find your whistle. You're screwed!

But from now on you're out of trouble: Fire up your trusty MakerBot and print a new whistle in 26 minutes!

This object prints the pea right inside the whistle. Since the pea is connected to the rest of the object only at one tiny point, it's quite easy to break it loose after printing with a small screw driver or tweezers.

I probably pushing luck a little bit with bridging the top layer. So far I printed the whistle twice without problems.

As always, I added the object as .obj file (wavefront), which can be imported into AOI and Blender.

The gcode file is the one I used to print the whistle on the image. The gcode file contains an experimental raft with additional "blobs" on the second (interface) layer.
You might want to generate your own gcode file with skeinforge settings, tested with your MakerBot. Be sure to setup Skeinforge to create an (almost) watertight object, since the whistle won't whistle if it's full of holes...

[Update]
I added a second version of the whistle. "Whistle_v2" is an attempt to fine tune the object a little bit. My brother (he's a pipe organ builder) gave me some tips how to optimize the whistles mouth. Whistle v2 should start whistle with less airflow than v1 and thus be (somewhat) less loud. I also downsized the pea a little bit and changed the shape of the lanyard loop.

Whistle v1 is still available for reference and also since it's more "tested"...

Since you blow the whistle with your mouth, be aware of possible problems concerning "food safety" of printed plastic. See the blog post "For foodies out there" ( blog.thingiverse.com/2009/09/13/for-foodies-out-there/ ) for more information.

This thing brought to you by

The plugin also includes a Thingiverse Stream widget, for embedding streams like “Things I’ve Made” as a simple sidebar widget. It just needs to be configured with the title, the type of stream you want to use, the Thingiverse username (for certain streams), and the maximum number of Things to display.

You can see this example on the page for MakerBot 131.

Installation

You can download the latest version of the Thingiverse Embed plugin from the WordPress Plugins directory:

Or you can download thingiverse-embed-0.1 here.

To install it, unzip the archive, copy the thingiverse-embed directory into your WordPress install’s plugins directory (usually /wp-content/plugins), and activate the plugin.

You’ll probably want to check out the thingiverse-embed/readme.txt for more information about how to use the plugin.

In addition to the WordPress Plugins SVN repository, you can also find the code for this plugin in the wp-thingiverse-embed repository on GitHub, for your forking pleasure.

It’s been fun a fun weekend developing this plugin, as it’s my first WordPress plugin, and the first “serious” PHP I’ve written. Of course, it is filled with nasty HTML parsing and XPath tricks, and could use lots of cleanup, so please give me feedback if you use it!

The final step was to hack the desktop software that controls the MakerBot – ReplicatorG.

What is ReplicatorG?

From the ReplicatorG website:

[ReplicatorG] is the software that will drive your CupCake CNC, RepRap machine, or generic CNC machine. You can give it a GCode or STL file to process, and it takes it from there. Its cross platform, easily installed, and is based on the familiar Arduino / Processing environments.

For my purposes, ReplicatorG provides two things. First, RepG is a user interface for controlling the MakerBot hardware:

Second, RepG reads G-code files describing how to build an object, and transmits them to the MakerBot over the USB:

Of course, ReplicatorG is open source, and the code is available on GitHub! So, it was simple to clone their repository and start hacking on it myself.

Camera Control via ReplicatorG

While it was relatively simple to update the extruder controller firmware to make it camera-aware, ReplicatorG is a bit more complicated. My first goal was to hack a new “Camera” checkbox into the control panel. Whenever the box was checked, the camera would take pictures. Whenever the box was unchecked, the camera would be idle.

You can find the code required for these changes in this commit on GitHub, but I will try to briefly break them down here:

• Define a new machine. In the machines.xml.dist file, I defined an experimental MakerBot configuration named “EXPERIMENTAL – Cupcake CNC w/HBP and remote camera”. It is essentially a copy of the typical MakerBot configuration with a heated build platform, but in the <tool> definition, I also added a camera="true" attribute.
• Update the tool model. In ToolModel.java, I added code to represent whether the tool has an attached camera, whether the camera is activated, and how to parse the camera attribute out of machines.xml.
• Update the machine driver model. In Driver.java, DriverBaseImplementation.java, and Sanguino3GDriver.java, I added the definitions and implementations to triggerCamera() and stopTriggeringCamera(). This is the code that actually sends the TOGGLE_CAMERA serial command to the extruder controller, which I also defined in ToolCommandCode.java.
• Update the control panel interface. In ExtruderPanel.java, I added the code to draw a new label and checkbox named “Camera”, if the machine is configured for a camera, and to respond to check/uncheck events by calling triggerCamera() or stopTriggeringCamera().

Compiling and Running the new ReplicatorG

Compiling ReplicatorG is pretty simple, so long as you have a reasonable JDK environment and have Ant on your path. There are basically two steps:

1. Copy machines.xml.dist to machines.xml.
2. Run the proper dist-linux.sh, dist-mac.sh, or dist-windows.sh.

ReplicatorG will be compiled and packaged up into the dist/ directory in two forms: an installable package for the chosen platform, and an unpacked version that you can run directly.

Opening up my modified version of ReplicatorG, I selected the “EXPERIMENTAL – Cupcake CNC w/HBP and remote camera” profile from the Machine -> Driver menu, opened up the control panel, and was happy to see this:

After hooking up my camera to the extruder controller’s D9 port, and starting the Remote Button script on the camera, I was able to take pictures by quickly toggling the camera checkbox on and off. I could also leave the checkbox activated to make the camera take pictures continuously.

Automatic Triggering with G-codes

Being able to trigger the camera by hand is all well and good, but my goal was to take pictures automatically at the end of every layer. To do this, I needed to be able to embed camera trigger commands in the G-code for building each individual object.

Looking at the ReplicatorG G-code docs, and the (machine-specific) M-code docs, I chose two codes for working with the camera:

• M150 – Trigger Camera
• M151 – Stop Triggering Camera

I may have to change these in the future, as the main ReplicatorG development team claim G- and M-codes for other features, but these work for now.

Modifying ReplicatorG to accept these M-codes (GitHub commit here) was straightforward: update GCodeParser.java to recognize the codes, and call the appropriate triggerCamera() and stopTriggeringCamera() methods.

I could now construct a G-code file which, when “built” in ReplicatorG, would take a picture on demand:

M150     (trigger the camera)
G4 P700  (wait 0.7 seconds for the camera to activate)
M151     (stop triggering)
G4 P1300 (wait 1.3 seconds for the camera to finish)


Finally, it was time to edit up the G-code for the models I want to photograph.

Typically, G-code is generated by taking a 3D object in STL format and running it through the Skeinforge tool. Skeinforge is a set of Python scripts, which means it is not too difficult to insert your own code.

For now, however, I decided to make a simple hack using a Perl script I wrote called add_camera_events.pl. It works by looking for (</layer>) comments, which signal the end of a layer of printing, and inserts lines to:

1. Move to a standard pose (X=0, Y=-45),
2. Trigger the camera and wait for it to finish, and
3. Move back to the original position

You can find the source for this script in the add_camera_events.pl gist. The source for all of my changes to ReplicatorG are on GitHub, in the “schmarty-camera” branch of my fork of ReplicatorG.

And with that, the computer aspect of this system was finally done!

Wrap Up

Phew! So far I’ve hacked a camera, wired it to the MakerBot, updated the MakerBot firmware to trigger it, updated ReplicatorG to trigger it, and written a script to update G-code files with camera triggers at the end of each layer.

So… does it work? You bet! Stay tuned for more examples and a breakdown video of this whole project in the final post in this series!

• Part 1: Remote control camera with CHDK
• Part 2: Wiring it up!
• Part 3: Updating the MakerBot Firmware
• Part 4: Updating ReplicatorG [YOU ARE HERE]
• Part 5: Printing with the Camera!

While I know I should be finishing my MakerBot time-lapse camera series, I took some time for another project to play with some Processing. The above image was rendered in Processing, in real time in just couple of minutes!

Basically, I wanted to take a simple shape, defined by an SVG path, and fill it with images of 3D objects loaded from STL files. Specifically, many wonderful MakerBot-printable objects from Thingiverse!

After some Googling around, I found out that this problem is basically a space-filling problem, similar to an excellent Processing sketch named Scattered Letters by Algirdas Rascius, but with a twist.

The basic algorithm is:

• Load an SVG and render it to an off-screen buffer
• Set curr_size, the size that STLs should be rendered, to max_size
• Choose a random STL model, give it a random orientation, and render it at the current size to an off-screen buffer
• Try several times to place this model by giving it a random x,y position and checking it for a good fit:
  • Each non-background pixel of the model’s off-screen image should fit within the non-background pixels of the SVG’s off-screen image.
  • Each non-background pixel of the model’s off-screen image should NOT overlap with any non-background pixel of the main display.
• If a fitting position is found, render the model to the display.
• Otherwise, shrink curr_size by a step and choose a new model.
• If we drop below min_size, we should stop.

You can find the code for my sketch, which I call ThingiverseCollage, on GitHub. To make it work, you’ll need to follow the installation instructions in the README to install my (very slightly) modified version of the unlekkerLib for STL loading and rendering. I modified it to allow rendering to a PGraphics object, since it originally only allowed rendering to the main PApplet.

A note on STL files: unlekkerLib only loads STL files in the binary format. It chokes dramatically on ASCII STL files, such as those exported from OpenSCAD. I was able to use Zaggo’s excellent Pleasant3D to load ASCII STLs and re-save them, which converts them to binary STLs. As a bonus, Pleasant3D also allows you to orient objects in a way that will make them look most interesting when they are rendered down to 2D in the final image.

An example M.svg, as well as several objects from Thingiverse are included with the code to get started. To use your own SVGs, I have had good luck using Inkscape to draw or import shapes, and save them as the native “Inkscape SVG” or “Plain SVG” formats. Some files might require hand-tweaking; for example, if the width and height header values are something like "100%" instead of a pixel value.

There is also some simple configuration in the sketch to allow the export of PDF files. This is nice because the resulting PDF has full vector data, making it easily rescaled to any size you wish. Unfortunately, the current PDF renderer for Processing renders each triangle of each STL model as a separate path, generating very complicated vector output, which tends to bring Inkscape to its knees. I have had some luck with importing those files, rastering them out to PNG at a high resolution (e.g. 600 dpi), and using Inkscape’s “Trace Bitmap” functionality to re-vectorize them, though this requires some cleanup by hand.

Anyway, this has been a fun little diversion for me for the last couple of days. I hope that you folks find it useful! Post your awesome pictures in the comments, here!

The next step was to update the software on the extruder controller so that it could activate (and deactivate) the camera, in response to commands from the motherboard.

An aside on MakerBot communications

The MakerBot electronics ecosystem is comprised of 3 parts: your computer, the MakerBot’s motherboard, and the extruder controller board. Your computer talks to the motherboard via a USB<->TTL interface (such as this FTDI cable from SparkFun). In turn, the motherboard communicates with the extruder using another serial protocol, RS-485, over an ethernet cable. Finally, the extruder triggers the camera via the custom cable I made in the previous post.

The software for all three components is available on the indomitable GitHub. The software for your computer is called ReplicatorG, and the source can be found in the MakerBot ReplicatorG GitHub repository. I’ll talk more about ReplicatorG in the next post in this series. For now, we want to focus on the MakerBot G3Firmware GitHub repository, which contains the code for the motherboard (in the SanguinoMaster subdirectory), and for the extruder (in the ArduinoSlaveExtruder directory).

Browsing through the code, we see that these components use their serial interfaces to send packets, where each command is represented by a number. The commands for the motherboard can be found in the SanguinoMaster/Commands.h, and those for the extruder can be found in ArduinoSlaveExtruder/PacketProcessor.cpp.

To send a message to the extruder – in this case, to activate or deactivate the camera – we must create a packet for the motherboard. The HOST_CMD_TOOL_QUERY code allows us to send the motherboard a packet which it will then pass along to the extruder controller.

That’s great, because it means the motherboard part of this software hack is done!

In fact, we’ve already hacked the camera, as well, so we’re halfway there!

Hacking a camera into the extruder controller

Since the motherboard already does everything we need (passes along packets from the computer to the extruder controller), we only need to update the ArduinoSlaveExtruder code.

To get this to work, I ended up changing the following files:
ArduinoSlaveExtruder/Configuration.h.dist – added in configuration options for enabling the camera and setting the pin on which to activate it.
ArduinoSlaveExtruder/Extruder.h – added function definitions for turning on/off the camera.
ArduinoSlaveExtruder/Extruder.cpp – actually implemented turning on/off the camera.
ArduinoSlaveExtruder/PacketProcessor.cpp – implemented the serial command to toggle camera.

Building and uploading

If you followed the 4 links above, you’ll notice that they go to my own G3Firmware GitHub repository. You can download it yourself to play along by cloning the repository and checking out the ECv2.3rc0-camera branch.

To build the firmware and upload it to the extruder controller, we need some common development tools (make, in this case), and the Arduino development environment. With those things installed, we can compile everything by setting the ARDUINO_HOME environment variable to the path to our Arduino install’s java directory (e.g. on OS X this would be /Applications/Arduino.app/Contents/Resources/Java/), and simply run make.

Once the firmware has been compiled, we can upload it to the extruder controller by using the USB<->TTL cable that usually connects the motherboard to our computer. Plug the cable into the extruder controller, and run the make upload command. You’ll need to make sure that ARDUINO_HOME is set, and you will probably need to alter the Makefile to specify the correct serial port, and maybe to update the call to avrdude to include the path to the Arduino avrdude config file. You can see an example of that in this commit.

Once the firmware is uploaded to the extruder controller, the MakerBot is all set to take pictures!

… Of course, we still have no way to tell the MakerBot to take a picture, so stay tuned for that information in the next update:

• Part 1: Remote control camera with CHDK
• Part 2: Wiring it up!
• Part 3: Updating the MakerBot Firmware [YOU ARE HERE]
• Part 4: Updating ReplicatorG
• Part 5: Printing with the Camera!

It works!

Using a Canon SD300 with CHDK, and some firmware hacks, Makerbot #131 has learned how to make time-lapse videos of all of its prints!

More details (and a how-to!) coming soon! And thanks to Thingiverse user Starno for the bottle opener model in the video.

Like many MakerBot owners, I feel compelled to help spread desktop 3D printing throughout the world.  So, for the past several months, MakerBot #131 has been hard at work printing parts in 3D to make another 3D printer!

The Mendel is the second (and current) design for the RepRap project, whose goal is to create rapid-prototyping machines that can replicate themselves.  As an Open Source Hardware project, everything about the Mendel’s design is available online via Subversion, from the mechanical parts to the electronics schematics, to the source code for the device and its host machine.  Additionally, there is a fantastic community of very smart people who are constantly improving the design, trying new things, and helping others get their RepRaps working!

While the Mendel requires various hardware bits such as motors, electronics, nuts and bolts, etc., its structure is about 51% 3D-printed parts.  This works out to about 98 individual pieces that need to be printed, and represents a huge number of printing hours.

To get started, I used a .zip file full of the 3D STL files for these parts that someone very nicely prepared and uploaded to the MakerBot Operators group.  These files were from the 1.0 release of Mendel, so some of them ended up being out of date, and a few had issues that made them unprintable.  Thankfully, another kind MakerBot operator uploaded a fully prepared set to Thingiverse, so I could go there for a replacement whenever I found a part that wouldn’t print.

I started printing Mendel parts almost as soon as I got MakerBot #131 working.  Since I knew it was going to be a long process, I created a spreadsheet to help me track and estimate the time it would take to complete the build.  I also used some silly Javascript magic to display a progress bar on my MakerBot #131 page based on this spreadsheet data:

This hack was accomplished by building my own JSONP into some cells of the spreadsheet, and loading this content as Javascript using Google Spreadsheet’s plain text export capability.  The spreadsheet cells were set up like this:

Here, column N47 contains the “completeness” of the Mendel as a value of 0.0 – 1.0 in terms of number of hours printed so far divided by the expected number of hours total.  This data could be used on an HTML page with an “update_mendel_progress” function by loading it with a script tag:

<script src="http://spreadsheets.google.com/pub?key=t7SNwhng2GkZjKWwwSOl2VA&single=true&gid=0&range=B52:E52&output=txt"></script>

The range “B52:E52″ are the cells in my spreadsheet containing the JSONP call, and the “output=txt” option returns the data as tab-separated data, which Javascript is happy to parse.  The update_mendel_progress method on that page parses the number that is passed in, looks for an HTML DIV element with an id of “mendel_progress”, updates it to be the appropriate width, and displays the percentage completion.

At any rate, after a lot of tweaking, many hair-raising moments, a required upgrade with the MakerBot Heated Build Platform v2.0, and hours and hours of printing, the parts were finally complete!  I gave them to Matt Mets, a member of HackPittsburgh, and you can see the photos he took of the parts, above!

Despite some of the parts belonging to a slightly out-of-date design, Matt has been making progress on getting everything together!

You can follow Matt’s progress on his blog.

I’m very happy to have finished off such a large project with MakerBot #131, and I have a lot of plans for it in the future, so be sure to watch this space for more updates!

On Thursday, March 25th, I spoke about desktop fabrication and the MakerBot Cupcake CNC 3D printer at Dorkbot Pittsburgh. After some slides, I gave a printing demo with my Cupcake, Makerbot #131. You can find my slides above. I’ll post the video when it becomes available.

Like many enthusiastic makers, I recently got my hands on a copy of the excellent Make: Electronics book from O’Reilly.  It’s an excellent bottom-up, experiment-based introduction to electronics, but sourcing all of the parts required to complete each experiment can be an adventure.

Thankfully, the Maker Shed is now offering two components packs to help you work through the book without having to order from a half-dozen parts vendors!

Tonight at HackPittsburgh, Matt Mets and I made a little unboxing video for the first components pack, which you can see embedded above.  Let me know what you think!

CHDK’s remote USB trigger functionality works by detecting when it receives power over USB.  This happens when two wires inside the USB mini-B cable are connected to power: the red wire gets 5 volts, and the black wire gets connected to ground.

So, I chose to find somewhere on the MakerBot’s electronics to hook up these power and ground wires such that the MakerBot could control when the red wire receives 5V.  The MakerBot uses RepRap Generation 3 electronics, and let me tell you, the gen 3 electronics documentation is fantastic!  Unfortunately, the docs for the main motherboard reveal that there are some free I2C headers for connecting serial devices, but no free general I/O pins.

Luckily, the extruder controller docs show two free digital pins, conveniently broken out with 5V and ground connections next to them.  These are digital pins D9 and D10.  According to the docs, they are intended for hooking up servo motors, but they would absolutely work for my purposes!

The layout for pins D9 and D10 goes (from left to right): I/O pin, 5V, ground.  Since I wanted the data pin itself to provide the 5V, I chose to make a cable using a 3-pin piece of female header, soldering the red wire connecting to the I/O pin (on the left) and the black wire connecting to the ground pin (on the right).  The center pin has no connection.  You can see my “super fancy” cable on the left.

I know this post isn’t particularly about code, so stay tuned for the next parts of this series:

• Part 1: Remote control camera with CHDK
• Part 2: Wiring it up! [YOU ARE HERE]
• Part 3: Updating the MakerBot Firmware
• Part 4: Updating ReplicatorG
• Part 5: Updating Skeinforge

It recently occurred to me that, since the MakerBot is such a hackable platform, I could probably make nice time-lapse videos by taking a picture of each layer.  The idea is to have the MakerBot pose the object after each layer, and trigger a camera to take a snapshot.

When discussing this idea with fellow HackPittsburgh member Matt Mets, he recommended I try out a Canon camera with the Canon Hack Development Kit (CHDK).  Making a quick stop on eBay, I soon had an SD300 in my hands, ready to be hacked!

I started by figuring out which firmware my SD300 was running, which told me which version of CHDK to download for my camera’s particular model/firmware combo.  Using an SD card reader, I copied the contents of the CHDK zip file onto my camera’s SD card and followed the instructions to make CHDK auto-load when the camera starts up.  I also changed my CHDK firmware settings to set “Disable LCD off” to “[Script]“, so the camera wouldn’t shut down on its own.

Once CHDK was loaded and configured, I followed the USB Remote Cable instructions from the CHDK wiki.  The basic idea is to set Enable Remote to on, and load a script that is ready to handle USB remote events.  The one on the wiki page didn’t work as-is for me, presumably because my camera has half-shoot (i.e. focus and charge flash) and full-shoot (take picture) settings.  Here is the result that worked for me:

As the script says, I now turn the camera on in record mode, disable the flash, and start the script.  After that, the camera will automatically take a photo whenever I plug in the USB to my computer.

More from this series:

• Part 1: Remote control camera with CHDK [YOU ARE HERE]
• Part 2: Wiring it up!
• Part 3: Updating the MakerBot Firmware
• Part 4: Updating ReplicatorG
• Part 5: Printing with the Camera!
]]> http://creatingwithcode.com/howto/makerbot-cam-1-chdk/feed/ 2