I’d like to take this chance to explain how the software works (as in, end-results, not a code analysis!) to facilitate motion control in the time-lapse automaton.

First, let’s talk about the essence of a dSLR time-lapse motion control system:

It must provide predictable motion in one or more axis (pan, tilt, dolly, truck, lift, drop, etc.)

This motion must occur at a rate relative to:

The overall distance to be moved (e.g. 5 inches, or 30 degrees)

The “real” time-scale of the time-lapse film (e.g. 1 hour)

The “perceived” time-scale (e.g.: film is 1 minute)

If motion occurs while the shutter is open, it must not move at a rate > 1 pixel during the exposure time

Measure of how much movement represents a pixel is based on sensor size and FOV of camera lens

e.g. if my sensor is 2000 pixels wide, and my lens has an FOV of 90 degrees, a movement of > 0.045 degrees during exposure time would result in movement of greater than one pixel

This prevents the perception of blur in non-moving objects, and increases output quality

There’s really not much more to it – you want to move, you want to control the rate you move, and you want to make sure that you don’t effect the quality of your output through movement.

Now, let’s talk about the TLA software:

Rather than worry about evaluating movement to prevent blur given the present exposure time, we make our movements between camera exposures. This means that it is literally impossible to introduce blur from programmed movement. This does, however, create a requirement that we know our exposure time and that we know when the exposure begins. To solve this requirement, we take control of the camera directly in the same microcontroller that operates the motors. This also means (for the current version) that we are limited to pre-programming our exposure time in the microcontroller. That is, we’re using ‘bulb’ mode in the camera. (I have already added support to the camera/motor controller to handle a manually-set exposure in the camera, but this is not yet supported in the UI. Later revisions will also include the ability to handle ramping exposures as light changes, such as day->night transitions.)

A Quick Break to Talk About Calculating Values:

Given that a time-lapse video is designed to compress a given length of “real” time to a final length of “perceived” time, we have to determine on what interval to create each exposure.

I = r/(sF)

(I being shot interval, s being seconds of “perceived” time, F being frames per second of output format, and r being the “real” time in seconds.)

So, if we want 60 seconds of output covering 1 hour of input, at 24 fps, we get:

2.5 = 3600 / ( 60 * 24 )

Or, more simply, we must fire a shot every 2.5s

edit: Thanks Bert for reporting the miscalculation in the original post

( The TLA software does not yet do this math for you, you must dial in the exposure time in ms and the interval time in ms. As I enhance the UI later, I’ll take care of these calculations internally. )

Ok, so what about motion?

For motion, we have to make a similar calculation for “continuous” motion:

M = t/r

(M being motion to be made each second, t being total motion occurring in the final film)

So, assuming we want to move 100 degrees (pan) in our 1-hour film:

0.028 = 100/3600

That means every second, we need to move 0.028 degrees.

And here’s the formula for calculating motion between shots:

M = t/(sF)

So, assuming we want to move 100 degrees (pan) in our sixty-second film at 24 fps, we get:

0.069 = 100 / (60 * 24)

That is, we need to move an equivalent of 0.069 degrees at or around each shot.

Therein lies the benefit of the ‘move between shots’ method, is that to extend our movement over a longer period of time (say 0.21 degrees in 15 shots) we only have to change the how often we move, not how fast.

edit: after some experimentation, this doesn’t always pan out. by reducing how often we move beyond once every other shot or so, the motion begins to seem jerky to the viewer. this is what experimentation is for =)

Back to the TLA Software:

The following describes the workflow for “bulb” (having the mC control the camera exposure time shooting) mode automation:

Execute program

Open camera shutter

Delay exposure_time ms

Close camera shutter

Set interval elapsed time back to zero mS

Determine which motors need to move

Move motors prescribed amount

motors can move at a rate of 2,000 steps/second

Monitor interval time passed in mS

If interval time passed >= shot interval time

Open shutter, repeat cycle

If interval time passed < shot interval time

Loop until interval time passed >= shot interval time

Note in there that we don’t delay() for interval time – the reason is that if we did, the total interval time would be (interval time + motor move time + any other code execution time between the delays). That is to say, if our interval is 1s, and it takes 250ms to move the motors, and 1ms to execute all the code between, then we end up with a total interval time of 1,251ms. That’s more than 25% greater than our expected interval time. In this design, the worst case scenario is that our interval time is either our exact interval, or the time (motor move time +any other code execution time) — which ever is longest. I like to call this optimistic intervalism as it is the interval most likely to match the interval you requested. Of course, you could put an interval in that neither your camera supports nor can you make the movements you desire in, in that case, you get the next best interval.

Now, earlier in the workflow, it states “determine which motors need to move” – there’s more to this than “just pan, just tilt, or just truck”. We can create even smoother senses of motion by spreading out our total motion on shot intervals. That is to say, we can say “move one step on every 5th shot.” This is referred to as the <motor> shot cycle in the TLA UI, where the name of the motor is shown. We can also control the motor direction.

So, the program configuration options available are:

truck move steps

truck end step

The final count of steps to take (stop moving here)

truck shot cycle

truck dir

pan move steps

pan start step

How many steps should the truck motor have taken before starting to move the pan

pan end step

pan shot cycle

pan dir

… you get the idea

Once a program is configured, it is transferred to the camera/motor controller by pressing ‘3’ on the keypad. A program can be started by pressing ‘1’, or stopped by pressing ‘2’.

It’s worth noting, that we can prepare the next program while the current one is running.

The following video shows us configuring and transferring a program:

Not only can a program be created and transferred, it can be saved to non-volatile memory (eeprom) or loaded from non-volatile memory. This allows the programs to be created in the field, or created at home and repeated later. There are 16 memory slots available (numbered 0-15), and you can save to them or read from them. You can also configure the remote unit to load a particular program slot automatically on startup.

The

So, What About Absolute Positioning?

Obviously, since we’re dealing with stepper motors, we can’t really say for sure where we are when the program begins. And, well, we really want to say where we begin, not necessarily where the last program left off. For this reason, a manual control mode is provided. It is entered by pressing ‘0’ on the keypad from the main screen. In this mode, we can choose which motor to move (‘5’ on the keypad), and a pre-set number of steps or continuous motion (0 steps are entered). Pressing ‘1’ moves the motor left and ‘3’ moves it right. If moving a pre-set number of steps, you are locked out of the UI until those steps are completed. If moving continuously, the UI is active, and you can stop by either pressing ‘2’ to stop, or ‘0’ to exit manual control.

Thanks Marcel – I was going to post a video yesterday, but some problems popped up in the first field test, as they usually do, and it didn’t look so great =) I’ve got a little time today to work on it, so I should have that worked out today, and a short video up.

I know what you mean about time – I have to admit, I’ve been neglecting other things while working on it, and that can’t last forever! The tilt stage will have to be delayed a while, as I promised the girlfriend I’d take care of some other projects around the house for a while (like cleaning it *grin*).

BTW, you had asked before what the ‘c’ in ‘c. a.’ stands for, I have to confess, most people I know just call me Church =)

wow! Really want to see results from this! I stumbled on this site looking for stepper motor control for doing timelapse. I also organize a timelapse film festival, going on its 6th year. Might be worth checking out.

Good stuff. I really like the needs-assessment. very clear, well organized, outlines all the variables, like a step not being more than a pixel during a shot/exposure speed! Good stuff.

Hi Chris! Thanks for the feedback! It’s interesting how small the whole timelapse world is — I’m working with one of your entrants (Jay Burlage) on a project. Hopefully, when I get to spend less time building time-lapse electronics, I’ll have more time out in the field to have something to contribute – next year, perhaps!