Saltearse al contenido

Firmware de dock DJI

ARGUS aloja los binarios de firmware en S3 y los envía a los docks vinculados (y a sus aeronaves) mediante el servicio ota_create de la DJI Cloud API. El pipeline vive en Admin → Gestión DJI → Firmware.

Quién puede subir

La subida de firmware es sólo admin. Los operadores ven la versión de firmware en el tile del dock pero no pueden iniciar una actualización.

Flujo de subida

Cuando un admin elige un archivo de firmware en Admin → DJI → Firmware → Subir:

  1. ARGUS solicita una URL de PUT presigned S3 de 10 minutos a la API. El TTL corto limita la ventana para una filtración de credenciales.
  2. El navegador lee el archivo y calcula MD5 del lado del cliente (archivos grandes se transmiten a través del digest subtle de Web Crypto — sin carga en memoria).
  3. El navegador sube directamente a S3 mediante la URL presigned. Ningún byte pasa por ARGUS.
  4. Tras la subida, la API ejecuta un S3.HeadObjectCommand para confirmar que el objeto existe con el tamaño esperado. Si el HEAD falla, la clave S3 se elimina y la subida se rechaza.
  5. La API acuña una URL de GET presigned de 6 horas (lo suficientemente larga para cubrir la descarga del dock + reintentos) y escribe un documento Firestore dji_firmware/{id} con:
    • nombre de archivo, tamaño, SHA, MD5;
    • cadenas de versión de producto + versión de firmware extraídas del nombre de archivo (convención de DJI — p. ej. WM265E_07.01.10.05.zip);
    • dominio objetivo (aircraft / dock);
    • uid del uploader + marca de tiempo;
    • la URL de GET presigned (regenerada al re-enviar si expira).

Enviar al dispositivo

  1. En la lista de firmware, elige la fila y haz clic en Enviar al dispositivo.
  2. Confirma el objetivo: dock, aeronave, o ambos (determinado por el nombre de archivo del firmware).
  3. ARGUS llama a POST /api/dji/docks/{sn}/firmware/upgrade con un array devices[] (una entrada para el SN del dock y el SN de la aeronave, con product_version + firmware_version).
  4. argus-dji publica el servicio MQTT DJI ota_create con el file_url presigned, md5, y file_size.
  5. El dock descarga el binario, verifica el MD5 y comienza la instalación. Cuando el objetivo es la aeronave, el dock instala a la aeronave en la siguiente presencia.

Pipeline de estado

El subcampo dji_docks/{sn}.firmwareUpgrade rastrea el progreso; la pestaña de firmware lo renderiza como una barra de progreso etiquetada:

EstadoSignificado
queuedEl push fue aceptado; el dock aún no ha comenzado.
downloadingEl dock está descargando el binario desde la URL presigned. El porcentaje de progreso es a nivel de bytes.
verifyingEl dock está verificando MD5 contra el manifiesto.
installingEscritura en flash en curso. No hagas ciclo de alimentación del dock durante esta fase.
completedInstalación terminada. El dock normalmente se reinicia en este punto.
failedVer lastError — normalmente un código de error DJI (p. ej. 50001 MD5 incorrecto).

Las actualizaciones de progreso llegan como eventos ota_progress de DJI en thing/product/{sn}/events y son espejadas a Firestore por argus-dji aproximadamente una vez por segundo.

Puertas de seguridad

ARGUS (y el firmware del dock) aplican:

  • Sin actualización mientras vuela. Si la aeronave está en cualquier código de modo en-vuelo (MANUAL_FLIGHT, WAYLINE_FLIGHT, AUTO_RETURNING_HOME, etc.), el push es rechazado por el bridge antes de llegar a MQTT. Aterriza primero.
  • Sin actualización durante una tarea de vuelo activa. Las misiones WPML enviadas se completan o cancelan antes de que se acepte una actualización.
  • lastError con código DJI. En caso de fallo, el código de error se expone crudo — las tablas de decodificación viven en la documentación Cloud-API de DJI. Códigos comunes: 50001 (desajuste de MD5), 50002 (almacenamiento insuficiente), 50005 (aeronave ausente del dock).

Sin rollback

No hay rollback. DJI no expone una ruta de downgrade mediante Cloud-API OTA. Una vez instalado un firmware, la única forma de volver atrás es un firmware de fábrica de DJI Support mediante una sesión de Assistant 2 adjunta físicamente por USB. Planifica en consecuencia:

  • Prueba una actualización en un dock antes del push a toda la flota.
  • Mantén un dock de repuesto con el firmware anterior como fallback.
  • No empujes durante una ventana operativa.

Disparar “comprobar actualizaciones”

La pestaña de firmware también tiene un botón Comprobar actualizaciones que reutiliza el mismo pipeline pero con campos product_version / firmware_version vacíos. El dock interpreta esto como una comprobación de actualización gestionada por DJI y extrae cualquier versión que crea que es su versión recomendada actual (sobrepasando el binario subido por ARGUS). Útil en una emergencia cuando ARGUS aún no ha espejado un nuevo release de DJI.

Relacionado