Intervalómetro con la Raspberry Pi: preparando el eclipse de 2026
El 12 de agosto de 2026 podremos ver un eclipse total de Sol por el norte de España, y ese es el motivo de este proyecto. La idea es capturarlo con un telescopio MAK-127 de SkyWatcher sobre montura Go-to. Para la captura usaremos una Sigma fp, la cámara full-frame que tengo a mi disposición. La distancia focal del MAK-127 es de 1500 mm, y en un sensor más pequeño la corona quedaría recortada.
La fp trae intervalómetro propio, pero se queda corto para esto. Durante el eclipse hace falta bracketing para ganar latitud de exposición, y al menos dos ajustes muy distintos: uno para las fases parciales y otro para la totalidad, ese minuto y medio escaso en el que aparece la corona y la luz se desploma varios diafragmas de golpe. En la totalidad, además, queremos disparar más a menudo para alargar un poco esa parte del video, así que cambia también el intervalo.
Un punto importante es poder saltar de un ajuste a otro en mitad del timelapse sin perder la continuidad de los intervalos. Si en el instante en que arranca la totalidad cambiamos de “parcial” a “totalidad” —otra exposición y un intervalo más corto—, el disparo siguiente debe caer cuando toca, sin reiniciar el contador ni descolocar la cadencia, para que no se vean saltos extraños en el movimiento de la Luna. Además, queremos que todo esto sea tan simple como pulsar un botón, o mejor aún, automático con la fecha y la hora, porque durante el eclipse no habrá tiempo para improvisar.
El dispositivo es una Raspberry Pi 3 con un HAT TFT de 2.2” y seis botones físicos. La fp se controla por su puerto USB. No hace falta que sea este modelo en concreto y funcionará igual en una Pi y una pantalla más modernas, simplemente reaprovecho hardware que ya tenía en un cajón.
Lo que viene a continuación no va tanto sobre cómo se escribe el código como sobre la estrategia para desarrollarlo con IA — Claude Code ha escrito el 100% del código.
Dejar que Claude pueda desplegar en el hardware
Para el desarrollo trabajamos desde un portátil y usaremos la Raspberry
Pi para las pruebas de validación, desplegando por SSH con rsync y
reiniciando el servicio. Lo primero que hicimos fue
facilitar el acceso — una clave pública SSH copiada a la Pi (se puede hacer
desde el propio asistente de Raspberry Pi Imager al grabar la tarjeta) y
una entrada con un alias en el ~/.ssh/config, de modo que el agente entre
sin contraseña y sin pelearse con credenciales cada vez que necesita la
máquina.
Cada prueba sobre el dispositivo real —desplegar, reiniciar, mirar el TFT, pulsar un botón— es lenta, especialmente si hay que hacerla manualmente. La estrategia, entonces, fue reducir al mínimo la prueba en el hardware, haciendo que casi todo el desarrollo y las pruebas ocurran en el propio portátil, y que, cuando toca bajar al hardware de verdad, el agente tenga herramientas para inspeccionarlo sin necesidad de intervenir manualmente.
Y esa es la idea de fondo de todo el proyecto: reducir al mínimo la intervención manual, montando el entorno para que el agente pueda escribir, probar y corregir de forma autónoma, e intervenir solo cuando es realmente necesario.
Que la pantalla y los botones respondan
Antes de nada, comprobar que el TFT pinta y que los botones se leen. La Pi arranca directa a la aplicación, a pantalla completa, sin login ni consola detrás. Eso son tres piezas: un servicio de systemd que lanza la app al encender, la consola del sistema desviada fuera del panel, y nada de auto-login.
Para validarlo, le pedimos a Claude Code una pantalla de test — una interfaz sencilla con los seis botones, cada uno con su pin GPIO, que se ilumina al pulsar y lo probamos a mano.
Comprobar que podemos hablar con la Sigma fp
Esto es básico. Si no podemos hablar con la cámara no hay nada que hacer, así que antes de pensar en la lógica del intervalómetro toca una prueba de viabilidad que confirme que la comunicación funciona.
De nuevo, le pedimos a Claude una prueba básica y se decanta por
sigma-ptpy, una librería PTP
(Picture Transfer Protocol) en Python puro, descartando el SDK oficial de
Sigma —binarios x86_64, inviables en una ARM de 32 bits—.
Esta parte la implementó Claude Code prácticamente sin ayuda, iterando directamente contra la Pi por SSH. Pusimos la cámara conectada a la Pi en modo “control de cámara” y podíamos ver cómo hacía fotos de vez en cuando y comprobaba los resultados. Solo hubo que indicarle un par de cosas que no funcionaron a la primera —relacionadas con el modo automático y el enfoque manual—, pero poco más.
Abstracción del hardware
Sabiendo que el hardware —pantalla, botones y control de la cámara— funcionaba, le pedimos a Claude que creara una capa de abstracción que admitiera varias implementaciones. Por ejemplo, para los botones una implementación lee directamente los GPIO y otra recibe pulsaciones simuladas. Para el display, una versión escribe directa en la pantalla y otra genera imágenes. Y para la cámara, una habla con la cámara real y otra la simula. Así el software puede correr tanto en la Raspberry Pi como directamente en el Mac, sin pantalla LCD, sin botones y sin comunicación real con la cámara.
Este paso fue clave para acelerar el trabajo. Le dábamos total autonomía al agente para desarrollar toda la lógica, y podíamos probar en varios niveles:
- En local, sin escribir en la Raspberry Pi y sin necesidad de ver la interfaz — por ejemplo, para probar la lógica de disparo.
- En local, simulando la interfaz para verificar que se ve como se espera (comprobando los PNG que genera).
- Directamente sobre el hardware, donde el agente desplegaba el código en la Pi y, a través de un pequeño servidor HTTP local, simulaba pulsaciones de botones y capturaba la pantalla (era curioso ver cómo la pantalla iba cambiando sin tocar nada).
La abstracción y las versiones mock permitieron cubrir la lógica entera con una batería de más de 250 pruebas que corre en una fracción de segundo en el Mac. Cada bug que aparecía se cerraba con un test que lo reproducía, así que el agente podía reescribir y reorganizar sin miedo a romper lo que ya funcionaba, y las regresiones se detectaban en el portátil mucho antes de bajar al hardware. La interfaz de usuario salió prácticamente a la primera, porque el agente podía interpretar los PNG sin ninguna intervención y comprobar que todo se renderizaba bien.
Pruebas de validación
La primera vez que el sistema completo bajó a la Pi, se perdían disparos — los marcaba como saltos (skips). Sin mirar el código, solo viendo cómo se refrescaba la interfaz, se intuía que la implementación no era muy eficiente y que se estaban perdiendo fotos por pequeños retrasos del refresco. Por ejemplo, en el bucle se comprueba que todavía no toca disparar, se repinta la pantalla entera y, cuando vuelve a comprobarlo, ya ha pasado el momento del disparo.
Le pedimos al agente que verificara lo que le estábamos diciendo, también sin entrar en el código, y le sugerimos un par de ideas, como procesar los eventos de forma asíncrona y refrescar la imagen solo cuando hubiera cambios en vez de repintar en cada vuelta. Reescribió el bucle siguiendo esa línea y, en la siguiente prueba sobre la Pi, los saltos habían desaparecido.
La carcasa
Una vez terminado el software tocaba meterlo todo en una caja para que fuera manejable. Partimos de una carcasa ya diseñada para la Raspberry Pi 3 —el Malolos de Printables— y la adaptamos para integrar la pantalla de 2.2” y los seis botones. La adaptación la hicimos en OpenSCAD, también con IA, pero eso da para otro artículo.
El resultado quedó bastante compacto, arranca solo al darle corriente y se maneja con los seis botones.
El software está liberado con licencia MIT y disponible en GitHub. Una configuración puede ser manual —de uno a nueve disparos con su tiempo e ISO, para el bracketing— o automática, dejando que la cámara mida cada toma. Arranca solo, se reconecta a la cámara si el USB se cae y guarda todo en un fichero sencillo que también se puede editar por SSH.
La prueba real
Para probar el intervalómetro hicimos un timelapse de la luna apareciendo sobre el horizonte tras el atardecer. La luna tiene mucho brillo y para que no se vea quemada hay que bajar la exposición oscureciendo otras partes de la escena. Para evitar esto hicimos un fuerte bracketing, 5 tomas con una separación de 3,5 pasos cada una, fusionadas con HDRMerge y editadas en DaVinci Resolve para preservar el detalle de la luna y del resto de la escena sin ruido visible.
Este fue el resultado:
El ensayo salió bien. El examen de verdad será el próximo 12 de agosto.
Actualización. El intervalómetro ha seguido creciendo desde aquella primera versión. A día de hoy ya no es solo para la Sigma fp: también funciona con la Nikon D5600 —esa capa de abstracción del hardware fue justo lo que permitió añadir una segunda cámara sin tocar la lógica— y por el camino han llegado el inicio programado por fecha y hora, la configuración del WiFi desde el propio dispositivo y otras mejoras para la creación de configuraciones.
Referencias
- Código del proyecto
fp-lapseen GitHub - Proyecto HDRMerge
- Carcasa Malolos original y la adaptación con TFT 2.2” y 6 botones.
- Wiki del HAT LCD 2.2” de Geekworm.