[Open-Source Engineering Preview] ESP32 Timelapse Box: External-Camera Smooth Timelapse for U1 and Klipper

[Fat_cat]

After quite a bit of development and testing, I have released the first version of the ESP32 Timelapse Box.

The goal is to let a Snapmaker U1 or another Klipper printer control an external camera for layer-by-layer timelapse photography, without requiring a PC-side listener during the print.

The complete workflow has now been tested with a Snapmaker U1, ESP32-S3, and Sony ZV-E10.

How It Works

SnapOrca generates a capture command for each layer
  → Klipper runs the ESP_TIMELAPSE_SHOT macro
  → ESP32 reads the event from Moonraker over Wi-Fi
  → ESP32 triggers the camera over Bluetooth LE

USB is only needed to power and configure the ESP32. Once setup is complete, no computer-side listener is required while printing.

Current Features

• Active Sony camera pairing from an ESP32-S3
• Automatic reconnection to a previously paired camera
• Klipper event monitoring through Moonraker
• Chinese/English browser configurator
• Chrome/Edge Web Serial setup without Electron
• Dry-run, armed, and camera-ready safety states
• Traditional and Smooth timelapse modes
• U1 native timelapse and external-camera capture can run together
• Compatibility with earlier ESP32-C3/CyberBrick shutter hardware
• Klipper macros, firmware, configurator, and documentation included
• Project source licensed under GPLv3

Capture Modes

Traditional Mode

After each completed layer, the slicer waits for motion to finish and triggers one frame. The toolhead is not moved to a dedicated parking position, so it may appear in the image.

Smooth Mode

After completing each layer, the printer:

1. Finishes the model and stabilization-tower work
2. Raises the Z axis
3. Moves the toolhead to a fixed parking position
4. Waits for all motion to finish
5. Triggers the external camera
6. Returns to the model at a safe clearance height

Smooth mode generates a real stabilization tower for both single-material and multi-material prints. It requires additional bed space, filament, and print time.

Real-World Test Results

I completed a 135-layer, multi-material Smooth timelapse print:

• Klipper generated 135 capture events
• The Sony camera saved 135 frames
• The toolhead was parked away from the model for each frame
• Stabilization-tower, tool-change, and final-layer cleanup ordering worked correctly
• U1 native timelapse and Sony external-camera capture ran simultaneously
• The ESP32 restored its Sony connection after a power cycle
• Automatic reconnection did not accidentally trigger the shutter

A finished timelapse video and photos of the U1, ESP32, and camera setup can be inserted here.

Download and Documentation

The main repository contains the firmware source, release downloads, Klipper macro, browser configurator, complete English and Chinese guides, troubleshooting information, and the experimental multi-brand camera probe:

GitHub - MOVIBALE/esp32-timelapse-box: Klipper layer-triggered camera timelapse box for...

The experimental SnapOrca 2.3.5 build with Traditional and Smooth timelapse integration is available here:

Release Snapmaker Orca U1 Experimental 2.3.5 alpha.1 · MOVIBALE/OrcaSlicer

Current Limitations

This is an engineering preview and is not an official Snapmaker feature.

The Sony ZV-E10 is currently the only camera that has completed the full hardware-validation process. Other Sony cameras exposing the same BLE remote-control service may work, but they still require real-device testing.

The repository also contains separate experimental community-test firmware for Canon, Fujifilm, Nikon, and Ricoh cameras. It currently supports manual scanning, pairing, and shutter testing only. Klipper automation is not yet enabled for these cameras.

Smooth mode requires space for its stabilization tower. Large models that fill most of the build plate may need to be repositioned or scaled. Traditional mode remains available when there is not enough room for the tower.

Testers Wanted

The project currently needs feedback for:

• Other Sony camera models
• SnapBridge cameras such as the Nikon D850
• Canon, Fujifilm, and Ricoh Bluetooth cameras
• Klipper printers other than the U1
• Windows and macOS browser-configuration workflows

When reporting results, please include the camera model, ESP32 model, printer model, firmware version, and a sanitized diagnostic report. Do not publish Wi-Fi passwords, private IP addresses, or Bluetooth device addresses.

The project is still under active development. Testing, issue reports, protocol research, and code contributions are welcome.

[xchrisd]

Thanks for sharing!

[CrazyIvan]

While not wanting to dis this, surely it would be more effective to mod the firmware to do this with the built-in facilities?

[Fat_cat]

Thank you for the suggestion. I also considered modifying the U1 firmware directly, but this solution actually involves two separate issues.

First, according to the currently available U1 specifications and documentation, the machine officially supports 2.4 GHz Wi-Fi and USB, but there is no documented Bluetooth functionality for connecting to a phone or an external camera. Even if the main controller itself may support Bluetooth, it would still require compatible hardware, drivers, pairing and bonding, automatic reconnection, and support for the remote-control protocols used by different camera brands. Therefore, I cannot currently confirm that modifying the firmware alone would allow the U1 to connect directly to an external camera.

Second, smooth time-lapse photography involves much more than simply triggering the shutter once per layer. The slicer must generate a stabilization tower, determine when the current layer, filament changes, and purge operations have actually finished, and plan safe Z-lift, parking, capture, and return movements. These operations depend on information such as the model position, printable area, purge tower, and complete G-code toolpaths, which is primarily available to the slicer. Firmware or Klipper macros can execute movements and trigger the camera, but it would be difficult for them to independently and reliably generate a stabilization tower or handle collisions, multi-material changes, and the final layer during printing.

My current architecture is therefore divided into three parts: SnapOrca handles the smooth time-lapse slicing and motion paths, a Klipper macro forwards the capture event, and the ESP32 connects to and controls the external camera. This avoids deeply modifying the printer firmware and also makes the solution easier to adapt to other Klipper-based printers.

If Snapmaker eventually provides full support across the printer hardware, firmware, and slicer, that would certainly offer a more integrated solution. I would also be happy to investigate further if anyone can share documentation about Bluetooth hardware or relevant firmware interfaces built into the U1.

[CrazyIvan]

Apparently I was under the naïve impression we were talking about simply making sure the toolhead was parked out of the way and taking a snap from the built-in camera once per layer. You seem to have something much more sophisticated in mind, and I have no idea what a stabilisation tower is.

[Fat_cat]

Sorry, I used an inaccurate term earlier. This is not a separate “stabilization tower.” It is the existing Prime Tower used by OrcaSlicer and Bambu Studio. In my Chinese interface, it is translated as “Wiping Tower.” Besides multi-material changes, it can catch nozzle oozing during the pause for a smooth time-lapse frame and help restore stable extrusion before the toolhead returns to the model.

The difference between the two modes is:

• Traditional mode: After each layer is completed, the photo is taken at the toolhead’s current position. It is faster and does not require an additional Prime Tower solely for the time-lapse, but the toolhead appears at different positions in each frame.
• Smooth mode: After each layer is completed, the toolhead moves to a fixed safe or parking position before the photo is taken, then returns to continue printing. This keeps the model and toolhead positions more consistent between frames and produces a smoother video, but it adds movement, waiting time, material usage, and overall print time.

So your understanding is essentially correct: the main idea is to move the toolhead away before taking one photo per layer. My implementation also uses the Prime Tower to handle possible nozzle oozing while the toolhead is away from the model and to reduce the chance of that oozing affecting the model surface.

[Zoe_M]

Hi, thank you for sharing this project with us.

If Snapmaker eventually provides full support across the printer hardware, firmware, and slicer, that would certainly offer a more integrated solution. I would also be happy to investigate further if anyone can share documentation about Bluetooth hardware or relevant firmware interfaces built into the U1.

Appreciate the suggestion! Thanks a lot

There were similar requests like UI or Top cover CAD files during the Innovation Fund program, and the team politely declined at that time. If you could elaborate on exactly what you’re looking for regarding Bluetooth hardware or firmware interfaces, I’d be glad to check with our engineers.

[Fat_cat]

Thank you for offering to check with the engineers. After reconsidering the architecture, I should clarify that my current project does not actually require access to the U1’s Bluetooth hardware or any additional firmware interface.

SnapOrca generates the Smooth timelapse motion, Prime Tower, and toolhead parking path. A Klipper macro sends the capture event over the local network, while the external ESP32 handles Bluetooth pairing and camera-specific shutter-control protocols. The complete system is already working without modifying the U1’s underlying firmware.

The question about the U1’s Bluetooth hardware came up because another user suggested using the printer’s built-in hardware and firmware instead of an external ESP32. I was only trying to determine whether that alternative was technically possible, rather than requesting Snapmaker to implement it.

In practice, keeping this functionality on the ESP32 may be a cleaner and more extensible design. It keeps camera-specific Bluetooth pairing, shutter-control protocols, and support for different camera brands or trigger methods separate from the printer firmware. These capabilities can then be developed and updated independently, while the same accessory can also be used with other Klipper-based printers.

If the team already knows whether usable BLE hardware is present, I would still be interested to hear the answer, but there is no need to investigate or expose a new interface specifically for this project.

Thank you again for your interest and support.

[Simon_Zhi]

Good！I’m going to give it a try！