1. Computer Skills
  2. Electronics

Motion Control With Arduino: Motorising a Camera Slider

Read Time:22 minsLanguages:

The availablility of cheap stepper motors and drivers these days allows ample opportunity for experimenting outside of the more expensive and complicated 2D/3D cutting and printing projects. 

For this project, I'll take the OpenBuilds camera slider (refer to the build video in Building a Basic Video Slider With Open Source CNC Parts) and motorise it. I’ll also create a self-contained system for controlling the motor.

This tutorial specifically covers putting together the hardware, but primarily building a rudimentary 16x2 LCD GUI using the LiquidCrystal library and a simple menu system for it to display, followed by the workings of of the A4988 stepper driver and how to control it with Arduino. 

This project is heavy on loops and steps, and while overall the project is more intermediate, I've tried to explain it in such a way that beginners can be up and running relatively quickly.

Equipment List




  • Computer with Arduino IDE (I use Win7, Arduino 1.0.5 r2)
  • Soldering iron with small chisel tip, solder, etc
  • 2.5mm allen key for M5 screws
  • 2mm allen key for M3 screws
  • 1.5mm allen key for set screws in GT2 pulley
  • multimeter for troubleshooting and current adjustment
  • Narrow pliers for tightening in small spaces

Functional Overview

I'll cover adding the motor and pulleys to the slider, stringing the belt around and fastening it all up. It's a simple modification. 

Then I'll cover how to put together a Pololu A4988 Black Edition kit and how to wire it up on a breadboard along with all the other external boards, as well as a simple plywood enclosure I knocked together in a few minutes for my 12V power supply (listed above) in order to prevent shocks as the wiring terminals are exposed.

Sideways so it remains large enough that the pin numbers are still visible!

The menu allows input of distance to travel, time to travel, number of steps to travel in and direction of travel. At the end of each step, the slider pauses while the camera is triggered.

Modifying the Slider

Step 1: Motor Assembly

The OpenBuilds V-Slot Actuator End Mount has NEMA 17 dimension holes in it, so four 30mm M3 cap head screws are all that's required to mount the motor to it.

The OpenBuilds V-Slot Actuator End MountThe OpenBuilds V-Slot Actuator End MountThe OpenBuilds V-Slot Actuator End Mount
The OpenBuilds V-Slot Actuator End Mount

Ensure the 20-tooth GT2 pulley is inside the mount before you slot the motor shaft in, as the mount isn't wide enough to add it on afterward. Once the motor is screwed on at the bottom, tighten up the set screws with one of them against the flat part of the motor shaft, ensuring that the teeth are directly in line with the centre of the whole extrusion unit.

Step 2: Idler Pulley Kit

The idler pulley kit goes together just like a wheel kit, and slots into the opposite end Actuator Mount:

The idler pulley kit

Step 3: Belting Up

Feed the belt through the centre of the V-slot in line with the pulleys, ensuring the teeth are facing up. 

Then feed it up and over the two pulleys and bring it back into the middle to the dolly build plate.

Feeding the beltFeeding the beltFeeding the belt
The teeth grip into each other.

Here you wrap one side through the belt slot and clamp, or zip-tie it, then use that to tighten the entire belt through the whole system before connecting the other side. Not too tight for the motor to turn, but not loose enough to skip teeth on the drive pulley!

Assembling the Electronics

Step 1: Assemble the Stepper Driver

The Pololu A4988 Black Edition Stepper Motor Driver (technically the A4988 carrier board- the A4988 is the chip itself) typically comes in kit form, which simply means that the headers have to be soldered on. Since this is a power component, even though it is not driving the unit at its maximum capacity, it's a good idea to add a heatsink to help enhance its lifespan.

Break the header row in half to have two rows of eight. Slot these into the plated through holes in the board, and then slot this carefully into the breadboard. Solder the pins in place while the breadboard holds everything nice and perpendicular.

Putting together the Stepper DriverPutting together the Stepper DriverPutting together the Stepper Driver
Putting together the Stepper Driver

Once this is complete, cut off the corner of a small self-stick heatsink using a hacksaw or scrollsaw (carefully, in a clamp!) to mount to the A4988 IC.

Cut off the corner of a small self-stick heatsinkCut off the corner of a small self-stick heatsinkCut off the corner of a small self-stick heatsink
Cut off the corner of a small self-stick heatsink

Step 2: Breadboard-Mount the Components

Now everything needs to be mounted to breadboards so that it can be wired together into a functioning cicuit. I'm using separate boards for each part for the sake of clarity in images, but feel free to fit it all into a single board if you wish.

The LCD keypad shield cannot be mounted to a board, thanks to Arduino's strange choice to adhere to a design flaw rather than meet standards. This will be kept separate, though screwing it to a piece of wood or something to protect the pins might not be a bad idea.

The camera trigger circuit at its most simple consists of a resistor, a transistor and a 2.5mm TRS sub-mini plug. I've added a LED that will blink when the trigger pin spikes high, and a 3.5mm TRS mini jack in order to allow flexibility. 

If you're buying components for this build, a 3.5mm socket designed for 0.1" pitch boards would be a good idea, but mine is from the scavenged pile so I've soldered a connector to it instead.

Lay everything out, ready to wire it all up.

Step 3: Wiring Everything Together

Time to grab all of the jumper cables. Having enough to keep things colour coded will make life easier when troubleshooting. Refer to the circuit diagram at the top if the following description confuses you at any point.

Wiring Everything TogetherWiring Everything TogetherWiring Everything Together
Wiring Everything Together

First wire up the LCD. Grab 10 female jumpers and connect them to the following shield pins: digital pins 4-9, power bus pins reset (if you want to use the LCD reset button), 5V & one of the GNDs. 

If you have female-to-male jumpers, you can leave it there. Otherwise, connect male jumpers—to the other end of the females—in order to plug them into the corresponding Arduino header sockets. If you have an LCD keypad shield which has passthrough female headers installed on top, you can skip this step since your shield isn't blocking anything.

Next, the Pololu A4988 board. This needs eight jumpers on one side, I've used black and red for logic/motor power at easch end, and red/green/blue/yellow in the centre four to match up with the stepper motor's servo leads. 

The logic power pin goes to 3.3V on the arduino, as the LCD above is using the 5V pin. The motor power leads go to your 12V power supply. On the other side, near the A4988 chip, I'm using blue and orange for STP and DIR respectively to contrast with the relatively uniform colours everywhere else. They go to Arduino pins 11 and 12 respectively, unless you modify the code. Then short RST and SLP together to keep the board enabled; I've used the white lead here.

When youre done it should look something like thisWhen youre done it should look something like thisWhen youre done it should look something like this
When you're done, it should look something like this.

Finally wire up the camera trigger switch circuit. Here the black wires are ground- the A row wire to Arduino, the C row wire to the 3.5mm socket. The yellow goes to Arduino pin 13 (so there's an LED indicator on the board as well as at the switch!), and the red wire goes to the other side of the 3.5mm socket (or 2.5mm plug lead if you're going that route).

Plug the stepper motor into the coloured wires according to the A4988 board diagram and your stepper's datasheet. For me, that was like this:

Like the button reader the test rotation sketch is included in the zip up topLike the button reader the test rotation sketch is included in the zip up topLike the button reader the test rotation sketch is included in the zip up top
Like the button reader, the test rotation sketch is included in the zip up top.

Caution: remember that the wires providing power to the motor will probably be pulling 1-2A at your chosen voltage, so ensure the wires used are rated for it. The A4988 chip and board around it may get hot! The potentiometer built into the board provides current limitation to protect both the A4988 and the motor, so ensure you set it appropriately before use using a multimeter.

Setting Up The Program

Once the components have been assembled, you can move to the coding. Download the zip included with this tutorial, or check this GitHub respository if you prefer. I’ll describe how I put it together so you can understand the general program flow and how the modules work together.

Step 1: Includes and Basic Definitions

The only include necessary for this was the LCD writing library LiquidCrystal.h. This gives access to the lcd.xxxx() functions. There's a pow() in the program, and I found that including the C++ library math.h isn't necessary as a few of its most helpful functions are included in the stock Arduino environment, including pow().

I set the LCD output pins, the stepper driver output pins, and the camera trigger output pin. Once the actual hardware interface is set up, I added variables for button events followed by the button-reading function, which I adapted from the DFRobot wiki on their identical LCD keypad shield. Note that SainSmart provides no documentation.

Step 2: Setup() Loop

This is super straightfoward. Initialise the LCD and relevant output pins, followed by a basic welcome screen, then drop into the home screen: menu option 1 with values zeroed.

Step 3: Monitor Buttons

The advantage here coding-wise is that the equipment doesn't need to do anything at all without user input. Which means that the very first thing can simply be an eternal button poll loop. Calling the readLcdButtons() function over and over until its value changes doesn't negatively impact program performance, and you don't need to worry about leaving interrupt pins available.

ReadLcdButtons() has a delay of 90ms in order to debounce the buttons. In actuality, this isn't a debounce, as it doesn't re-take the ADC measurement after a set amount of time, but rather polls the buttons infrequently enough to rarely register more than a single click. 

It achieves the same thing from a practical UX view. It's more of a poll buttons every 90ms rather than constantly, which is why use of delay() is generally not considered good practice for debouncing purposes, but it fixed the problem (only each end of menus were accessible).

Step 4: Screen Refresh

Once the unit can react to input, there needs to be a way for it to display those reactions. 

After trying on-the-fly updates, I determined that consistent screen refresh like a real OS was easier to manage in my attempts at a modular upgradeable structure. Doing this is as simple as clearing the screen, then rebuilding based on known current parameters.

This sounds complicated, but in practice makes life much easier. It removes a large number of LCD commands from elsewhere in the program, and creates a variable-type-agnostic zone which is minimally affected by program updates external to it.

The actual refreshing part evolved to consist of four distinct steps:

Reset parameters...

...print the top line...

...print the bottom line, which I'll explain a little later...

...and add screen-specific commands over the top of what's already printed.

Building A Menu: Main Headings

Naturally, that exact screen refresh section doesn't write itself, and we need to know the menu it's writing to screen before it can be completed. The main headings are easy, since they don't actually change depending on user input. This means it can simply be a string array- technically a char pointer array, or an array of arrays:

This means that this menuItemsTop array can be navigated simply by altering the number inside the square brackets at screen refresh time. Which just so happens, since everything is zero-indexed, to track identically with the integer currentMenuItem

Manipulating currentMenuItem on button events allows us one-dimensional navigation, so when you see menuItemsTop[currentMenuItem] it's obviously current menu heading.

So you can move left and right, and go into a menu, or in the case of Go! then motion control is activated. Which is all that's required here.

Building A Menu: Submenu

The submenu system took a little more doing, thanks to its internal complexity. The first three entries, Distance, Duration and Steps, technically consist of a sub-sub-menu, each allowing navigation of the multi-digit value as well as each individual character.

This is covered by making each submenu entry a switched heading system in its own right. While this was a long way around, it's a simple and consistent method of allowing such low-level navigation. Since I really just figured out the Distance submenu and then copied it over for the other submenus, here's a look at that one.

Left and right are essentially the same as the top-level menu, simply moving back and forth along the number in the same way, by having the number actually be a set of digits in an int array and the current location stored in an int called currentCursorPos which allows blinking as seen in the screen refresh module above. 

Printing these arrays along the bottom LCD row is what the for loops were for in the screen refresh section; i from 0 to 3, LCD column from 0 to 3, currentDistance[] from 0 to 3.

Increasing and decreasing the number is achieved by storing the current digit in the variable currentChar, which is then passed to the adjustDigit() function along with a boolean value indicating direction; to increase or decrease the motor. 

This simply adjusts the digit according to the boolean value and saves the result, whereon flow returns to the main loop, where the currentChar value is saved back into the correct position of the original currentDistance[] array and the new adjusted digit is printed at screen refresh.

Parsing Display Array Values

When Select is hit from one of the number array submenus, it triggers the relevant parsing function- in this case parseArrayDistance(). You need to parse the array, used to conveniently display and edit, into an integer useful for actual motion calculations. I chose to do this now rather than on Go! to keep UX feeling snappy.

I came up with this function from the one useful passing comment I found after exhausting Google looking for standard array-to-int functions, coming up empty, and getting rid of the mess of array-to-char-to-int functions that were an ineffective workaround. It seems fairly short and light given that it's literally based on the foundation of decimal mathematics, but if you know a better method, I'm all ears.

Motion Control and Camera Triggering

All the values are set and you hit Go! What happens next? You need to calculate exactly what the numbers given to it are supposed to do in order to run the final motion. This part is functional, but a work in progress; I feel there need to be more options for different types of motion.

What's happening in this function is fairly clear from the commenting, I think. I've put a shutterDuration of 2 seconds in the software, mainly to keep testing fairly rapid. If you're shooting at night, at lower ISOs, this might need to be more like 25-35 seconds depending on your exact shutter speed.

The pulseDelay is multiplied by 1000 at the end to convert from seconds to milliseconds, of course. The L to convert the constant int to a long is more me erring on the side of caution than actually being strictly necessary. Since it's a relatively small sketch, I'm not overly concerned about variable memory usage.

These calculations assume that the loop itself requires a negligible amount of time to run in comparison to the pulseDelay time, which, once I took out the button polling, appears to be true.

Lastly, note the currentSteps value set at 1. I haven't created an error-checking function for this, but simple common sense says stepSize becomes infinite if currentStepsInt == 0, so it's best to keep it at one if continuous motion is desired. I added an improvement entry for this already.

Running the Final Product

For something running on code written more or less from scratch in two days and bugfixed over two more, it works like a dream! The proof is in the pudding, though. Does it actually get worthwhile timelapse footage, and does the control unit really work well in the field?

In my tests, the answer appears to be a whole-hearted yes. Below is a two-hour, 650-frame timelapse, the very first test. The slider also completed a 9 hour 720 frame test flawlessly, but unfortunately the camera battery didn't do so well after 2 hours in ...which I didn't find out until the 8.5 hour mark, naturally.

If I set the time and steps appropriately, the motion can be continuous for slow dolly moves in live action video, though the jerky ends need editing out or speed-ramping. 

Sound may be an issue unless your stepper is very quiet, but for adding production value to self-recordings, it's an option.


As with anything, there are possible improvements to be made. I've listed these at the top of the .ino file, though admittedly without particular care over feasibility nor ordered by any kind of importance. 

Some of these I considered fixing prior to releasing this tutorial with v0.2, but I feel like they in themselves are a learning experience to look at in terms of mentally dismantling the usability of a program.

These are just the improvements I've thought of so far, in an effort to guide the codebase from a rudimentary but functional v0.2 towards a more optimised and more capable release v1.0. You may notice more. Feel free to leave them in the comments below or on GitHub.

Wrapping Up

If you've followed from beginning to end, including the Photography Tuts+ portion of the build, you're now the proud owner of a high quality motorised camera slider that can produce timelapse footage and subtle dolly moves. If you're using the code for some other project, I'd love to see it.

In this tutorial, I've looked at different forms of loop-based flow control, creating a rudimentary GUI and updating an LCD based on user input. I also looked at simultaneously controlling multiple external mechanical devices via breakout boards. 

You've seen the flow and ease of programming modular code, as well as seeing ideas for how to improve code that is functional, but not optimised, both from UX and processor efficiency standpoints. These tools should serve you well for a variety of communication- and interaction-based projects in future.

Please leave any questions or comments the comments below!

Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.