Hi all,
I’ve been trying to solve this in the software instead of adding extra sensors. As the stage moves over a sphere cap, it seems a good approximation that the stage is centred when it’s at its highest position in z, which we can track on a flat-ish sample
In the video above, you can see the height of the stage as a function of xy. Hopefully soon we’ll have some scanning code that (optionally) compensates for this z travel when performing long xy moves
If anyone wants to test my code to recentre, you can get it from Joe Knapper / height_map · GitLab. It runs in a couple of minutes, prints the estimated xyz centred position, and moves there. When I’m running multiple long scans now, I always recentre between scans using the coordinates from this.
Although this doesn’t detect the limits of the ROM, every OpenFlexure Microscope should have the same range. If you’re always starting from that point, I should be able to measure the limit on my v7, and share it so people can set a hard limit - no moves are permitted outside of that range. Some of the code that me and @r.w.bowman have been working on can also detect when the stage doesn’t move properly during a movement; there’s no guarantee that’s because of the limited ROM, but it can still flag something to the user
Comments, questions and testers welcome
7 Likes
NICE! That is very clean data. This seems like a great way forward. How, well does it perform when you are near the edge, I have found it is much much harder to fit a turning point if the turning point is outside the data. I suppose in that case it can move to its best estimate and run again?
What do you mean by outside the data sorry? If it starts so close to the edge that it hits the limit of the ROM?
In your example you have the height mapped in an area, and you find the max:
I am wondering how well it performs if the maximum is outside the scanned area. Do you fit a sphere cap or look for the maximum in the area? If you do fit, does it still work well (as often fitting algorithms struggle to find turning points outside the data range). i.e. which of these positions does it find?
The recentering code will run until it passes the peak, which I then reset as [0,0,0] and return to after every scan. For the fitting, I’ve done separate quadratic fits in x and y. Even though movement in x and y should be the same, I’ve found the fits are slightly different
I think even if it’s a small scan like in your examples, you should centre your stage first, because the parasitic z movement is less towards the centre, giving you a better chance to autofocus within the 2000 step range
1 Like
It’s worth mentioning that @siddons has done some very cool work on magnetic encoders, but I have been very bad at finding the time to support this with modifications to the microscope body. These would give (approximate) read-out of where we are at any time, which is attractive - but at the cost of making the build a bit more fiddly, and requiring more custom electronics. One of these days I’ll get time to build one…
Hi Richard, I thought the project had dies from lack of interest, so I haven’t done much more on it. I did modify and build a delta stage using it, and it performed as expected from my earlier study. Then I broke a hinge! I even got as far as designing a new motor board with the 4-channel ADC included, but then got distracted by setting up a screen-printer / reflow oven to build it 
I know that the residual errors (+/- 10um) seen in the device come from unwanted motions of the actuator out of the actuation plane. I recently came across a 3D magnetometer chip, which, in principle, means I could measure the complete trajectory of the actuator, and maybe correct the errors. It is an i2c device, so wouldn’t need the ADC. Unfortunately it only has 1 i2c address, so some tricks would be needed to mount three of them. But like Richard, time is hard to find, so I have a PCB to support it on the actuator shell but haven’t built one yet. I thought I sent you the OpenSCAD model with my mods; did you receive it? I’m sure you found the code ugly
It did seem to me that knowing where you are to this precision, instantly from power-up, would remove the need for homing completely, but I’m not a real user, so I could be wrong.
Thanks for chiming in and sorry again I’ve failed to find time to do anything with it. Part of my reason for mentioning you was so anyone interested could see what you’ve done and express an interest to work with you to take it further… Sadly that’s unlikely to be me in the near future, as there are too many other things that are more urgent.
Knowing where you are would definitely make both homing and crash detection much easier, and would help manage big scans - it’s just a question of whether the additional complexity (another custom PCB, slightly fiddly magnet insertion) is likely to appeal to most people building it. A thought does occur to me that if you have a 3D chip, would it be able to track the stage directly (rather than each axis individually)? That would probably be better for a number of reasons. I guess the question is what range you’d get if you were moving in 3D…
Out of pure curiosity, could you explain or provide a link to help me understand how you arrived at the z compensation formula: z_diff = int(-1.3 * 10**-6 * r** 2 + 3.5 * 10**-2 * r)" ?
Thanks in advance.
Looks like a polynomial fit to compensate for the Z component induced by the flexures.
I also assume its from a fit.
I just did my back of the envelope calculation for the sphere and think it should be
z = -8.2e-7 r^2
from first principles. 8e-7 and 1.3e-6 aren’t a million miles away (it’s late so I wouldn’t say I haven’t missed a factor of 2 or root 2 somewhere). The r term implies that the the sphere cap isn’t perfect or isn’t perfectly aligned.
FYI @JohemianKnapsody,
z_diff = int(-1.3 * 10**-6 * r** 2 + 3.5 * 10**-2 * r)
would be better as
z_diff = int(-1.3e-6 * r** 2 + 3.5e-2 * r)
As you aren’t making python calculate powers of 10 just to save a float.
Would be interesting to parameterize the fit by x and y rather than r, to see what the xy coefficient ends up being.
1 Like
Hi, @j.stirling and @tkircher are right, that’s just the values measured when I ran my calibration
As Thomas says, I think an xy fit makes more sense, that’s what I’ve been working on recently. To give a sneak peek:
It’ll use the position of autofocuses to fit a sphere cap to the stage, move to the centre of it and save parameters for z against x and y separately.
Measuring the ROM is based on work by our future PhD student Ben - moving along an axis until the offset according to the motors and the camera drops, which suggests its reached the limit of the ROM
Can measure these fairly reliably with the right sample, just trying to work out where to then use the calibration data in the rest of the software
I suppose the thought is that the position is stored permanently so as long as the microscope isn’t disassembled or run outside the ROM (causing skipped steps) then it should know where it is.
I suppose one option would be to use this number to stop it running to the end of the travel?
It would be interesting to put an option in the software where it notifies you to do a recentre every X days (perhaps once a month or once a week). It would then be interesting to see how much this drifts over time and whether it correlates with the number of steps taken in between (if this sort of data is saved).
We can run these sort of analytics on our own microscopes. We could also have an option for others who want to to send these reports to us.
Aside about telemetry- click to read
One idea we had in a different group for different software was a telemetry extension that can be installed by the user. This way not only is telemetry opt-in, but also there is no telemetry code on your machine unless you go out of your way to install it.
This way if people do want to contribute back to the project by sharing data they can, but we can offer this without adding telemetry to the core code base.
Yeah the plan is for the z compensation to be baked into some moves (like when scanning) and the ROM measurement to be a limit on travel. I more meant we’re working out at what level to put that logic, and how easy it should be to overrule
telemetry
I like the idea of the self reporting being an additional, non standard download. The reporting joins a host of open questions about connecting to a network, where I think the other big one is how to make updating the software as easy as possible
