Saltearse al contenido

Medios DJI

Las aeronaves de dock DJI capturan fotos y vídeos a la tarjeta SD de la aeronave durante el vuelo. Al aterrizar, el dock copia la tarjeta SD a su propio almacenamiento y transmite los archivos a S3 a través del pipeline de medios de ARGUS. Todo se indexa en Firestore para que la vista de operaciones pueda exponer los medios capturados por tarea de vuelo.

Fuente de captura

  • Fotos — disparadas por acciones de waypoint en la wayline, por una pulsación manual del disparador durante DRC, o por el modo de seguimiento inteligente de la aeronave.
  • Vídeos — grabados al inicio de grabación de vídeo DRC, o por una acción startRecord de waypoint.
  • Sidecars PPK / RTK.obs (observaciones RINEX), .rtk (observaciones de la estación base del dock), .mrk (marcador de exposición por foto), .nav (mensaje de navegación GNSS), .dat (binario crudo). Capturados siempre que la aeronave vuela con RTK habilitado.

La aeronave escribe a su propia tarjeta SD; no ocurre ninguna subida durante el vuelo.

Subida al aterrizar

Cuando la aeronave aterriza y se re-acopla:

  1. El dock copia los contenidos de la tarjeta SD a su almacenamiento interno. Esto toma 30–300 s dependiendo del tamaño del payload.
  2. El dock publica file_upload_progress sobre MQTT conforme cola archivos para subida.
  3. Para cada archivo, el dock solicita un PUT presigned S3 a argus-api y sube directamente a S3 — sin salto intermedio.
  4. En cada subida completada, el dock publica fileupload_callback con {file_name, object_key, sub_file_type, fingerprint, size, ...}.
  5. argus-dji recibe el callback y, dentro de una transacción Firestore, escribe un documento dji_media/{id} con:
    • deviceSn / dockSn;
    • bucket + key de S3;
    • fileName, fileSize, fileType (photo / video);
    • flightTaskId — enlace de vuelta a la wayline / vuelo ad-hoc que lo produjo;
    • position (lat/lng/alt de captura, desde el EXIF de la aeronave);
    • marcas de tiempo capturedAt + uploadedAt.

Los medios aparecen en la pestaña Medios de la vista de operaciones en segundos tras completar la subida del dock.

Manejo de sidecars PPK / RTK

Los archivos sidecar comparten el nombre base de su foto (DJI_0042.JPG se empareja con DJI_0042.MRK). argus-dji los etiqueta con un subFileType para que el post-procesador de misión pueda empaquetar cada foto con su marcador de exposición y las observaciones crudas del dock para georreferenciación con precisión centimétrica. Una misión RTK típica produce ~7 archivos por imagen:

  • .JPG — la imagen en sí.
  • .MRK — marca de tiempo de exposición por foto.
  • Por misión: .obs, .rtk, .nav, .dat, y el JSON de resultado de la wayline.

Si el post-procesamiento PPK está habilitado para la misión, argus-media recoge los sidecars y ejecuta el post-solucionador basado en RTKLib para producir coordenadas EXIF corregidas — reemplazando la posición cruda del lado de la aeronave.

Deduplicación

El object_key de cada subida es único por sesión de captura, pero un dock puede reintentar un fileupload_callback (p. ej. por un fallo transitorio de escritura a Firestore). argus-dji escribe cada documento dji_media/{id} dentro de una transacción Firestore indexada por object_key: si ya existe un documento para esa clave, el reintento es un no-op. Esto mantiene el índice limpio incluso en enlaces poco fiables.

Priorización

Por defecto, las subidas de medios corren en el orden nativo del dock (captura más antigua primero). Para una misión activa donde el operador necesita una imagen específica ahora (p. ej. una foto de objetivo de interés para triaje), la vista de operaciones ofrece una acción Priorizar en cualquier fila de subida pendiente:

  • ARGUS publica un servicio MQTT media_upload_prioritize al dock con el object_key.
  • El dock re-ordena su cola de subida para que esa clave salte al frente.
  • El estado en la fila cambia de queued a uploading en pocos segundos.

Aspiracional: la priorización en bloque por id de waypoint de wayline (para que un lote de waypoint-crítico salte toda la cola) está planificada pero aún no conectada — actualmente el operador prioriza un archivo a la vez.

Descargar / ver

En la pestaña Medios de la misión, hacer clic en cualquier miniatura llama a GET /api/dji/media/{id}/url y redirige a un GET S3 presigned de corta vida. Los archivos de vídeo se abren en un player inline; las fotos en un lightbox. Los zips de descarga en bloque se generan del lado del servidor a partir de la selección.

Ubicación de almacenamiento

Bucket por organización, prefijado por serie del dock y fecha de captura: s3://{org-bucket}/dji-media/{dockSn}/{yyyy-mm-dd}/{filename}. La retención sigue la política de almacenamiento de la organización (por defecto 1 año, configurable en Admin → Organización → Almacenamiento).

Solución de problemas

  • Aparecen fotos pero no vídeos. Los vídeos pueden ser cientos de MB — filtra la pestaña de medios por fileType: video y espera; la barra de progreso en el tile del dock muestra la profundidad de la cola de subida del dock.
  • Faltan sidecars PPK. La aeronave voló con RTK deshabilitado — los sidecars sólo se emiten cuando RTK estaba activo en el momento de captura.
  • Miniaturas vacías. La generación de miniaturas es perezosa; la primera apertura lanza el generador. Refresca tras ~10 s.

Relacionado

  • Tareas de vuelo — el envío de wayline que dispara la mayoría de capturas.
  • DRC — ruta de captura manual.
  • Tile del dock — expone el almacenamiento del dock usado / total.