Управління дроном AI: де ламаються класичні автопілоти
Класичний контур керування будується навколо заздалегідь розрахованої моделі: коефіцієнти підбираються під номінальну масу, аеродинаміку та передбачуваний сценарій польоту.
Поки умови збігаються з розрахунковими, автопілот упевнено тримає траєкторію — проблеми керування дроном починаються на межі допустимого, там, де модель перестає описувати реальність.
Перше — зміна корисного навантаження. Підвісили важчу за попередню камеру, змістили центр мас — і та сама логіка дає перерегулювання й автоколивання: апарат «клює» носом, рискає, втрачає висоту на розвороті.
Друге — вітер і пориви: регулятор компенсує збурення із запізненням, і на довгому маршруті помилка накопичується до нестабільного польоту.
Третє — втрата сигналу та нештатні траєкторії. Детермінований сценарій знає «зависни» і «повернися на точку», але не вміє добудувати маршрут у незнайомому рельєфі або обійти динамічну перешкоду.
Тут відмова автопілота виглядає як відмова техніки, хоча апарат справний — не вистачило політики поведінки.
Кожне з цих місць — вузьке місце керування, і лікується воно не підкручуванням коефіцієнтів. Навчання з підкріпленням формує політику інакше: не за формулами, а за досвідом тисяч прогонів у симуляторі з вітром, різною масою та обривами зв'язку. Розбираємо, як така система керування дроном AI закриває ці збої.
Що дає навчання з підкріпленням у реальних польотах
Навчання з підкріпленням дає те, чого не витягує класичний контур стабілізації: політику керування, яка вчилася не на одній траєкторії, а на тисячах епізодів із рандомізацією умов — маса та зміщення центра мас, пориви вітру, просідання тяги, затримка каналу та відмови окремих датчиків.
Агент отримує нагороду за утримання заданої траєкторії та за завершення місії, а не за окремий вдалий кадр керування, тому в реальному польоті він обирає режим, який тримає задачу загалом, а не парирує одне збурення.
Вимірювано це видно на трьох числах: частка успішно завершених місій, максимальне відхилення від заданої траєкторії та кількість ручних втручань оператора на годину польоту.
Після перенесення навченої політики на борт типово скорочується розкид відхилення за траєкторією та падає кількість втручань — оператор із «пілота в контурі» стає спостерігачем, який підключається на етапі вибору завдання, а не на кожній корекції.
Окремий ефект — стійкість до завад і підміни навігації.
Політику дообучують на сценаріях зі спотворенням сигналу та короткочасною втратою навігаційного рішення, тому апарат не зривається в некерований дрейф, а переходить на утримання за візуальними та інерціальними даними і продовжує маршрут.
Цілий клас відмов — втрата керування при зовнішньому впливі — зникає зі статистики, а разом із ним зникає й ручний режим як обов'язковий страховий контур.
Переносність дає зв'язка з відкритим польотним стеком: ми працюємо з PX4 як бортовою платформою, тому навчена політика стикується з наявним залізом і парком без заміни апаратів.
Дообучення на логах реальних польотів уточнює модель на конкретних умовах майданчика — і автономний політ перестає бути демонстрацією, а стає режимом із передбачуваним відсотком виконання місій.
Режими навчання та керування: порівняння підходів
Вибір контуру визначається не модою, а тим, скільки реальних польотів ви готові витратити на навчання і наскільки дорогою є помилка.
Симулятор дає тисячі епізодів без ризику для заліза, але політика, навчена на ідеальній моделі динаміки, розвалюється від шуму сенсорів і затримок контуру. Льотні дані закривають цю розбіжність, але їх мало і вони нерівномірно покривають режими.
Порівнюємо варіанти за трьома осями: скільки реальних польотів потрібно до робочої якості, як поводиться політика поза номінальним режимом і скільки коштує перенавчання після зміни платформи чи корисного навантаження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Навчання в симуляторі | Складна поведінка: обліт перешкод, групова взаємодія | Розбіжність моделі та реальності, чутливість до шуму сенсорів |
| Дообучення на реальних даних | Є накопичені логи, цільовий режим зрозумілий | Мало даних на рідкісні ситуації, повільний перебір політик |
| Гібридна схема | Потрібен баланс швидкості та стійкості | Потрібна інфраструктура запису, синхронізація спостережень і дій |
| Класичний контур стабілізації плюс навчання верхнього рівня | Критична передбачуваність і розбір причин відмови | Нижча адаптивність у нестандартних ситуаціях |
Перенесення моделі в реальний контур
Це окремий етап, а не побічний ефект. У навчання закладають розкид маси та тяги, затримки каналу керування, шум і зміщення датчиків, обмеження за кутами та швидкістю — тоді політика перестає залежати від єдиного набору умов.
Перевірка йде за ступенями: стенд, короткі польоти зі страховкою оператора, потім розширення режимів.
Етапи розробки: від аудиту телеметрії до льотних перевірок
Порядок робіт вибудуваний так, щоб помилки ловилися на землі, а не в польоті. Кожен етап завершується перевірюваним артефактом: розміткою логів, схемою контурів керування, результатом серії прогонів у симуляторі.
До наступного кроку переходимо після приймання попереднього — так керування дроном на основі ШІ відлагоджується без ризику для апарата та майданчика.
- Аудит телеметрії та постановка мети. Розбираємо наявні логи: частоту опитування датчиків, пропуски, шум, поведінку апарата на різних режимах і в ручному пілотуванні. Критерії приймання формулюємо вимірювано — утримання курсу та висоти, час реакції на команду, частка успішно пройдених місій.
- Схема контурів і захисних обмежувачів. Визначаємо, що вирішує навчена модель, а що залишається на класичній стабілізації: повернення додому, обмеження висоти, межі зони, аварійне зависання. Модель не отримує керування там, де її помилка незворотна.
- Складання середовища навчання. Будуємо симулятор за обмірами конкретного апарата та додаємо збурення: вітер і пориви, зміщення центра мас, затримки каналу зв'язку, відмови датчиків. Чим чесніша модель середовища, тим менше сюрпризів на полігоні.
- Налаштування моделі. Проєктуємо функцію нагороди: штрафи за різкі перевантаження, вихід із коридору, розкачування. Навчання йде хвилями, версії фіксуються окремо — потрібна можливість відкотитися на попередню.
- Прогін нештатних сценаріїв. Прогоняємо втрати сигналу, відмови, розряди, конфліктні траєкторії. Фіксуємо, де політика деградує передбачувано, а де поводиться нестабільно.
- Льотні перевірки. Йдемо за ступенями: стенд, зависання, короткі місії, повний маршрут у різних умовах. Розбіжність із симулятором розбираємо та уточнюємо або модель, або цифрового двійника.
- Здача системи. Передаємо ваги моделі, конфігурації, скрипти навчання, документацію з перенавчання та протоколи льотних перевірок, а також супроводжуємо перші тижні експлуатації.
Склад постачання: конфігурації, документація, регламенти
Проєкт здано не тоді, коли модель упевнено літає в симуляторі, а коли ваша команда може перезібрати, перевірити та безпечно відкотити систему без нас.
Тому в постачання входить не лише навчена політика керування, а й увесь контур її супроводу — від конфігурацій борта до регламенту експлуатації.
- Конфігурації борта: параметри польотного контролера, регуляторів та обмежувачів із поясненням, який сценарій якими значеннями закривається і що змінювати не можна.
- Середовище навчання: сценарії, функції нагороди, файли запусків і зафіксовані залежності — експеримент відтворюється на вашій машині з тим самим результатом.
- Картки моделей: архітектура, діапазон вхідних даних, метрики на відкладеній вибірці та явно описані межі застосовності.
- Схеми: контур керування, шлях даних від сенсорів до команд, точки відмови та поведінка борта при втраті зв'язку.
- Політики доступу та ролі: хто править конфігурацію, хто лише читає телеметрію, як розділені стенд і реальний борт.
- Регламент експлуатації: передпольотні перевірки, порядок оновлення моделі, дії при відхиленні поведінки від очікуваної.
- План відкату: як повернути попередню версію моделі та конфігурації за одну операцію, не зупиняючи програму випробувань.
Документація із системи ведеться у вашому контурі — репозиторій, реєстр моделей, внутрішня база знань. Приймання йде за чек-лістом: ваші інженери самі проганяють навчання та оновлення борта, ми фіксуємо розбіжності та закриваємо їх до підписання.
Кейс: стабілізація польоту в зоні без супутникового зв'язку
Як було до впровадження
Метрики знімали на одному типі місій — обліт протяжного об'єкта в зоні без супутникового зв'язку: щільна забудова, вузький рельєф, завади в каналі керування. Оператор вів апарат вручну за відео з борта.
На вибірці з десяти вильотів чотири місії перервано до кінця маршруту, бокове відхилення від траси сягало 12–15 метрів, а повторний обліт тієї самої траси не збігався з попереднім — порівнювати дані між вильотами було неможливо.
Що змінили і що не спрацювало з першого разу
Навчили політику керування в симуляторі з рандомізацією динаміки, поривів вітру та шуму датчиків, потім перенесли на борт. Оцінку положення зібрали з інерціальних даних, оптичного потоку та візуальної одометрії, а контур замкнули на ROS 2.
Перша версія перевірку не пройшла: нагорода заохочувала утримання позиції, і при боковому вітрі апарат зависав замість продовження маршруту. Переписали функцію нагороди, додали штраф за незавершений маршрут і розширили рандомізацію збурень.
Що стало
На тій самій трасі перерваних місій — одна з дванадцяти, бокове відхилення — близько метра, розкид між повторними обльотами однієї траси — пів метра.
Дані стали порівнюваними між вильотами, а оператор перейшов із режиму безперервного керування в режим контролю та втручання за відхиленням.
Що робити, якщо на борту вже працює готовий AI-контур
Коротка відповідь: переписувати робочий контур не потрібно. Готове рішення зазвичай закриває нижній рівень — стабілізацію, утримання висоти та курсу, відпрацювання команд оператора, — і воно вже перевірене на реальних польотах.
Навчена політика вбудовується рівнем вище: вона не керує приводами напряму, а формує уставки, які відпрацьовує той самий класичний регулятор.
Точка інтеграції — інтерфейс команд і телеметрії, який уже є в системі. Якщо обмін іде через уставки за швидкістю, положенням і висотою, нова схема підключається без втручання в польотний контролер.
Важливо, щоб обидві схеми писали в один журнал: тоді поведінка порівнюється на тих самих польотах, а розбіжності видно не за відчуттями, а за даними.
Міграція йде за режимами, а не загалом. Перший крок — тіньове включення: рішення навченої моделі рахуються та пишуться в лог, але на керування не впливають.
Другий — заміна однієї ділянки, наприклад обходу перешкод або польоту за маршрутом, зі збереженням класичного контуру як резервного. Третій — розширення на решту режимів, якщо накопичена статистика підтверджує стійкість.
Вибір схеми залежить не від новизни підходу, а від зони відповідальності: де класичне керування передбачуваніше, його залишають, а навчену частину вмикають там, де правил стає занадто багато і вони починають суперечити одне одному.
Такий перехід залишає можливість повернутися до попередньої поведінки одним перемиканням — і це головна умова, за якої заміна контуру на борту взагалі допустима.
Часті технічні сумніви перед стартом проєкту
Технічні сумніви перед стартом зазвичай одні й ті самі: як перевіряти поведінку моделі без ризику для заліза, хто відповідає за безпеку польотів і що залишиться команді після запуску.
Ми вважаємо політику керування змінним шаром поверх штатної логіки борта: його можна вимкнути або відкотити, не виводячи апарат з ладу.
Чи можна навчати модель без реальних польотів?
Так. Основне відпрацювання йде в симуляторі з фізикою та цифровим двійником майданчика, на борт політика потрапляє після контрольних сценаріїв. Режими розширюємо поступово — від зависання до складних траєкторій, із записом телеметрії.
Що буде, якщо модель помилиться в повітрі?
Зовнішній контур обмежень працює незалежно від моделі: він тримає висоту та швидкість, утримує апарат у дозволеній зоні та повертає його при втраті зв'язку. Політика не керує приводами напряму, тому її помилка призводить до спрацювання запобіжника. Кожен випадок розбираємо за логами.
Чи доведеться перенавчати модель під кожен борт?
Зазвичай ні. Політику навчають із розкидом умов, тому вона переноситься між однотипними апаратами і терпить невеликі зміни маси та навантаження. При серйозній зміні конфігурації дообучення йде в симуляторі на записах польотів.
Що входить в обслуговування після запуску?
Регламент: контроль якості керування за телеметрією, відстеження дрейфу моделі при зносі заліза, планове оновлення політики. Передаємо документацію, конфігурації та сценарії перевірки, щоб підтримку можна було вести власними силами.
Обговоримо задачу і повернемося з оцінкою та планом робіт
Щоб повернутися з оцінкою, а не з уточнювальними питаннями, нам потрібен від вас мінімум по проєкту. Нижче — те, що реально впливає на архітектуру та строки: решту наші інженери відновлюють самі за логами, телеметрією та вашою документацією.
- Клас апарата, схема керування та бортова платформа, на яку можна поставити модель керування дроном.
- Цільові сценарії: що апарат робить на вході, який результат вважається успішним і що вважається відмовою.
- Обмеження середовища: коридор польоту, вітрове навантаження, завади, вимоги до поведінки при втраті сигналу.
- Дані: логи польотів, телеметрія, записи сенсорів, опис полігону або симулятора, де можна набирати досвід без ризику для апарата.
- Метрики приймання — частка успішних епізодів, час виходу в ціль, стійкість у нештатних режимах.
- Відповідальні з вашого боку: хто відкриває доступ до апаратів і узгоджує льотні дні.
- Зовнішні обмеження з безпеки, які не можна порушувати при навчанні та перевірках.
У відповідь ви отримуєте оцінку проєкту та план робіт: етапи, результат кожного етапу, порядок старту та точки, де ми звіряємося з вами. Окремо показуємо ризики — де даних не вистачає і де керування доведеться обмежувати правилами, — і чим кожен ризик закриваємо. Опишіть задачу у вільній формі: повернемося з оцінкою та планом робіт.
