VolAnti lleva la detección acústica de código abierto a los drones FPV de fibra óptica

VolAnti apareció en Hacker News el 9 de septiembre de 2026 con una propuesta fácil de resumir, aunque más difícil de descartar: si un dron ha dejado de comunicarse por radio, hay que escuchar sus hélices. Este proyecto de hardware abierto utiliza cuatro micrófonos MEMS, un ESP32-S3, una pantalla de tinta electrónica y una radio LoRa para detectar el sonido estructurado de un multirrotor y distribuir una alerta.

La idea es más concreta de lo que puede sugerir la expresión «detector acústico de drones». VolAnti no intenta identificar todas las aeronaves, generar una trayectoria similar a la de un radar ni reemplazar una instalación antidrón por capas. Es un dispositivo local de alerta temprana para cubrir una carencia específica, aunque relevante, de los sistemas centrados en radio. El repositorio lo describe únicamente como un sistema de detección y alerta, y excluye de forma explícita la interferencia, la interceptación, la designación de objetivos y otras contramedidas.

El proyecto merece atención porque publica toda la cadena: archivos de hardware, firmware, modelos de la carcasa, audios de prueba, documentación y un simulador en el navegador. También conviene observarlo con cautela. Una prueba satisfactoria a 104,2 metros demuestra que el diseño puede funcionar en un contexto determinado; no demuestra que ofrezca una cobertura fiable con otro clima, paisaje o entorno de amenazas.

El problema que realmente intenta resolver VolAnti

Muchos detectores de drones, tanto de consumo como profesionales, empiezan buscando una firma electromagnética. Una aeronave radiocontrolada suele tener un enlace de control, un transmisor de vídeo o una emisión de identificación remota. Un receptor puede explorar esas señales, clasificarlas y, en algunos casos, estimar la ubicación de la aeronave o de su operador. El límite de este enfoque es claro: necesita que haya algo en el aire que recibir.

Un aparato FPV de fibra óptica cambia ese límite. Su operador envía las órdenes de control y recibe el vídeo a través de una fibra física, en lugar de usar un enlace de radio convencional. Por eso, la aeronave puede permanecer silenciosa en radio durante la parte del vuelo en la que un escáner buscaría normalmente indicios. Eso no la vuelve silenciosa desde el punto de vista acústico. Los motores, las hélices, las vibraciones y el desplazamiento del aire siguen siendo señales físicas.

La idea central de VolAnti consiste en buscar la estructura regular de ese sonido, no un umbral arbitrario de volumen. Una hélice giratoria produce una frecuencia de paso de pala. Una hélice de tres palas que gira a una velocidad determinada genera una frecuencia fundamental asociada con tres pasos de pala por revolución, además de energía en múltiplos de esa frecuencia. En un espectro, esos picos forman un peine: dientes repetidos, separados por un intervalo relativamente constante.

La firma acústica exacta depende de la hélice, el motor, la carga, la velocidad, el chasis, la distancia, el viento y las superficies del entorno. Lo importante no es que todos los drones produzcan un sonido idéntico. Es que el ruido de los rotores contiene una característica periódica que el ruido ambiental de banda ancha normalmente no conserva de la misma manera. VolAnti intenta puntuar esa regularidad.

Por eso el proyecto no es simplemente un micrófono conectado a un medidor de volumen. Un medidor de volumen quedaría confundido por el tráfico, la maquinaria, las voces o un portazo. Un detector que pregunta si el espectro contiene componentes de rotor espaciados de forma uniforme plantea una pregunta más útil, aunque todavía debe enfrentarse a muchos sonidos capaces de imitar partes de ese patrón.

Qué hay dentro de la caja

El diseño completo cabe en una carcasa de aproximadamente 91 milímetros. Su núcleo de procesamiento es un ESP32-S3, una elección práctica para un proyecto de procesamiento de señales integrado y de bajo coste: ofrece capacidad suficiente para la carga de trabajo indicada, está ampliamente disponible y cuenta con un ecosistema de desarrollo maduro. El conjunto de sensores utiliza cuatro micrófonos MEMS ICS-43434 dispuestos en forma de cruz.

Los micrófonos no se emplean como un sistema completo de cámara acústica. El repositorio explica que el conjunto está pensado principalmente para mejorar la sensibilidad, no para determinar la dirección. Con las frecuencias de funcionamiento y la separación física del proyecto, las cuatro señales pueden combinarse para mejorar la relación señal-ruido y conservar una cobertura casi omnidireccional. Se estudió la formación de haces, pero el conjunto es demasiado pequeño para que la separación entre micrófonos permita una solución útil para el papel previsto.

El resto de los componentes es deliberadamente corriente. Una pequeña pantalla de tinta electrónica muestra alertas y marcas de tiempo, con la ventaja de que el último mensaje permanece visible después de retirar la alimentación. Un zumbador, un LED rojo y un motor de vibración proporcionan distintas formas de notificación local. Un módulo LoRa Ra-01H envía un paquete compacto de alerta a otras unidades. El sistema no utiliza un servidor central ni necesita una conexión de red para que el detector tome una decisión.

El diseño de alimentación es más cuidadoso de lo que podría sugerir la lista de materiales. VolAnti utiliza una entrada USB-C, un cargador BQ24074 con gestión de ruta de alimentación, un convertidor buck-boost TPS63020 y una celda de polímero de litio 1S de 2500 mAh. El proyecto informa de una autonomía aproximada de entre 18 y 22 horas por carga. La batería también se conserva en las unidades que funcionan conectadas a la red eléctrica, porque la activación simultánea del zumbador, el motor de vibración y la radio provocó una caída de tensión durante la puesta en marcha cuando la placa dependía únicamente de la alimentación USB.

Ese detalle ilustra bien el valor de publicar los fallos de ingeniería. Un esquema puede mostrar que existe un riel de alimentación; no muestra que un evento de alerta pueda hacer que el dispositivo se reinicie. En un instrumento de aviso, el modo de fallo importa más que la elegancia del circuito.

La cadena de procesamiento de señales

El detector toma un nuevo cuadro de audio cada 32 milisegundos. Según la documentación del proyecto, muestrea a 16 kHz y utiliza una FFT de 2048 puntos sobre cuadros de 512 muestras. La FFT convierte un fragmento breve de datos del micrófono en información del dominio de la frecuencia que puede compararse con posibles velocidades de rotor.

Primero, VolAnti mantiene una representación adaptativa del suelo acústico normal. Los sonidos ambientales tranquilos se aprenden durante varios segundos, mientras que los eventos intensos de banda ancha se incorporan más deprisa. El objetivo es evitar que el ruido permanente de un lugar se trate como una amenaza nueva cada vez que el detector empieza a escuchar. Es útil en un entorno real, pero introduce un problema conocido: un sonido que permanece presente durante suficiente tiempo puede pasar a formar parte de la línea de base.

El proyecto aborda ese problema con varios niveles de detección. El detector de peine rápido compara la energía en los dientes de un patrón armónico candidato con la energía en los huecos. Busca velocidades candidatas entre 70 y 2000 Hz y conserva la mejor puntuación normalizada. La clave está en el contraste entre dientes y huecos, no solo en la intensidad absoluta de la señal.

Una puntuación alta aislada no basta. La misma velocidad candidata debe mantenerse como ganadora durante seis cuadros consecutivos, dentro de una tolerancia del dos por ciento. Esta comprobación de persistencia busca rechazar el ruido transitorio. La velocidad del rotor puede cambiar, especialmente cuando una aeronave se aproxima o modifica el empuje, por lo que el firmware utiliza más de una forma de estimar si la estructura acústica se mantiene.

Los cuatro niveles de detección reflejan distintas situaciones de vuelo y ruido:

• El detector de peine rápido está pensado para una aeronave que se aproxima o cambia, y el repositorio informa de una latencia de unos 0,23 segundos en las condiciones de prueba indicadas.
• Un detector de peine lento utiliza un suelo adaptativo más prolongado para una aeronave que llega y después permanece suspendida, con una respuesta comunicada de aproximadamente 1,4 a 4 segundos.
• Un detector basado en la envolvente busca una modulación de banda ancha asociada con un vuelo cercano, cargado y de alto empuje, y figura con una respuesta de entre 1 y 3 segundos.
• Un detector de peine sin suelo utiliza un espectro de Welch de dos segundos y blanqueamiento para un vuelo estacionario largo en un lugar donde el suelo ordinario ya ha aprendido demasiado; su respuesta indicada es de unos 5 a 15 segundos.

La arquitectura establece un equilibrio de ingeniería razonable. Un detector ajustado únicamente a los cambios de sonido puede captar una aeronave que llega, pero perderla cuando se estabiliza en vuelo estacionario. Uno ajustado solo a un patrón estable puede ser lento cuando la aeronave se aproxima. Ejecutar varias pruebas especializadas sobre el mismo espectro permite responder a historiales acústicos diferentes sin fingir que un único umbral sirve para todas las escenas.

El proyecto también indica que el primer nivel está fijado mediante vectores de prueba dorados. El mismo audio de prueba debería producir el mismo resultado en un portátil y en la placa integrada, hasta en la puntuación comunicada. Esa reproducibilidad es más valiosa que un panel de control pulido cuando otras personas necesitan inspeccionar o mejorar un sistema de procesamiento de señales.

Qué demuestra el primer resultado de campo —y qué no demuestra

El resultado principal corresponde a una prueba fechada el 6 de septiembre de 2026. Un equipo de pruebas con cuatro motores de clase 2807 y hélices de tres palas de siete pulgadas permaneció en vuelo estacionario a 104,2 metros, en una calle rodeada de paredes de ladrillo. El repositorio indica que había viento ligero, tráfico pasando y personas hablando cerca del detector. El detector sin suelo se activó a esa distancia, mientras que el proyecto informa de que los coches no dispararon una alerta.

Es una demostración útil por dos motivos. Primero, emplea un equipo pensado para aproximarse a la clase de motor y hélice de la aeronave que el diseño pretende abordar, en lugar de un dron de juguete no especificado. Segundo, enfrenta el detector al tipo de sonido competidor que importa en la práctica. Un algoritmo que solo funciona en un campo silencioso tiene un valor limitado como alarma.

El resultado sigue siendo un único punto medido. No establece un radio universal de detección de 104 metros. El alcance acústico cambia de forma drástica con la dirección y la velocidad del viento, la temperatura, el terreno, las paredes, la vegetación, el estado del motor y la orientación de la aeronave. El propio repositorio ofrece una expectativa amplia: alrededor de 100 a 200 metros en condiciones quietas y silenciosas, pero de 15 a 50 metros en un lugar ventoso o ruidoso, con un rendimiento que empeora por encima de 8 metros por segundo de viento. Son estimaciones del proyecto, no una certificación independiente.

Las pruebas anteriores descritas por el proyecto también tienen límites claros. Una prueba en terreno abierto del 21 de agosto detectó hélices cargadas a 14 metros con viento cambiante y sin falsas alarmas durante esa sesión. El 28 de agosto, una placa de producción supuestamente coincidió con la salida de referencia en los vectores dorados; el cuadro más lento tardó 29,4 milisegundos frente a un presupuesto de procesamiento de 32 milisegundos, a lo largo de 1938 cuadros. Eso dice algo sobre los tiempos de ejecución y la repetibilidad de la implementación. Dice menos sobre el funcionamiento prolongado en un lugar nuevo.

El repositorio también informa de que hasta ahora no se han producido falsas alarmas en sus sesiones de campo. «Hasta ahora» es la parte importante. La tasa de falsas alarmas no es una propiedad del circuito por sí solo; pertenece a un lugar, una posición de montaje, un patrón meteorológico y una rutina de mantenimiento. Una carretera, un tejado, una fábrica, una vía ferroviaria o una obra introducirán cada una distintos elementos que pueden confundir al sistema. Los informes públicos de construcciones realizadas en esos entornos serían más informativos que otro vuelo estacionario controlado.

Por qué el diseño LoRa es deliberadamente sencillo

Cada unidad VolAnti decide de forma local. Cuando detecta un candidato, envía un paquete de 18 bytes que contiene información de identidad, nivel del detector, frecuencia, puntuación y secuencia. Las demás unidades reciben ese paquete directamente. El repositorio destaca que no hay retransmisor ni enrutamiento de malla, y que el sistema no espera a que una segunda unidad vote antes de activar su propia alarma.

La elección se desprende del propósito del dispositivo. Una red puede mejorar la cobertura y llevar una alarma al interior, pero exigir consenso puede añadir retraso o convertir un único fallo de radio en una alerta perdida. La detección local también permite que una unidad siga funcionando si el resto de la instalación está fuera de servicio. El coste es que el sistema no fusiona observaciones en una trayectoria compartida ni calcula una ubicación. Distribuye alertas; no crea una red de sensores con inferencia centralizada.

La configuración de radio es una cuestión de despliegue, no un ajuste universal. La documentación identifica 868 MHz para el Reino Unido y la Unión Europea y 915 MHz para Estados Unidos, siempre sujeta a la asignación local y a la normativa aplicable. Hay que seleccionar la frecuencia correspondiente al país donde se utilice la unidad. Es un recordatorio pequeño, pero importante: el hardware abierto no elimina la necesidad de cumplir las normas de radio.

Una instalación con varias unidades también modifica el problema práctico. Un nodo situado en el perímetro puede oír primero una aeronave, mientras que otro instalado en el interior puede colocarse donde las personas puedan reaccionar a la advertencia. Sin embargo, la cobertura no puede deducirse de un círculo sencillo en un mapa. Los edificios y el terreno moldean el sonido, el ruido de fondo varía según la hora y las suposiciones del detector pueden comportarse de forma distinta en cada lugar. La documentación recomienda considerar la colocación, la alimentación, los intervalos de servicio y los cálculos de cobertura como parte del despliegue, no como una tarea posterior.

Quién debería probarlo

VolAnti es un candidato sólido para makers que quieran aprender sobre DSP integrado, conjuntos de micrófonos, hardware abierto y pruebas reproducibles. El repositorio proporciona dos rutas de construcción. La versión sobre protoboard utiliza una placa de desarrollo y módulos de micrófono, sin necesidad de una PCB personalizada más allá del cableado y los conectores habituales. El proyecto estima aproximadamente entre 35 y 45 libras esterlinas y una tarde de trabajo para esa opción.

La unidad completa utiliza una placa ensamblada de cuatro capas, una carcasa impresa y una pequeña cantidad de soldadura y montaje mecánico finales. La estimación publicada de componentes es de unas 50 a 80 libras, y el diseño está pensado para que el dispositivo sea portátil y más sencillo de desplegar que un prototipo de banco. Los precios variarán según el envío, la disponibilidad de componentes, la región de fabricación y si el constructor ya dispone de herramientas.

También es un proyecto útil para investigadores y mantenedores que quieran aportar datos del mundo real. La guía de contribuciones solicita informes de construcción que incluyan la versión del firmware, la fuente sonora, la distancia a la que la detección se produjo y a la que no se produjo, el viento y las falsas alarmas. Eso es exactamente lo que el proyecto necesita. Un resultado negativo obtenido en un lugar ruidoso puede revelar más que un segundo éxito bajo condiciones parecidas.

Una institución pequeña podría utilizarlo como capa experimental de alerta alrededor de una propiedad, pero solo después de realizar sus propias pruebas y una revisión legal. La documentación abierta facilita la inspección y la reparación; no convierte un prototipo económico en un producto de seguridad vital. Si la pérdida de una aeronave pudiera causar daños graves, VolAnti debería considerarse una entrada más entre sensores y procedimientos independientes, no la única base para tomar una decisión de protección.

Quién debería esperar

Cualquiera que busque un sistema de detección certificado debería esperar. VolAnti es un proyecto joven, tiene un historial público de desarrollo reducido y presenta mediciones elaboradas por el propio proyecto, no una evaluación de rendimiento de terceros. Sus licencias están separadas dentro del repositorio: el hardware se distribuye bajo la CERN Open Hardware Licence, versión 2.0 Weakly Reciprocal; el firmware, bajo Apache-2.0; y la documentación, bajo CC BY-SA 4.0. Es una estructura razonable para un proyecto de hardware abierto, pero los usuarios deben entender qué licencia se aplica a cada artefacto y revisar los archivos completos antes de redistribuir un diseño modificado.

Quien espere encontrar la dirección de una aeronave también debería esperar o elegir otra clase de sistema. Cuatro micrófonos dentro de esta carcasa mejoran la sensibilidad, pero el repositorio no presenta el conjunto como un estimador preciso de rumbo. El enlace LoRa comparte alertas entre unidades; no triangula la aeronave. Un comprador que necesite un mapa, confianza de clasificación, estimación de distancia o integración con un sistema de mando existente tendrá que añadir sensores y software.

La misma cautela se aplica a la clasificación de amenazas. VolAnti escucha una periodicidad parecida a la de un rotor. No demuestra que el sonido proceda de una aeronave concreta, no identifica una carga útil ni distingue todos los drones de todos los elementos mecánicos que pueden confundirlo. El alcance del proyecto es deliberadamente estrecho. Esa limitación es una fortaleza para un prototipo construible, pero no debe transformarse en capacidades que el repositorio no afirma tener.

La contribución de código abierto más interesante

Lo interesante no es solo la caja terminada. Es la forma en que el proyecto construye un argumento comprobable desde la cápsula del micrófono hasta la salida de alarma. Los archivos de hardware exponen las suposiciones físicas. El firmware muestra los tiempos de cuadro y la lógica del detector. Los audios de prueba permiten examinar el algoritmo. Los vectores dorados crean una referencia para cambios futuros. El simulador facilita entender la cadena de procesamiento antes de que un constructor haya pedido una PCB.

Ese patrón resulta más adecuado para proyectos de hardware con implicaciones de seguridad que publicar un vídeo breve y una lista de componentes. Un vídeo puede mostrar que una unidad concreta detectó una aeronave concreta. No puede mostrar cómo se comporta el sistema cuando cambia el viento, cuando un vuelo estacionario pasa a formar parte de su suelo o cuando se produce un pico de consumo en el mismo instante que una alarma. Un corpus de audio reproducible y unos umbrales explícitos proporcionan, al menos, algo concreto que la comunidad puede poner a prueba.

El proyecto también fija un límite especialmente claro para un diseño de doble uso. El alcance declara que VolAnti detecta y alerta, y que no incluirá interferencias, suplantación, interceptación, designación de objetivos ni otras contramedidas. Eso no elimina los riesgos del despliegue, pero mantiene el repositorio público centrado en la detección pasiva y el aviso. En un proyecto abierto dentro de un área sensible, controlar el alcance también forma parte de la ingeniería.

Aquí hay una lección más amplia para la infraestructura de código abierto. Cuando un método de detección conocido falla porque un adversario o una tecnología ha cambiado el canal, una respuesta útil puede consistir en buscar otra señal física, en lugar de hacer más complejo el receptor original. VolAnti lo hace con el sonido. Su éxito dependerá menos de la novedad de la idea que de la siguiente fase de evidencia: lugares variados, condiciones meteorológicas distintas, aeronaves diferentes, montajes diversos, funcionamiento prolongado sin supervisión e informes honestos de los fallos de detección.

Una forma sensata de evaluarlo

Un constructor cuidadoso debería empezar por la ruta de protoboard del repositorio y por el material de prueba suministrado. Primero debe confirmar que la placa reproduce el comportamiento de referencia antes de interpretar un experimento en directo. Después conviene probar los sonidos ambientales normales del lugar previsto, incluidos los que estarán presentes cuando se espera que el detector funcione. Hay que medir tanto la distancia de detección como la distancia a la que no se detecta; afirmar que una aeronave se oyó en un punto no equivale a tener un mapa de cobertura.

A continuación, conviene variar un factor cada vez siempre que sea posible: el viento, la orientación de la aeronave, el vuelo estacionario frente a la aproximación, el estado de las hélices, la altura de montaje y los obstáculos cercanos. Hay que registrar el nivel del detector, el tiempo de respuesta, la puntuación y las condiciones ambientales. Los resultados deben mantenerse separados de las cifras originales del repositorio, para que las mediciones locales no se confundan con especificaciones del proyecto principal.

Cuando se utilice más de una unidad, hay que probar el enlace LoRa de forma independiente de la ruta acústica. Un dispositivo que escucha correctamente pero no consigue alertar a otra unidad tiene un problema de comunicaciones; un dispositivo que transmite cada falsa alarma local tiene un problema del lugar o del algoritmo. Son fallos distintos y requieren correcciones distintas.

Por último, el procedimiento humano debe mantenerse sencillo. La salida es una alerta, no una decisión automatizada. Los operadores tienen que saber qué significa la señal, qué no significa, cómo silenciar una alarma molesta sin detener la detección y qué otras pruebas hacen falta antes de tomar una medida con consecuencias. La pantalla de tinta electrónica y las distintas salidas locales ayudan a mantener esa claridad operativa, pero ninguna interfaz compensa una suposición de despliegue que no se haya probado.

Veredicto

VolAnti es uno de los proyectos de hardware abierto más convincentes que han aparecido recientemente en el radar del código abierto porque conecta una carencia real y clara con un diseño comprensible y reparable. Es compacto, económico para los estándares del equipamiento de detección especializado y poco habitual en su transparencia sobre los algoritmos, los vectores de prueba, el fallo de alimentación y las limitaciones. La demostración a 104,2 metros constituye un resultado relevante, sobre todo porque tuvo lugar con tráfico y personas cerca.

No demuestra que unos pocos micrófonos puedan reemplazar al radar, la monitorización de radio o los equipos profesionales antidrón. El detector puede no captar aeronaves, el alcance acústico puede desplomarse con el viento y el ruido, y la evidencia pública sigue siendo limitada. Por eso, el consejo adecuado es condicional: hay que construirlo si se quiere estudiar el problema, aportar datos de campo o añadir una capa pasiva de aviso que pueda validarse de forma independiente. No debe tratarse el repositorio actual como un perímetro certificado, una ayuda para designar objetivos ni una garantía de que un espectro de radio silencioso implique un cielo silencioso.

La próxima versión útil no será necesariamente la que incorpore el clasificador más ingenioso. Será la que esté respaldada por grabaciones más diversas, falsas alarmas documentadas, protocolos de campo repetibles y respuestas claras sobre el mantenimiento. Ahí es donde un experimento de código abierto empieza a convertirse en una infraestructura en la que la gente puede confiar de forma responsable.

Fuentes

La información técnica, las mediciones, los componentes, el alcance declarado y las licencias se han tomado del repositorio y README de VolAnti. La presentación y el debate iniciales aparecen en Hacker News y en la publicación de Reddit sobre el detector acústico basado en ESP32-S3. Para contexto adicional, el proyecto también cuenta con páginas en Hackster.io y Hackaday.io. La referencia general sobre licencias de repositorios procede de GitHub Docs.