Щойно UAV злітає, підрозділ, що ним керує, отримує асиметричну розвідувальну перевагу — за умови, що ця інформація досягає всіх відповідних операторів. Типова оперативна помилка — не відсутність покриття дроном: оператор дрону описує побачене голосом по радіо, поки всі інші сліпо працюють зі своїми GCS або екранами ATAK. Інтеграція телеметрії дрону TAK усуває цей розрив, передаючи позицію UAV, кут гімбала та відеопотік безпосередньо на загальну оперативну картину, щоб кожен клієнт ATAK у мережі бачив дрон як живий трек поряд із дружніми силами.
Ця стаття розглядає повний технічний конвеєр: телеметрія MAVLink від дрону до наземної станції управління (GCS), конвертація до Cursor on Target (CoT), пересилання до TAK Server, ретрансляція відео, кодування відбитку гімбала, зворотна синхронізація маршрутних точок, оптимізація пропускної здатності для радіо MANET та конвенції управління кількома дронами. Усі описані компоненти є відкритими або комерційно доступними — архітектура не прив'язана до конкретної реалізації.
Чому інтеграція дрону-COP важлива: проблема перемикання контексту
Типова операція UAV малого підрозділу включає щонайменше три різні ролі операторів: пілот дрону, що стежить за відеопотоком GCS, командир наземних сил, що працює з картою ATAK, та оператор датчика, що контролює камеру. Без інтеграції кожна роль працює з різним джерелом даних. Пілот знає, де дрон; командир — ні, якщо пілот не наративує. Коли пілот зосереджується на виконанні маневру, коментарі припиняються. Наземні сили не мають треку — вони не можуть бачити зону охоплення дрону, не можуть визначити, коли датчик дивиться на ціль, і не можуть надіслати нову маршрутну точку, не знайшовши пілота та не попросивши усно.
Інтеграція UAV ATAK замінює голосову координацію даними. Дрон з'являється як рухомий повітряний трек на карті ATAK. Відбиток гімбала — полігон, що показує точно, на що дивиться датчик — оновлюється в реальному часі. Відеопотік доступний одним дотиком у ATAK Video Receiver. Командир може надіслати нову точку зависання з карти, не шукаючи пілота. Пілот бачить оновлену місію на GCS. Це не поліпшення зручності: в оскаржуваній міській місцевості з дотриманням комунікаційної дисципліни це різниця між скоординованою ISR та здогадками.
Конвеєр телеметрії MAVLink: від дрону до TAK Server
Конвеєр має п'ять етапів: автопілот дрону → радіоканал даних → GCS (QGroundControl або Mission Planner) → процес-міст MAVLink → TAK Server.
Основи протоколу MAVLink. MAVLink — домінуючий протокол телеметрії та управління для малих UAS. Це легкий бінарний протокол, розроблений для низькопропускних, схильних до втрат радіоканалів. Версія 2 (MAVLink 2) є поточним стандартом і додає підписання пакетів та більший простір ідентифікаторів повідомлень. Потік MAVLink від типового автопілота (ArduPilot, PX4) включає GLOBAL_POSITION_INT з частотою 2–10 Гц, ATTITUDE з 10–50 Гц, HEARTBEAT з 1 Гц, MOUNT_ORIENTATION з 10–25 Гц (якщо встановлено гімбал) та MISSION_ITEM_INT за запитом.
GCS як маршрутизатор телеметрії. GCS отримує потік MAVLink через радіоканал даних — зазвичай радіомодем 900 МГц або 2,4 ГГц, LTE-донгл або mesh-радіо в режимі інфраструктури. QGroundControl та Mission Planner підтримують пересилання MAVLink: налаштування вторинного UDP-виходу на localhost:14551 (або на віддалену IP-адресу) доставляє повний потік будь-якому процесу на машині GCS без перешкод основному підключенню GCS.
Міст MAVLink-to-CoT. Процес-міст читає перенаправлений потік MAVLink та конвертує кожний звіт про позицію у XML-подію CoT. Ключове зіставлення: GLOBAL_POSITION_INT.lat / lon / alt → CoT <point> lat/lon/hae; GLOBAL_POSITION_INT.hdg → CoT <detail><track course=... />; yaw ATTITUDE → резервний курс треку. Існує декілька відкритих мостів — MAVLink2TAK (Python), UASLINK (C++) — або можна реалізувати легкий міст на Go чи Rust для виробничого розгортання, де обмеження ресурсів мають значення.
Доставка до TAK Server. Міст підключається до TAK Server через TCP/TLS на порту 8089 за допомогою клієнтського сертифіката. Він надсилає події CoT як потоковий XML — одна подія на TCP-відправлення, без роздільника кадрів. TAK Server негайно федерує події до всіх підключених клієнтів ATAK, WinTAK та CloudTAK, підписаних на групу дрону.
Структура повідомлення CoT для повітряних треків
Правильний код типу CoT важливий — він керує іконкою ATAK та кольором треку. Для дружнього фіксованокрилого безпілотного літака тип — a-f-A-M-F-Q. Розшифровка: a = атом (реальна сутність), f = дружній, A = повітряний домен, M = військовий, F = фіксоване крило, Q = безпілотний. Для дружнього дрону з обертовим крилом: a-f-A-M-H-Q. Для невідомого контакту: замініть f на u.
Поле how має бути m-g (машинно-згенероване, GPS) — це повідомляє клієнтам ATAK, що позиція є автономними даними сенсора, а не введеною людиною оцінкою. Час застарілості (атрибут stale елемента <event>) слід встановити на 20–30 секунд попереду часу події для дрону, що летить із типовими розвідувальними швидкостями. Занадто короткий час застарілості спричиняє зникнення треку під час короткочасних перебоїв телеметрії; занадто довгий залишає примарні треки на карті після посадки дрону або його значного переміщення.
Мінімальна подія CoT для звіту про позицію дрону:
<event version="2.0"
uid="DRONE-ALPHA-01"
type="a-f-A-M-F-Q"
how="m-g"
time="2026-05-29T10:00:00.000Z"
start="2026-05-29T10:00:00.000Z"
stale="2026-05-29T10:00:25.000Z">
<point lat="48.3794"
lon="31.1656"
hae="250.0"
ce="5.0"
le="10.0"/>
<detail>
<contact callsign="ALPHA-1"/>
<track course="045.0" speed="18.5"/>
<remarks>MAVLink sysid=1</remarks>
</detail>
</event>
Значення ce (кругова похибка) та le (лінійна похибка) мають відображати фактичну точність GPS з повідомлення GLOBAL_POSITION_INT автопілота — ATAK використовує їх для відображення кільця точності навколо іконки треку.
Інтеграція відеотрансляції: RTSP до ATAK
Більшість корисних навантажень малих UAS кодують відео у H.264 або H.265 та надають його як RTSP-потік через канал даних. Шлях інтеграції: камера дрону → бортовий кодувальник → RTSP через канал даних → GCS → ретрансляція FFmpeg → ATAK Video Receiver.
Ретрансляція FFmpeg. На машині GCS FFmpeg отримує RTSP-потік від дрону та ретранслює його у форматі, оптимізованому для доставки ATAK. Для UDP multicast (розповсюдження LAN/MANET): ffmpeg -i rtsp://192.168.1.100:554/stream -c copy -f mpegts udp://239.2.3.1:1234. Для unicast на конкретний пристрій ATAK або ретранслятор TAK Server: -f rtsp rtsp://localhost:8554/drone-alpha. Ключовий параметр — -c copy — транскодуйте лише за необхідності, оскільки транскодування додає затримку та навантаження на CPU GCS.
Налаштування ATAK Video Receiver. Клієнти ATAK не потребують ручного налаштування відео при правильному налаштуванні конвеєра. Міст публікує подію CoT типу b-i-x-i (псевдонім відео), що містить URL потоку, протокол, шлях та зрозумілий людині псевдонім. Коли ця подія надходить до клієнта ATAK, плагін Video Receiver автоматично додає потік до списку джерел. Оператори торкаються іконки треку дрону та вибирають "Переглянути відео" — ATAK відкриває потік вбудовано.
Адаптація до деградованого каналу. Коли канал даних перевантажений або обмежений дальністю, якість відео деградує до того, як канал телеметрії перестає працювати. Налаштуйте FFmpeg для прийому менш якісного потоку від кодувальника дрону (або тригеруйте кодувальник для зменшення бітрейту через MAVLink-параметр CBRN_VIDEO_BITRATE у ArduPilot). При 500–800 кбіт/с H.264 забезпечує прийнятне розвідувальне відео 720p/15fps. Нижче 300 кбіт/с розгляньте перехід на потік знімків JPEG з меншою роздільною здатністю, опублікований як точка датчика CoT, а не живе відео, щоб зберегти пропускну здатність телеметрії.
Накладення гімбала та датчика: кодування полігону FOV
Позиція дрону на карті повідомляє операторам, де знаходиться UAV. Полігон відбитку гімбала повідомляє їм, що охоплює датчик — значно більш оперативно корисна інформація. Обчислення відбитку вимагає: позиція дрону (lat/lon/HAE), кут pan гімбала (азимут від півночі), кут tilt гімбала (депресія від горизонту), горизонтальне та вертикальне поле зору камери (градуси) та плоскоземельне наближення або проекцію WGS84 для вершин полігону.
Для камери, спрямованої в надир на висоті H із горизонтальним FOV θ_h та вертикальним FOV θ_v, відбиток є прямокутником. Для косого кута відбиток є трапецією. Міст обчислює чотири кути та кодує їх як полігон CoT GeoObject:
<event type="u-d-f" uid="DRONE-ALPHA-01-FOV" ...>
<detail>
<shape>
<polyline closed="true">
<vertex lat="48.3802" lon="31.1641"/>
<vertex lat="48.3802" lon="31.1671"/>
<vertex lat="48.3786" lon="31.1671"/>
<vertex lat="48.3786" lon="31.1641"/>
</polyline>
</shape>
<color argb="-2130706433"/>
<strokeColor value="-16711936"/>
<fillColor value="570556928"/>
<remarks>ALPHA-1 gimbal FOV</remarks>
</detail>
</event>
UID полігону FOV виводиться з UID дрону із суфіксом (-FOV), щоб клієнти ATAK могли асоціювати полігон з батьківським треком. Оновлюйте полігон з кожним повідомленням MOUNT_ORIENTATION — зазвичай 10–25 Гц — щоб оператори бачили розворот гімбала в реальному часі. Обмежте до 2–5 Гц через обмежені радіоканали. Використовуйте час застарілості 5 секунд для полігону, щоб він зникав при втраті телеметрії гімбала, запобігаючи введенню операторів в оману застарілими відбитками.
Синхронізація маршрутних точок: від ATAK назад до GCS
Двонаправлена інтеграція — оператори надсилають завдання з ATAK до дрону — є найбільш оперативно значущою можливістю і найбільш технічно складною. Зворотний шлях: оператор ATAK малює маршрут → ATAK публікує подію CoT route на TAK Server → міст отримує маршрут → конвертує маршрутні точки CoT у MAVLink MISSION_ITEM_INT → завантажує місію до GCS → GCS передає дрону.
Події CoT route. Коли оператор ATAK малює маршрут та надсилає його до UID дрону, ATAK публікує подію CoT b-m-r (маршрут), що містить упорядкований список елементів <point>. Міст підписується на події CoT від TAK Server, відфільтровані за UID дрону, і обробляє вхідні події маршруту.
Протокол завантаження місій MAVLink. Завантаження — це рукостискання запит-відповідь: міст надсилає MISSION_COUNT, дрон підтверджує, дрон запитує кожний MISSION_ITEM_INT за порядковим номером, міст надсилає кожен елемент, дрон надсилає MISSION_ACK після завершення. Реалізуйте тайм-аут та повторну спробу на кожному кроці — перебої радіоканалу є поширеними, і завантаження місії має бути надійним. Після успішного завантаження міст публікує подію CoT remark на TAK Server, підтверджуючи прийняття місії з міткою часу.
Примітка щодо системи координат. MAVLink MISSION_ITEM_INT використовує кадр MAV_FRAME_GLOBAL_RELATIVE_ALT за замовчуванням — висота відносно домашньої точки, встановленої при зброюванні дрону, а не абсолютний HAE. CoT використовує HAE (висота над еліпсоїдом, WGS84). Міст повинен конвертувати: HAE → (HAE − home_HAE) = відносна висота. Отримуйте домашню висоту з потоку GLOBAL_POSITION_INT під час зброювання або з повідомлення MAVLink HOME_POSITION.
Оптимізація для малопропускних радіо MANET
Радіо MANET, що використовуються в операціях пішого підрозділу — Persistent Systems MPU5, Silvus StreamCaster, Harris FALCON IV — забезпечують 1–20 Мбіт/с спільної пропускної здатності між усіма вузлами мережі. Одна інтеграція дрону з оновленнями позиції 5–10 Гц, відеопотоком і оновленнями полігону гімбала 10–25 Гц може споживати непропорційно велику частку бюджету і деградувати ситуаційну обізнаність наземних сил, що залежать від того ж радіо.
Обмеження частоти оновлення треку. При 1 Гц дрон, що рухається зі швидкістю 20 м/с, переміщується на 20 м між оновленнями — прийнятно для повітряного треку, по якому оператори не ведуть точний вогонь. При 0,5 Гц трек відстає достатньо, щоб вводити в оману під час поворотів. 1 Гц — розумне значення за замовчуванням для більшості ISR-застосувань через обмежені канали; збільшіть до 2 Гц для сценаріїв близької підтримки, де позиція дрону безпосередньо корелює з наземними діями.
Бінарний CoT vs XML CoT. TAK Server 4.x і нещодавні збірки ATAK підтримують кодований protobuf CoT (бінарний CoT), який зменшує розмір повідомлення на 55–65% порівняно з XML CoT. Для оновлення позиції вагою ~400 байт у XML бінарний CoT становить приблизно 150 байт. При 1 Гц для 4 дронів це заощаджує ~1 Мбіт/с радіопропускної здатності — суттєво на 5 Мбіт/с каналі MANET, спільному для 20 вузлів. Увімкніть бінарний CoT, налаштувавши вхідний конектор TAK Server та оновивши налаштування ATAK на клієнтських пристроях.
Управління якістю відео. Відео є найбільшим споживачем. Потік H.264 720p при 2 Мбіт/с для одного дрону споживає 40% каналу MANET 5 Мбіт/с. Використовуйте RTSP unicast замість multicast, коли відео потрібне лише одному-двом операторам — multicast доставляє до всіх вузлів незалежно від того, чи вони переглядають. Реалізуйте простий механізм запиту на перегляд: оператори запитують відео через повідомлення CoT, сторона GCS доставляє unicast лише клієнтам, що запитали.
Ключове спостереження: Інтеграція дрону-COP — це так само проблема радіобюджету, як і програмна проблема. Моделюйте бюджет каналу MANET перед розгортанням — враховуйте телеметрію, відео, CoT наземних сил, голос та накладні витрати. Інтеграція дрону, що працює на стенді з LAN-комутатором, деградуватиме плавно або катастрофічно через радіо залежно від того, чи була спланована пропускна здатність.
Управління кількома дронами: конвенції позивних та управління групами
Одночасна операція більш ніж двох дронів — чи то координований ISR-рій, чи кілька незалежно поставлених завдань платформ — створює проблеми деконфліктації на карті ATAK. Без дисципліни кілька треків дронів із схожими іконками та без чіткого маркування спричиняють плутанину щодо того, який дрон охоплює яку зону.
Конвенції CoT UID та позивного. Кожен дрон повинен мати глобально унікальний CoT UID — використовуйте структуровану схему, що вбудовує підрозділ, роль та серійний номер: ПІДРОЗДІЛ-РОЛЬ-СЕРІЙНИЙ (наприклад, 3ВЗВОД-ISR-01, 3ВЗВОД-ISR-02). Позивний, що відображається на мітці карти ATAK, має відповідати тій же конвенції та збігатися з голосовими позивними підрозділу. Уникайте загальних позивних на кшталт "Дрон 1" — в операції рівня батальйону з 10+ UAV у повітрі буде кілька треків "Дрон 1", і оператори не знатимуть, який належить якому підрозділу.
Призначення груп CoT. Групи TAK Server контролюють, які клієнти бачать які треки, і дозволяють операторам показувати/приховувати підмножини картини. Призначайте дрони до тієї ж групи, що й наземний підрозділ, якому вони надають підтримку — органічний UAV взводу йде до групи взводу, а не до групи батальйону, щоб оператори взводу бачили його за замовчуванням без фільтрації. Прикомандировуйте дрони до вищих груп, коли картина потребує згортання до COP роти або батальйону.
Реєстр дронів моста MAVLink. Коли кілька екземплярів GCS звітують на один TAK Server, міст на кожній GCS повинен використовувати реєстр дронів — постійне зіставлення системних ID MAVLink з CoT UID — для забезпечення узгодженості. Два мости, що обидва звітують про системний ID 1 з різними UID, створять дублікати треків. Реєстр — це простий файл JSON або SQLite; його слід попередньо заповнити перед розгортанням та зберігати централізовано, щоб уникнути конфліктів при ротації персоналу GCS.
Обізнаність рою у масштабі. Для операцій з більш ніж 5–6 дронами одночасно у повітрі розгляньте додавання спеціального накладення управління дронами — кастомного плагіна ATAK або компонента WinTAK, що відображає всі треки дронів із станом батареї, статусом місії та доступністю відео у табличному форматі поряд із картою. Чисте управління на основі карти стає незручним понад 4–5 одночасних треків у стисненому бойовому просторі. Більший розмір екрана WinTAK робить його кращою платформою для цієї ролі.