TLA – Program Operation, User Interface and notes on Time-Lapse Motion

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:

  1. Execute program
  2. Open camera shutter
  3. Delay exposure_time ms
  4. Close camera shutter
    1. Set interval elapsed time back to zero mS
  5. Determine which motors need to move
  6. Move motors prescribed amount
    1. motors can move at a rate of 2,000 steps/second
  7. Monitor interval time passed in mS
    1. If interval time passed >= shot interval time
      1. Open shutter, repeat cycle
    2. If interval time passed < shot interval time
      1. 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.


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.

TLA Control Specs:

Minimum Movement Pan/Tilt: 0.07 degrees

Minimum Movement Truck: approx 0.001 inches

Maximum Shot Interval Time: approx 36 days

Maximum Camera Exposure Time: approx 36 days

Minimum Exposure Time: approx 1/1000s

Minimum Shot Interval Time: approx 1/100s

Maximum Motor Shot Cycles to Skip: 255

Absolute Slowest Movement pan/tilt: 0.07 deg every 25.15 years

Maximum Truck Travel Distance: approx 32 inches

Maximum Pan Rotations: unlimited

Maximum Tilt Travel: undefined presently (still under construction)

Power Input: 12V @ Approx. 2.8A

~ by c.a. church on August 30, 2008.

7 Responses to “TLA – Program Operation, User Interface and notes on Time-Lapse Motion”

  1. Nice job. I can see some serious time investment there. Hope it works for you. I look forward to seeing the results.

    My project is stalled due to a lack of available shed time. Hey ho.


  2. 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 =)


  3. I’m not sure about your calculation for shutter frequency. If you want 1 hour of time to make a 60sec 24fps movie you need 60X24=1440 frames. You have 3600sec to do this, thats one shot every 2.5sec.

  4. Bert, you are correct – I mis-placed ‘r’ in the formula, it should be:

    I = r/(sF)

    I will correct the posting. (Trying to write too much in one go =)

    Thanks for pointing this out!


  5. […] – bookmarked by 1 members originally found by dobico on 2008-11-21 TLA – Program Operation, User Interface and notes on Time-Lapse Motion […]

  6. 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.

    Chris Jordan

  7. 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!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: