Timelapse en tu Neptune 4 sin tocar el firmware: cámara USB + Raspberry Pi

Conectas una webcam al puerto USB de tu Elegoo Neptune 4, la impresora la reconoce sin chistar… y en la pantalla no aparece nada. No hiciste nada mal: el programa que debería entregar el video viene instalado de fábrica, pero está esperando un archivo de configuración que Elegoo nunca creó. Ese detalle explica la mitad de las preguntas que circulan en los foros sobre este tema.

En esta guía vas a resolver las dos cosas que la gente busca cuando le pone una cámara a la impresora: ver el avance en vivo desde el sofá y grabar un timelapse donde la pieza crece capa por capa. Ninguna de las dos requiere flashear firmware ni reemplazar el sistema de la impresora. Al final vas a saber elegir la cámara correcta, ubicarla donde el video sirva de algo, decidir si necesitas un Raspberry Pi o no, y dejar el stream registrado en Moonraker para que Fluidd lo muestre solo.

Todo está armado sobre una Neptune 4 Plus con firmware original, pero funciona igual en cualquier impresora con Klipper y Moonraker.

Por qué la impresora ve la cámara y no la muestra

Cuando enchufas una webcam UVC en el puerto USB de la Neptune 4 Plus, el Linux interno la levanta como /dev/video4 con el driver uvcvideo y formato MJPEG hasta 1920×1080. Puedes comprobarlo desde cualquier equipo de la red, porque Moonraker publica la lista de periféricos:

curl http://<IP-de-la-impresora>/machine/peripherals/video

O sea: el módulo del kernel está, la cámara está, y el streamer también. En /home/mks/mjpg-streamer/ hay un mjpg-streamer ya compilado y un servicio webcamd heredado del proyecto OctoPi, activo desde el arranque. El problema es que ese servicio busca su configuración en /home/mks/klipper_config/webcam.txt, y en el firmware de fábrica ese directorio no existe. No encuentra nada, escribe "Goodbye" en el log, systemd lo reintenta unas cuantas veces y se rinde. Los puertos 8080 y 8081 quedan cerrados.

Esa es la razón por la que anda dando vueltas un webcam.txt en GitHub y en los foros: no es parte de una instalación, es el archivo que le falta a un servicio que ya está ahí.

Con eso claro, tienes dos caminos honestos:

La regla es simple: si solo quieres mirar, no necesitas el Pi. Si quieres grabar, sí.

Qué cámara sirve (y por qué el MJPEG no es un detalle menor)

Cualquier webcam USB que cumpla el estándar UVC y entregue Full HD en MJPEG. Y conviene que tenga foco fijo: un autofoco reenfoca cada vez que el cabezal se mueve, y en el timelapse eso se ve como si la imagen respirara.

El MJPEG no es un capricho. La cámara entrega los cuadros ya comprimidos como JPEG y ustreamer simplemente los deja pasar. La alternativa, YUYV sin comprimir, obliga a comprimir en software. y en el Raspberry Pi 5 eso duele, porque perdió el codificador de video por hardware que tenían los modelos anteriores.

Y hay un segundo motivo que el tutorial original no menciona: el ancho de banda del bus USB. Un cuadro YUYV de 1080p pesa 1920 × 1080 × 2 bytes ≈ 4 MB. A 30 cuadros por segundo son unos 124 MB/s. USB 2.0 entrega, en el mejor de los casos, alrededor de 35 MB/s útiles. Por eso una cámara UVC que solo ofrece YUYV en 1080p te da 5 fps y no 30: no es que el procesador no dé abasto, es que físicamente no cabe por el cable. En MJPEG el mismo cuadro pesa entre 100 y 300 KB y el problema desaparece. Cuando revises los formatos de tu cámara, esto es lo que estás buscando.

¿Y por qué no la cámara oficial del Raspberry Pi?

Los módulos de cámara del Pi tienen más resolución. el Camera Module 3 llega a 12 megapíxeles contra los 2 de una webcam Full HD. , pero para un video en 1080p eso da exactamente lo mismo. Al lado de una impresora pesan más tres cosas prácticas:

• El cable. El flex de la cámara del Pi mide entre 15 y 50 cm, y no tolera bien ni dobleces ni vibración. Una webcam trae 1,8 m de USB, así que el Pi puede quedar donde no estorbe.
• El montaje. La webcam viene con pinza y rosca de trípode. El módulo del Pi es una placa desnuda.
• La carga de cómputo. El módulo entrega datos crudos que hay que comprimir. La webcam ya entrega JPEG.

Dónde poner la cámara: cinco reglas que definen el video

Esto importa más que cualquier parámetro del script. Cinco reglas, cada una aprendida de un intento fallido:

1. Fíjala a algo que no se mueva. Trípode, pinza de mesa o el perfil vertical fijo de la impresora. Nunca al eje X ni al carro Z: ahí la cámara sube junto con el cabezal, la vista queda siempre a la altura de la boquilla, y la pieza no crece hacia arriba sino que la cama se hunde.
2. Desde arriba en diagonal, no de perfil. Unos 20 a 30 cm por sobre la cama, inclinada lo suficiente para que la plataforma quede como superficie en el centro del cuadro. La pantalla de la Neptune y todo lo que esté delante de la impresora no van en la toma.
3. La pieza tiene que ser suficientemente grande. Con 95° de diagonal y unos 56° en vertical, a 30 cm de distancia los 1080 píxeles cubren unos 32 cm de alto: 3,4 píxeles por milímetro. Un clip de 10 mm ocupa 35 píxeles, o sea una mancha. Desde unos 5 cm de altura, y en un color que contraste con la cama negra, recién se convierte en video.
4. En una impresora de cama móvil, la pieza viaja. La Neptune 4 mueve la cama en Y, y con ella la pieza cruza el cuadro. Ubica la cámara al costado, mirando perpendicular al eje Y: así la pieza se desplaza lateralmente sin cambiar de tamaño.
5. Haz un recorrido de prueba antes del primer print. Mueve la cama a mano desde Fluidd al mínimo y al máximo de Y, y confirma que la pieza siga en cuadro en todo el trayecto y que nada choque con la cámara.

Este es el resultado de ignorar la regla 1. Son seis capas del mismo print, con la cámara montada en el carro Z:

Las primeras capas muestran la cama desde arriba; al final la cámara mira la pieza de canto. La perspectiva se corrió sola durante toda la impresión, sin que nadie tocara nada.

Camino A: cámara en el Raspberry Pi

El Pi queda al lado de la impresora, la webcam colgando de su puerto USB, y todo lo demás pasa por la red. Cuatro pasos, ninguno toca la impresora.

Paso 1: preparar el Raspberry Pi

Instala un Raspberry Pi OS limpio con el Raspberry Pi Imager, configurando ahí mismo las credenciales de WiFi y activando SSH. No necesitas escritorio: OS Lite basta, porque vas a manejar todo por SSH. Después instala los tres paquetes:

sudo apt update
sudo apt install -y ustreamer ffmpeg v4l-utils

ustreamer ya viene como paquete listo en las generaciones actuales de Raspberry Pi OS, así que compilarlo desde el código fuente. como indican guías más antiguas. ya no es necesario. Tu usuario debe pertenecer al grupo video para poder abrir la cámara; el que crea el Imager ya lo está. Verifícalo con groups.

Antes de seguir, revisa la alimentación. Esto no está en el tutorial original y es la causa número uno de fallas raras en un Pi 5: si la fuente no entrega los 5V/5A del estándar USB-C PD, el Pi limita la corriente de los puertos USB y la webcam se desconecta sola en medio de una impresión. El síntoma es un stream que muere sin explicación. Compruébalo con vcgencmd get_throttled: si devuelve algo distinto de throttled=0x0, tienes un problema de fuente, no de cámara. Un cargador de celular genérico no sirve acá, aunque el conector calce.

Paso 2: conectar la webcam y verificarla

Enchufa la cámara y mira con qué nombre de dispositivo apareció:

v4l2-ctl --list-devices

Muchas webcams se anuncian con varias entradas, porque además de la cámara a color traen una infrarroja para reconocimiento facial. La de color suele ser /dev/video0. Para confirmarlo y ver qué formatos soporta:

v4l2-ctl -d /dev/video0 --list-formats-ext

Lo que buscas es una entrada MJPG con 1920x1080 y 30.000 fps:

ioctl: VIDIOC_ENUM_FMT
	Type: Video Capture

	[0]: 'MJPG' (Motion-JPEG, compressed)
		Size: Discrete 1920x1080
			Interval: Discrete 0.033s (30.000 fps)
			Interval: Discrete 0.042s (24.000 fps)
			…
	[1]: 'YUYV' (YUYV 4:2:2)
		Size: Discrete 1920x1080
			Interval: Discrete 0.200s (5.000 fps)

Fíjate en el contraste: MJPG a 30 fps, YUYV a 5 fps. Ese es exactamente el límite del bus USB del que hablábamos más arriba.

Los nombres de dispositivo cambian entre reinicios. /dev/video0 no garantiza que sea la misma cámara después del próximo arranque. En las webcams con cámara infrarroja el problema es peor: ambas reclaman el mismo nombre bajo /dev/v4l/by-id/, y quién se lo queda lo decide el orden de arranque. Si un día el stream aparece en negro, es esto. La ruta confiable está en /dev/v4l/by-path/, que incluye puerto USB e interfaz: la cámara a color es la que termina en 1.0, por ejemplo …-usb-0:1:1.0-video-index0. Mírala con ls -l /dev/v4l/by-path/ y usa esa ruta en lugar de /dev/video0. La única condición es que la cámara se quede en ese puerto USB.

Paso 3: levantar el video en vivo con ustreamer

Para probar basta una llamada en el terminal:

ustreamer --device=/dev/video0 --format=MJPEG --resolution=1920x1080 --desired-fps=15 --host=0.0.0.0 --port=8080

Abre http://<IP-del-Pi>:8080 en el navegador. La página de inicio enlaza el stream en /stream y una foto suelta en /snapshot —ese snapshot es justamente el que va a usar después el script de timelapse.

En la salida del terminal, al arrancar, aparece la línea Switching to HW encoder: the input is (M)JPEG. Esa es la confirmación de que los cuadros pasan sin recomprimirse. Quince cuadros por segundo sobran para mirar una impresión; más solo carga el WiFi.

Para que el stream vuelva solo después de cada reinicio, déjalo como servicio de systemd. Crea /etc/systemd/system/ustreamer.service con sudo nano y ajusta el nombre de usuario si el tuyo no es pi:

[Unit]
Description=ustreamer - MJPEG stream from the USB webcam
After=network-online.target

[Service]
# use the stable by-id path if you have more than one video device: ls -l /dev/v4l/by-id/
ExecStart=/usr/bin/ustreamer --device=/dev/video0 --format=MJPEG --resolution=1920x1080 --desired-fps=15 --host=0.0.0.0 --port=8080 --persistent --slowdown
Restart=always
RestartSec=3
User=pi

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now ustreamer
systemctl status ustreamer

Dos opciones del servicio están puestas a propósito: --persistent deja a ustreamer corriendo si la cámara deja de responder un momento, en vez de terminar el proceso; y --slowdown baja la cámara a un cuadro por segundo mientras nadie mira el stream. Para el timelapse, que de todas formas pide una foto cada varios minutos, eso no cambia nada.

Paso 4: registrar la cámara en Moonraker

Moonraker mantiene una lista de webcams conocidas, y de ahí se sirven tanto Mainsail como Fluidd. Registras la cámara del Pi con una sola llamada, desde cualquier equipo de la red:

curl -X POST http://192.168.178.67/server/webcams/item \
  -H "Content-Type: application/json" \
  -d '{"name": "Pi Webcam", "service": "mjpegstreamer", "stream_url": "http://192.168.178.50:8080/stream", "snapshot_url": "http://192.168.178.50:8080/snapshot", "aspect_ratio": "16:9", "target_fps": 15}'

Reemplaza las dos direcciones por la de tu impresora y la de tu Pi. Ojo con el puerto: en la Neptune 4 la dirección de la impresora va sin puerto (http://<IP>), porque Elegoo puso Moonraker detrás de un servidor web en el puerto 80. En instalaciones normales de Mainsail o Fluidd es http://<IP>:7125.

La respuesta es un JSON con el registro nuevo, y curl http://<IP-de-la-impresora>/server/webcams/list te lo muestra después. La interfaz web de la Neptune 4 no es otra cosa que Fluidd. Elegoo lo entrega sin modificar, solo con otros colores. , así que la tarjeta "Cámaras" aparece de inmediato en el dashboard:

Si prefieres hacer clic antes que escribir, Fluidd tiene el diálogo equivalente: engranaje arriba a la derecha → Configuración → Cámaras → Agregar cámara. Ahí pones nombre, tipo MJPEG Streamer, URL de stream http://<IP-del-Pi>:8080/stream, URL de snapshot http://<IP-del-Pi>:8080/snapshot y relación de aspecto 16:9. Va a parar exactamente a la misma lista de Moonraker.

Y hasta ahí llega Fluidd con una cámara: la muestra, no la graba.

Camino B: webcam directa a la impresora, sin Pi

La Neptune 4 Plus es en sí misma un pequeño computador Linux: una placa MKS PI con núcleos Cortex-A53, 1 GB de RAM y un Armbian basado en Debian 10. Para el video en vivo sobra, y como Elegoo ya trae el streamer, no hay que instalar nada. Tres pasos, todos reversibles.

Paso 1: habilitar SSH desde la pantalla

Elegoo dejó un camino oficial para esto. En la pantalla táctil: Ajustes → Advanced Settings → ROOT.

Aparece un descargo de responsabilidad de cuatro puntos que confirmas marcando I accept the risks of root login.

Después de "Enabling Root", la pantalla muestra las credenciales: usuario neptune4, contraseña elegoo3dp.

Con eso entras desde cualquier equipo de la red:

ssh neptune4@<IP-de-la-impresora>

El usuario pertenece al grupo video y puede usar sudo con la misma contraseña. El directorio home sigue llamándose /home/mks pese al nombre de usuario, y ahí vive todo lo que compone Klipper, Moonraker y Fluidd. No toques nada que no conozcas; para la cámara solo necesitas el paso siguiente.

Paso 2: crear el webcam.txt que falta

El directorio donde el servicio busca su configuración no existe, así que lo creas y escribes el archivo dentro. La ruta del dispositivo va por puerto USB e interfaz en lugar de por número, para que sobreviva a los reinicios: ls -l /dev/v4l/by-path/ en la impresora te la muestra, y la cámara a color es la entrada con 1.0-video-index0. No uses la ruta by-id si tu webcam tiene cámara infrarroja: puede quedarse con el mismo nombre después de un reinicio, y entonces mjpg-streamer arranca con el dispositivo equivocado y aborta.

mkdir -p /home/mks/klipper_config
cat > /home/mks/klipper_config/webcam.txt <<'EOF'
camera="usb"
camera_usb_options="-d /dev/v4l/by-path/platform-xhci-hcd.0.auto-usb-0:1:1.0-video-index0 -r 1920x1080 -f 15"
camera_http_webroot="./www-mjpgstreamer"
camera_http_options="-n"
EOF
sudo systemctl reset-failed webcamd
sudo systemctl restart webcamd

Unos segundos después mjpg-streamer queda escuchando en el puerto 8080, y el nginx de la impresora lo publica en /webcam/ sobre el puerto 80. esa redirección Elegoo también la dejó lista. Compruébalo en el navegador: http://<IP-de-la-impresora>/webcam/?action=snapshot entrega una foto, y ?action=stream el video.

En el log /var/log/webcamd.log van a aparecer al arrancar unas líneas UVCIOC_CTRL_MAP - Error. Son comandos de control antiguos de Logitech que tu cámara no conoce, y no molestan.

Paso 3: registrar la cámara en Moonraker

Igual que con el Pi, pero como el stream y Moonraker corren en la misma máquina, basta una ruta relativa:

curl -X POST http://<IP-de-la-impresora>/server/webcams/item \
  -H "Content-Type: application/json" \
  -d '{"name": "Neptune Webcam", "service": "mjpegstreamer", "stream_url": "/webcam/?action=stream", "snapshot_url": "/webcam/?action=snapshot", "aspect_ratio": "16:9", "target_fps": 15}'

Listo: video en vivo en el dashboard, sin un segundo equipo.

Qué le cuesta esto a la impresora

Medido con mjpg-streamer corriendo en la Neptune 4 Plus: 1,0 % de un núcleo mientras nadie mira, 2,9 % con un espectador en el stream, y 11 MB de RAM. Klipper se mantuvo sin cambios, en poco menos de 2 %.

Una diferencia respecto del Pi: mjpg-streamer lee la cámara permanentemente, aunque nadie esté mirando. ustreamer en cambio se autolimita en reposo gracias a --slowdown. Para la impresora da lo mismo.

Lo que este camino no puede hacer es grabar. La impresora no tiene ni el espacio ni un componente de timelapse, y agregarlo significaría meterse en el Moonraker antiguo que Elegoo modificó. Para eso está el Pi.

Cómo volver atrás

Todo lo que cambió este camino es un archivo y un registro en base de datos:

rm /home/mks/klipper_config/webcam.txt
sudo systemctl restart webcamd
curl "http://<IP-de-la-impresora>/server/webcams/list"        # lee el uid del registro
curl -X DELETE "http://<IP-de-la-impresora>/server/webcams/item?uid=<uid>"

Con eso la impresora queda como salió de fábrica.

Timelapse: detectar la capa sin tocar el firmware

El camino habitual para un timelapse por capa bajo Klipper se llama moonraker-timelapse: un componente en la impresora que, mediante una macro del slicer, dispara una foto en cada cambio de capa. En el firmware de fábrica de la Neptune 4 no existe.

El enfoque de este tutorial da vuelta el problema: el script corre en el Pi y solo necesita de la impresora lo que Moonraker ya le cuenta a cualquiera en la red.

Cómo se detecta la capa

Moonraker entrega el estado de la impresora como JSON en /printer/objects/query. Con dos valores alcanza: print_stats.state dice si está imprimiendo (printing, paused, complete), y gcode_move.gcode_position trae la posición actual en coordenadas de G-code, incluyendo Z.

Klipper también reporta el número de capa en print_stats.info.current_layer, pero solo si el slicer lo envía con SET_PRINT_STATS_INFO. En el perfil de ElegooSlicer probado (versión 1.5.3.4, un derivado de OrcaSlicer) ese campo viene en null. Por eso el script trabaja con la altura Z.

Y ahí está lo interesante, porque "Z subió, entonces hay capa nueva" no funciona. En cada desplazamiento sin extrusión la impresora levanta un poco la boquilla (Z-hop, 0,4 mm en el caso medido). Lo que hace el script es juntar los valores de Z de una ventana de tiempo y quedarse con el mínimo: ese es el plano sobre el que la máquina está imprimiendo de verdad, porque los saltos y los viajes solo pueden subir Z, nunca bajarla.

El tamaño de esa ventana costó dos intentos:

• Con cinco segundos, un viaje largo por encima de la pieza contaba como capa nueva, porque la boquilla estuvo arriba durante toda la ventana. Y peor: el umbral quedaba fijado demasiado alto, así que hasta que la impresión real alcanzaba esa altura no se tomaba ni una foto más.
• La solución fueron veinte segundos, más que cualquier viaje, más una autocorrección: si el mínimo queda por debajo de la altura de capa recordada, esa altura recordada era un viaje, y el valor se arrastra hacia abajo en vez de esperar una capa que nunca existió.

Cómo calcular tu propia ventana. Veinte segundos funcionan para la mayoría de las piezas, pero el criterio real es: la ventana debe ser más larga que el viaje sin extrusión más largo de tu impresión. Si imprimes piezas anchas y separadas, ese viaje cruza toda la cama. A 150 mm/s de velocidad de desplazamiento, cruzar 300 mm toma 2 segundos; con múltiples objetos y retracciones, una secuencia de viajes encadenados llega fácil a 10 o 15. Si ves capas duplicadas o fotos que desaparecen a mitad de la impresión, sube la ventana antes de tocar cualquier otra cosa.

El tercer tropiezo está al comienzo de la impresión. El G-code de inicio hace el homing, palpa la cama y estaciona el cabezal bien arriba mientras calienta. a 100 mm en el caso medido. Moonraker ya reporta printing en ese momento, y la primera foto habría clavado el umbral en 100 mm. Por eso el script espera a la primera extrusión (print_stats.filament_used mayor que cero) antes de mirar Z siquiera. Y el salto del final, cuando el cabezal sube a estacionar, lo descarta con un límite MAX_JUMP.

Tres fotos por capa, y el cabezal desaparece

Una sola foto por capa tiene un defecto estético: el disparo cae justo en el instante en que empieza la capa nueva, y ahí el cabezal está en cualquier parte. a veces justo delante de la pieza. A lo largo de cientos de capas, termina bailando por todo el video.

La solución del script es tomar tres capturas por capa separadas por ocho segundos (SHOTS_PER_LAYER y SHOT_GAP), escribiendo la posición del cabezal en el nombre del archivo:

l00005_s1_x0046_y0108.jpg
l00005_s2_x0282_y0217.jpg
l00005_s3_x0281_y0183.jpg

Capa 5, tres capturas: el cabezal una vez a la izquierda en X = 46 mm y dos veces atrás a la derecha.

Al renderizar, el script conserva una sola por capa según la regla que le indiques: x_min toma siempre la captura con el cabezal más a la izquierda, x_max la más a la derecha, y_min e y_max lo mismo en profundidad, y first y last van por tiempo. Para impresoras de cama móvil existe además y_near, que elige la captura en que la cama está más cerca de una posición fija. si no, la pieza salta hacia adelante y atrás en el video.

Cuál es la regla correcta depende de desde qué lado mira tu cámara, y la forma más rápida de saberlo es probar. Las capturas no se borran al renderizar, y cada regla escribe su propio archivo (timelapse_x_max.mp4, timelapse_y_near.mp4), así que puedes renderizar el mismo directorio con varias reglas y comparar:

python3 timelapse.py --render ~/timelapse/20260912-1535_mein_druck --pick x_max
python3 timelapse.py --render ~/timelapse/20260912-1535_mein_druck --pick y_near

Antes del primer print, la vista previa te deja verificar el encuadre con una grilla:

Sobre el consumo de disco: con tres capturas por capa, una impresión de 500 capas ocupa unos 500 MB. Si te importa el espacio, SHOTS_PER_LAYER = 1 deja el script comportándose como uno de una foto por capa.

Al terminar la impresión entra ffmpeg y arma un video H.264 a 30 cuadros por segundo, dejando el último cuadro congelado un segundo y medio. Una impresión de 300 capas da un video de poco más de diez segundos; si lo quieres más largo, baja FPS a 15. Renderizar esas 300 imágenes toma alrededor de 45 segundos en un Pi 5, y 43 segundos para 331 capas.

El script completo, con su bloque de configuración al inicio (dirección de Moonraker y altura de capa de tu perfil), está publicado en el artículo original enlazado al final.

Cuando algo no funciona: diagnóstico ordenado

La mayoría de las fallas de este montaje caen en seis categorías, y casi todas se identifican sin desarmar nada. La regla general es avanzar desde la cámara hacia el navegador, no al revés: si el problema está en el paso 1, no tiene sentido revisar Moonraker.

Tres comandos cubren el 90 % de los casos y conviene tenerlos a mano:

systemctl status ustreamer          # ¿está corriendo el servicio?
journalctl -u ustreamer -n 50       # ¿qué dijo al fallar?
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8080/snapshot

El último devuelve 200 si ustreamer está entregando imágenes localmente. Si ahí responde bien pero desde otro equipo no, el problema es de red o de firewall, no de la cámara.

Un apunte sobre seguridad

Vale la pena decirlo explícitamente: ustreamer publica el stream sin autenticación, y el registro de webcams de Moonraker tampoco pide credenciales. Dentro de tu red doméstica eso es razonable. Lo que no debes hacer nunca es abrir el puerto 8080. ni el 80 de la impresora. hacia internet desde el router: estarías publicando video de tu casa y, peor, el control completo de la impresora, que puede calentar una boquilla a 300 °C.

Si quieres ver la impresión desde fuera de casa, el camino correcto es una VPN (WireGuard o Tailscale sobre el mismo Pi) que te deje entrar a la red local, no una redirección de puertos. Es la misma cantidad de trabajo y no deja nada expuesto.

Variantes y mejoras

Tres ideas concretas para llevar este montaje más lejos, ninguna de ellas en el tutorial original:

1. Notificación cuando el print falla, no solo cuando termina. El mismo script ya consulta Moonraker dos veces por segundo. Con una condición extra sobre print_stats.state puedes disparar un webhook a Telegram o a Home Assistant cuando el estado pase a error o paused. Es media docena de líneas sobre la consulta que ya existe, y convierte la cámara de entretención en supervisión real.

2. Un segundo Pi Zero 2 W como cámara dedicada. Si ya usas el Pi 5 para otra cosa, un Pi Zero 2 W corriendo solo ustreamer cuesta una fracción y consume bajo 2 W. No lo uses para renderizar —ffmpeg sobre 300 imágenes ahí demora varios minutos. , pero para servir el stream MJPEG le sobra, y puedes renderizar después copiando el directorio a un computador.

3. Iluminación constante con tira LED USB. Es la mejora que más se nota y la más barata. El timelapse revela cualquier cambio de luz como un parpadeo entre capas: si una nube pasa por la ventana a mitad de impresión, se ve. Una tira LED USB regulable fijada al marco, siempre encendida y con la luz de la pieza controlada, elimina ese problema. Fija además el balance de blancos de la cámara con v4l2-ctl para que tampoco lo ajuste sola.

Personalización para Chile

Todo lo que necesitas para el Camino A se consigue en el catálogo de MechatronicStore. Los equivalentes directos:

• Raspberry Pi 5 (4 GB). es el que se usó en el montaje original. Un Raspberry Pi 4 o incluso un Pi Zero 2 W sirven igual para el video en vivo; para renderizar el timelapse, el Pi 5 es notoriamente más rápido.
• Fuente USB-C 27 W oficial para Raspberry Pi 5. no la reemplaces por un cargador de celular. Como explicamos arriba, sin los 5V/5A del estándar PD el Pi limita la corriente USB y la webcam se cae sola.
• Tarjeta microSD 64 GB (clase A2). la clase A2 importa acá: el script escribe cientos de JPEG durante la impresión.
• Webcam USB Full HD con foco fijo y MJPEG. el tutorial original usa una Lenovo Performance FHD (parte 4XC1D66055) y menciona la Logitech C920s como equivalente. Cualquier webcam UVC del catálogo que liste MJPEG en 1080p cumple exactamente la misma función; verifica el formato con v4l2-ctl --list-formats-ext antes de montarla. Si es autofoco, desactívalo con v4l2-ctl -d /dev/video0 -c focus_automatic_continuous=0.
• Brazo articulado con clamp y rosca de 1/4". el "magic arm" del original. Un trípode de mesa pequeño cumple lo mismo, siempre que quede apoyado en algo que no vibre.
• Tira LED USB regulable. opcional, pero es la mejora de mayor impacto por peso en el bolsillo.

Lo único de la lista que no compras acá es la impresora con Klipper y Moonraker, que ya tienes.

Un detalle eléctrico local: la red chilena es 220V/50Hz, y las luminarias LED baratas parpadean a 100 Hz. Si iluminas la cama con una ampolleta cualquiera en vez de una tira LED alimentada por USB (corriente continua), ese parpadeo va a aparecer como bandas horizontales en las capturas. La tira USB evita el problema de raíz.

Los precios y SKU varían; revisa la ficha de cada producto en el catálogo antes de comprar.

Recursos

• Tutorial original (alemán): Elegoo Neptune 4 Kamera: Webcam einrichten, Livebild in Fluidd und Timelapse mit dem Raspberry Pi. de Philipp Schweizer, donde está publicado el script timelapse.py completo
• ustreamer en GitHub: pikvm/ustreamer
• Documentación de webcams en Moonraker: Moonraker Web API. Webcam APIs
• OpenNept4une (reemplazo completo de firmware, para quien quiera ir por ese camino): OpenNeptune3D/OpenNept4une

Versión chilena con componentes en stock local, inspirada en el trabajo de raspberry.tips.