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