ПЕРЕЙТИ ДО ЗМІСТУ
Дистанційна ударна група Альфа
EN SV ВИДАННЯ 2026-Q2 АКТИВНА
НЕТАЄМНО
FSG-A // ДОКТРИНА // AAR

РОЗБІР ПІСЛЯ ДІЙ
ДРОНОВИЙ ДЕБРИФ МІСІЇ

Автор: Tiny
ГОТОВО 7 ХВ ЧИТАННЯ
КЛЮЧОВИЙ ВИСНОВОК
Кожна дронова місія отримує розбір протягом 2 годин після посадки. Не факультативно. Дані SD-карти з Jetson замінюють пам'ять пілота — відео покадрово, журнал AI-виявлень, телеметрія MAVLink. Чотири питання: що планувалось, що сталось, чому різниця, що змінити наступного разу. Результат: рівно одне конкретне, вимірюване покращення. Команди, що послідовно проводять структуровані розбори, перевершують ті, хто не проводить, приблизно на 25 % у середньому (мета-аналіз Tannenbaum & Cerasoli 2013, 46 досліджень, Human Factors 55(1): 231–245).

ДЖЕРЕЛА ДАНИХ ДЛЯ AAR

SD-карта (Jetson)
Журнал AI-виявлень (JSONL), мініатюри, впевненість YOLOv8 на кадр
MAVLink-лог
Маршрут польоту, висота, акумулятор, статус EKF3, події failsafe
COP Lisa 26
Часова шкала: виявлення → рекомендація → затвердження → удар → BDA
DVR-запис
Запис FPV-окулярів — що пілот насправді бачив
Дебриф пілота
Усний — записаний ПІСЛЯ перегляду даних, не до

Чому дані перед пам'яттю

Пілот під бойовим стресом пам'ятає неправильно. Адреналін спотворює сприйняття часу — «я бачив ціль п'ять секунд» фактично було 1,2 секунди на DVR-записі. Оцінки відстаней помилкові у два-три рази. Послідовність подій переставляється. Це не критика пілотів — це людська нейробіологія під стресом. Рішення просте: переглянути дані ПЕРЕД тим, як питати пілота, що сталося. SD-карта не має адреналіну. MAVLink-лог не забуває.

Журнали Lisa 26 забезпечують об'єктивну часову шкалу кожної події: коли AI виявив, який рівень впевненості, коли було згенеровано L2-рекомендацію, коли командир затвердив, коли FPV запустився, коли вдарив, і що показав BDA-прохід. Ця часова шкала виявляє вузькі місця, які суб'єктивна пам'ять пропустила б. Найпоширеніше відкриття: затримка між виявленням і ударом становить 8–12 хвилин, коли цільова має бути 2–5 хвилин. Пілот думає, що було швидко. Лог каже інакше.

Чотири питання

Питання 1: Що планувалось? Брифінг місії визначає намір, зону цілі, вектор заходу, ROE і резерви. Запишіть це ДО місії, щоб його не можна було ревізувати заднім числом. Якщо план був «ISR-зачистка сектору 4, атакувати машини можливостей із півдня» — це базова лінія, проти якої все вимірюється.

Питання 2: Що сталось? Це повністю з даних. DVR показує, що бачив пілот. MAVLink-лог показує, куди літав дрон. Лог Lisa 26 показує, що AI виявив і які рекомендації було згенеровано. SD-карта показує впевненість виявлення кадр за кадром. Пілот додає контекст лише після перегляду даних: «Я бачив ціль на тепловізорі, але вирішив не атакувати, бо підозрював цивільний транспорт». Цей контекст має значення — але приходить другим, не першим.

Питання 3: Чому різниця? Тут відбувається навчання. План казав атакувати з півдня. Пілот атакував зі сходу. Чому? «Вітер був 15 км/год з півдня — захід проти вітру зменшив акумулятор до критичного рівня перед досягненням цілі. Я перенаправив на схід для заходу з попутним вітром». Це валідна тактична адаптація. Або: «Я забув, що брифінг казав південь». Це прогалина в підготовці. Дані відрізняють одне від іншого.

Питання 4: Що змінити наступного разу? Одне. Не десять. Одну конкретну, вимірювану зміну. «Наступна місія: перевірити напрям вітру під час передпольотного огляду і скоригувати вектор заходу, якщо зустрічний вітер перевищує 10 км/год». Конкретно. Тестовано. Наступний AAR перевіряє, чи була ця зміна впроваджена і чи допомогла.

Правило одного висновку

Кожен розбір завершується РІВНО одним конкретним, вимірюваним покращенням. Не трьома. Не п'ятьма. Одним. Причина: три висновки означають, що жоден не буде виконаний. Один висновок означає, що він буде виконаний до наступного вильоту. Приклади правильних висновків: «Додати перевірку напряму вітру в передпольотний чекліст» (конкретно, вимірюване); «Збільшити мінімальну висоту Fischer 26 з 120 м до 150 м у секторі Б» (конкретно); «Перевіряти заряд акумулятора перед кожним зниженням нижче 150 м» (вимірюване). Приклади неправильних: «Бути обережнішим» (не вимірюване), «Покращити тактику» (не конкретно).

Типові висновки з українських операцій

Висновок 1 — затримка рішення: час від виявлення Fischer 26 до удару FPV в середньому 8–12 хвилин. Цільова 2–5 хвилин. Коренева причина: командир взводу запитує підтвердження на рівні роти замість прийняття рішення на своєму рівні повноважень. Виправлення: явна делегація ROE ДО місії — «машини в секторі 3 попередньо затверджені для ураження на рівні взводу».

Висновок 2 — провал передачі цілі: пілот FPV не може знайти ціль, яку виявив Fischer 26. Коренева причина: помилка позиції 50–200 м без GPS означає, що координати ставлять пілота у правильну зону, але не на ціль. Виправлення: Fischer 26 підтримує орбіту над ціллю і потокує живе відео на другий екран пілота FPV під час заходу. Пілот бачить ціль через камеру Fischer 26, летячи до неї.

Висновок 3 — пропущений BDA: після удару пілот доповідає «влучення» і повертається. Жодного BDA-проходу Fischer 26. Результат: ціль записана як знищена, але фактично вижила (30–40 % влучень FPV не виводять ціль з ладу). Виправлення: обов'язковий BDA-прохід Fischer 26 через 30–60 секунд після кожного удару. Без винятків. Якщо Fischer 26 недоступний, одноразовий ISR виконує BDA.

Висновок 4 — управління акумулятором: пілот запускається з частково зарядженим акумулятором, бо «було достатньо». Дрон повертається з 5 % — один порив вітру від падіння. Виправлення: мінімальна напруга запуску, примусово виконувана в передпольотному чеклисті. Нижче 3,7 В на комірку = жодного запуску, крапка.

Типові висновки — таблиця частоти

ПроблемаЧастотаТиповий висновок
Втрата зв'язку при зниженні~30 % місійНе знижувати Fischer 26 нижче 150 м без підтвердження LOS
AI хибні спрацьовування на техніці~20 % виявленьПеревіряти AI-клас > 85 % перед рекомендацією удару
Акумулятор недозарядів~15 % вильотівДодати перевірку напруги на клітинку перед запуском
Вітровий ефект на витривалість~25 % місійЗменшити запланований час на 20 % при вітрі > 10 км/год
Помилкова координата цілі~10 % виявленьПерехресна перевірка візуального орієнтира з картою

Формат AAR

ШАБЛОН ЗВІТУ AAR

ID місії
YYYYMMDD-HHMM-підрозділ-тип (напр., 20260415-0830-A4126-FPV)
Тривалість
Час запуску → час повернення (з MAVLink-логу)
План vs Факт
Брифований намір vs що показують дані
Виявлення
Кількість, класи, діапазон впевненості, хибні позитиви
Удари
Тип цілі, зброя, результат: K (знищено) / M (рухливість) / F (вогнева міць) / MISS
Втрати
Втрачені дрони + причина: бойова / падіння / РЕБ / технічна
РЕБ-середовище
Виявлено глушіння (Т/Н), частоти, деградація MANET
Висновок
ОДНА конкретна зміна для наступної місії

Аналіз паттернів у часі

Окремі AAR ідентифікують тактичні коригування. Зібрані AAR за тижні й місяці виявляють паттерни. Lisa 26 на бригадному сервері зберігає всі AAR-дані в PostgreSQL. Паттерн-запити: «Які вектори заходу дають найвищий рівень успіху ударів проти окопаних машин?» Відповідь після 200 місій: південь-південний захід між 14:00–16:00 (сонце за атакуючим, екіпаж цілі засліплений відблиском). Це знання, якого жодна окрема місія не продукує — воно виникає з систематичного збору даних через сотні ураження.

Другий приклад паттерну: рівень втрат дронів за часом доби. Дані з 6 місяців операцій показують, що втрати сягають піку на світанку і в сутінках — низький кут сонця створює теплові градієнти, що деградують навігацію за оптичним потоком, спричиняючи більше падінь під час автономних сегментів. Виправлення: збільшити мінімальну висоту під час переходів світанок/сутінки з 50 м до 80 м AGL. Рівень втрат падає на 40 % у наступному місяці. Це покращення було невидиме окремим пілотам — воно з'явилося лише в агрегованих даних.

Швидкість навчання

За мета-аналізом Tannenbaum & Cerasoli (2013, 46 досліджень, Human Factors 55(1): 231–245), команди, що послідовно проводять структуровані розбори, покращують показники приблизно на 25 % у середньому (Cohen's d ≈ 0,79). Структуровані розбори з фасилітатором показують ефекти вдвічі більші за неструктуровані. Для дронових підрозділів, що виконують 10–15 місій за 2–3 тижні активних операцій, це передбачає помітне покращення тактичних показників після перших 10–15 циклів AAR. Різниця — не талант, а дисципліна збору і аналізу даних.

Процес розбору після дій перетворює індивідуальний досвід місії на інституційне знання. Кожен розбір генерує рівно одне конкретне покращення, яке наступна місія тестує. За 20 місій 20 розборів генерують 20 покращень — наростаюча тактична перевага, яку жодна передрозгортальна підготовка не може відтворити.

Структурована методологія AAR відокремлює професійні військові дронові операції від аматорської імпровізації. Дисципліна розбору гарантує, що кожна оперативна дія — успішна чи невдала — генерує задокументоване навчання, що приносить користь усій організації. Без цього систематичного процесу підрозділи повторюють ті самі помилки нескінченно, вірячи, що покращуються лише через досвід.

ПРОСТОЮ МОВОЮ: AAR ЗА 15 ХВИЛИН
Після кожної місії: підключіть SD-карту, перегляньте DVR, перевірте часову шкалу Lisa 26. Чотири питання: планувалось, сталось, чому різниця, що змінити. Один висновок. Запишіть. 15 хвилин. Не факультативно. Команди, що послідовно проводять розбори, перевершують ті, хто не проводить, приблизно на 25 % (Tannenbaum & Cerasoli 2013). Дані, не пам'ять.

← Частина Інтеграція взводу

Реалізація

# AAR Data Export — Lisa 26 to CSV for Pattern Analysis
# pip install psycopg2
import psycopg2
import csv
from datetime import datetime, timedelta

def export_aar_data(days_back=30, output_file="/tmp/aar_export.csv"):
    """Export AAR data from Lisa 26 PostgreSQL for pattern analysis."""
    conn = psycopg2.connect("dbname=lisa26 user=lisa26 host=localhost")
    cur = conn.cursor()

    cur.execute("""
    SELECT
        m.mission_id,
        m.launch_time,
        m.recovery_time,
        m.drone_type,
        EXTRACT(HOUR FROM m.launch_time) as hour_of_day,
        d.class as target_class,
        d.confidence,
        s.result,
        s.approach_vector_deg,
        m.ew_jamming_detected,
        m.drone_lost,
        m.loss_cause
    FROM missions m
    LEFT JOIN detections d ON m.mission_id = d.mission_id
    LEFT JOIN strikes s ON m.mission_id = s.mission_id
    WHERE m.launch_time > NOW() - INTERVAL '%s days'
    ORDER BY m.launch_time
    """, (days_back,))

    rows = cur.fetchall()
    headers = [desc[0] for desc in cur.description]

    with open(output_file, 'w', newline='') as f:
        w = csv.writer(f)
        w.writerow(headers)
        w.writerows(rows)

    print(f"Exported {len(rows)} AAR records to {output_file}")
    conn.close()

export_aar_data(days_back=30)

Пов'язані розділи

Джерела

Нормативні джерела. Методологія AAR — US Army Center for Army Lessons Learned (CALL), TC 25-20 «A Leader's Guide to After-Action Reviews» (публічний). Зберігання PostgreSQL — postgresql.org офіційна документація. Формат MAVLink-логів — mavlink.io специфікація повідомлень.

Параметричні джерела. Статистика «30–40 % FPV-влучень не виводять ціль з ладу» — опубліковані аналізи Watling & Reynolds «Meatgrinder», RUSI (2023). Паттерн «затримка 8–12 хв виявлення-до-удару» — документовано в ISW щоденних оцінках кампанії (архів understandingwar.org). Схема бази даних Lisa 26 (таблиці missions, detections, strikes) — внутрішня архітектура FSG-A (концептуальна).

Операційні оцінки — не верифіковано FSG-A в польових умовах. «Команди перевершують на 25 %» — це результат мета-аналізу Tannenbaum & Cerasoli (2013) на 46 дослідженнях (зважене середнє Cohen's d ≈ 0,79). FSG-A не проводила власного контрольованого дослідження. 15–30 хвилин тривалості AAR — проєктна ціль з US Army TC 25-20. Усі цифри в таблиці «Типові висновки» (~30 %, ~20 %, тощо) — ілюстративні приклади з публічних джерел, не статистика, зібрана FSG-A. FSG-A не має власних AAR-даних з польових місій.

Зовнішні стандарти та джерела. US Army TC 25-20 «A Leader's Guide to AAR»; Center for Army Lessons Learned публікації (call.army.mil). Watling & Reynolds, «Meatgrinder: Russian Tactics», RUSI (2023) — українська AAR-практика. ISW щоденні оцінки кампанії (архів understandingwar.org) — оперативні паттерни з України. PostgreSQL офіційна документація. MAVLink специфікація повідомлень (mavlink.io).