My DIY motorized/timelapse head

Very nice work! I like your use of found hardware mixed in with machining =)

To be honest, the first thing you want to implement will likely be an option between continuous and SMS motion. Then, linear ramping of output speeds.

A big feature a lot of people like is to set the movie parameters, and then have the software work everything out, e.g.:

Movie: 24FPS frame rate, 30s long video, 2 hours "elapsed time", move 10 degrees up =

10 second interval
720 total shots
0.0014 degrees/second movement

!chris

No problem! I'm here to help *grin* SMS is "Shoot-move-Shoot" (or move-shoot-move, or interleaved... =) it refers to moving between shots, and not while the camera is exposing. Here's a brief article on some common motion types: http://openmoco.org/node/93 this is a good starting point for the three basic motion modes.

In all of my motion control stuff, I use the camera as the metronome - it is the core of my timing. That is to say, nothing happens (generally) if the camera isn't firing, in SMS mode, a completion of a shot triggers a move. In continuous mode, I generate all "end points" based ultimately on frames exposed, if I want a fixed length of time, I usually deduce it to exposures except in certain cases. (Like program run time keyframes in the TimeLapse Engine.) Basically, if you're not shooting - then you're not making a timelapse film, and you've got a good timing reference with your intervalometer.

Check out the documentation link at the top left to get an idea of some features you might want. The MX2 documentation describes a fairly simple system for DC motors, while the TimeLapse Engine docs describe a very complex, script-oriented system for steppers.

!chris

Oh, it was in the article =)

Quote:The number of steps between shots (s) is calculated as the spatial distance per step (d), the total distance to be moved (D), the seconds of video time to make the move over (T), and the frame-rate per second (f) of the output video. Or: s = (D / d)/(T * f).

note: there appeared to be a typo in my original formula in the article, where it divided time by frames

In this case, "spatial distance" is degrees, so if your encoder does 100 pulses per rotation of shaft, and 3 shaft rotations equal 360' rotation, then d = 360 / ( 100 * 3 ), or 1.2 degrees per "step" (step in this case being the smallest observable movement), so you just plug in the rest of the formula:

D = 180' (user input)
T = 30" (seconds, user input)
f = 24fps

steps between shots = ( 180 / 1.2 ) / ( 30 * 24 ) or, s = 0.2 "steps" between shots. (Obviously, you have to normalize to your minimum measurable distance.)

(The simple way of looking at this is, how many pulses it takes to travel that distances, divided by the number of frames you're going to take while covering that distance.)

The reason you use output video time and framerate is because your camera firing, or interval, is your metronome for the output video. Each shot is one frame, so to calculate the right rate of motion, it's based on how many frames you're shooting and how fast those frames playback in the final video. In this case, since you're doing SMS, it's completely irrelevant how much wall time is passing in real life, because time will only be observed when a frame is exposed.

You can include wall time by using it calculate the seconds between exposures required to reach the final output video, i.e.:

i = W / (T * f)

So, if I wanted 1 hour of wall (or "real") time to be elapsed into a 30s video:

i = 3600 / ( 30 * 24 ) or i = 5 seconds

Thus, to input my parameters as "30 seconds of video at 24fps, covering 1 hour of real time and moving 180 degrees," the end result is a 5-second interval and 0.2 steps between each shot.

!c