Camera Slider 0.1

Used and Abused

Exploiting the old printers brought up some useful stuff. First of all, of course some functioning stepper motors like this little buddy here:

It’s a Mitsumi M35SP-11NK LF stepper motor (link to specification sheet of the manufacturer) from an old printer/scanner.

As we have two of the all-in-one printers, we decided to use the second one with the stepper motor attached to the scanners linear slider for a first prototype.

Linear slider from scanner unit
Linear slider from scanner unit

The motor is driven by an Electrely L298N dual H-bridge board (Amazon link). Everything works. Thanks. Bye.

Fast Forward and Rewind

Everything worked. Probably a year ago. If you read the last blog post regarding the RaspiBlitz you will notice some similarities. Anyway, let’s start from scratch. Make photos. Search the specifications of the stepper motor and the L298N driver board. Build the manual triggers at the breadboard and the code for the Arduino. But this time with proper documentation (Just wait for next years blog post).

How to document stuff? This site should be just fine. In addition, I noticed quite a few maker use Fritzing, an open source tool to make hardware projects more accessible (see their website: Let’s give it a try.


I started with the triggers for later back and forth movement of the slider. The result looks like this: Fritzing schematics on the left, photo of the triggers on the right and code below. The Fritzing project including description, schematics and code can be found here.

Arduino Code:

int TrigRght =3;
int LightLft =12;
int LightRght=13;

void setup() {
  // put your setup code here, to run once:
pinMode (TrigLft, INPUT);
pinMode (TrigRght, INPUT);
pinMode (LightLft, OUTPUT);
pinMode (LightRght, OUTPUT);

void loop() {
  // put your main code here, to run repeatedly:

  if (digitalRead(TrigLft)==HIGH)
      digitalWrite(LightLft, HIGH);
  if (digitalRead(TrigRght)==HIGH)
      digitalWrite(LightRght, HIGH);

  if (digitalRead(TrigLft)==LOW)
      digitalWrite(LightLft, LOW);
  if (digitalRead(TrigRght)==LOW)
      digitalWrite(LightRght, LOW);

Wow! feelsgoodman.jpg. Everything in one place. Let’s move on (pun intended).

Is this a slider?

The motor driver and the stepper motor itself have to be connected next. Connections for both can be googled. A comprehensive explanation of the L298N can be found here.

In principle it is also possible to distinct between the two coils of the stepper motor by yourself. Just shortcut two of the four connectors until you find a combination that makes it harder to move the motor by hand. These two connections belong to the same coil. The other two belong to the second coil. Coil one is connected to OUT1 and OUT2 of the L298N board; coil two to OUT3 and OUT4. The colors of the wires in the schematics below connecting the stepper motor are chosen to match the actual stepper motor cable colors.

Anyway, the result looks like this:

As the Mitsumi motor requires up to 24V, an additional DC power supply is required. As you noticed, the 5V input of the L298N board is not connected. Reason is we kept the 5V enable jumper in place, and therefore, used the L298N internal voltage regulator to generate the 5V necessary to drive the logic circuitry.

The complete Fritzing project including the Arduino code can be found here. In real life it looks a little messier… BUT … it works.

Driving the slider with the manual triggers

By the way, this is maximum speed and it required 0.3A at 24V from the DC power supply to run the stepper motor. Driving the motor at these settings for as long as seen in the video results in a blistering hot motor.


However, this thing might certainly be a very, very basic slider, despite the fact that there is so much room for improvement (I tried to collect some of the improvement potential somewhere below.).

Agile project development

The original plan was to build a working end point detection at the start and end of the slider route next. With this one could image the program finding the slider limits first in some sort of initialization process defining the maximum number of possible steps for the motor. That would also help calculating the amount of steps per image in the later timelapse and, last but not least, allows the implementation of some sort of safety mechanism, preventing the slider to push further and further into the limits.

Without the end point detection the maximum range had to be measured manually. It is 64 revolutions with each revolution consisting of 96 steps. That’s 6144 steps for the whole slider range.

Make some videos

However, the curiosity was just too big. So I gently put my camera on the slider and moved it around manually a bit. The camera is super unstable without any mount (–> to do list) but hey, who cares.

As speed is not key in our application, the tests were carried out at low stepper motor speeds requiring only 5V DC and 0.2A. I decided to go for a two hour time lapse with images obtained every thirty seconds. That’s 240 images in total and the same amount of stepper movements in between. Our total slider range of 6144 steps divided through 240 stepper movements results in 25 steps of the motor per stepper movement. All the variables can be found in the code section of the Fritzing file.

Finally, I started the cameras time laps program and approximately fifteen seconds later the slider by pressing the right manual button. And here it is, the first video of our test slider:

Do you see the movement?

I have to admit, the actual slider motion is hard to observe. But if you look closely for example at the left edge of the video it’s very faint to see. This can be done better. Below you can see the second test. It is basically the same view but this time with some objects in the foreground and some blurry stars in the background. Next time the focus has to be also on the actual camera settings.


One problem came up during the test. It looks like the clocks of the camera and the Arduino are running quite differently. After one hour the time difference of approximately 15 seconds between the Arduino and the camera was completely used up. I do not know which one was faster, but this calls for synchronization (–> to do).


So far, so good. That’s it. The slider slides. It’s the best slider 0.1 that we could build. Let’s see if there will be a version 0.2. Maybe it will implement some of the following slider improvements proposals (SIPs):

  • end point detection
  • camera mount
  • overall stability
  • synchronization of slider movement and camera shutter release
  • automated calculation of steps per image as function of time lapse overall time and length of the slider route
  • longer slider route
  • more compact design
  • more axes for camera motion