I hadn’t too much time for developing Pleasant3D lately. Sorry for that!

However, I did some work on Pleasant3D in the last year:

• Better (more performant) versions of the Quicklook  plugins (for previewing STL and GCode files in the Finder)
• An experimental implementation of a DAE file import plug-in
• Experimental support for printing directly from Pleasant3D (still not functional, but the infrastructure is there…)
• Support for different devices (3D printers, CNC mills etc.)

… and some other stuff.

Unfortunately, I currently don’t have the time to develop, test and stabilize the current code on my own in order to release a new binary version of Pleasant3D.

So starting today, I open source the complete code base of Pleasant3D:

https://github.com/zaggo/Pleasant3D

(The slicer plugins of Pleasant3D were open source from the beginning. I’ll mark the old open source BitBucket repository as obsolete.)

I’d be very happy, if some of you 3D-printing (or CNC-milling) Mac developers out there would help with the further development of Pleasant3D!

Please note, that the published sources aren’t in a fully tested state. As far as I can tell, the project builds and runs after a clean ‘clone’. Be sure to use Xcode 4 and to choose “Pleasant3D/32-bit” as build scheme.
However, there seem to be some issues with the Quicklook generators in this version (they seem to run in Debug mode, but crash when running in the real world…).
Also the OpenCL slicer seems to be broken in the current version.

The  stable version of Pleasant3D (v2.0) is (and will be) still available as pre-built binary release: Download Pleasant3D

Here’s the code of teardrop module from the Libs.scad library. I changed the Libs.scad code on my computer to use the polygon code instead of whosawwhatsis’ projection code, since the projection code takes forever to render in CGAL mode.

module teardrop(radius=5, length=10, angle=90) {
	$fn=resolution(radius);

	rotate([0, angle, 0]) union() {
		linear_extrude(height = length, center = true, convexity = radius, twist = 0)
			circle(r = radius, center = true);
		linear_extrude(height = length, center = true, convexity = radius, twist = 0)
			polygon(points = [
				[radius * -cos(-45), radius * sin(-45)],
				[radius * -cos(-45), radius * -sin(-45)],
				[(sin(-135) + cos(-135)) * radius, 0]],
				paths = [[0, 1, 2]]);
	}
// This code take forever to render:
// teardrop module by whosawhatsis <www.thingiverse.com/thing:3457>
// Creative Commons LGPL, 2010.  I added default values and resolution code
/*	rotate([0, angle, 0]) union() {
		linear_extrude(height = length, center = true, convexity = radius, twist = 0)
			circle(r = radius, center = true);
		linear_extrude(height = length, center = true, convexity = radius, twist = 0)
			projection(cut = false) rotate([0, -angle, 0])
			translate([0, 0, radius * sin(45) * 1.5])
			cylinder(h = radius * sin(45), r1 = radius * sin(45), r2 = 0,
					center = true);
	}*/
}

The problem with teardrop holes is, that they need considerably more space. This can be a real problem, when the main object is limited in size for one reason or another.

For example, this is a ball bearing retainer:

When simply using teardrops instead of cylinders for the holes, the result would be this:

As you can see, the larger footprint of the teardrop shape becomes a real problem with the larger holes in front and back of the retainer. In this case, the structural stability might still be good enough, since the smaller center bore  is still closed at the top. But often teardrop holes just aren’t an option unless you significantly re-design the main object (and usually make it larger).

Well, it turns out there is another option after all:

Introducing the Flat Teardrop

The solution is simple. Although overhangs > 45° are a problem in 3D printing, reasonably short bridges aren’t!

So why not just cut off the dead space in the tip of a teardrop?

I wrote a new module in OpenSCAD, called flatteardrop. This module is derived from the original teardrop module in Libs.scad:

module flatteardrop(radius=5, length=10, angle=90, luck=0) {
	$fn=resolution(radius);

	sx1 = radius * sin(-45);
	sx2 = radius * -sin(-45);
	sy = radius * -cos(-45);
	ex = 0;
	ey = (sin(-135) + cos(-135)) * radius;

	dx= ex-sx1;
	dy = ey-sy;

	eys = -radius-luck;
	dys = eys-sy;
	ex1 = sy+dys*dx/dy;
	ex2 = -ex1;

	rotate([0, angle, 0]) union() {
		linear_extrude(height = length, center = true, convexity = radius, twist = 0)
			circle(r = radius, center = true);
		linear_extrude(height = length, center = true, convexity = radius, twist = 0)
			polygon(points = [
				[sy, sx1],
				[sy, sx2],
				[eys, ex2],
				[eys, ex1]],
				paths = [[0, 1, 2, 3]]);
	}
}

Since the top is cut at radius height of the theoretical cylinder inside the teardrop, it might be a problem when the bridged part at top of the flat teardrop sags a bit during printing. This might happen when the bridge gets longer, i.e. on larger teardrops.

As a countermeasure it’s possible to add a little bit height to the cut “for luck”. To do so, set the value of the luck parameter to the additional height. However, the default value of this parameter is 0 and simply can be omitted in most cases.

The module makes use of the resolution function of the Libs.scad library. If you add the flatteardrop module to this library (as I did on my computer), it just works. If you plan to use the flatteardrop module separately, you might want to comment out the line

$fn=resolution(radius);

or set $fn to a fixed value (e.g. 36).

https://github.com/zaggo/PleasantMill

As you might guess from the version number, this firmware isn’t finished yet and probably still has some bugs to fix (help’s highly appreciated, BTW :).

As mentioned before, I use a Seeduino Mega and some Pololu A4983 stepper motor drivers.

One recent addition on the hardware side was a 24V/6.3A power supply. I also glued some small heat sinks on the A4983 chips.

Then I increased the current to 1.68A, the max current, the stepper motors (SY42STH47-1684B) are rated for. Driving the steppers at 24V/1.68A enabled me to dramatically increase the top feedrate for the machine (about 1800mm/min instead 600mm/min). Unfortunately, the little heat sinks weren’t enough and the thermal shutdown of the A4983 kicked in after a few minutes. So I had to lower the current to about 1.2A again (and the max feedrate to 1100mm/min).

As you can see in the image at the top of this page, I’m still using a messy bread board for the electronics. As soon as I have the feeling to know the main issues with the whole shebang, I’ll build some kind of Seeeduino Mega shield, of course.

Right now, I plan to put the stepper motor drivers on a separate daughter PCB, somehow integrated in some kind of big ass heat sink.

If anyone knows a good way to cool the tiny A4983 chips on the Pololu breakout boards, please let me know!

—

The just published firmware release contains code for the G2/G3 commands (arcs) and for several drilling cycles (G81, G82, G83, G85, G89 and G73, see video below).

The drilling cycle commands also recognize the L (loop) parmeter, which is nice to drill multiple holes in a row. Just switch to incremental positioning (G91) and use something like G81 X10 Y0 Z-12 R1 L7 to drill 7 holes along Y=0mm, 10mm apart and 12mm deep. Don’t forget to switch back to absolute positioning (G90) after :)

I also added the M6 (tool change) command. Of course, I have no automatic tool changer (and I don’t really plan to build one). On the Pleasant Mill, the M6 command pauses the G-code processing and displays a message on the LCD, containing the tool number, requested by the G-code program and waiting for feedback from the operator.

For example, the line

M6 T3

results in

I even wrote some code to save a “tool database” in the Seeeduino’s EEPROM, so the LCD would say something like “Insert tool: 3mm drill bit”, but this code doesn’t work properly yet.

Both, the drilling cycles and the tool change command are showed off in the following video:

And here’s the G-code, I sent to the machine during the video:

G21
G90
G0 Z3
G0 X2 Y2 ; Simple drilling cycle
G91
G81 X6 Y0 Z-8 R2 F300 L4
G90
G0 X2 Y7 ; Drilling cycle with dwell
G91
G82 X6 Y0 P500 L4
G90
G0 X2 Y12
G4 P1000 ; Peck Drilling cylce
G91
G83 X6 Y0 Q2 L4
G90
G0 X2 Y17; Peck drilling cycle, high speed
G91
G73 X6 Y0 Q3 L4
G90
G0 X2 Y22 ; Drilling cycle, slow retract
G91
G85 X6 Y0 L4
G90
G0 X2 Y27; Drilling cycle with dwell, slow retract
G91
G89 X6 Y0 P500 L4
G90
G0 X0 Y-25 Z19.5 ; Tool change position
M6 T2 ;  Change Tool
G0 X2 Y32
G91
G81 X6 Y0 Z-5 R2 L4
G90
G0 X2 Y34
G91
G81 X6 Y0 Z-5 R2 L4
G90
G0 X0 Y25 Z13.5


—

I also implemented the commands G54 to G59. Each of these commands switches the machine to one of 6 “work coordinate systems” (WCSs). These are 6 user defined “zero positions”, saved in the machines EEPROM.

To define a WCS, use the “Jog XZ”, “Jog Z” and “Jog AB” functions in the mill’s UI (“Cartesian”) to move to the desired position. Then choose the menu command “Set WCS” to save this position in the EEPROM. You also can view already saved positions with the “Show WCS” command.

When writing G-code, you can then use one of the commands G54 to G59 to load the previously saved positions as zero positions.

In order to get the whole WCS stuff working, you need to “home” the machine once (either by sending the G28 command or by choosing “Find home” from the Cartesian menu in the UI). This is necessary to give the firmware an idea of the machine’s absolute zero position. If you try to save a WCS position in the UI or to use G54 to G59 without homing, an error is displayed.

It was aluminum.

It turns out, that my mill is able to cut aluminum. But man, that was loud!

The quiet before the storm:

Tools & Settings:

• 2mm aluminum
• Dremel 400 Digital
• Tungsten carbide 3mm mill bit
• 20000 RPM
• Feedrate 100 mm/minute
• .3 mm depth per cut
• lots of cutting oil

I guess I could increase the feedrate a bit, but I should lower the depth per cut to probably .2mm

All in all, I’m very exited. But really: It was LOUD!!

[Update 05/14/11]

And here’s the inevitable video:

Don’t get me wrong, I’m still happy with printing 3D stuff in plastic. As matter of fact, I used far more printed parts during the build of my new CNC mill than I had planned in the beginning. But there are quite some situations, when printed plastic just isn’t the best choice material for an object.

That’s where usually laser cutters, plasma torches and water jets come in. Or, in case of a poor, lone DIY warrior, a home made CNC mill.

The plan

I looked for an open source CNC machine which would be able to mill wood (mostly plywood and MDF), acrylic and maybe even aluminum.

The internet is full of DIY CNC mills, but only a few people publish plans and/or enough technical data. There are some kits, but I didn’t want buy a kit, since I already had many parts for a CNC mill lying around (high torque stepper motors and Pololu A4983 motor drivers from a dead end project of mine, waiting for recycling, a bunch of precision rods from old scanners and printers). Also I love to plan and build stuff by myself.

Eventually I stumbled upon the website of the Mantis CNC mill. This mill is open source and kits are available for sale.

I liked the compact size and use of wood for the main construction. However, there are several things, I don’t like:

• For my taste, there’s way too much glueing involved in the construction. Although this makes the build process easier, glueing stuff together with epoxy means also there won’t be any chance for adjustments later. They even glue one of the stepper motors to the back of the machine….
• The Z axis construction is made for a -glued in- custom spindle. No easy way to attach other tools, like a Dremel or maybe an extruder on the machine.
• The Mantis’ work area was a little bit too small for me.
• The whole construction and plans are in imperial measure. No offense, but I’m a very happy user of the metric system.

That said, I used the Mantis plans as base for my own, custom plans.

I slightly scaled the parts up and “rounded” them to the next metric measure. The 10″x4″ build platform became a 300 x 150 mm build platform and so on.

In order to keep track of the changed parts and the construction as a whole, I constructed the machine in a 3D application:

I also changed the construction of the Z axis in order to provide a more versatile base for different tools. The Z stepper motor sits on top of the Z axis in my construction (and isn’t glued to the back of the X axis plate).

Bodywork

Based on my 3D drawing, I wrote a BOM for the wooden parts. I use 16mm MDF and the whole material cost less than 10€ in my local hardware store (already cut to size).

Here are some pictures from the build process. Building a LCD (and a micro joystick switch) directly into the machine was part of the plan from the beginning.

Problems

One thing, I wasn’t sure about were the bushings. Since they uses bush bearings in the original Mantis construction, I ordered some sintered bronze bushings together with the acme threads.

Despite all precautions and match drilling all holes for the precision rods, I wasn’t very happy with the results when first assembling the x axis.

The slide was much too sluggish (see following video). So I decided to go back to proven mechanics and designed Mendel-style linear bearings for all three axis.

Since there isn’t too much room for the bearings (especially at the Z axis), I designed the printed ball bearing retainers as low profile as possible. The “inner” ball bearings are halfway sunk in the base plate.

This not only keeps the assembly as low as possible, but also guarantees the same height reference for the fixed bearings (the axle sits directly on the plate). All upper bearings are adjustable.

Here’s a short video with a comparison of both bearing styles. I guess, bush bearings are only usable when the whole construction is manufactured by CNC machines…

I published the STL files for the linear bearings on Thingiverse.com: http://www.thingiverse.com/thing:8480

Build platform

The build platform is (same as in the Mantis construction) a sandwich of two boards of the same size. The linear bearings and the acme rod are attached to the lower board. That way, the upper board can be easily replaced in case of an accident or maybe if a heated build platform is needed in the future.

I drilled a grid of 4mm holes in the upper board, each with its own drive-in nut. The grid then can be used to easily attach a workpiece on the build platform by using scew clamps or directly bolting the piece down.

The tool

As spindle, I attached my Dremel to the Z stage. I printed an upper and lower clamp on my Makerbot Cupcake, which hold the Dremel gentle and tight on the Z axis.

The electronics

For a while I planned to use RAMPS electronics from UltiMachine to drive the three steppers (and any extruders in the future). But ever since I looked in the store, the PCB was out of stock. In addition to that, I already had a Seeeduino Mega lying around, which I liked to use for this job and which is not shield compatible with the Arduino Mega. Finally I needed some custom connections for the LCD, the joystick switch and the emergency stop button, I built into the mill.

So I decided to go for my own, custom RAMPS shield for the Seeeduino Mega.

Based on the open source design of the UltiMachine RAMPS electronics, I started to design the new Seeeduino shield.

The board design is far from finished yet! Meanwhile I started to put the electronics onto a big breadboard on the backside of the mill.

As soon as the circuits are working correctly and the schematics are fully tested, I’ll manufacture the final shield PCB. But this might still take a while and I’ll definitely write at least one other blog post about this topic.

So far, the breadboard contains only three Pololu A4983 boards for the steppers, as well as connectors for three endstop switches and some additional components for the LCD and switches.

I currently use mechanical endstops for the three axes. I’m still not sure if I’m happy with these. Maybe I’ll switch to opto endstops later, since I have the feeling, that they are much more accurate.

The software

I used the newest version of the RepRap firmware as a starting point. I very much like the acceleration feature for the cartesian system. Originally I thought I’d use the RepRap firmware more or less unchanged and just add code for the LCD and switches.

But it turned out quickly, that I’d need to make bigger changes to the firmware in order to implement some features I planned (e.g. jogging with the joystick switch etc.).

One thing came to another, I started to re-write some parts, added some code in the G-Code parser which is important for milling (G2, G3, G81 etc.). Then I started to throw out obsolete code and to redesign other code in order to implement stuff more object oriented…

Long story short, the firmware tuns out to be more based on the RepRap firmware than to be just an extended variant.

I have plans to go even further and to try to implement G41/G42 functionality (Cutter Radius Compensation). In order to do so, the G-Code parser needs a lot changes and extended functionality.

In order to keep my focus on the functionality important for milling, all 5D-extruder support is currently removed from the firmware. I’ll definitely add this code again later, when the milling code is working.

I’ll also publish my version of the firmware as open source, of course. But I’ll need some more time to further stabilize and clean up the code  before that. Please stay tuned.

The movie

Finally, here’s a video of the mill’s first real cut and a short demo of the LCD menu system of the current firmware:

His homemade resin-based 3D printer seems to work really, really well.

According to his blog, he plans to somehow publish documentation and maybe even kits with the required parts for his 3D printer design.

I can’t wait to get my hands on one of these printers :)

1. No bubbles, no troubles

When printing with a heated build platform, it turns out, that Kapton tape is a great surface for ABS printing. The only problem is, that normal Kapton tape is rather fragile and easily get ripped off the build platform when removing printed parts. Therefor I use 10x10cm sheets of glass with a layer of Kapton tape on top as exchangeable build surfaces on my heated platform.

One problem is to get the Kapton tape on the glass, well aligned and without bubbles.

The trick is to use soap, water and a scraper. Here’s a short how-to video, I made:

2. Snap-in, not snap-off

I recently designed a printable Tricopter:

One special thing of this design is, that the Tricopter is foldable for easy transport:

For this, the printed center piece (below the plywood platform) has two snap-in hinges for the front arms:

I’m sure, there are several other applications for this technique.

Speaking of technique, slightly off topic, but maybe also interesting:
A “mechanical disadvantage” of Tricopters versus Quadrocopters is, that in order to countervail the unbalanced torque of the three propellers, one of the motors needs a tilt mechanism (Quadrocopters use two CW propellers and two CCW propellers to self balance the propeller’s torque).
This tilt mechanism is usually one of the more complicated parts to build on a Tricopter. Here’s the tilt mechanism I designed for my printed Tricopter:

One frequent type of question was about the stability and rigidity of printed objects.

Of course, there is the normally pitched answer “it’s the same stuff Legos are made of”. And (at least in case of ABS printing) this is certainly true. But almost anytime I give (or hear) this answer, I think: … well, it depends.

Although 3D printed objects are likely out of ABS, there is one huge difference between 3D printed objects and injection mold Legos: Printed objects are layered. So when it comes to rigidity, they are much more like wood than like “atomic” Legos.
That’s why I prefer to compare printed objects -regarding rigidity- with wooden parts instead Legos.

In my experience, it’s quite important to consider the layer orientation of a printed part during the design process. When building wooden objects, a stressed span is less likely to fail if tension is applied along the grain, rather than across the grain.
The same is true when printing 3D objects.

Of course, sometimes you need to compromise in order to print a complex object in one piece. And this might be ok as long as the “against the grain” parts aren’t stressed too much.
But sometimes it is way better to split a complex object into two or more parts and bolt (or glue) them together after printing, in order to get the layers into the “best” orientation for each part.

One of many examples of compound objects (to gain more rigidity) is the Adrian’s geared Mendel extruder:

Technically, it woudn’t be a problem to print the base plate, the stepper motor retainer and even most of the gear retainer as one single, complex object. But then you’d have to decide in which direction you’d print the object. Besides some restrictions due to overhangs, the main problem would be that either the base plate or the motor & gear retainers would loose a lot of their rigidity when not printed “with the grain”. By breaking down the complex object into 3 or 4 parts, the whole thing not only gets easier to print, but also the assembled full object gains a lot of stability.

However, I recently began to wonder, if I could do some test to measure the strength of similar printed objects, depending on the orientation they are printed in.

To measure the rigidity and strength of printed objects, I decided to print a basic shape in different print orientations and then use a rack to rip the objects apart, measuring the needed force.

Given a basic “monolith” shaped object, there are three different ways to print:

1. laying down on it’s face:

This would be the “natural” orientation to print such an object for most of us 3D printer operators. Besides much less problems with printing the infill, this orientation also puts the “grain” along the widest span of the object.

2. laying on it’s side:

Although this changes the order of layers, the grain still runs along the widest span. So (besides likely more problems with printing the narrow infill), the resulting object should be as rigid and stable as an object printed laying on it’s face (1.)

3. standing upright:

Printing a tall object this way usually means trouble. Not only the longest side of the object will be against the grain (and thus more likely to chip off under load), it’s also harder to print thin, tall objects on a FDM printer like the Makerbot or Reprap for several reasons.

But sometimes there’s no good way around printing a tall object in upright orientation,…

4.

And then there was a fourth way to print a tall object. I had this idea a while ago and really wanted to finally try it: The object is still printed in upright orientation, but using some kind of “interlock” between the infill layers. See the following cross sections:

Instead of using a normal infill like this:

… the infill would printed in an alterning pattern like this:

As far as I know, this kind of layer-crossing infill isn’t supported yet by any slice’n'dice utility out there.

In order to generate Gcode for the test objects, I wrote a little Perl command line tool. This script generates Gcode for “2001: A Space Odyssey” style monoliths in three different types:

“Mode 0″ – The object is printed laying down on it’s face (see above “1.”) with a normal 100% infill.

“Mode 1″ – The object is printed in upright position with a normal 100% infill.

“Mode 2″ – The object is printed in upright position with the above described interlocking “bonding infill”.

If you’d like to play around with the script, you can download it from thingiverse: http://www.thingiverse.com/thing:5069

Calling the script without arguments, shows a short usage text:

zaggo$ ./monolith.pl
Usage: ./monolith.pl --mode <mode> --out <output path>
[--lw <layer width>] [--lh <layer height>] [--fr <feedrate>]
[--lenf <length factor>] [--depf <depth factor>]
[--heif <height factor>] [--preface <path to preface file>]
Mode: 0 = flat
      1 = high
      2 = bonded
Size: lenf/depf/heif are factors of layer width
Defaults are 10 x 40 x 90 (1:4:9)

There are two mandatory attributes:

–mode defines the orientation of the object on the build platform and the infill algorithm.

–out sets an output file for the generated gcode.

So the simplest way of using the script is like this:

./monolith.pl --mode 1 --out outfile.gcode

This would generate a file (“outfile.gcode”), containing the gcode for the default monolith, printed in upright orientation with a normal 100% infill.

You can easily adjust the gcode for your needs (or your printer’s specific extruder specs) by using the optional arguments. For instance, use –lh to set a custom layer height (default is .45mm) or –lw to set a custom layer with (in mm! If not set, the script automatically calculates the layer width by multiplying the layer height by 1.4).

Since the script doesn’t generate any startup code or temperature settings, you probably want to use the –preface argument to insert custom preface gcode at the beginning of the output file. I simply use the standard preface gcode file, I also use as preface in my Skeinforge settings.

I started with objects in the default dimensions of the script and a simple unmotorized version of the rack. But it turned out, that the printed objects were way too stable for the tests and that using the rack with a wrench was really time consuming.

The pocket balance I use to measure the pulling force has it’s maximum at 25kg (about 56 lbs). During my first tests, the Mode 0 monolith chipped off at 20kg.

The Mode 2 monolith was even more stable: I was able to crank the rack up to it’s 25kg limit without breaking the monolith (with it’s grain across the pulling force!). I let the whole setup sit for a while, just to check if the monolith would withstand the pulling force for longer than just a few moments.

After about 5 to 6 minutes the rack finally snapped. But it wasn’t the monolith that cracked, it was the wooden base, holding the monolith…

So I printed the monoliths a little bit thinner (using the –depf argument).

Because of the thinner shape (and the resulting issues with still hot ABS in lower layers), the printed objects had slightly different dimensions (although the gcode used the same dimensions). I decided to adjust the –depf argument for each mode, so the resulting objects had the same dimensions after printing. On my Makerbot, this resulted in printing the Mode 0 monolith with –depf 8, the Mode 1 monolith with –depf 6 and the Mode 2 monolith with --depf 5.

With these settings, I got the 3 types of monoliths, all with the same thickness of 4.6mm.

I also improved the rack by using an electric screwdriver as motor:

The monoliths were clamped to the other end of the rack:

With the thinner monoliths and the motorization, the rack worked much better and smoother:

Here are the results of my tests:

Mode 0: 14.5kg

Mode 1: 8.5kg

Mode 2: 12kg (!)

As expected, the Mode 0 object was the sturdiest.

I’m still surprised, how stable the upright printed object (Mode 1) was. I guess, using more common infill rates (like 15 or 20%) lowers the rigidity of such objects immensely and the results would be much more than I expected. Printing the objects with an 100% infill seems really to make sense if you need a maximum of stability. I guess it would be great if there was a way to manually define parts of an object to be printed with a higher infill rate than the rest of the object.

A great success was the test of the Mode 2 object. Interlocking the infill really seems to make a big difference. The object was much closer to the stability of the Mode 0 object than the Mode 1 object. Maybe there will be a way to generate such type of infill with Skeinforge in the future…

During my tests, I ripped apart a lot more monoliths than just the three above. Although the other objects weren’t all the same size and thickness (and thus not easily comparable to the above standardized objects), the reults of the other tests went all in the same direction (Mode 0 strongest, Mode 1 weakest, Mode 2 much stronger than Mode 1).

I’ll probably try some skeinforged monoliths, with different infill rates, in the future…

Finally, here’s a short video of my tests:

Anyway, since I’m relatively new to flying radio controlled stuff, I still crash the thing more than I fly it. Recently things really went out of control and I crash landed my Quadrocopter in a forrest, 450m away from its start position.

About 4 hours search time later (on the next day), my brother in law (who was part of  the little search party) found the crashed thing. Of course, since the (LiPo) batteries were (still) connected for about 24 hours, they were fully discharged (and thus damaged). Also the Quadrocopter’s props and frame were damaged. But on the bright side, we were able to recover all motors and the (rather expensive) electronics, including the FPV related stuff (AV transmitter, camera).

Although it might be possible to repair the broken original frame, I decided to rebuild the Quadrocopter from scratch. And of course, I printed all custom plastic parts on my MakerBot :)

There aren’t many parts needed for a Quadrocopter’s frame: It’s more or less just four arms with the motors attached to one end and a center plate on the other end, forming the typical X shape.

The center plate is also where most of the electronics are mounted: the Quadrocopter’s gyroscope controller (which stabilizes the whole thing when airborne), the battery pack and, of course, the RC receiver. The four ESCs (Electronic Speed Controllers), driving the brushless motors, are mounted directly on the arms (i.e. nearby the motors).

In my case, due to flying the whole thing with FPV, there is need for some additional electronic components: an AV transmitter, a camera and the OSD (On Screen Display), consisting of three  separate PCBs. The OSD isn’t mandatory for FPV, but it’s quite handy to see the battery’s remaining capacity, the Quadcopter’s GPS position and height and such, overlaid in the transmitted video.

So here’s the design I came up with:

For the arms, I use 10x10mm wood profiles. It’s cheap, it’s light weight and it’s tough!

The four arms (each 25cm long) fit into the holes on the center plate. They are hold in place by  M3x25mm bolts, for which I drilled a 3mm hole through each arm after inserting them into the center plate. The exact positions of the holes are already printed into one side of the center plate.

The motors are bolt to small platforms which are attached to the outer end of the four arms:

I used M3x20mm nylon bolts (not printed…) to secure the motor platforms.

The separate holders for the additional electronics (AV transmitter and OSD main PCB) are attached to their respective mounting places on the side and the back of the center plate. The RC receiver and the Gyroscope/Main controller are mounted on top of the platform with double-sided adhesive tape (the Gyro with additional rubber foam padding to reduce vibrations):

The FPV camera is mounted on the front of the center plate. Above it (on the left side in the following picture), the OSD’s GPS receiver is mounted on the top of the center plate (double-sided adhesive tape):

As mentioned before, the ESCs (which control the brushless motors) are mounted directly on the arms. So is the RC receivers additional antenna unit:

On the bottom side, you can see a x-shaped structure. This holds the third (and final) PCB of the OSD, containing the current measurement unit which allows the OSD to measure and display up to 50A current. The x-shaped holder and the velcro tape for later holding the battery pack are bolt down to the center plate with help of the four M3x25 bolts (see above).

Well, that’s about it, so far:

The feet in the above picture are currently simply four pieces of 6mm aluminum pipe. I plan to replace these by 6mm carbon rod, with nice, printed landing plates:

Unfortunately, these aren’t ready, yet. I’d like to build these with some kind of suspension in order to soften rough landings. But I’m still in process to design a simple, light weight and effective way to build this…

That leaves me with a last important question:

Will it blend fly?

The whole Quadrocopter, including the full FPV equipement, battery pack and preliminary feet weights only about 650 gramms, which is well under the theoretical maximum flying weight (including payload) of the original Gaui 330XS hardware.

Unfortunately, it’s raining outside, so I couldn’t test it in the wild. But I couldn’t resist to do a short hovering test in my living room. You must know, that my living room is rather small and stuffed with furniture, so it’s kind of hard to do test flights there, especially for a not-so-experienced pilot as myself.

But see for yourself:

Well, this looks promising!

So far I’m quite happy with the results of 3D printing structural parts for a Quadrocopter. The parts are quite sturdy, yet light weight. And if  I’ll brake any part of the Quadrocopter in the future, the replacement is always just a quick print away!

Of course, I’ve published the designs of the printed parts on Thingiverse: http://www.thingiverse.com/thing:4812

I need a tripod stand for my iPhone 4.

Fortunately, there’s a nice design for one of these, ready for download on Thingiverse: http://www.thingiverse.com/thing:4335

A minor problem with this object is, that Bradley Rigdon, the creator of this design, owns a couple of Dimension 3D printers. Since these professional printers automatically print with support material, large overhangs and such are no problem for them. And there are some large overhangs in the iPhone 4 tripod design…

It’s no secret, that the standard MakerBot Cupcake doesn’t have a second extruder for printing support material. Nonetheless, some people (including yours truly) recently started experimenting with Skeinforge’s built-in support stucture feature. It turns out, that these support structures don’t necessarily need a second extruder with dedicated support material.

Keen to experiment, I turned on the support feature in Skeinforge and sliced the downloaded STL (BTW, which needed resizing by factor 25.4, since the original STL was exported in inches).

In the relatively old version of Skeinforge, I still use for several reasons (v2009-11-06), the support settings are part of the Raft preferences:

I printed the generated gcode in white ABS with my -more or less- standard MakerBot.

Removing the support structures after printing is relatively easy as long as you choose “Support on Exterior only” in the above settings.

Besides the relative coarse bottom side (which was likely more a problem with some Skeinforge settings unrelated to the support structure), the main problem with the printed object was the tiny wall on one side. You’ll know which wall I mean and what’s the problem when you compare the following picture with the object’s STL-screenshot above:

One thing I learned in the last year, printing 3D objects with my MakerBot: avoid printing single, tall, thin walls in upright position, unless you want to break them away later (intensionally or unintensionally…).

The missing wall on the above object broke away when I tried to attach the object to my iPhone for the first time.

The easiest solution for such a problem is usually to print the object “on its side”, i.e. rotate the whole thing by 90°:

But in this case you’d run right into the next problem: Now you’d need to manage the 90° overhang (marked with the red circle). In order to use Skeinforge’s support structures for that, you’d need to switch the “Support Material Choice” setting to “Support Everywhere” (instead of “Support on Exterior only”). But removing those “inside” supports after printing isn’t easy and the support structures would likely degrade the surface of the rail on the upper side of the object, critical for the fit of the iPhone.

My solution for the dilemma was to print the object only slightly rotated:

I started with 30° rotation from the upright orientation. Since I used support structures anyway, the weird angle shouldn’t be a problem to print. By choosing a rotation angle smaller than 45° the resulting additional overhangs of the former vertical walls shouldn’t need additional support (Skeinforge automatically don’t generate support structures for those overhangs; see “Support Minimum Angle” in the above settings).

By rotating the object, the iffy wall is now also sliced in an angle, which greatly improves its stability:

The print looked ok on first sight…

… and the stability of the printed object was indeed greatly improved.

But unfortunately, printing the 30° overhangs didn’t work very well:

I did some additional adjustments in the Skeinforge settings:

To give the curved lower part more plastic to stick on, I changed the “Thread Sequence Choice” (Fill Preferences) from the default value “Perimeter > Loops > Infill” to “Loops > Infill > Perimeter”.

I also reduced the rotation of the object from 30° down to 15°, which still should be enough to give the front wall sufficient stability:

This time, the print looked good:

The refined settings seem to do the trick.

Here’s the printed part after breaking away the support material:

And here’s a comparison of all three different prints (left to right: 15°, 30°, 0°):

The stability-improved vertical (diagonal) structure  (from left to right: 0°, 30°, 15°):

One more lineup (left to right: 0°,  30°, 15°):

And now to an interesting question: Does the part work?

See for yourself:

Looking good!

After the successful first test, I coated the whole thing with liquid rubber (Plasti Dip):

The rubber coating isn’t needed for grip (of the iPhone). But I thought, a little bit color couldn’t hurt. And also I like the rubbery texture on printed objects :)