# Delta stage geometry

I was looking at the source code used for the Delta stage co-ordinate transforms. I was wondering what elements of the stage geometry are represented by the constants flex_a, flex_b and flex_h?

Hi @nicola

Thanks for bringing this up - it’s something that ought to have documentation but doesn’t yet. Hopefully a post here will go some way to fixing that!

There’s lots written about the kinematics of delta robots in general, if you’ve not come across them before - I recommend:

Those documents care about relatively large movements, where the various angles involved are quite large. We are constrained by the flexures only to bend through small angles (up to about 6 degrees, presently). This means that the small angle approximation is reasonable, and so we can simplify things a lot.

I’ve sketched what I mean by a, b, c, X, Y, and Z below, along with a rough schematic of the system’s geometry:

Firstly, if we want to move in Z, this is simple - just move all three actuators by the same amount, and the moving stage will follow.

To move in X, imagine looking at the system from the side:

Keep actuator c still, and move a and b by opposite amounts - this tilts the triangle formed by the links and the moving stage, and causes the moving stage to move in x. If the angle is small enough, it doesn’t move much in Z.

Y is slightly trickier - because now the distance between the actuators and the moving stage is not the same between a,b and c. That is why c must move twice as far.

The importance of the geometry becomes clear if we look at the triangle we’re tilting: the ratio between the actuator’s motion and the moving stage’s motion is set by the angle of the links, i.e. the ratio of flex_a and flex_h.

What’s flex_b then? That’s an implementation detail; the delta stage doesn’t actually have 1:1 actuation, because the actuating nut and the linkage are both on a lever, that gears down the motion of the nut slightly. That means that if the bottom of the linkage moves by a distance \Delta c the nut actually moves by \frac{\mathrm{flex\_b}}{\mathrm{flex\_a}} \Delta c. That means we end up with flex_b/flex_h rather than flex_a/flex_h, and we also pick up a factor of flex_b/flex_a for the Z axis (which would otherwise be 1:1).

However, the auto-calibration feature should take care of constant scaling (and indeed rotation) so there’s not really any need for all these scale factors. That’s just as well, because I’m fairly sure the values used there are not up to date with the current delta geometry! It might be simpler to remove the scale factors there, in favour of the ones calculated by the camera-stage-mapping plugin. I guess the only useful thing is that they relate your Z calibration to the one you can do for X and Y…

2 Likes

For the record, current values of the parameters should be:

flex_h = flex_z2 - flex_z1 = 70
xy_gain = 2
flex_a = lever_l= flex_h/xy_gain = 35
flex_b = nut_y = lever_l + 12 = 47


This is based on me reading parameters.scad and making an informed guess as to what the parameters in there mean. The variables I’ve mentioned above, except the three in the diagram, are all from parameters.scad.

2 Likes

Do you think we should update the values in the software to their true values?

I will also document those variables better.

I can’t see that it would do any harm, other than possibly confusing people who have already run the camera-stage mapping calibration because their calibration matrix will change. That’s probably not a major issue, though.

I’m not sure though whether it’s better to update the values, or just remove them - if we remove them, everything still works, and the CSM plugin sorts out the scaling factors. If we update them, they might get out of date again in the future, or we end up needing to make them configuration parameters…