El código abierto está en todas partes, pero de vez en cuando aparece un proyecto que lleva el concepto a un lugar inesperado. Es exactamente el caso del trabajo de Phil Underwood, presentado en la charla Open Source Caving: 20 Years of Making Cave Mapping Tools durante Hackaday Europe 2026.
Underwood recorre allí una serie de dispositivos de hardware abierto, cada uno más avanzado que el anterior, diseñados para aumentar la velocidad y la precisión del mapeo subterráneo. En el camino aprendió varias lecciones sobre cómo diseñar equipos lo bastante robustos para un entorno tan hostil como una cueva, y a la vez lo bastante accesibles para que un aficionado pueda construirlos y usarlos.
¿Cómo se mapea una cueva sin electrónica?
La mayoría de los lectores no ha pasado mucho tiempo arrastrándose por pasajes subterráneos, así que conviene partir por el método tradicional. Se necesita una brújula, un inclinómetro, una huincha de medir y bastantes anotaciones detalladas.
Una vez recogidos esos datos y de vuelta en la superficie, la información se carga en un software que construye un mapa tridimensional de la cueva. Si se le suma la topografía de superficie, se obtiene una vista bastante completa de lo que hay arriba y abajo del terreno.
Como muchos espeleólogos, Underwood quería hacer menos tediosa la primera mitad del proceso. Imaginó un dispositivo electrónico que tomara al menos algunas de las mediciones por él, pero a comienzos de los años 2000 chocaba con los límites de la tecnología y de la capacidad de fabricación casera disponible para un aficionado.
Estaba además el ambiente de la cueva. Cualquier equipo usado bajo tierra no solo tiene que aguantar polvo y espacios estrechos: debe ser razonablemente resistente a golpes y existe una probabilidad no menor de que pase un rato sumergido en agua.
Mejoras incrementales, generación tras generación
El primer instrumento electrónico llegó en 2008. Dentro de una caja comercial de Radio Shack iban un microcontrolador PIC18LF2550 de 8 bits, una pantalla de matriz de puntos, un acelerómetro y un magnetómetro. Los datos de ambos sensores permitían determinar el rumbo y el ángulo con que se sostenía el aparato. Aunque el operador todavía debía medir la distancia a mano sobre ese vector, tener dos tercios de la información ya calculada ahorraba tiempo y esfuerzo considerables.
El siguiente salto llegó en 2020, y no fue solo del dispositivo sino de las herramientas disponibles. Ese nuevo equipo usaba un microcontrolador de 32 bits, un chasis impreso en 3D y un telémetro láser. Con más capacidad de cálculo a bordo, más operaciones se resolvían en el propio dispositivo. Underwood advierte, eso sí, que los datos del módulo láser no siempre eran confiables y que proteger un equipo más complejo de los elementos trajo nuevos problemas.
Ya con un ritmo más rápido, para 2023 el diseño había mejorado con una carcasa impresa en 3D mejor integrada, botones de silicona a medida y una interfaz de usuario más pulida. En ese punto también migró el firmware a CircuitPython. La barrera de entrada más baja frente a C caló mejor en la comunidad y, como consecuencia, Underwood empezó a recibir más contribuciones de código desde afuera.
Una nueva dimensión y sus problemas
Con un dispositivo de mano ya sólido, el resultado final seguía siendo el mismo que si las mediciones se hubieran tomado a mano. Cada generación hacía el levantamiento más rápido y menos incómodo, pero no mejoraba de forma sustantiva el producto final.
Construir mapas de mayor fidelidad exigía más datos y más poder de cómputo para procesarlos. Por eso la generación más reciente del hardware usa un Compute Module de Raspberry Pi 5 y un par de cámaras de baja luminosidad para hacer fotogrametría. Combinado con los datos de rumbo y ángulo, el sistema produce un modelo 3D texturizado del interior de la cueva con mínima intervención del usuario.
Esta última versión es claramente más capaz que las anteriores, pero hay un argumento para decir que también retrocede en algunos aspectos. Las cámaras son un punto físico débil, y Underwood sigue trabajando en cómo manejar el mayor consumo del Compute Module de Pi 5 frente a los microcontroladores de sus equipos previos.
| Generación | Año | Cerebro | Aporte principal |
|---|---|---|---|
| Primera | 2008 | PIC18LF2550 (8 bits) | Rumbo y ángulo automáticos |
| Segunda | 2020 | MCU de 32 bits | Telémetro láser, chasis impreso |
| Tercera | 2023 | MCU de 32 bits | CircuitPython, carcasa integrada |
| Cuarta | actual | Raspberry Pi 5 Compute Module | Fotogrametría y modelo 3D texturizado |
El costo de replicar la primera generación hoy es casi anecdótico: un acelerómetro y un magnetómetro combinados en un solo módulo cuestan pocos dólares, y cualquier ESP32 supera con holgura al PIC de 2008. La cuarta generación es otra historia, porque el Compute Module y las cámaras suben el presupuesto y, sobre todo, el consumo energético, que bajo tierra no se resuelve enchufando nada.
Quizá la lección más valiosa de la charla sea justamente ese enfoque incremental. La enorme mayoría de quienes la vean nunca va a explorar un sistema de cuevas, mucho menos mapearlo. Eso no impide aprender de un método práctico y metódico para construir la herramienta correcta para cada trabajo. Los repositorios SAP5 y STIC están publicados y disponibles para quien quiera partir desde ahí.
