Borrador v0.1 — publicado pronto, en público, a propósito
Un archivo de show que se puede
comprobar antes de volar
DSX (Drone Show eXchange) es un formato de archivo abierto y neutral respecto al fabricante para espectáculos de luces con drones: diseñado para ser volable y validable por máquina, no solo visualizable.
Lo que aún no es cierto
Ninguna aeronave ha volado un archivo DSX. Hoy están probados la especificación, los JSON Schema y el muestreador normativo; la codificación binaria .dsb sigue siendo un esquema; la cobertura de vectores del muestreador no es exhaustiva. Decirlo con claridad es el punto: un formato que exagera su madurez reproduce exactamente la conducta que este proyecto existe para sustituir.
El hueco
Ningún formato abierto es hoy a la vez volable y verificable de forma independiente
Cada formato en uso está en uno de dos estados: abierto pero no listo para volar, o listo para volar pero sin documentar. Las consecuencias no son hipotéticas: los shows se intercambian como CSV y pierden sus metadatos de seguridad, los campos de geocerca existen pero nunca se rellenan, la referencia de altitud (AGL / AMSL / elipsoide) queda implícita, y la orientación de los ejes difiere en silencio entre herramientas. Cada uno tiene un modo de fallo conocido.
| Formato | Abierto y documentado | Volable | Validable por terceros |
|---|---|---|---|
| VVIZ | sí | no — un formato de visualización, no pensado como fuente de trayectorias listas para volar | no |
| .skyc / .skyb | código legible (GPL), sin especificación pública | sí | no |
| .dac, .bin, .path/.path3, .essp, .json de fabricante | no se ha localizado una especificación pública | sí | no |
| CSV | abierto de forma trivial | parcialmente | no |
| DSX | sí | diseñado para ello — aún no ha volado | contenedor, esquemas, reglas del §10 y vectores del muestreador, probados hoy |
«Localizado» es la afirmación precisa: la ausencia de una especificación pública no se puede probar, solo no encontrarse (búsqueda: 2026-08).
Diseño
Dos capas, limpiamente separadas
Mezclar intercambio y carga en un solo archivo es el error que cometen la mayoría de los formatos. DSX los separa y fija el compilador entre ambos como determinista: la misma entrada debe (MUST) producir una salida idéntica byte a byte. Eso es lo que hace auditable un archivo de show.
Intercambio, archivo, revisión, presentación regulatoria.
ZIP + JSON — comparable (diff), legible
Carga en la aeronave.
TLV binario — analizable por el MCU
Lo que una aeronave o carga útil concreta puede hacer de verdad.
JSON — viaja dentro del .dsx
La interoperabilidad es una propiedad del formato, no un servicio de un servidor
Todo .dsx conforme DEBE (MUST) poder reducirse, mediante un algoritmo normativo de muestreo, a t, x, y, z, R, G, B a cualquier frecuencia de cuadro — idéntico bit a bit en cada implementación. Cualquier sistema existente tiene por tanto una vía de importación el primer día, sin entender los polinomios.
t, x, y, z, R, G, B
Respaldado por una implementación de referencia y seis vectores de prueba calculados a mano, no solo por prosa.
La identidad del hardware es explícita
Un show referencia un perfil de dispositivo por UUID estable y declara el modo para el que se escribió. Una herramienta puede por tanto rechazar la carga de un show cuyo envolvente de vuelo declarado supera los límites publicados de la aeronave — en vez de descubrirlo en el aire.
En el archivo
Tres cosas que un archivo de show puede llevar y los formatos de hoy no
No son funciones de producto. Son campos, reglas y un algoritmo de muestreo — especificados, comprobados por el esquema y (en el caso de las oleadas) ejercidos por dos ejemplos L2.
Una vía de importación que no espera al conversor del fabricante
Todo archivo conforme se reduce, mediante un algoritmo de muestreo publicado, a t, x, y, z, R, G, B a cualquier cadencia — idéntico bit a bit. Un controlador que ya consume matrices de fotogramas puede importar un show DSX el primer día sin entender polinomios. Los conversores con nombre hacia y desde otros formatos están previstos, no se entregan; cualquier conversor así debe publicar una matriz de pérdidas que diga qué conserva, aproxima o descarta.
El muestreador existe y está comprobado. El conjunto de conversores (dsx-convert) no.
Una valla doble que vive en el archivo firmado
Una burbuja blanda que se mueve (~4 m) dispara un aterrizaje automático. Un polígono duro dispara el desarmado. Ambos son campos del archivo, resumidos con el resto del show y evaluables a bordo sin el reproductor. Una valla que solo existe como ajuste de consola puede ponerse en el número equivocado sin que nadie lo note — ese es un patrón de accidente documentado.
La valla operativa a bordo es termination.geofence. El safety.geofence del show es la envolvente, no una segunda copia de la misma regla.
Más de un despegue por aeronave
Los formatos existentes comprimen coreografía, aeronave y batería en un solo objeto — así un show no puede durar más que una carga. DSX separa rol, aeronave y salida. Los grupos aterrizan, cambian baterías y despegan de nuevo hacia la misma pieza. Existen dos ejemplos L2: un show de 42 minutos con seis aeronaves y un ciclo generativo para operación continua.
20 de 25 reglas de rotación tienen una comprobación ejecutable. El muestreo de shows abiertos (duration_ms: null) sigue sin definirse.
Seguridad
El envolvente de seguridad es dato, no un PDF al lado
La escalada de terminación, las geocercas, el comportamiento ante pérdida de enlace, la política de integridad GNSS y los interbloqueos de carga útil son campos del archivo: independientes de la reproducción y evaluables a bordo, sin conexión al reproductor del show.
Una escalera de cuatro peldaños
- 1Hold / Suspend
Reversible. El show se detiene donde está.
- 2RTH coordinado
Un retorno que el archivo declara viable — o declara con honestidad que no lo es.
- 3Aterrizar en el sitio
Descenso controlado, allá donde esté la aeronave.
- 4Kill / Disarm
Irreversible. La caída ya debe estar contenida por el área de seguridad.
Una acción del operador por peldaño
Este requisito existe por un accidente documentado: un piloto dejó seguir el show mientras las aeronaves ya caían sobre una multitud, porque pausarlo exigía demasiados pasos. Una vía de aborto demasiado cara de usar no es una función de seguridad. DSX trata por tanto «cuántas acciones cuesta este peldaño» como parte del archivo.
Mapa de viabilidad del RTH
Un retorno a casa no está disponible en cada instante de un show. DSX hace explícitas las ventanas inviables, con un motivo y los peldaños de escalada que quedan — en vez de dejar que una estación de tierra lo descubra bajo presión de tiempo.
Caída contenida
El área de seguridad declarada DEBE (MUST) encerrar la trayectoria de caída de una aeronave desarmada desde cada posición que alcance el show. El peldaño de desarmar solo es usable si eso se ha establecido de antemano.
Burbuja blanda, polígono duro
El archivo lleva dos vallas, no una. La valla blanda es una burbuja que sigue la posición mandada; salir de ella inicia un aterrizaje automático. La valla dura es un polígono fijo; salir de ella desarma los motores. Ambas viajan con el archivo firmado, así que una estación de tierra no puede cambiar el número en silencio.
Perfiles
Perfiles de conformidad, no una lista de funciones
Un fabricante no tiene que implementarlo todo para ser conforme. Cada nivel es un compromiso completo y comprobable.
Solo posiciones y RGB. Equivalente a CSV. Cualquier controlador puede hacerlo.
Trayectorias por segmento, programas de luz, envolvente de seguridad, rejilla de despegue, RTH.
Guiñada, cargas (pirotecnia, recuperación, dispensadores), rotación multi-oleada, multi-flota, sincronía de audio, firma.
Conformidad
Qué se prueba — y qué no
Existe y corre hoy
- Seguridad del contenedor: nombres de entradas, límites de descompresión, casos de elusión de firma
- Validación JSON Schema de .dsx, .dsxp y termination — aislada, sin red
- El muestreador normativo, frente a seis vectores calculados a mano
- Integridad del archivo: cada recurso referenciado viaja, los hashes se recalculan, los sellos se verifican
- Las reglas semánticas del §10 (rotación y operación continua) — 20 de 25 tienen una comprobación ejecutable
- Ejemplos de referencia para L0, L1 y dos casos L2
Aún no existe
- Suites de ida y vuelta y de determinismo — así que «conforme a DSX» aún no es una afirmación que alguien pueda ganar de extremo a extremo
- Conversores con nombre hacia y desde otros formatos (dsx-convert) — previstos; el muestreador es la vía de importación que existe hoy
- La codificación binaria .dsb (sigue siendo un esquema)
- El muestreo de shows sin fin fijo (duration_ms: null)
- Cualquier archivo de referencia que ejercite cargas, interbloqueos pirotécnicos o los campos de integridad GNSS — están especificados, pero ningún ejemplo los demuestra
- Perfiles de dispositivo aportados por fabricantes — aún no hay ninguno
- Un solo vuelo. Ninguna aeronave ha volado un archivo DSX.
Licencias
Elegidas por una razón: tiene que poder implementarse en firmware propietario
Especificación, esquemas, ejemplos, perfiles de dispositivo
Community Specification License 1.0
Su concesión de patentes cubre implementar la especificación — que es el punto entero, y que una licencia de software no da de forma fiable.
Código, herramientas de referencia, suite de conformidad
Apache-2.0
Incrustable en firmware propietario, con una concesión de patentes cuyo alcance encaja de verdad con el código.
El nombre «DSX» y la extensión .dsx
Sin marca registrada, y no hace falta
El nombre de un formato es una designación técnica, como .zip o .json. Cualquiera puede implementar; la conformidad la define la suite pública de pruebas, no una marca.
Explícitamente no GPL: una implementación de referencia bajo GPLv3 no puede incrustarse en el firmware propietario que tiene que leer el formato, y un estándar cuyo código de referencia su propia audiencia no puede enlazar tiene un techo de adopción. Explícitamente no MIT: no hay concesión de patentes. Explícitamente no Apache-2.0 para el texto de la especificación: su §3 licencia patentes para «transferir de otro modo la Obra» — el documento — no para implementar lo que el documento describe.
Si produce shows y el software se lo impide, abra un issue
La creación de issues está abierta. Las propuestas se discuten, no se cierran como «not planned». Quien contribuye figura por nombre en la especificación. Es un compromiso, escrito para que se nos pueda exigir.