Modifying Marlin Firmware to work with a TandemB

In previous posts I built a prototype ‘TandemB’  which can be thought of as a 2D Delta printer in terms of its x and y-axis movement. This prototype could be moved about under its own power but that had no compatible firmware to drive it. In this post I cover the firmware modifications required to make the Tandem move using normal g-code commands. You can find a copy of this modified firmware here.

Modifying Marlin

Note: If you are considering doing any major modifications to firmware beyond just editing the config files I highly recommend exploring options other than the standard arduino code editor. I have been using the free community edition Visual Studio 2013 to view, modify and upload the firmware and it is a big improvement. Visual studio actively monitors the #define statements and then greys out any code that is not defined. ie: definitions that have been commented out. This makes skimming through the code much quicker as around 80% of what’s there is not in use for any one setup and so is greyed out. The tabs are also much easier to view, search and organise and I find the the compiling errors are simpler to find and diagnose. If you would like to use VS then you will also need VisualMicro for arduino support.

Marlin firmware was modified to work with my Tandem setup due to its compartmentalised nature and the fact that Craig Bossard had already started to make the very changes I needed. Craig would like to use scavenged flatbed scanner parts to build a 3D printer in the same manner as the Tandem and so had already been modifying Marlin to this end before I even started working on the Tandem idea. So thanks Craig for sending me a copy of you modified Marlin as it gave me a great starting point!

Craig’s idea was that rather than  re-writing a lot of code it would be far simpler to modify the existing Delta reverse kinematics. The required changes all take place in marlin.main.cpp.

The original Delta kinematic equations from marlin.main are shown below:

void recalc_delta_settings(float radius, float diagonal_rod)
delta_tower1_x= -SIN_60*radius; // front left tower
delta_tower1_y= -COS_60*radius;
delta_tower2_x= SIN_60*radius; // front right tower
delta_tower2_y= -COS_60*radius;
delta_tower3_x= 0.0; // back middle tower
delta_tower3_y= radius;
delta_diagonal_rod_2= sq(diagonal_rod);

void calculate_delta(float cartesian[3])
delta[X_AXIS] = sqrt(delta_diagonal_rod_2
– sq(delta_tower1_x-cartesian[X_AXIS])
– sq(delta_tower1_y-cartesian[Y_AXIS])
) + cartesian[Z_AXIS];
delta[Y_AXIS] = sqrt(delta_diagonal_rod_2
– sq(delta_tower2_x-cartesian[X_AXIS])
– sq(delta_tower2_y-cartesian[Y_AXIS])
) + cartesian[Z_AXIS];
delta[Z_AXIS] = sqrt(delta_diagonal_rod_2
– sq(delta_tower3_x-cartesian[X_AXIS])
– sq(delta_tower3_y-cartesian[Y_AXIS])
) + cartesian[Z_AXIS];

This code works off the delta tower definitions which is also located in marlin.main.cpp and is shown below:

#ifdef DELTA
float delta[3] = { 0, 0, 0 };
#define SIN_60 0.8660254037844386
#define COS_60 0.5
// these are the default values, can be overriden with M665
float delta_radius = DELTA_RADIUS;
float delta_tower1_x = -SIN_60 * delta_radius; // front left tower
float delta_tower1_y = -COS_60 * delta_radius;
float delta_tower2_x = SIN_60 * delta_radius; // front right tower
float delta_tower2_y = -COS_60 * delta_radius;
float delta_tower3_x = 0; // back middle tower
float delta_tower3_y = delta_radius;
float delta_diagonal_rod = DELTA_DIAGONAL_ROD;
float delta_diagonal_rod_2 = sq(delta_diagonal_rod);
float delta_segments_per_second = DELTA_SEGMENTS_PER_SECOND;

Using the code above as a basis I constructed an excel spreadsheet that modeled the delta kinematics (copy here) so as to allow me to make changes to the equations and see the results in real time. Note that excel does not allow you to plot an xyz three dimensional scatter plot and so if you want to visualise the results you will need to use a third party program such as Origin Pro.

By removing one tower completely, and then redefining the z-axis to behave as the y-axis the changes were complete. A spreadsheet that models the tandem kinematics and plots the required carriage position can be found here.

The new kinematic equations in marlin for the tandem setup are shown below:

void recalc_delta_settings(float radius, float diagonal_rod)
delta_tower1_x = -radius; // front left tower
delta_tower2_x = radius; // front right tower
delta_diagonal_rod_2 = sq(diagonal_rod);

void calculate_delta(float cartesian[2])
delta[X_AXIS] = (sqrt(delta_diagonal_rod_2 – sq(delta_tower1_x – cartesian[X_AXIS])) + cartesian[Y_AXIS]);
delta[Y_AXIS] = sqrt(delta_diagonal_rod_2 – sq(delta_tower2_x – cartesian[X_AXIS])) + cartesian[Y_AXIS];
delta[Z_AXIS] = cartesian[Z_AXIS];

and the new tower definitions:

#ifdef DELTA
float delta[3] = { 0, 0, 0 };
#define SIN_60 0.8660254037844386
#define COS_60 0.5
// these are the default values, can be overriden with M665
float delta_radius = DELTA_RADIUS;
float delta_tower1_x = -delta_radius; // front left tower
float delta_tower2_x = delta_radius; // front right tower
float delta_diagonal_rod = DELTA_DIAGONAL_ROD;
float delta_diagonal_rod_2 = sq(delta_diagonal_rod);
float delta_segments_per_second = DELTA_SEGMENTS_PER_SECOND;

For now I have left the homing code unchanged as it seems to be working fine. The only other changes were to configuration.h. Here the normal delta definitions are as follows:

// Center-to-center distance of the holes in the diagonal push rods.
#define DELTA_DIAGONAL_ROD 175.0 // mm

// Horizontal offset from middle of printer to smooth rod center. Adjust this to calibrate x-axis distance for tandem setup.
#define DELTA_SMOOTH_ROD_OFFSET 118.0 // mm

// Horizontal offset of the universal joints on the end effector.
#define DELTA_EFFECTOR_OFFSET 0.0 // mm

// Horizontal offset of the universal joints on the carriages.
#define DELTA_CARRIAGE_OFFSET 0.0 // mm

As there is no effector or carriage offset both of these values were set to zero. The DELTA_DIAGONAL_ROD distance was set to the length of the arms (175.0mm) and the DELTA_SMOOTH_ROD_OFFSET was originally set to half half the distance separating the smooth rods, just as you would in a normal delta. The result of these setting is shown below where an upscaled 40mm cube print is being dry run with a pen acting as a pen plotter.


Its clear that the cube outline is neither symmetrical or square.

In a norma Delta configuration each carriage has two parallel arms connecting it to the end effector in such a way that the resulting  parallelogram prevents the tool head from moving in any direction other than parallel to the print surface. For the TandemB setup only two arms in total are used and therefore no such parallelogram exists. It is because of this, and the fact the tool head is not directly positioned where the centre pivot is located, that we are seeing this curvature. The solution turned out to be as simple as adjusting the DELTA_SMOOTH_ROD_OFFSET from 118.0 down to 89.5 which was determined by trial and error but is something that should also be derivable mathematically. After this adjustment I can now trace cubes that are almost square.


Hopefully some fine tuning of the carriage homing positions and the tool head location is all thats now needed to make it perfect.

In the video below you can again see an upscaled ’40mm’ cube that has been stretched so as to fill the available build area and had the first layers removed so that the infill is now being drawn first.

Its far from perfect, but its a good start.

As expected, there is quite a lot of play in the z-axis (vertical) direction during rapid direction changes. This is not a problem when using a pen, as the pen acts to support itself as it pushes against the surface its drawing on. However, it will be a massive problem for a 3d printer and so needs to be addressed. I have a few ideas of how to solve this problem without reverting to the potentially much slower ‘TandemC’ design shown here and these ideas may even remove the need for any smooth rods in the whole design. More to come soon.

Posted in Tandem | Tagged , , , , , , , , , | 3 Comments

Construction of a TandemB Prototype

In a previous post I proposed the idea using an unconventional kinematic system to translation movements in the x and y axis. This idea, which was dubbed ‘Tandem’, is similar to that of a delta robot with the key difference being that rather than operating in three dimensions (X, Y and Z), it is restrained to only two (X and Y).  A mockup of the ‘TandemB’ style kinematic system  can be seen here. In this post I cover the construction of a ‘TandemB’ design which will be used for further experimentation.

CAD Drawings

The sketchup models shown previously (available here) were modified slightly and used as a basis for the design. The biggest change made was the addition of angled aluminum extrusion for the ‘arms’ as this simplified construction and is actually much lighter and stiffer than a 6mm stainless steel rod.

Sketchup Design

Each different part was arranged and dimensions added in order to make up a set up blueprints which were used for the construction.


The material chosen for construction was a 14mm thick hardwood plank simply because I happen to have this spare. Below you can see the parts needed for the x and y axis which were cut from this plank using hacksaw and then drilled out with a drill press. After a few iterations the parts came together fairly quickly.



Its interesting to note that other than the bearings, screws and M8 bolts, all the other metallic parts shown were scraped from old printers and pen plotters. I assembled the parts on a flat test board which I will use for now until I can work out the changes need to firmware to drive it correctly.


In more detail, the stepper motors are driven by a RAMPS 1.2 setup and have a 12mm spindle attached that moves a fine braided wire. This wire was also scrapped from a pen plotter. The wood screws shown below are just holding the stepper motor in place and allow for slight adjustments to its position and angle.


The wire spindles were turned down on a small lathe I have access to at work from 15mm aluminium bar stock. Each spindle then had two machine screws added to act as grub screws. I suppose something like these spindles could also be bought from an online store, but this was the fastest option available to me.


Freewheeling bearings that act as guides for the wires are located on posts at the opposite ends of  the board to the stepper motors.


The pivoting sections each slide on the smooth rods using two LM6UU bearings. In the original design I had these bearings sandwiched between two pieces of timber. However I quickly found that this restricted their movement too much, leading to jams. This was fixed by replacing the timber with an aluminium plate and using the cable tie method instead.


I had also only planned on using a single 608ZZ bearing for each pivot point. However, due to a large amount of play in the bearings when used in this way I ended up using two bearings for each pivot as this made the arms much more rigid. Thankfully, due to the timber being 14mm thick and the bearings being exactly 7mm thick, no changes were needed. With a total of six 608ZZ bearings the arms are now stiff enough that the ‘TandemC‘ design may not be required for use with a 3D printer. However, more testing is needed to tell for sure. The holes for the bearings came out slightly oversized after drilling and so rather than compressing the wood further with the screw, which risks it cracking, I added some electrical tape to each bearing to bring its outer diameter up to the right size. This is something I should also have done for the smooth rod mounts as they did end up cracking their holding posts.

Below is a view with the arm removed off its posts and flipped upside down. One smooth rod is longer than the other because they are only what I had on hand.


In order to test out the movement of the arms with the stepper motors I used a simple sketch written with the AccelStepper library. The sketch shown in the video below has the two axis moving to random positions at random speeds using something similar to the ‘Random.pde‘ example sketch.

Note that the AccelStepper library allows a maximum of 4000 steps per second for both axis combined and so I have had to use full stepping, as opposed to microstepping, in order to get a reasonable movement speed. This is far below the ~16,000 steps per second you would normally see with a RAMPS set up and leads to very noisy movements that are then made worse by the mounting board acting as a soundboard.

The next step is to now find a suitable firmware that I can modify in order to add the reverse kinematics described in the previous postMarlin firmware has been suggested as the simplest choice due to its level of segmentation, while Teacup has also been suggested due to the readability of its code. Unfortunately, after spending quite a few hours looking over the code for both I am no closer to understanding how either works due to my non-existent programing skills.

If anyone is able to help with adding ‘Tandem’ support to any RAMPS compatible firmware it would be greatly appreciated!

Posted in Tandem | Tagged , , , , , , | 6 Comments

Working in Tandem – Unconventional XY-axis layouts for 3D printing, laser cutting, CNC milling, engraving or pick and place.

Below I outline three separate concepts for moving in the X and Y plane with a specific emphasis on minimising the moving mass, maintaining high mechanical stiffness, reducing backlash and allowing two stepper motors to work in tandem. It is my hope that these concepts, or some variation of them, will make high accelerations possible in the X/Y plane without sacrificing positional accuracy.

Note: If anyone is aware of what the correct names are for these types of designs then please let me know by leaving a comment.

TandemA (Kite)

This first concept relies on the movement of two rods, jointed at an elbow by a bearing, having only four degrees of freedom: Translation forward and backwards and rotational yaw left and right. This movement style is inspired by polargraph drawing machines, but can also be thought of as one third of a Stewart platform.


An example of the movement available with this setup is shown in the video below which was made using Sketchup with the aid of the sketchyphysics plugin.

The build area (the area swept by the elbow where a tool would sit) is shown by the red filled section in the image above and has a shape that resembles a kite. The movement is brought about by the rotation of a gear on either of the two stationary stepper motors which pushes the a rod towards or away from a pivot point using a gear rack as shown by this close up image. If one rod is extended or retracted more than the other then this results in sideways movement or if both rods are extended or contracted together this a forward or backwards movement.

Advantages of TandemA

  • Like the CoreXY or Delta design, both motors can work in tandem to move the elbow joint in the conventional X/Y-axis directions. Only a specific movement through a given arc will use a single motor. In this case the shape of such an arc will be similar to the build area boundaries.
  • A high stiffness, low backlash mechanical arrangement should aid in maintaining accurate movements even with high acceleration.
  • The total moving mass for both axis is comprised of only the two rods with attached gear racks, one bearing and the tool of your choice (hot end, laser etc). This low moving mass will also allow for high acceleration without missing stepper motor steps.
  • Low parts count (3x 608ZZ bearings, 2x LM6UU linear bearings, 2x 6mm stainless rods and a cheap rack and pinion setup (or similar), and some brackets.

Disadvantages of TandemA

  • A relatively small and awkwardly shaped build area.
  • A large machine footprint relative to the build area.
  • The fast moving rods extending from the back of the machine would need to be enclosed to prevent injury.
  • Relies on computationally intensive movement calculations (square roots) for Atmel AVR based microcontrollers. However, this may be far less of a problem than that seen for delta based designs due to only operating in 2D.
  • Nonlinear deflection in the z-axis that depends on the extent of the arm extension. In other words, if you place a weight, such as an extruder or similar tool, at the end of a rod while that rod is supported from only the opposite end then it will bend (deflect) slightly. This becomes worse with longer arms or thinner rods. This point is explored further in the discussion.

If you would like to download a copy of this model, or just take a look at it in 3D without the need to install sketchup, then visit my 3D warehouse page. The Clipboard01 symbol allows for an interactive 3D fly-around view. Note that the models are a little rough around the edges and up-scaled (1mm = ~1cm) due to problems with small objects in sketchyphysics not working correctly.

TandemB (Shield)

This second concept can be thought of as a 2D cousin to the delta robot. Again, two rods are jointed at an elbow with a bearing. However, the ends of the rods furthest from the elbow stay a fixed distance apart and instead move forwards or backwards to allow the elbow to sweep the ‘shield’ shaped build area. Rather than a rack and pinion setup as used for TandemA, this setup would use a belt or wire pulley system. Although a threaded rod or lead screw setup would also work, the much larger moment of inertia of the rods would likely reduce the maximum acceleration rates achievable by a considerable amount.


Note that although the image above shows rods used for the ‘arms’, any shape or material will work provided it is stiff enough.

The video below again gives an example of the movement.

Advantages of TandemB

  • Again, both motors work in tandem to move the elbow joint in the conventional X/Y-axis directions with the exception of very specific arcs.
  • Reduced part count, moving mass and total belt length, which reduces backlash, over an equivalent (CoreXY or ultimaker style) movement system. Can be built with only two smooth rods if the arms are replaced with other materials.
  • Larger build area than TandemA and also does not suffer from the same non-linear flexing of its arms as they are at a fixed ‘extension’. Further discussion later.
  • Build area can be isolated from all stepper motors, allowing a high temperature enclosure to reducing warping when 3D printing.
  • Alternatively, the build area could be located in an unenclosed space away from the bulk of the machine for easy viewing, part extraction and extruder servicing.
  • Only two rods need to be aligned in parallel in total for both the X and Y-axis.
  • Both the X and Y-axis have the same steps/mm and mover linearly in the Y direction, simplifying calibration.

Disadvantages of TandemB

  • Relies on computationally intensive movement calculations for Atmel AVR based microcontrollers, but again, likely not as bad as a delta due to being in 2D.
  • Large horizontal footprint relative to actual build area.
  • Careful management of the Bowden cable/wire harness to the tool head is needed to prevent changes in the vertical (z-axis) loading and the resulting flex in the z-axis.
  • Possibility of the tool head oscillating in the Z-axis direction during rapid movements forwards and backwards. Further testing needed to see if this is really a problem.
  • Possibility of a high wear rates on the linear bearings. This will likely limit the total tool mass to laser cutting/engraving or 3D printing with a Bowden extruder system.

In order to overcome the last three problems outlined above there is a third option which sacrifices maximum acceleration speeds in exchange for rigidity in the z-axis.

TandemC (Box)

This design is the same as TandemB, but with the addition of a stiffening crossbar to prevent flexing in the Z axis direction. This crossbar reduces the available build area to the green square shown below and also requires that the smooth rods are lengthed.


TandemB mockup made in sketchup with sketchyphysics.

Advantages of TandemC

The same advantages as outlined for TandemB with the addition of:

  • Provided a large enough rod diameter is used, and if each axis was driven by a lead screw, then this setup could be rigid enough in the Z-axis for light milling duties and heavier tool heads than that possible with TandemB.

Disadvantages of TandemC

  •  Higher moving mass and part count than TandemB due to the addition of the crossbar, its linear bearings and mounts. The maximum acceleration will therefore be lower. There would also bow be a need for precisely parallel bars to prevent jamming, which is not true for TandemB.

Again, you can find a sketchup copy of these designs here.


Of the three ideas I think TandemA would be the most rigid in the X and Y plane and the most light weight, and therefore the fastest. However, as mentioned above it will also suffer from a deflection in the x-axis due to the bending of the rods and play in the linear bearings. Some back of the envelope calculations (end loaded cantilever beams) suggest that the deflection expected in Z axis at full extension for a 6mm diameter, 250mm long stainless steel rod is in the order of 0.5mm for a 250g load placed at its end. Needless to say this is quite large and does not even take into account the play in the linear bearings. Even if you increase the rod diameter to 10mm, which now makes them quite heavy, you would expect a deflection greater than 0.07mm. The problem only gets worse if you try to increase the already small build area by making the arms longer.

Solving this deflection problem is not as simple as adjusting the bed angle either as the deflection is not linear. It could be possible to adjust for this deflection by tieing the z-axis position in firmware to the level of arm extension or just by rotating the whole device by 90 degrees so that the arms do not need to fight gravity. However neither solution is idea. Therefore, this might limit the TandemA design to applications where tight tolerances in the Z axis are either not required (such as engravers?) or only where very light loads are placed on the rods. Really, testing is needed to know for sure.

Note that the same deflection problem exists for the TandemB design, but because the arms are at a fixed ‘extension’ once the tool hight is calibrated it should no longer be a problem.

Equations of motion

The equations of motion for TandemA design can be found here, as they should be the same as for the polargraph design. The maths the TandemB and Tandem C designs, which are both identical in this respect, are outlined below using the schimatic shown.

Tandem Setup


In order to move the ‘pivot tool’ to a given position ( x, y) , the movement required on the A and B side is described by the following equations:


Eq. of Motion.



Where the x-axis movements for A (Ax) and B (Bx) are irrelevant as they are fixed at a given distance apart while the y-axis movements are a result of the parallel bar separation distance (S, where q = 1/2*S), arm length (r) and desired x and y position.  I have made a spreadsheet where its possible to play around with the numbers and you can find that here.

I intend on building a TandemB to see just how stable it can be in the z-axis during rapid direction changes. If anyone has advice on how to implement the above motion equations into firmware that is compatible with RAMPS V1.2, or if you just have any other thoughts or comments regarding these concepts I would love to hear from you.

Posted in Tandem | Tagged , , , , , , , , , , , , , , , , , | 9 Comments

Bootstrapping a pen plotter to make a 3d printer

Back in 2010 I developed an intense interested in understanding and eventually building a 3D printer. This interest took me down the path of reading all the material available at the time and purchasing a RAMPS (V1.2) which I used to control a modified mantis made from parts found in disassembled printers with the eventual goal of turning it into a 3D printer. Although I came quite close to finishing this project I found that my my interests shifted when I moved out of home and started a full time PhD materials engineering. My ‘engineers itch’ was being more than satisfied by my day job and so this project has sat on the back burner for quite some time.

Now that I am approaching the end of my PhD and spending less time in the lab during the day I have decided to pick up where I left off. Unfortunately, the oversized mantis (dubbed the gunstrap) has long since been disassembled and thrown out. I do however still own a scientific pen plotter which I did a tear down on here and works quite well when controlled by RAMPS. The video below is this RAMPS powered pen plotter in action:

I had planned on replicating this pen plotter design to use as a 3d printer. Although I never found the time to undertake this project, it looks like a few others have adopted this design for their own printers. Note that this XY axis style has been used by 3d printer enthusiasts long before my pen plotter tear down.



Not having the time or parts to build one of the above printers I decided to use the pen plotter itself as the base for the XY axis of a 3d printer. The following photos show what I came up with.

The z-axis design is based on the common linear bearing with threaded rod design. The rods, stepper motor and aluminium plate are all donated from old laser printers. The pen plotter had its inner plate removed to allow for an extruder. Here it is setup for testing.


The heated build platform is heated by aluminium clad resistors that are thermally glued to the plate.


A dedicated 12V computer PSU is used to drive the heated build platform through a low on resistance FET. Total build platform power output is around 100W. enough to for ~90c.

The extruder hot end is machined from a single shafter of stainless steel based on hydraraptors ‘no compromise’ hot end design. Two enameled resistors are located in the hotend with a total output of 100W at 24v.

IMG_20150131_232116Another view of the hot end. The resistors are located in piece of machined aluminum which is grub screwed onto the stainless steel shaft.


This hotend is fed a 3mm PLA filament from a geared wades extruder via a PTFE tube. Here is the hotend attached to the plotter.


This whole setup was then mounted in a wooden frame.


Playing around with deisgn a few problems become apparent. The build area is severely restricted due to the way the hot end is placed. However the biggest problem is a lack of z-axis stability due to play in the x and y axis.


There is simply not enough support for the central spar as seen above.

I am currently thinking of stiffening this axis with a secondary plate and some additional bearings as shown with the layout below.


However this will require some more work. I have also since had some ideas for an unconventional X-Y axis layout that may be much more suited to 3d printing. More about that next post.

Posted in Mendel Build | Leave a comment

The ideal shape for a multirotor ‘ducted-fan’ that can dramatically improve thrust and flight time.

2016 update: David has produced a great customizable OpenSCAD file based on the study referenced in this post. The file can be found over at thingiverse here (thing:1535549).


In a previous post I discussed how the addition of a well designed duct can reduce hovering power consumption of a rotor by over 60% or alternatively nearly double the thrust if power consumption is kept at the same level as the unducted rotor. These claims are based on a scientific study conducted on this very topic which can be found here (Mirror here) (Jason L. Pereira 2008).

If you want to have a go at testing these claims for yourself then this post will hopefully give you an idea of what kind of shape that duct needs to be and also suggest some possible ways to construct it.

The perfect duct for hovering

Below is an cross-sectional view of a duct taken from the reference above. It outlines the critical parameters that affect performance: Diffuser included angle (θd), diffuser length (Ld), inlet lip radius ( r lip), blade tip clearance (δ tip).

The parameters that affect performance: Diffuser included angle (θd), diffuser length (Ld), inlet lip radius ( r lip), blade tip clearance (δ tip)

The parameters that affect performance: Diffuser included angle (θd), diffuser length (Ld), inlet lip radius ( r lip), blade tip clearance (δ tip) (Credit: Jason L. Pereira 2008)

According to the study the optimal optimal configuration found experimentally includes a δtip = 0.1%Dt,  rlip = 13%Dt, θd = 10and Ld = 50% to 72%Dt. I have used sketchup to mockup what such a duct would look like for a 5″ rotor as seen below. Note that I went with Ld = 50% to try and keep the overall length to a minimum and also made it a single surface by using the inner wall only.

Single Rotor Duct Design

Single rotor duct design

The same duct can also be extended slightly for a contra-rotating setup and shown below.

Double rotor contra-rotating version (left image made transparent)

Double rotor contra-rotating version

The dimensions for a single rotor duct are shown below (larger views available) for a 5″ rotor. Scale accordingly for a rotor of your choosing, but be sure to measure your rotor first as it may not be quite what you expect.

Top view with dimensions

Top view with dimensions

SIde view with dimensions.

SIde view with dimensions.

You can find a copy of the sketchup model here.


The most difficult part about making a duct for a multirotor will be keeping it light enough that you do not offset the respective gains. Thankfully, the literature suggests that when done correctly the additional thrust gained is so large (~90%) that you would need to nearly double the weight of your multirotor to cancel out the gains.

Remember though, if you only want to bench test the thrust or efficiency improvements (as I hope to do eventually) then the duct can weigh whatever you want, it doesn’t matter. The following is a list of suggestions for how you could achieve a lightweight duct.

  • Carbon fiber – The ideal solution: In an ideal world you would construct your duct out of a single piece of 0.5mm thick pre-impregnated vacuum bagged and autoclaved carbon fiber. If have access to this equipment then look no further.
  • Fiberglass reinforced foam – The realistic option: A more DIY solution would be to purchase some styrofoam blocks  and carve them into the desired shape. For added rigidity you could also layer fiberglass on the surface like you would for a RC boat hull or model plane wing.
  •  Cheapest possible or just for testing – If you just want to test out the idea then really anything will do the job, balsa wood, cardstock, old drink bottles, paper mache, gap filling foam etc.

The most difficult part of the build would be getting the blade tip clearances as close as possible, as this has a big impact on efficiency but also requires very tight tolerances. One way around this problem is to build the duct quite roughly and then line the inside of the duct where the rotor will be placed with a material that can be scraped away by the rotor as it turns. Something like expanding gap filling foam may be perfect for this. Once the rotor scrapes away the excess foam you should be left with blade clearances measured in fractions of a millimeter.

If you do end up trying something let me know as I would be really interested to see what you came up with and how you went.

Posted in Multirotor Projects | Tagged , , , , , , , , , , | 19 Comments

Breaking through the 2 hour barrier – Maximising efficiency to achieve the longest flight time of an electric multirotor (quadcopter)

The current record holders.

Small electric RC helicopters and multirotors are known for their very short flight times. Even after considerable effort the current record holders (as of Jan 2015) for longest flight time that I can find for an electric helicopter is just under 3 hours (link to owners website) while less than 1 hour 40 minutes (unofficial) for a quadcopter. I have since been made aware (thanks cloidnerux) of a longer flight time of a quad of over 2 hours!

Timo Wendtland RC Elec

Previous Record Setting RC Electric helicopter (Credit: Timo Wendtland)

Current (unofficial) endurance record holder for a quadcopter (Credit:EndOfDays)

Current (unofficial) endurance record holder for a quadcopter (Credit:EndOfDays)

Although these are amazing flight times when you consider their size they are still very short when compared to full sized aircraft. In this post I explore why multirotors, quadcopters in specific, have these short flight times and see where improvements can be made.

How real aircraft do it.

Keeping a rotary-wing aircraft in the air for a long period is relatively straight forward and its something we have known how to do for decades. It is a case of:

  • Build the largest rotary-wing aircraft practically possible with today’s materials and optimise it for your flight conditions. Bigger is better from the Reynolds number perspective, but due to a finite specific modulus of todays composite materials and the square-cube law  there will be an optimum size. In other words, a bigger rotor is more efficient but make things too big and it will either be too heavy or break.
  • Reduce weight as much as practically possible. This includes removing the heavy human component, reduce payload etc.
  • Equip your rotary-wing aircraft with the highest efficiency and highest energy density drivetrain possible.  Efficiency and energy density tend to be mutually exclusive, so a compromise between the two will always be needed.
  • Use the highest energy density fuel practically possible. A nuclear powered helicopter will have a great endurance, but more realistically a high energy density liquid fuel.

When you put these components together you can end up with the 20+ hours flight time seen for the A160 Hummingbird UAV, even with a moderate payload, and I would not be surprised if much longer loiter times have been achieved and not published for obvious reasons.

So what happens when you try to apply these principles to small electric RC helicopters and multirotors?

Endurance and electric RC multirotors: Size matters.

First the good news: The energy density and efficiency of electric motors is generally far greater than a comparable internal combustion engine. Furthermore, the smaller size scales of RC models means you need very little structural material to achieve the required rigidity.

The bad news: Size matters. A lot. As you reduce the size of a rotor down to that of an RC helicopter or worse, a quadcopter, the rotors lift to drag ratio increases dramatically which in turn lowers overall efficiency. The properties of the air itself does not change for smaller rotors, but rather the way the rotor interacts with the air. Viscous forces come to dominate at high speeds and small rotor length scales meaning that smaller rotors are simply less efficient. Unfortunately, this is an unavoidable side effect of small rotors and is one of the reasons we don’t already have jet packs and flying cars. This is also why the record flight duration for an RC helicopters is nearly double that of an equivalent quadcopter, they simply have bigger rotors that are more efficient due to their size. If it was not for the simplicity of quadcopters over helicopters (think swashplate), they may have never become as popular as they are today.

Another more obvious factor is that batteries are also not as energy dense as liquid fuels. Lithium-polymer batteries have an energy density typically around 150 Wh/kg (higher if you sacrifice C rating) and even the 18650 Lithium Ion cells used by the record holders above are only in the 250 Wh/kg region. In comparison, petrol has an equivalent energy density of over 12,500 Wh/kg and when you consider that around two thirds of that energy is lost as heat in an internal combustion engine this still gives an energy density 16 times that of the best batteries available.

These two factors are the key reason why micro sized (palm of your hand) quadcopters can barely achieve 5 minutes flight time.

How to improve efficiency for longer quadcopter flight times.

So how can we improve on the current endurance record for an electric multirotor such as a quadcopter. The quadcopter mentioned above is already doing all the right things by having minimal weight, large rotors running on efficient motors at low rpm, the highest energy density batteries available and minimal obstructions to the air stream.  So where to from there?

Make it bigger. The most obvious answer by now is perhaps to simply make it bigger. Bigger rotors equal less drag for a given thrust and so longer flight times. However, before you start building a house size quadcopter note that there are a few problems with this idea. Things get very expensive very quickly, the rotors become much more dangerous to be around and worst of all the angular momentum of the rotor can become so large that the rapid rpm changes needed to maintain the stability of a quadcopter become difficult or even impossible. One solution to the latter problem is to add a collective pitch setup like a helicopter, but then aside from the maneuverability benefits you may as well use a standard helicopter platform which will be lighter and more efficient anyway. So supposing we want to keep the footprint (rotorprint?) of the quadcopter fixed to around the same size as that shown above then what other options are there? Some possibilities are as follows:

  • Adding more rotors. This simply will not help. The rotors would need to be smaller to fit in the same given area and so will actually lead to worse flight times due to the increased drag mentioned above. The only reason to add more props is when size is not restricted so as to increase lift without encountering the aforementioned safety and stability problems. Hence why the first commercial manned multi rotor looks the way it does.
  • Adding more batteries. This also won’t help if the lift to weight ratio is already optimised for the quadcopter size.
  • Reducing frame weight. The current record holder is already using a simple carbon fiber frame that would be difficult to improve on.
  • Custom ESC or Motors. By using high saturation magnetisation permanent magnets, lower core loss soft magnetic materials and higher quality electrical components it would be possible to improve efficiency. However the reward for such dedication will likely only be minor.
  • Invert the motors. One suggestion is to invert the motors to push rather than pull. It is suggested here that this will reduce prop wash and so improve lift efficiency, leading to slightly longer flight times. Definitely worth considering and is currently used by some commercial UAV such as the Aeryon SkyRange shown below.
The commercial Aeryon SkyRange UAV (Credit:

The commercial Aeryon SkyRange UAV (Credit:

  • Addition of ducts around the rotor.Although there is a lot debate on RC forums, many scientific studies have shown conclusively that the addition of a duct (also called a shroud depending on how you define it) around rotors, big or small, does increase thrust, and by a considerable amount too.

The most useful source of information on this topic I have found to be by Jason L. Pereira, which can be found here, and I have used this as my source of information for the following discussion.

In short, compared to an open rotor, an optimally designed ducted rotor of the same size can expect a reduction in power consumption in the order of 60%. Needless to say, thats quite a lot even after considering a weight penalty for the ducts themselves. This reduction in power consumption is due to a few factors that we will be elaborated on shortly. What’s more, thrust can be increase by nearly 100% if you keep the power consumption at the same level as an unducted rotor. I believe the reason for the debate on this topic on RC forums is that people who try this at home nearly always use commercially available electric ducted fans (EDF) as seen in these many videos. These fans, which are designed for fast level flight and not static hovering, are not the right tool for the job. They normally have a much smaller propeller diameter than an equivalent quadcopter rotor and a duct shape that adds little additional thrust for hovering. An example is shown below:

A typical EDF (Credit: Hobbyking)

A typical EDF (Credit: Hobbyking)

A more efficient duct shape is shown by the slightly exaggerated profile below. Notice the large slope on the inlet lip and the expansion of the duct cross section downstream of the rotor.

Profile of a ducted fan (Credit: J. Pereira 2008)

Profile of a ducted fan (Credit: J. Pereira 2008)

There are three main ways in which a duct is able to improve thrust:

  1. Additional lift is created by air being drawn over the lip of the inlet, creating a upward suction suction force.
  2. Tip vortices of the rotor are reduced dramatically by the close proximity of the duct wall to the rotor tips.
  3. The diffuser section of the duct prevents the narrowing, and can even expand, the exhaust flow of air, increasing thrust.

If you are interested in designing your own duct I suggest you read the source mentioned earlier. I believe that if well designed and reasonably light weight ducts can be added to a quadcopter it should dramatically improve flight time. However, please keep in mind that ducted rotors will degrade horizontal flight performance and make the quadcopter more susceptible to high winds due to the larger cross sectional area. As a result, FPV racers need not apply and instead its use may be limited to the many applications where flight duration or carrying capacity are of most importance.

  • Addition of contra-rotating rotors. When properly designed, two oppositely spinning rotors placed on the same axis has been shown to improve flight efficiency between 6 and 16%. My reading suggests that for optimal efficiency the pitch of the downstream rotor needs to be higher and varied along its length compared to the upstream rotor for unducted setups.
An example of a contra rotating rotor (Credit: Ed Kirk)

An example of a contra rotating rotor (Credit: Ed Kirk)

However, apparently for a for ducted contra rotating rotors the pitch requirements of the secondary rotor become far simpler and so off-the-shelf rotors may be all that is required to get a good effect. So when used in conjunction with ducted fans perhaps even greater endurance could be reached while maintaining the same footprint.

Thinking outside the box.

A more radical suggestion for increasing flight duration is to try to combine the large rotor area, and thus lower relative drag, of a traditional helicopter with the simplicity (no swashplate) of a quadcopter. But how to achieve this?

One possibility would involve a large singular centrally located ducted rotor to provide lift and then four smaller rotors on the exterior for stability. So long as the smaller motors are only used for pitch, roll  and yaw control this will lead to an improvement in overall efficiency with a small weight penalty. Stators (non-rotating fins) can be used to prevent rotor swirl causing yaw or, alternatively, the more efficient contra-rotating setup can be added.

In fact such a multi rotor craft already exists, and its aim at the military. See Reference Tech’s Hummingbird series.

Reference Tech's Hummingbird II (Credit: Reference tech)

Reference Tech’s Hummingbird II (Credit: Reference tech)

An in depth video on the older hummingbird 1 can be found here. Running on batteries, the hummingbird 1 has a claimed dwell time of over 2 hours and is not much bigger than a conventional quadcopter. So not only is it possible to break the 2 hour mark, its already been done. What’s more, the petrol model has a stated incredible 5 hours dwell time and is used as a hybrid configuration where the ICE is only used to produced electricity. The model shown above uses 6 exterior rotors but I see no reason why four would not work equally as well. Perhaps the 6 rotors was decided on for redundancy reasons for military use.


 So, is there room for improvement on the current duration records for quadcopters? Most definitely. Electrically powered, multirotor stabilised, contra-rotating ducted fans have already shown what’s possible. Will a multirotor ever be able to beat the endurance of an equivalent weight helicopter? Highly unlikely, but there is no harm in trying.

If you have found this interesting stay tuned as I intend to follow up this post with designs for a ducted fan multirotor that can be built using commonly available hobby-grade parts.

Posted in Multirotor Projects | Tagged , , , , , , , , , , , | 6 Comments

One step conversion of an image to gcode for Makerbot Unicorn and Reprap style 3D Printers

How to take an image like this:

and in one step generate the gcodes required to do this:

All credit for goes to the original creator Neil Gershenfeld of  MIT Center for Bits and Atoms and David Carr of Make Your Bot who optimised the code that is in use here.

By attaching a pen to a 3D printer it is easy to turn it into a basic pen plotter. However producing the G-codes require to drive your 3D printer as a pen plotter can be anything but easy. This short guide seeks to change that. There are currently a number of ways of producing plotting paths from images. A selection includes:

 Of these options I believe is by far the simplest as once it is setup you can convert an image directly to gcode in one go with one program and with out the need to use a command prompt. The following is how to install and use

Program Installation

Download the following software for your respective OS. Note that python 2.6 must be used for to work. Either un-install newer versions or dirct to work with python2.6 only.

Generating the gcodes.

Run the that suits your hardware. I have included three types all with the same interface but each outputs slightly different gcodes.

  • ( Plotting with Z axis -> For use with a three axis Cartesian bot such as a reprap, Makerbot etc. where the pen is lifted off the page due to the movement of the Z (vertical) axis.
  • ( Plotting with solenoid or ->For use with a 2 axis bot where the pen is lifted of the page by an action such as a solenoid or a cutting action like a laser is required. (Use fan port for solenoid as it is switched on off with gcode M106 and M107. Commands need to be switched for use with a laser, see “Optimisation” below.)
  • ( Plotting with Makerbot -> For use with Makerbot Unicorn system which uses a servo to lift the pen off the page.
If you see a command prompt for a split second and then nothing when you run one of the above then recheck you have all the correct programs installed and the correct version of python (2.6!).

When the program begins do the following to test your setup:

  1. Select the test image.png file by clicking the “Input File” button and navigating to the “Test Images” folder.
  2. Set “in. per unit”: 25.4
  3. Click “Cam” button
  4. Click “Output Format” and select file type: “.gcodes”
  5. Set the following values:
    1. maximum vector: 0.75
    2. tool diameter: 0.03
    3. tool overlap: 0.1
    4. contours: 1
  6. Click “contour” and wait for the paths to be generated. They appear as red lines over the image at its edges.
  7. Click the save butting and the file will be output to the input directory.

Thats it, your done. Now load up your desired host, run the gcode and watch your bot draw. Here is a timelaps of my plotter at work.


Now that you hopefully have the basics out of the way you may want to know a little more detail. It appears that takes a black and white image, performs edge detection on the black areas and then calculates tool paths based on that. When choosing your image I recommend you keep its size under 1000pixels or else the rendering time will be come very long (hours+). For best effect use images with clear distinctions between white and black. Although other image formats such as .jpg do work they dont appear to give the same results as png images. Therefore I recommend you convert .jpg to .png and make sure the image is in black and white with high saturation using your desired image software such as irfanview. When the plotting is started the image will be plotted in the positive dictions from where ever the pen is when printing begins. Therefore you can print many images on the same page by moving the pen to a new position between prints.

Furthermore you can copy and past past multiple gcode files into one as long as you add the new starting position at the end of each file. As mentioned above you have a number of variables to play with in To the best of my knowledge this is their functions:

  • Window sizes – Changes the size of the display window of A larger window can make it easier to see when you have the settings right.
  • X Width and Y Width – The size of the image when printed. Roughly equates to the size of the image printed in cm when a .png file is used. Best to do a ‘dry run’ with out a pen first to check the size of your image then adjust accordingly.
  • Zmin and Zmax – The distance the pen is lifted using the z axis (Works for ( Plotting with Z axis  only)
  • Intensity min/max – Change these to change the level of darkness that interpreted as an edge in an image. Often a low “Intensity Max” value will help the edge detection pickup less distinct areas.
  • Inches per unit – At 24.5 roughly 1cmx1cm image should plot an 1cmx1cm image. Change the value to change the size of your image.
  • Maximum vector fit error – How closely the edge detection fits to the image. Very small values (eg <0.2) take longer to process and can lead to jagged edges. Very high values (eg >1) can lead to corner cutting.
  • Tool Diameter – The most important parameter. The size of the pen end. Lower values mean more detail but longer processing time. To big a value (eg 0.05) and you will not see the detail. Too small (0.001) and you will get artefacts in the edge detection seen as small boxes and dots.
  • Tool overlap – How close two plotted paths are next to each other when more than one contour is used (see below)
  • Contours – The number of layers of infill that will be plotted in dark areas. Set to 1 only the outline will be plotted while -1 will give a complete infill.
  • Feed rate, spindle speed and tools – all not used.

If you wish to go even further then use a text editor to modify the python script its self (eg ( Plotting with Z axis Remember to back up the original before making changes.

  • Movement speed – Open with text editor, Use Replace All (Crtl + H for notepad) to replace “F2000” with your desired feed rate (eg F1500) and for the x/y axis or replace all “F300” for z axis. Then save the file. Gcode generated will now use that speed.
  • Reverse solenoid direction – Replace all “M106 S255 (Pen Up)” with “M106 (Pen Down)” and vice versa to change the solenoid direction or for using a laser. Currently the solenoid is off when the pen is down.
  • Change unicorn serve travel distance – Change the S value (eg S50 to S60) in the “M300 S50 (Pen Up)”  and “M300 S40 (Pen Down)” commands to change the servo travel distance.
  • Change delay time after pen up and down – Replace all “G4 P120” commands with your desired delay time in miliseconds. Eg P120 (120 miliseconds) to P150 (150 miliseconds.
I have only tested the output gcodes with the repetier firmware and host and using a solenoid as the pen lift method.

Finally as was originally designed to create tool paths for milling there is nothing to stop you from attaching an engraver, laser or similar and engraving your favourite pattern or quote on something interesting.

Posted in A Reprap Project | Tagged , , , , , , , , , | 5 Comments