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:
- 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…
3 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.
3 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…
Did someone work on implementing the kinematics into the firmware directly?
mbe the arduino nano isn’t good enough though for dealing with floating points.
I’ve never tried - given that we’re only ever dealing with one move at a time, it seemed easier just to keep it in the Python. In principle you could; I’m just not sure there would be much of an advantage.
I am looking into alternative uses of the delta stage.
Maybe we find some other people interested?
I started to work on a patch with puredata (pd), which is a creative software tool for sound art, VJing or other fun things.
I worked with this loooong time ago and used some motion tracking for microscopic animals…
1 Like
I have made the delta stage recently. But I am not able to control the stage in delta coordinates properly. Does anyone have the proper code for delta coordinate controlling?
@adam1 welcome to the forum. I am not completely clear what you mean. Can you give a few more details of how you are controlling the stage, is it using the web app (in a browser, or through the Openflexure connect) or using one of the other methods? Do you mean that you ask the stage to move on the x-axis say and it does not move in that direction? Or it will not move at all? or it moves, but along the wrong axis?
Which software version are you using? It is in the about section of the web app, the current version is v2.10.1
as in you can give it cartesian coordinates, and it moves correctly in xyz, but you’d like to move each axis independently? I don’t think the microscope server offers a way to do that, but if you use the pysangaboard module directly from Python (i.e. without the microscope software) I think it only works in axis coordinates, and doesn’t do any conversion.