Slider

Camera Slider

A DIY camera slider with independent linear travel and continuous pan, controlled by an ESP32-C6.

Two stationary stepper motors drive a belt-and-gear mechanism that moves the carriage and rotates the camera platform. Program a move with the rotary encoder, or open Motion Studio in a browser to build keyframe sequences, preview camera motion, and track a fixed point in the scene.

The repository contains the mechanical design, printable parts, KiCad electronics, firmware, and assembly documentation. The current mechanical release is v06, with 10 mm belts and a compact motor bridge.

Mechanical files · Web interface · OLED controls · Electronics · Getting started · Русский обзор

CAD rendering of the v06 assembly. Watch the 37-second demo with English captions · Animation sources

Features

• Coordinated slide and pan. Set carriage position in millimeters and camera angle in degrees; both axes arrive together. Angles accumulate across turns, so 720° means two complete rotations.
• Timed or speed-based moves. Use a specific duration or a constant travel speed. Stationary pans use degrees per second.
• Standalone operation. An SSD1306 OLED and a rotary encoder provide HOME, manual movement, a local scenario editor, and controller settings without a phone or computer.
• Persistent local scenarios. The encoder's 2–8-point scenario is saved in ESP32 nonvolatile memory when an edited value is confirmed or a point is added/deleted.
• Browser-based Motion Studio. Create up to 64 keyframes and 16 target objects, with separate timing and tracking settings for each transition.
• Geometric object tracking. Keep the camera aimed at a fixed scene coordinate during a slide, with an optional framing offset. This uses known coordinates, not computer vision.
• Offline preview and JSON exchange. Scrub through frames, preview at different playback speeds, save named scenarios in the browser, and import/export JSON.
• Wi-Fi with a fallback access point. Save your network's SSID and password through the web interface. The controller reconnects automatically while its own access point remains available.
• Local hostname. Open slider.local on a network that supports mDNS, or use the controller's IP address.
• On-device execution. A running scenario continues if the browser closes or Wi-Fi disconnects. The web STOP button, encoder button, and USB console can stop motion.

Motion Studio

The controller serves its own HTML and JavaScript: no cloud service, account, or internet connection is required. The web interface supports English and Russian. Use the Language / Язык selector in the header; the choice is remembered in this browser. On first visit, Russian browser locales use Russian and other locales use English. OLED menus are in English.

The screenshots below show the actual interface running against a local documentation fixture. Positions, HOME state, SSID, and IP are demonstration data, not a live hardware test.

Scene preview and tracking

Choose keyframes on a top-down view of the rail, place target objects, and inspect the camera's orientation before moving anything. The solid camera is the preview; the dashed camera represents the position reported by the controller.

Each transition can use a duration, speed, or frame count. Frame-count timing is calculated as frames / FPS; it does not trigger the camera shutter. Continuous tracking can be enabled separately for each transition.

Try the included object-tracking example: a 600 mm slide around a target at X=300 mm, Y=200 mm over 180 seconds.

Manual movement

Enter an absolute X position and angle, then choose a duration or speed. The interface also provides motor arming, manual HOME, and switch-based homing.

Previewing or editing a scenario does not move the motors. To execute a scenario, establish HOME, validate it, move to its first keyframe, wait for the controller to become ready, and then run it.

Network settings

Enter your 2.4 GHz Wi-Fi SSID and password under Settings → Connection, then select Save and connect. The credentials are stored on the ESP32 and applied without a reboot. Use Forget network to return to access-point-only operation.

The CameraSlider access point remains enabled even when connected to a router. Failed connections, lost connections, and unfinished DHCP attempts are retried every 30 seconds. A channel change during connection can briefly interrupt an access-point client.

Open http://slider.local from the same local network. If mDNS is blocked or client isolation is enabled, use the IP shown in the connection panel or USB log. The hostname assumes one slider on the network.

What is saved where?

The encoder scenario and browser library are separate. Export JSON to transfer browser scenarios between devices or between the AP IP, LAN IP, and slider.local addresses.

Standalone control

Hold the encoder button for about 0.8 seconds to arm the motors. Turn to select an item; click to open it or confirm an edited value. A long press ends editing or returns to the main menu.

These are pixel-accurate outputs from the firmware's 128×64 display renderer, enlarged 3×. They are not photographs of a physical OLED.

For local scenarios, NEXT is the time from the selected point to the next one, from 1 to 3600 seconds. Confirm the edited field before switching off power: flash is written on confirmation, not on every encoder detent. A failed write shows SCENARIO SAVE ERROR and can be retried by confirming again.

During motion, the OLED shows progress, passed/upcoming keyframes, elapsed time, and time remaining. A completed move shows DONE. Pressing the encoder during ordinary motion requests a stop; pressing it during automatic homing accepts the current position as HOME.

Mechanical design and parts

The v06 design uses a 700 mm V-Slot 2020 rail, a four-wheel carriage, two 17HS4401S NEMA 17 motors, and a 1/4″-20 camera mount. Both motors stay at one end of the rail. The camera platform supports continuous mechanical rotation; the camera and any attached cables must allow it.

The rail length is not the usable travel. Set the firmware travel limit to the actual assembled clearance; the default is 600 mm.

Download and build

Detailed mechanical and electronics notes are currently mostly in Russian. Part IDs are consistent across the BOM, STEP/STL files, and CAD generators. Do not mix parts from different revisions.

The Fusion bodies are editable solids. Dimensions are reproduced by the Python generators; Fusion motion joints and a parametric feature timeline are not configured. Older designs remain under cad/ and manufacturing/ for reference.

Electronics

The controller combines a MuseLab nanoESP32-C6 v1.0, two TMC2209 modules, an SSD1306 I²C OLED, a KY-040 rotary encoder, and one optional normally closed HOME switch.

Open the project from the electronics/kicad/ directory so its local libraries resolve. The PCB contains manual layout/routing work. The electronics notes document a driver pinout correction and a required schematic-to-PCB review; archived manufacturing files and old DRC results do not certify the current board. Do not regenerate the PCB over those edits.

Firmware pin assignment

The firmware uses STEP/DIR control without TMC2209 UART. Each driver has its own enable signal. The default microstep settings are 1/8 for M1 and 1/32 for M2; set the firmware to match the physical MS1/MS2 straps. Software settings do not change the driver's electrical mode.

Use 12 V for motor power, the board's designated 5 V input or USB for the MCU, and 3.3 V for the OLED and encoder, with a common ground. Check module orientation, coil pairs, VREF/current, and the wiring guide before powering the motors.

Getting started

1. Review the BOM and print the fit coupons before the main mechanical parts. Follow the v06 assembly guide and check belt clearance and free movement.
2. Verify the electronics and set each driver's current and microstep straps. Connect the OLED and encoder; a HOME switch is optional when using manual zero.
3. Build and flash the firmware.
4. Set travel and calibration for your mechanism. Place the carriage and camera at the intended origin, arm the motors, and choose SET HOME HERE, or use automatic homing with a correctly wired switch.
5. Start with a short, slow move before trying a full scenario.

Build and flash

The firmware uses ESP-IDF 6.0.2, targeting ESP32-C6. From an activated ESP-IDF environment:

cd firmware
idf.py set-target esp32c6
idf.py build
idf.py -p /path/to/serial-port flash monitor

From the repository root, the Makefile provides the equivalent convenience commands:

make build IDF_PATH=/path/to/esp-idf
make upload IDF_PATH=/path/to/esp-idf PORT=/path/to/serial-port
make monitor IDF_PATH=/path/to/esp-idf PORT=/path/to/serial-port

IDF_PATH defaults to ~/esp/esp-idf-v6.0.2. Replace the serial port with your device's port, such as /dev/ttyACM0 or /dev/cu.usbmodemXXXX. Exit the serial monitor with Ctrl+].

Connect to the controller

Join CameraSlider and open its URL. You can then configure your own Wi-Fi network in Motion Studio. There is no automatic movement after boot, even when a saved scenario exists.

Development and validation

Run the firmware's host checks with a C compiler, Python 3, and Node.js:

python3 firmware/tests/run.py
node firmware/tests/test_web.mjs

The tests cover motion planning, coordinated motor stepping, encoder decoding, HOME and stop behavior, local scenario persistence, Wi-Fi retry/fallback logic with mocked ESP-IDF calls, and display rendering. The web tests cover scenario timing, tracking, JSON migration, and browser storage serialization.

The v06 mechanical package includes reports for solid geometry, belt clearance, gear engagement, motion combinations, and mesh integrity. These checks and host tests do not establish physical payload capacity, missed-step behavior, repeatability, or camera footage quality. The current firmware uses constant-speed motion without acceleration ramps; practical speed and load limits must be established on the assembled mechanism.

For full operating details, see the firmware guide. For screenshot provenance and regeneration, see documentation images. Third-party geometry references are recorded in the v06 source notes.