● з чого складається система керування дроном: сенсори, гіроскоп-акселерометр (IMU), GPS, компас, барометр;● EKF — фільтр, що зводить суперечливі дані сенсорів в одну оцінку стану дрона (де він, куди й з якою швидкістю летить);● різниця між тим, що дрон хоче зробити (бажаний стан), і тим, що з ним відбувається насправді (оцінений стан);● польотні режими: Guided (керування зовнішніми командами), Auto (місія за точками), Land (посадка), RTL (повернення додому);● де в цю систему підключається комп'ютерний зір.
Практика (перевіряється): візьмеш свої або навчальні польотні логи (записи, що дрон робив під час польоту) і для одного відрізка знайдеш, що автопілот хотів зробити, що він думав про свій стан і що сталося насправді.
Результат тижня: намалюєш архітектуру ArduPilot без підказок і поясниш весь шлях від виміру сенсора до зміни обертів моторів.

● як симулятор SITL замінює справжній дрон і навіщо це потрібно на старті;як EKF обирає, яким сенсорам довіряти, коли їхні дані розходяться;● інструменти навколо симулятора: MAVProxy (текстовий пульт керування), параметри, мережеві з'єднання;● повний цикл: запуск → політ → перегляд логу → перезапуск;● як безпечно змінити параметр і перевірити, що зміна застосувалася.
Практика (перевіряється): встановиш середовище розробки й запустиш віртуальний дрон, проведеш його через Arm (готовність моторів) → зліт → зависання → політ у точку → повернення → посадку, після чого розбереш лог польоту.
Результат тижня: запускатимеш віртуальний дрон за кілька хвилин і читатимеш його польотні логи, не шукаючи інструкцію щоразу.

● MAVLink — «мова», якою дрон і програма спілкуються: сигнал «я живий» (heartbeat), команди, повідомлення, підтвердження отримання;● чим команда відрізняється від повідомлення й від телеметрії;● як програма підключається до дрона й читає потік даних;● часові мітки — коли саме прийшов кожен вимір і чи не застарів він;● чому різні дані приходять із різною частотою.
Практика (перевіряється): напишеш програму читання телеметрії, яка в реальному часі показує режим польоту, стан моторів, координати, висоту, нахили, швидкість і заряд батареї, і додаси до кожного значення позначку часу отримання.
Результат тижня: читатимеш живий стан дрона з Python і знаходитимеш потрібне повідомлення в документації.

● як програмою віддати команди готовності моторів, зльоту й польоту в точку;● як перевірити, що дрон справді виконав команду, а не просто отримав її;● машина станів — покрокова логіка, де наступний крок настає лише за виконаної умови попереднього;● чому не можна керувати паузами («почекай 10 секунд») замість перевірки реального стану;● що робити, коли команда не підтверджена або дрон не в тому режимі.
Практика (перевіряється): напишеш програму автономної місії, яка підключається до дрона, дочікується сигналу «я живий», переходить у режим зовнішнього керування, піднімає дрон, веде його в задану точку, тримає на місці й повертає додому — з переходами за реальним станом, а не за таймером. Окремо навмисно віддаси хибну команду й перевіриш, як програма її обробить.
Результат тижня: керуватимеш автопілотом на Python через MAVLink і виконуватимеш автономну місію в симуляції без ручного пульта.

● модель камери: фокусна відстань, спотворення об'єктива, матриця камери;● калібрування — вимірювання «характеру» конкретної камери, щоб виправити спотворення;● AprilTag / ArUco — спеціальні мітки-квадрати відомого розміру, за якими можна точно визначити відстань і положення;● оцінка положення мітки: як за її кутами програма рахує, де вона в просторі;● перехід від пікселів на картинці до метрів у реальності.
Практика (перевіряється): відкалібруєш камеру за друкованою шахівницею, збережеш результат калібрування у файл і отримаєш координати мітки (вправо, вгору, відстань до неї) у метрах відносно камери.
Результат тижня: переведеш об'єкт із пікселів у справжню відстань у метрах і побачиш, що координати змінюються правильно, коли рухаєш мітку.

● системи координат: зображення, камера, корпус дрона, зовнішня (де північ, схід, низ);● чому в камери й у дрона осі спрямовані по-різному й це створює плутанину, перенесення й поворот координат між системами;● матриця повороту й кути нахилу (крен, тангаж, курс) простими словами;● послідовне складання кількох перетворень в одне.
Практика (перевіряється): напишеш модуль переведення координат із системи камери в систему корпусу дрона й далі в зовнішню систему, і перевіриш його на контрольних випадках (ціль прямо перед дроном, праворуч, знизу, камера нахилена, дрон повернутий на 90°).
Результат тижня: переведеш ціль із системи координат камери в систему дрона й передбачиш знак координати ще до запуску коду.

● як власний нахил і поворот дрона впливають на те, де насправді знаходиться побачена ціль;● переведення цілі в зовнішню систему координат з урахуванням положення дрона;● затримка (latency) — скільки часу проходить від зйомки кадру до готової команди;● застарілий вимір — коли дані вже не відповідають реальності;● чому правильно розпізнана ціль може все одно привести до неправильного руху дрона.
Практика (перевіряється): візьмеш нахили дрона із симулятора й порахуєш положення цілі в зовнішній системі координат; заміряєш затримку на кожному етапі (зйомка → розпізнавання → розрахунок → команда) і відкидатимеш виміри, які застаріли понад допустимий поріг.
Результат тижня: збереш повний ланцюг «камера → положення цілі з поміткою часу» й пояснюватимеш, чому затримка небезпечніша за неточність.

● запуск моделі на бортовому комп'ютері (NVIDIA Jetson) — маленькому комп'ютері на самому дроні;● прискорення й стиснення моделі, щоб вона встигала працювати в реальному часі;● супровід об'єкта в кадрі (трекінг) — утримання тієї самої цілі від кадру до кадру;● повторне впізнавання цілі після того, як вона на мить зникла з поля зору;● вбудовування нейромережевого розпізнавання в наявний ланцюг зору замість міток або поряд з ними.
Практика (перевіряється): підключиш вихід детектора (рамка об'єкта → центр → положення) у ланцюг переведення координат із Блоку 2 і порівняєш затримку нейромережевого розпізнавання з розпізнаванням за мітками.
Результат тижня: розпізнаватимеш довільні об'єкти нейромережею й передаватимеш ціль у логіку автономності.

● машина станів наведення: старт → готовність → зліт → пошук → захоплення цілі → супровід → зниження → посадка;● аварійні режими й переривання місії, коли щось іде не так;● підтвердження цілі за кілька кадрів поспіль замість реакції на одне випадкове спрацювання;● як не дати апарату почати зведення від однієї помилкової детекції;● обробка появи, зникнення й повторної появи цілі.
Практика (перевіряється): напишеш модуль поведінки, який на вхід отримує стан дрона, стан цілі й час, а на виході видає поточний етап місії й команду; протестуєш його на сценаріях, коли ціль з'явилася, зникла, знову з'явилася, стоїть далеко від центру або розпізнається нестабільно.
Результат тижня: побудуєш логіку, яка веде апарат від пошуку цілі до зведення на неї й приймає рішення за станом системи.

● відсів хибних вимірів — коли координата раптом «стрибає» в неможливе місце;● згладжування даних, щоб прибрати дрібні коливання;● рівень довіри до цілі й перевірка, чи не застаріли її дані;● сторожовий таймер (watchdog) — контроль, що всі частини системи ще працюють;● перелік типових відмов і заздалегідь визначена реакція на кожну.

Практика (перевіряється): навмисно спровокуєш збої (ціль зникла, камера зависла, зв'язок обірвався, координата стрибнула на 20 метрів) і пропишеш у файлі-таблиці, як система має реагувати на кожен випадок; проведеш щонайменше 10 таких тестів.
Результат тижня: зробиш так, що апарат поводиться передбачувано під час зведення на ціль навіть у збоях, а не тільки в ідеальних умовах.

Практика (перевіряється): збереш наскрізну систему, яка виконує сценарій готовність → зліт → політ у зону пошуку → розпізнавання цілі → наведення й вирівнювання над нею → точна посадка, і проженеш її через щонайменше 10 сценаріїв (ціль по центру, збоку, тимчасово втрачена, з шумом у координатах, із затримкою, із розривом зв'язку, звичайне зведення).
Оформиш інженерний пакет: діаграма архітектури, опис проєкту (README), логи типових запусків (успішний / втрата цілі / затримка / хибний вимір), метрики (частота кадрів, затримка, точність зведення, точність посадки, час відновлення після втрати цілі), таблиця відмов, короткий демозапис.

Результат: збереш робочий прототип системи наведення на візуальну ціль — від камери до точної посадки в одній системі, зведеній твоїми руками.

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

Ні. Увесь autonomy-стек відпрацьовується в симуляції (SITL і Gazebo). Реальне залізо опціональне на ранніх модулях зору — вистачить звичайної веб-камери й друкованого маркера. Потрібна Linux-система (Ubuntu) або віртуальна машина.

Це відкритий галузевий стандарт автономності БПЛА з реальним застосуванням. Курс дає системне мислення autonomy-інженера — розкладати задачу від сенсора до контролера — тому після нього ти орієнтуєшся й у суміжних інструментах, а не заучуєш один набір команд.