Saltearse al contenido

Misiones de relay multi-dock

Relay multi-dock envía una única misión lógica a través de múltiples docks DJI en secuencia. El dock A despega, cubre el segmento 1, aterriza en A; el dock B despega, cubre el segmento 2; y así sucesivamente. El operador planifica una ruta; ARGUS maneja la división de segmentos, la generación de KMZ por dock, las entregas atómicas y la recuperación ante fallos.

Cuándo usarlo

Una aeronave típica de DJI Dock 3 cubre ~10 km de radio ida-vuelta. Para un corredor lineal de 40 km o un área SAR muy grande, una aeronave no puede alcanzar el extremo lejano. El relay divide la ruta entre 2, 3, 4+ docks posicionados a lo largo de la ruta.

Planificación

  1. Crea un plan de misión de dron que abarque toda la ruta.
  2. En la sección Coordinación del plan, elige Relay multi-dock.
  3. Elige los docks que participarán (en orden — dock A primero, B luego, etc.).
  4. ARGUS calcula un índice de waypoint de entrega por dock — el waypoint donde aterriza la aeronave del dock actualmente volando y el del siguiente dock toma el relevo.
  5. Guardar.

Envío — el truco de la pre-subida

El relay multi-dock tradicional requiere que la webapp genere los KMZ de segmento en cada entrega. Eso es frágil — si el navegador del operador muere a mitad de misión, la cadena se rompe.

En lugar de eso, ARGUS pre-sube el KMZ de cada segmento por adelantado para que argus-dji pueda hacer las entregas autónomamente sin ningún round-trip de la webapp:

  1. Cuando haces clic en Enviar, ARGUS:
    • Convierte cada segmento a su propio WPML KMZ.
    • Sube cada KMZ a S3 vía PUT presigned.
    • Persiste relaySegments[] en el documento padre de la misión: [{dockSn, startIndex, endIndex, s3Key, djiWaylineId, sizeBytes}].
    • También escribe allWaypoints: mission.waypoints para que la UI pueda renderizar la ruta completa planificada.
  2. El segmento 0 se envía mediante el flujo normal de un solo dock.
  3. El servicio de relay de argus-dji escucha los eventos de mission-complete en cada dock; al completarse, recoge la entrada del siguiente segmento de relaySegments[] y reenvía autónomamente.

Esto significa que los operadores pueden cerrar su navegador, estrellarse, quedarse sin conexión, lo que sea — la cadena de relay sigue funcionando mientras argus-dji esté arriba.

El flujo de entrega

  1. La aeronave del dock A vuela el segmento 0 → aterriza en A.
  2. El multi-dock-relay-service de argus-dji observa el evento flight-complete para el segmento 0.
  3. Lee relaySegments[1] del documento padre de la misión.
  4. Usa una transacción Firestore para reclamar atómicamente el siguiente dock (campo relayCurrentSegment). Esto previene doble-envío si múltiples eventos de dock disparan simultáneamente.
  5. Crea un nuevo documento dji_flight_tasks/{id} apuntando a la wayline pre-subida para el segmento 1.
  6. Llama a prepareTask en el dock B → el dock B toma el relevo.

Monitoreo

Los operadores ven:

  • Mapa — la ruta completa planificada renderizada con un gradiente de color por segmento. El rastro de la aeronave activa está sobre el segmento actual; los segmentos completados se desvanecen.
  • Tile de flota — una misión lógica con el dock actualmente volando resaltado. Conforme ocurren las entregas, el tile de flota transita suavemente al siguiente dock.
  • Registro de vuelo — eventos de límite de segmento registrados para el after-action.

Manejo de fallos

El sistema está diseñado para degradarse con gracia:

  • KMZ ausente de S3 — improbable (PUT presigned es idempotente), pero si ocurre, argus-dji emite un evento relay.segment_failed y pausa la cadena. El operador puede enviar manualmente el segmento faltante.
  • Dock queda offline aproximándose a una entrega — la cadena pausa con una alerta de precaución maestra. El operador elige: esperar a que vuelva el dock, saltar el segmento, o abortar la cadena.
  • La aeronave pierde el waypoint de entrega (p. ej. desviada por viento) — la wayline entregada es recuperable mediante recover_in_flight_wayline. argus-dji reenvía el segmento desde el último break-point.

Limitaciones

  • Todos los docks en la misma organización. Relay entre organizaciones no está soportado.
  • Se prefiere un solo tipo de dron por cadena. Mezclar Dock 2 + Dock 3 funciona pero los chips de capacidad varían por segmento.
  • SOC mínimo de batería requerido en cada dock participante (configurable por organización, típicamente 60 % para participar).
  • Sin replanificación en vivo — no puedes cambiar la ruta a mitad de cadena. Aborta y replanifica + reenvía si lo necesitas.
  • Recuento de segmentos — el límite práctico es ~8 docks; cadenas más largas aumentan la probabilidad de fallo de entrega.

Relacionado