Projects‎ > ‎

Motorized Camera Dolly

I've been interested in camera motion control for a while, and this project is my first foray into designing my own "MoCo" system.

This project is a collaboration with Mark Davis, another RIT student. He's the proud owner of a Dana Dolly, and has already used it with a hand operator for several of his projects. However, he's looking for some more precise control, and I'm hoping to work with him to provide it.

As an aside... I still remember the motion control system that first got me interested in all this. My father used to film stop motion animations of LEGO figures, and he built a miniature dolly for his camera. It's got a threaded rod running the length, so he can very slowly crank the camera between each frame. I sat there for hours next to him, moving the camera a half turn at a time between each frame. The rig's still in his shop, last time I checked.

Now, on a larger and faster scale, this project will hopefully bring motorized, computerized control to a professional camera dolly.

The Parts List:

After some research, a stepper motor seems like it's the way to go. An electric motor with some sort of position feedback (such as a rotary encoder) might have worked well, but the fine-tuned positioning of the stepper will hopefully allow me to have better control over the acceleration and deceleration of the camera. Plus, it's a great opportunity for me to learn more about stepper control!

The motor I picked is a KL23H286-20-8B stepper motor rated at 425 oz-in of holding torque. This should be more than enough torque to work with a heavy camera, such as the Arri D-21, even on moderate inclines and declines.

In order to drive it, I plan to use a BigEasyDriver (from Sparkfun, of course!). This is a bipolar stepper driver capable of providing up to 2A/phase.  While the motor's datasheet states that it is rated for 2.8A/phase, this is at 4.2 Volts. The BigEasyDriver's active current limiting allows the motor to be driven at a much higher voltage than the internal coil resistance would normally allow. There will be more on this later!

Update: I've had a lot of problems with the BigEasyDriver. It may simply be operator error, but I've burnt out four of them. With such a large motor on the driver, it seems that even very small accidental rotations of the motor create enough back EMF (current generated by the motor flowing through the part) to blow something inside the controller chip. I got sick of spending money on a new controller every time this happened (even after adding flyback diodes, etc.), so I switched parts.

My new stepper motor driver is the Probotix SideStep. It's a little bit more expensive, but if it doesn't constantly blow out it'll save me some money in the long run - plus it'll provide a little bit more juice if I find I need it.

I also purchased several mechanical parts, including two metal pulleys, some 3/8" fiberglass-reinforced timing belt, and some screws and the like to mount the motor, idler pulley, and timing belt.

The Brains:

An Arduino Uno R3 is going to be used as the primary controller for the project. The Arduino is a great tool to handle the low-level interface to the stepper motor and other sensors. The lack of an operating system running on the microcontroller means that inputs and outputs are "extremely" (for lack of a more quantitative term) deterministic. In other words, timing for input and output events is (with a few small caveats) guaranteed within a very small jitter. This will be important for timing the pulse rate going to the stepper controller!

There's some thought that eventually a high-level interface will be available for Linux. Run from a Raspberry Pi or other GPIO-capable Linux device, it would provide a way for a user to control the dolly. However, for now, I'm going to stick with getting the Arduino and its peripherals working.

For those interested, here is some additional information about the BigEasyDriver failure.

From Brian Schmalz, creator of the BigEasyDriver:

"The power supply is pretty protected because of the diode on the BED in the M+ line. However, the BED itself can be fried by back-driving the motor.

I've seen people solve this problem several different ways - mechanical clutches on the motor shaft so it can't be back-driven... or diodes from the motor coil lines to current limiting resistors (to dump the power)."

Even if you cut the jumper and power the logic side separately, you can still damage the high voltage driver side of the BED, I believe. "

The Controls:

In addition to the (proposed) Linux interface, a hardware control system is going to be available for use. This will allow an operator to move the dolly manually, and eventually provide a recording mode where the dolly's motion could be captured and repeated.

The main control is going to be a slide potentiometer. This will allow a

The part I am going to use is a Motorized Slide Potentiometer. This is a really cool part that allows the user to move the slide potentiometer back and forth to change the resistance through it, but in addition a small electric motor can drive it. I think this has a lot of potential for this system!

With the motor, I am hoping to be able to provide gentle pressure for the pot to move back to center - if the operator lets go, the dolly will slow and stop of its own accord! Further, I think a bit of "haptic feedback" if the dolly hits a limit switch will be a great way to warn the operator of some sort of problem. Finally, if the device is running in program mode, the user will be able to see the lever move to match the dolly's current motion. Perhaps even a manual override...? The list goes on.

The rest of the interface will be a few tactile buttons and a switch or two to control the rest of the device functionality. This will sort itself out as the project continues.

Comments