Scary maths

Or how to convert from x,y,z coordinates to delta robot position

With a simple cartesian robot (or printer), the mechanism moves directly along rails in each of the x, y and z directions.  If you want to move a print head from the origin to, say, (10,10,20) you simply direct the motors to move it 10mm along the x axis rail, 10 along the y axis rail and 20 along the z.  You get the idea.  With a delta configuration, it’s not so simple.  Moving any one of the carriages which run up and down the three vertical struts will cause movement of the tool head in x,y and z simultaneously.  Calculations are required to work out how to move all three carriages at the same time to move the print head to the right place.  Fortunately, they are not too hard (and don’t need too much processor power for the Arduino to cope with).

Suppose we want to move the extruder nozzle to a particular point.  We’ll call this the tool position, and it will have coordinates (tx,ty,tz).  We want to calculate the positions of the three carriages (the bits that move up and down the struts) based on the tool head position.  We’ll call the carriages A, B and C.  Looking down from the top of the printer, Carriage A is on the X axis, carriage B is 120° anti-clockwise from A, and Carriage C is 240° anti-clockwise from A.  The positions of A, B and C are:

A2 = (a2x,a2y,a2z),
B2 = (b2x,b2y,b2z) and
C2 = (c2x,c2y,c2z).

The diagram below shows this a bit more clearly:

image

Because we know that the arm length (la) is fixed and that the carriages can only move up and down (so we always know their x and y coordinates) we can calculate the carriage positions from some simple trigonometry.  First, we need to know the positions of the other ends of the arms (which I’m calling the the pivot points).  These are

A1 = (a1x,a1y,a1z),
B1 = (b1x,b1y,b1z) and
C1 = (c1x,c1y,c1z).

The diagram below shows how we can calculate these.  It’s a schematic view of the tool head, looking down from above.  We have to take into account the distance between the extruder nozzle and the pivot points, because it’s a finite size:

image

Pivot A

Pivot B

Pivot C

a1x = tx + po
a1y = ty
a1z = tz + to
b1x = tx + po * cos(120)
b1y = ty + po * sin(120)
b1z = tz + to

c1x = tx + po * cos(240)
c1y = ty + po * sin(240)
c1z = tz + to

Once we know the locations of the pivot points, it’s straightforward to use Pythagoras’ theorem to calculate the distance in the x-y plane from the pivot to the carriage, and then use Pythagoras again to calculate the height the carriage must be above the pivot.  the next diagram shows the geometry, looking at it side-on:

image

Firstly, we know the carriage head positions in x and y, because they are fixed to the strut positions:

Carriage A

Carriage B

Carriage C

a2x = sp
a2y = 0
a2z = ?
b2x = sp * cos(120)
b1y = sp * sin(120)
b2z = ?

c2x = sp * cos(240)
c2y = sp * sin(240)
c2z=?

The x-y plane distances of the pivots to the struts are given by:

aa = sqrt((a2x-a1x)*(a2x-a1x) + (a2y-a1y)*(a2y-a1y))
ab = sqrt((b2x-b1x)*(b2x-b1x) + (b2y-b1y)*(b2y-b1y))
ac = sqrt((c2x-c1x)*(c2x-c1x) + (c2y-c1y)*(c2y-c1y))

And then the heights of the carriages above the pivot are calculated thus:

ha = sqrt((la*la) – (aa*aa))
hb = sqrt((la*la) – (ab*ab))
hc = sqrt((la*la) – (ac*ac))

so the heights of carriages above the floor of the printer (which is what we wanted to find), are then simply

a2z = tz + to + ha
b2z = tz + to + hb
c2z = tz + to + hc

And there it is.  The maths isn’t particularly hard, and I’ve described it in a procedural way to make it easy to implement in code should you so desire.  Calculating the other way (determining the nozzle position starting with the positions of the carriages) is harder, because it its necessary to calculate the intersection point of three spheres.  Fortunately, we don’t need to do that to drive a printer!

Motorized mayhem

Caution!  Hyperbole warning!

All right, so there is no mayhem involved.  But there are motors.  Stepper motors, to be exact.  Four of them.  Over the weekend I built my RAMPS module (Aah, solder fumes!) and I am pleased to crow about the fact that it worked first time.  In case you don’t know, this is an arduino shield which integrates the majority of the external components required for a 3d printer.  It can host 5 stepper motor drivers (I only need 4 at the moment, but it gives me the option to add a second extruder), manage the inputs from end stops, thermistors and other safety devices, and can provide power for a heated base on which to print.  Each stepper motor has its own little daughter board, a pololu A4988 which handles the slightly complex business of powering the coils on the motor.  Driving stepper motors is different to driving simple DC motors – they have two or more (sets of) coils, which are powered in sequence (and with varying polarity) to move the rotor in discrete steps.  The motors I have have two sets of coils, and have a resolution of 200 steps per revolution.  The Pololu driver boards are sophisticated, and by manipulating the voltages over both sets of coils at once, can make the stepper motors turn in increments of as little as 1/16th of a step (which gives the motor a resolution of 3200 steps per revolution).  The completed board with its steppers attached looks like this:

WP_20130218_001 (1)

Yes, I know it’s out of focus.  My camera seems to have developed a very irritating fault, and every photo I take is slightly blurry.  The lack of focus doesn’t show up on the LCD viewfinder, because the resolution is insufficient.  It’s like going back to the old days of taking photos on film and not discovering that they were out of focus until a week later, when the film was developed.  I don’t really want to buy a new camera, so you might have to put up with soft focus images for a while.

Back to the point: the RAMPS board works perfectly.  To test it, I’ve loaded Marlin firmware into my Arduino.  Marlin is the program which takes more-or-less standard ‘G-code’ instructions (G-codes are widely used in the manufacturing industry to tell computer controlled machine tools how to act) and converts them to stepper motor steps.  I’m going to have to hack the Marlin source code a bit, because it’s designed for printers which have one motor for each of the x, y, and z axes.  Delta printers have more complex geometry, and that’s what my next post will be about.  Marlin in turn listens to a PC over a USB connection and gets its instructions from Pronterface, which allows me to test the movements of the motors.  It does a lot more than this, in fact.  Its true purpose is to drive the printer mechanics over the whole print run – but more of that when I’ve got something to print with.  For now, just marvel at the lovely UI, and accept that it allows me to test that all four motors work properly.

Pronterface

A note on power supplies

Stepper motors take electricity.  This may not be a revelation to you.  What you may not know is that they take quite a bit of electricity, even when they are not moving.  Especially if you are using micro stepping, the motor coils need to be energised (Mr Scott) simply to hold the motor in a given position.  Four motors can easily eat a few amps.  A very easy way to get a relatively high current power supply is to use one from and old PC.  I’ve got more of those than you can shake a stick at, so the whole printer will be driven from an old ATX PSU.  Easy.

Something for the weekend, Sir?

I love the smell of solder fumes in the morning.

Raw materials for my 3D printer keep arriving.  It’s not surprising, as I keep ordering them, but it is fun.  I’ve now received the aluminium extrusions I’m going to use for the vertical posts in my design.  I ordered them from a place in Surrey, and was a amused to watch their delivery progress on the UPS website.  Amused, because they started their journey in Austria, stopped off in Germany, then briefly visited Barking, Tamworth and Dewsbury before ending up in Hull.  And I thought I was ordering from the UK.  Never mind, I’m now the proud possessor of three 1-meter lengths of extrusion, which looks like this (the penny is just for scale):

WP_20130215_005

A carriage (to be printed by Rob) will run up and down each of these posts, and will be linked to the print head by parallelogram arms.  I really must post an image of the design soon.

One metre length doesn’t sound much, but I have a suspicion that this printer is going to end up quite big.  This weekend’s tasks are to (1) cut the base and top of the assembly out of nice stiff plywood and (2) to assemble the RAMPS kit which will control the stepper motors.  It’ll be nice to get soldering again. 

WP_20130211_006 

The kit is very well packaged and looks a doddle to make, so it shouldn’t take long.  Once it’s up and running, I’ll put some firmware (probably Marlin) on to the Arduino and see if I can get it to drive the stepper motors.  Watch this space.  Unless you have better things to do, which I really hope you have.

Printer Claus has come to town!

As you know (because you follow my blog very closely), I’m building my own 3D printer.  Today I received a box of stepper motors, an Arduino Mega 2560 board and a RAMPS controller board kit.  These are the major items that I had to buy (rather than getting Rob to print for me).  Having spent actual money, I’m now really committed to building the printer.  Any day now I should receive the aluminium extruded sections I am using as vertical struts.  Watch this space.

WP_20130211_001

WP_20130211_004

Jumping Jack Flash

It’s a gas, gas, gas…

OK, so the title’s rubbish.  I’m open to suggestions for a better one which includes the word ‘gas’ or ‘meter’.  Except the Beatles song ‘From me to you’, of course, because that would be a dreadful pun.  And so to the point, which is that this blog post talks about using Gadgeteer kit to periodically read a gas meter, and send the data to a server for further use.

Continue reading “Jumping Jack Flash”

Breaking out of bondage

Let my inputs go!

The Gadgeteer system is great; there are loads of modules that you can easily use to do a range of interesting things. There’s a ‘but’ coming here, of course, and it is this: there’s no obvious way of connecting things which are not already Gadgeteer modules. For example, suppose you want to put a switch on your fridge door, so that you can trigger a Gadgeteer camera to take a picture of the person who is surreptitiously drinking all your milk. Or maybe you want to connect multiple switches, perhaps to determine the ammunition remaining in your USB missile launcher. The Gadgeteer buttons are not really suited to the task. Even if you can physically fit them where you want them, and you’ve got long enough cables, each module only has one switch on it. There’s a solution to this, and that’s what this post will start to cover – adding your own devices to the Gadgeteer system.

Continue reading “Breaking out of bondage”

Tracking fast moving targets with a Gadgeteer camera…

…is completely impractical.

In my last post, I briefly described a simple hack which allowed the Gadgeteer system to control the bearing and azimuth of an old USB missile launcher by using a joystick.  Manual control like this is all very well, but it would be much more entertaining if the systems could track a target automatically before raining down atomic retribution on it.  I use the words ‘would be’ advisedly, because as we shall see this is fairly impractical with the Gadgeteer kit I have to hand.  Even so, there’s a lot to be learned from the process of trying.

Continue reading “Tracking fast moving targets with a Gadgeteer camera…”

Nuclear armageddon

Or possibly sponge-tipped minor annoyance

In this post, I’m going to show you a little bit of interfacing the Gadgeteer system with the real world.  I’m going to do this by hacking an old USB-controlled rocket launcher which I picked up (from Marks and Spencer of all places) some years ago.

Continue reading “Nuclear armageddon”