Fast Stacker (Arduino based automated focus stacking rail)

[pulsar123]

I assumed you'd set the counter (for an OS clock interrupt to handle), in the loop, so the processor's not doing nothing.
Several ways to skin the cat, I guess.

I find acceleration (ie a ramp) while trying to watch for focus, a bit annoying. Constant speed, perhaps for the first couple of seconds, would be more predictable and perhaps nicer to use.

You can't completely get rid of the acceleration ramp, as it is there in part to limit forces and torque on the rail bearings and the motor. Meaning you can't just switch from one (slow) speed to the next (faster) one instantly. And if one has to deal with acceleration anyway, I'd rather have it behave nicely (being either constant, or change linearly). I will report back on how convenient the "fixed third derivative ramp" feature is once I implemented it.

[mjkzz]

I am just curious how you determined that accuracy is 2.5um? Thanks.

[pulsar123]

I am just curious how you determined that accuracy is 2.5um? Thanks.

This is just the size of one microstep: one full rotation consists of 1600 microsteps of teh stepper motor, and moves the rail by ~4mm. I haven't tested if indeed this accuracy is achieved - I think I'd need higher magnification for that (my highest is 5:1).

[mjkzz]

Thanks. So the 2.5um is a theoretically achievable number. From my experience, when you get into micron world, construction of hardware matters a lot. For example, one key part of design (for me) is to keep the coupling between the moving block and the rail as tight as possible. I tried a few rails with two guiding rods, they all wobble at micro level, this is due to machining tolerance. So I finially build my own using industrial linear slider that has very tight specs, even the cheap Chinese one :-)

[pulsar123]

Thanks. So the 2.5um is a theoretically achievable number. From my experience, when you get into micron world, construction of hardware matters a lot. For example, one key part of design (for me) is to keep the coupling between the moving block and the rail as tight as possible. I tried a few rails with two guiding rods, they all wobble at micro level, this is due to machining tolerance. So I finially build my own using industrial linear slider that has very tight specs, even the cheap Chinese one :-)

I see. I am only dealing with magnifications up to 5:1, and the Velbon Super Mag Slider seems to be perfectly adequate for the task. I am happy with its minimal backlash - I estimate it around 50 um, not an issue at 5:1, but nevertheless I am implementing a proper backlash compensation in my software (it's done, but still buggy), if anyone will want to use my design for higher mags.

[pulsar123]

Anyone trying to reproduce my rail (or just contemplating it), please check this new page:

http://pulsar124.wikia.com/wiki/What's_new

(For some reasons, clicking doesn't work with the above link - you have to manually paste and copy it to your browser).

[nsomnius]

Thanks so much for the excellent write up and for sharing your elegant software. This system is really quite impressive in many ways, all the more so for it's novel (to me) approach that allows to use a less than rock solid, totally vibration free setup. I've ordered everything I didn't already have and plan to do my best to get this working. I'm going to try and use an IGUS Drylin rail rather than the rail you are employing. I've had good success with them in the past with my DSLR based array film scanner that's pulling ~4 lbs. https://www.flickr.com/photos/35334802@ ... 9166336275
The cost will be pretty much the same overall. That project was based off of Stackduino https://www.flickr.com/photos/reallysma ... 2341602394 and used optoisolators rather than relays. Is there a particular reason you went with relays over optoisolators? Of course they do the same job, I'm just curious.

Thanks for keeping us updated on your progress. I look forward to seeing the next revision.

[pulsar123]

Thanks for sharing the info - nice to know that more people are joining the club Makes me feel better about those countless hours I am spending on code development. (But to be honest, I do it because it is fun.) There is one person at dpreview who already assembled the electric part of my design and loaded my software, and it all seems to work.

No particular reason to choose relays - it is just something I had experience in the past. Not sure if it is cheaper than other approaches, perhaps just a bit.

Using a different rail is a bit of a risk factor as I have no clue if the motor will have enough of torque to drive it. You might end up doing some modifications to the design and software. In particular, I suspect one might trade off accuracy for torque, by hardwiring the motor driver to use larger steps (say, 4 microsteps per step instead of my 8 ). Also, one can always trade the maximum travel speed for torque, and that is very easy - just modify one parameter in my code.

I am almost done with my software v0.10, with a bunch of new features, so stay tuned.

[nsomnius]

I'm mostly interested in 1:1 or 1:2 magnification stacks so I think that should allow me to work with whole steps for the highest torque. The motor I'll be using is a little more powerful and will require a Big Easy Driver. I'm going to try the battery approach but I won't be heartbroken if I have to keep the unit plugged into the wall for adequate power.

I'm hesitant to say I know from looking at the code how whole stepping would be enabled. Will changing "const short N_MICROSTEPS = 8;" to "const short N_MICROSTEPS = 1;" do it or is there more that would need to be altered? I know how to set up the driver for whole stepping but the code has enough parameters that I'm starting to second guess myself : ). And while I'm asking, which parameter would I need to change to control the max travel speed? Is that "const float SPEED_LIMIT_MM_S = 5;" If so, what value would you suggest? I'd rather not guess at these things..

[pulsar123]

I'm mostly interested in 1:1 or 1:2 magnification stacks so I think that should allow me to work with whole steps for the highest torque. The motor I'll be using is a little more powerful and will require a Big Easy Driver. I'm going to try the battery approach but I won't be heartbroken if I have to keep the unit plugged into the wall for adequate power.

I'm hesitant to say I know from looking at the code how whole stepping would be enabled. Will changing "const short N_MICROSTEPS = 8;" to "const short N_MICROSTEPS = 1;" do it or is there more that would need to be altered? I know how to set up the driver for whole stepping but the code has enough parameters that I'm starting to second guess myself : ). And while I'm asking, which parameter would I need to change to control the max travel speed? Is that "const float SPEED_LIMIT_MM_S = 5;" If so, what value would you suggest? I'd rather not guess at these things..

You are correct with both suggestions - regarding N_MICROSTEPS and SPEED_LIMIT_MM_S, though I never changed the parameters so there is a small chance that changing them might trigger an unknown bug - hopefully not.

Be aware that increasing the step will generate more vibrations which could potentially show in your shots as blur. Reducing vibrations (and not higher step accuracy) was my primary motivation for choosing the smallest microstep size available.

And it is not just torque you should worry about once you start deviating from my parameters. Probably equally important is the timing constraint: you wanna make sure that the time interval between microsteps is larger on average than the Arduino main loop length. If you want to have timings as good as mine or better, the microstep time interval should be around 500 us or larger. The interval (in us) is computed as 10^6 * MM_PER_ROTATION / (MOTOR_STEPS * N_MICROSTEPS * SPEED_LIMIT_MM_S).

[pulsar123]

I am releasing a new major upgrade of my Arduino based focus stacking rail. It involves a slight hardware modification (a bit of soldering, only inside the control unit), and a significant software upgrade, with many new functions and improvements.

The detailed description of the changes can be found in my wikia tutorial:

http://pulsar124.wikia.com/wiki/What's_new

The whole tutorial has been updated to reflect the changes.


To summarize, the upgrade:


1) Makes the rail more accurate. (Backlash compensation; code profiling and additional coding to eliminate any skipped motor steps; different - slower - acceleration for rewinding and fast-forwarding helps to position the rail more accurately.)

2) Makes the rail more convenient. (Full-featured "Pause" functionality during stacking; new functions "Start stacking from the foreground point" and "Go to the last starting point")

3) Makes the rail more pleasant to use. (Custom bitmaps for different battery charge levels and the direction of the rail motion; hardware SPI interface makes the LCD 10x faster = smoother experience).

[ChrisR]

Sounds interesting - I shall have a look..

Hopefully a working link: http://bit.ly/1NW5h7m

[pulsar123]

Sounds interesting - I shall have a look..

Hopefully a working link: http://bit.ly/1NW5h7m

Thanks - this forum doesn't like links with an apostrophe...

[ChrisR]

Thanks - this forum doesn't like links with an apostrophe...

One of its many sensibilities

[pulsar123]

I have a question. On another forum, someone already reproduced my macro rail, but he really wants the traditional - slow - mode of stacking (move - stop - wait a certain time for the rail/mirror vibrations to settle down - take a shot - move again etc.), whereas I have only been focused on the "continuous" mode, which is much faster, and I believe should be as good, if one uses a flash at say 1/16 of the full power which should effectively freeze all the vibrations.

Do you think adding a non-continuous stacking mode would make my rail design significantly more attractive? It is actually very doable, probably would take 2-3 weeks to implement and debug.