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:
- The Rostock delta kinematics document and more generally the RepRap Wiki
- Further mathematical detail from a work by Robert Williams, Ohio University
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…