Кожен бортовий комп'ютер БПЛА постійно порівнює поточні параметри польоту з очікуваними діапазонами. Відхилення за межі норми — «аномалія» — може бути незначним (незначний шум вібрації), попереджувальним (знижений ресурс батареї), критичним (desync двигуна) або аварійним (відмова GPS у urban каньйоні з активним REB).
Сучасні FC (Betaflight, ArduPilot, PX4) мають від кількох десятків до кількох сотень тригерів виявлення аномалій. Для бойових умов ключова проблема — рівень чутливості: занадто чутливий налаштування дає хибні спрацьовування під час бою (вібрації, радіошум), занадто ліберальний — пропускає реальні небезпечні стани.
Автономні failsafe-реакції FC на аномалії (повернення додому, зниження, утримання позиції) є рятівним механізмом у цивільному контексті. У бойовому — їх потрібно конфігурувати з великою обережністю: «Return to Home» може привести борт прямо у позицію противника або розкрити позицію оператора.
Ієрархія тривог та реакцій польотного контролера
Типові аномалії та їх джерела у бойових умовах
| Аномалія | Причина у бою | FC реакція | Оперативна реакція оператора |
|---|---|---|---|
| RSSI різко впало | REB, перешкода, або вийшов за дальність | Failsafe через 1–3 сек | Повернути на меншу дальність; змінити висоту |
| GPS accuracy знизилась | GPS jamming (РЕБ), urban canyon | Warning → switch to ACRO/STABILIZE | Перейти на ручне управління |
| Вібрація понад норму | Пошкоджений гвинт або мотор | Log warning; PIDs stiffened | Візуальна перевірка, посадка для огляду |
| Battery voltage drop | Пошкоджена ємність або холод | Low bat warn → forced RTH | Прискорене повернення або посадка |
| ESC thermal limit | Агресивний пілотаж або важке навантаження | Motor output limit (derate) | Зменшити маневрування, знизити навантаження |
Часті запитання
Що відбувається коли FC виявляє аномалію і чому failsafe може бути небезпечним у бою?
FC (Flight Controller) — мозок дрону — безперервно моніторить сотні параметрів. При виявленні аномалії виконується одна з дій: Рівень INFO/WARNING: запис у blackbox лог, відображення на OSD, передача через телеметрію на GCS. Пілот отримує сигнал і вирішує. Рівень CRITICAL/EMERGENCY: FC може автоматично змінити режим польоту без участі пілота. Найпростіший приклад — Failsafe «Return to Home» (RTH): якщо пілот втратив зв'язок більше 2–3 секунд → FC автоматично летить назад до точки старту. Чому RTH небезпечний у бою: 1) «Лінія повернення» — читабельна для противника. БПЛА летить по прямій до позиції оператора → розкриває її ворожому засобу спостереження або РЕБ. 2) Висота RTH (зазвичай задана наперед): може бути надто висока — видимий силует над полем бою. 3) РЕБ може навмисно «відключити» канал → спровокувати RTH → БПЛА летить до відомої позиції. Бойові налаштування failsafe ЗСУ: Ряд підрозділів ЗСУ відключають RTH і замість нього ставлять: «Hover 3 сек → Land In Place» або «Drop» (вимкнути мотори). Ударні FPV: failsafe взагалі не застосуємо — one-way weapon. Ключовий принцип: у бохових умовах failsafe треба конфігурувати індивідуально під завдання, а не залишати заводські налаштування. Заводський RTH — цивільне рішення для втраченого парку.
Як GPS jamming впливає на виявлення аномалій і що робить FC при втраті GPS?
GPS jamming — один з найчастіших викликів у бойовому просторі України 2023–2025: Факти: Росія розгорнула потужні GPS-jam системи (Pole-21, Borisoglebsk-2, вертолітна РЕБ). У пікові моменти jamming охоплював 50–200 км радіус деградованого GPS. Симптоми у телеметрії: HDOP різко зростає (нормальний <1.5, поганий >5, непридатний >10). GPS Speed і Accuracy флуктують. «GPS Fix» іноді повністю втрачається (від 3D fix до No Fix). Реакція ArduPilot/PX4 при GPS degradation: 1) «GPS Glitch» виявлення: якщо позиція телепортується нереалістично (GPS drift/spoof) → FC автоматично «відхиляє» GPS і переходить на Dead Reckoning (IMU інтеграція). 2) При повній втраті GPS Fix у режимі Loiter/Auto: FC перемикається у ALTHOLD (утримання висоти по барометру) або STABILIZE. RTH стає неможливим (немає координат home). 3) Betaflight FPV: GPS rescue (якщо налаштований) — при jamming стає ненадійним або повністю відключається. Практика ЗСУ: перенавчання операторів на manual ACRO-flight без GPS залежності. Саме тому кращі FPV-пілоти ЗСУ не покладаються на GPS взагалі — all manual flight. Для autonomy-based БПЛА → розробка GPS-denied navigation (optical flow, terrain matching) — тема окремих сторінок.
Що таке Pre-Arming Check і які аномалії він виявляє?
Pre-Arming Check — набір автоматичних перевірок FC перед дозволом на arm (увімкнення моторів): ArduPilot Pre-Arm checks (неповний список): 1) GPS Health: мінімум N супутників, HDOP < threshold. При GPS jamming: arm може бути заблокований. Обхід: ARMING_CHECK маска може відключити GPS check при тактичній необхідності. 2) RC Calibration: всі RC канали в межах очікуваних значень. Виявляє сбій RX, погані trim. 3) IMU consistency: кілька IMU (якщо є) повинні збігатися. Виявляє пошкоджений гіроскоп. 4) Compass: магнітне поле без великих відхилень. Компас поблизу металу або двигунів → помилка. 5) Battery: напруга вище мінімального порогу. Нова батарея або battery check. 6) Barometer: атмосферний тиск у нормі. 7) Airspeed (fixed-wing): calibrated zero. 8) Board voltage: стабільне живлення FC. Betaflight Pre-arm: схожий набір але менший. Accelerometer calibrated, Gyro stable, Baro reading, RX connected. Betaflight 4.4+: додано motor direction pre-check. Бойова прагматика: у польових умовах деякі checks відключають для прискорення операції. Ризик: пропуск реальної неполадки. Золота середина: критичні checks (battery, IMU) — ніколи не відключати. GPS check — може бути відключений при навмисному GPS-denied flight. Рекомендація: мінімальна конфігурація = battery + IMU + RC calibration checks завжди ввімкнені.
Як FC виявляє відмову двигуна і що відбувається далі?
Motor failure detection у FC — критична функція безпеки: ArduPilot Motor Failure Detection (з версії 4.1): Метод 1: «ekf_lane_switch»: FC стежить за різницею між очікуваним і фактичним рухом. Якщо двигун впав → craft відхиляється від рівного льоту → EKF (Extended Kalman Filter) виявляє аномальну динаміку. Метод 2: ESC telemetry monitoring: якщо ESC передають RPMS → FC порівнює очікуваний RPM з фактичним. RPM = 0 на «вмикнутому» моторі → аномалія. Метод 3: Current monitoring: якщо двигун відмовив → ампераж цього каналу падає до нуля при command > 0. Потребує per-motor current sensing. Реакція FC на motor failure (квадрокоптер): Один мотор відмовив: FC намагається компенсувати трьома іншими → кардинальне збільшення output на протилежному моторі. Борт починає нерівно обертатись по yaw → FC намагається утримати горизонт. Результат: зазвичай борт починає некероване зниження. ArduPilot може спробувати «controlled descent» навіть при одному відмовленому моторі. Два мотори (один бік): практично некерований. Betaflight: немає автоматичного Motor Failure Mode. Пілот відчуває аномалію і реагує вручну. Статистика: більшість невдалих FPV-польотів від technofailure — саме motor desync або esc failure. Blackbox чітко показує: який мотор і коли підвів.
Що таке Crash Detection в ArduPilot і як він фіксує аварію?
Crash Detection — автоматичне виявлення факту аварійного зіткнення БПЛА: ArduPilot CRASH_CHECK параметр (за замовчуванням: enabled): Алгоритм: FC виявляє «crash state» якщо: 1) Квадрокоптер в режимі що вимагає стабілізації (не ACRO). 2) Кути крену/тангажу перевищують ~30–45° від горизонту більше 2 секунд. 3) При цьому FC подає команди моторам для виправлення, але кути не зменшуються (борт «застряг» перекинутим або вдарився об перешкоду). Дія при виявленні crash: FC дизармить (вимикає) двигуни → запобігає пошкодженню від обертання на землі. Blackbox запис: crash detection тригер фіксується у лозі з точним timestamp → «де стався краш». Обмеження: FPV в режимі ACRO: Crash Detection не спрацьовує (великі кути — штатна ситуація в акро-польоті). Fixed-wing: різний алгоритм — continuous inverted flight або extreme pitch → crash detect. Інший алгоритм: «Motor sound detection» (нові FC): акселерометр фіксує характерний imupact signature → crash confirm. Бойове значення: для дронів що повернулись пошкодженими — crash event у blackbox точно вказує момент і параметри зіткнення → корисно для визначення причини (вогонь противника vs технічна відмова vs пілотська помилка).
Як налаштувати оптимальні threshold-и аномалій для бойових умов?
Налаштування threshold-ів — баланс між чутливістю і хибними спрацьовуваннями: Загальний принцип: у бойових умовах значна кількість «аномалій» — це нормальні оперативні умови (RSS падає під РЕБ, GPS погіршується, вібрації від маневрів). Якщо threshold-и — цивільні дефолти → постійні хибні тривоги. Підхід до бойового калібрування: 1) Зібрати baseline: з 5–10 «нормальних» місій без аномальних подій → записати типовий діапазон усіх параметрів (RSSI min/max, vibration range, voltage range). 2) Встановити military margin: threshold = «нормальний мінімум» × 0.75 (25% відступ). 3) По кожному параметру окремо: один розмір не підходить для всього. RSSI threshold — залежить від типу radio link. Voltage — залежить від хімії батареї. Ключові параметри для перегляду в ArduPilot: FS_THR_VALUE (RC failsafe threshold), BATT_LOW_VOLT, BATT_CRT_VOLT, BATT_LOW_MAH, GPS_HDOP_GOOD. В Betaflight: rxFailsafeChannelConfigs (per-channel failsafe value), failsafe_delay (затримка рішення failsafe). Практичний совет: вести журнал «хибних тривог» під час бойових місій. Після 2–3 тижнів стає ясно які threshold-и потребують підвищення. Progressive tuning: починати з заводських → поступово послаблювати ті що дають хибні alarm → не послаблювати ті що корелюють з реальними інцидентами.