ПЗ для дронів

Чеклист готовності до польоту

Спершу весь чеклист — бо саме про це питає огляд готовності до польоту і бо кожен його рядок уже коштував комусь апарата: сім таких аварій — унизу цієї сторінки. Він пронумерований, щоб на рядок можна було послатися: «ми жодного разу не проганяли 2.4» — це задача, тоді як «фейлсейфи треба б переглянути» — це настрій. Він написаний для команди, яка будує або інтегрує ПЗ — на PX4PX4відкритий автопілотВідкритий автопілот для дронів, літаків та інших безекіпажних апаратів, який розвиває Dronecode Foundation під егідою Linux Foundation, з ліцензією BSD. Він працює на польотній платі й відповідає за стабілізацію, оцінку стану, режими польоту й фейлсейфи; дозвільна ліцензія — одна з причин, чому компанії будують на ньому продукти.Усі терміни, ArduPilotArduPilotвідкритий автопілотВідкритий автопілот для мультикоптерів, літаків, гелікоптерів, човнів і наземних апаратів під ліцензією GPLv3. Він покриває те саме, що й PX4, — стабілізацію, навігацію, режими, фейлсейфи — із ширшим набором типів апаратів і копілефт-ліцензією, яка важить того дня, коли ви постачаєте змінену прошивку.Усі терміни чи власному автопілоті. Це не передпольотна картка оператора, хоча половина групи 5 зрештою на неї потрапляє.

Робіть спершу групи 2 і 6. Конфігурація фейлсейфів — це те, що апарат справді робить, коли щось іде не так, а доки збій не вкинули в симуляції, ніхто не бачив, як ця конфігурація працює.

1. 1.Стек і його межі

   1. 1.1Політний контролер виконує керування й оцінку стану — і більше нічого. Фіча не йде туди через те, що там «ближче до заліза».
   2. 1.2Бортовий компʼютер звертається до автопілота через один інтерфейс повідомлень як недовірений клієнт: кожне завдання, яке він надсилає, перевіряють на допустимий діапазон і можуть відхилити.
   3. 1.3Автопілот стежить за сигналом «я живий» (heartbeat) від бортового компʼютера й має налаштовану дію на випадок, коли той замовкне.
   4. 1.4Жодне рішення керування на борту не чекає, поки відпрацює канал із землею.

2. 2.Драбина фейлсейфів

   1. 2.1Кожна умова має налаштовану дію: втрачено канал керування, втрачено позицію, мало енергії, досягнуто межу, бортовий компʼютер мовчить, оцінювач стану несправний.
   2. 2.2Кожну дію забезпечує найнижчий ярус, здатний її забезпечити: межу й запас енергії — автопілот, і ніколи не лише наземна станція.
   3. 2.3Тестують комбінації, а не лише окремі умови: втрачений звʼязок разом із низьким зарядом і зустрічним вітром — окремий випадок.
   4. 2.4Останній щабель — посадку на місці, парашут, припинення польоту — справді відпрацьовано, а що він робить над людьми, водою й дорогами, записано.

3. 3.Енергія й шлях додому

   1. 3.1Повернення вмикає енергія, потрібна, щоб долетіти додому, плюс резерв на посадку, порахована з відстані й вітру, — а не фіксований відсоток батареї.
   2. 3.2Залишок ємності оцінюють за спожитим зарядом, а не лише за напругою, і знають, що на холоді ця оцінка завищена.
   3. 3.3Маршрут на випадок утрати звʼязку оминає людей і закінчується там, де вимушена посадка прийнятна, — а не петлею, яку летять, доки не скінчиться паливо.
   4. 3.4Пільговий таймер утрати звʼязку дає рутинним обривам минути, не перериваючи місії, і його значення — рішення, ухвалене на рев’ю, а не значення за замовчуванням.

4. 4.Позиція і стан

   1. 4.1Справність оцінювача стану відстежують, і оцінка, якій більше не можна вірити, — це окрема умова фейлсейфу, а не попередження на екрані.
   2. 4.2Утрата супутникового позиціонування веде до визначеної поведінки: утримуватися на інерціальній і візуальній оцінці задане число секунд, потім знижуватися чи повертатися.
   3. 4.3Кожен сенсор, здатний завершити політ, звіряють з іншим: супутникову позицію чи показ висоти, що розходиться з рештою, беруть під сумнів, а не виконують.
   4. 4.4Кожне вимірювання має мітку часу, яку перевіряють, бо застаріле значення, подане як свіже, шкодить більше, ніж відсутнє.

5. 5.Наземна станція й конфігурація

   1. 5.1Параметри лежать у системі контролю версій окремо для кожного планера, а їхню зміну переглядають так само, як зміну коду.
   2. 5.2Перед польотом параметри на апараті порівнюють із переглянутим набором, і будь-яка розбіжність блокує зліт.
   3. 5.3Налаштування, послаблене заради тесту чи демонстрації, має власника й дату, коли воно спливає.
   4. 5.4Прошивку, параметри й файли місії підтверджують на кожному апараті: флот — це N підтверджень, а не одне завантаження.
   5. 5.5Керування не може перейти між пультами чи операторами, поки вони розходяться в положенні органу керування, а критичний для безпеки збій має власну тривогу.

6. 6.Тести й докази

   1. 6.1Симуляція software-in-the-loopsoftware in the loopсправжня прошивка, змодельований світТестування, у якому справжнє керувальне ПЗ працює на звичайному компʼютері проти змодельованого апарата, сенсорів і світу. Воно досить швидке, щоб запускатися на кожен коміт, і тому стає регресійним набором; не знайде воно лише того, що залежить від таймінгу справжнього процесора.Усі терміни запускається на кожен мердж, і кожна змодельована місія має перевірки по записаному логу.
   2. 6.2Hardware-in-the-loophardware in the loopсправжня плата, змодельований світТестування, у якому справжня плата контролера з її справжньою прошивкою підключена до симулятора, що подає їй сенсорні дані замість фізичного світу. Воно знаходить помилки таймінгу, перевантаження процесора й баги драйверів, недоступні чистій симуляції, — ціною того, що залізо має стояти на стенді.Усі терміни запускається за розкладом, бо помилки таймінгу й баги драйверів у чистій симуляції невидимі.
   3. 6.3Збої — це скриптовані кейси в наборі: обірвати звʼязок, заморозити сенсор, зсунути мітку часу, підмінити показ батареї, зупинити мотор.
   4. 6.4Кожен політний лог зберігають і можуть відтворити, а збій, побачений у повітрі бодай раз, стає тест-кейсом, що житиме завжди.

Стек — це ієрархія дедлайнів

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

Одну деталь діаграма спрощує, і вона важить, коли читаєте код PX4 чи ArduPilot. Перші два яруси зазвичай — та сама плата з тією самою прошивкою. Регулятор кутових швидкостей, оцінювач стану, навігація й логіка режимів — це задачі на одному мікроконтролері, розділені пріоритетом і частотою циклу, а не кабелем. Тож межа між ними — рішення планувальника, і додати роботи у швидку задачу — саме той спосіб, у який фіча краде час у стабілізації. Бортовий компʼютер — перший ярус, що справді є окремою машиною, і саме тому йому можна дозволити падати.

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

Драбина фейлсейфів — це і є специфікація

План місії описує, що має статися. Конфігурація фейлсейфів описує, що станеться, і саме вона вирішує, чи можна цим апаратом узагалі літати. Фейлсейф (failsafe) — це поведінка, налаштована заздалегідь для одного конкретного збою: умова, що її вмикає, і дія, яку апарат після цього виконує сам, нікого не питаючи. Кожен запис відповідає на одне питання — це сталося, що тепер, — і кожна відповідь є обміном без безкоштовного варіанта.

З цієї таблиці варто витягти дві властивості — це рядки 2.2 і 2.3. Перша: кожну поведінку слід забезпечувати на найнижчому ярусі, здатному її забезпечити. Межа, реалізована в наземній станції, є побажанням, бо саме наземна станція й зникає. Друга: фейлсейфи взаємодіють, і саме у взаємодіях живуть несподіванки. Зниклий звʼязок плюс низький заряд плюс зустрічний вітер — ситуація інша, ніж кожне з трьох окремо, і конфігурація, що обробляє кожне поодинці, все одно може дати апарат, який упевнено летить геть від дому.

З тієї ж причини доступність — хибна ціль для всього, що літає. Відсоток часу роботи описує сервіс, який або працює, або ні. Апарат проводить свої найцікавіші хвилини в часткових станах — без звʼязку, без супутникової позиції, без бортового компʼютера, — і корисна специфікація називає, що ще працює на кожному рівні втрат. Таблиця фейлсейфів і є такою специфікацією, тільки записаною.

Повернення — це розрахунок енергії, а не відсоток

Найпоширеніше налаштування батареї в полі — якийсь варіант «повертатися на 30%». Воно виглядає як обережність, і воно хибне з обох кінців польоту. Енергія, потрібна апарату, щоб дістатися додому, росте з відстанню до дому й із вітром, проти якого доведеться летіти. Фіксований відсоток не знає ні того, ні іншого.

Візьмімо умовний мультикоптер, що витрачає близько 4% батареї на кілометр у безвітря й хоче мати 10% резерву на посадку. За кілометр від дому йому треба 14%, щоб повернутися, тож тригер на 30% відправляє його назад із 16% батареї, які так і не використали. За пʼять кілометрів йому треба 30% — поріг точний рівно на одній відстані й більше ніде. Тепер додаймо зустрічний вітер, що вдвічі зменшує шляхову швидкість. Кожен кілометр триває вдвічі довше й коштує приблизно вдвічі більше енергії, тож за пʼять кілометрів тому самому апарату треба вже близько 50%, і тригер на 30% спрацьовує тоді, коли долетіти вже неможливо.

Обидва основні відкриті автопілоти дають більше ніж одне число. ArduPilot має двоступеневий фейлсейф батареї — низький і критичний рівні, кожен спрацьовує за напругою або за спожитою ємністю й має власну дію. PX4 має рівні low, critical та emergency і, окремо, фейлсейф саме для цієї проблеми: він оцінює, чи залишку батареї вистачає ледве-ледве на повернення, і тоді вмикає режим Return. Хоч що ви використовуєте, рішення для рев’ю — це рядок 3.1: з чого рахують тригер, а не який відсоток вписати.

Та сама логіка стосується шляху додому — це рядок 3.3. Маршрут на випадок утрати звʼязку — це план польоту, який виконується без жодного нагляду, тож він отримує той самий рев’ю, що й місія, і навіть більший: де він перетинає людей, яку висоту тримає над рельєфом, який справді перетинає, і де закінчується, якщо звʼязок так і не повернеться. «Літає петлею, доки не повернеться контакт» — не закінчення. Це неухвалене рішення про те, де апарат опиниться на землі, коли скінчиться енергія.

Автономність — це набір рішень, а не рівень

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

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

Четвертий квадрант — той, який проєкти пропускають: часу спитати немає, а скасувати не можна. Мотор відмовляє низько над дорогою; оцінка позиції розвалюється за кілька метрів над землею; спрацьовує умова припинення польоту. Порадитися ні з ким, і що б не сталося далі — це остаточно. Відповідь тут — ні автономність, ні людина в контурі. Це людина, яка заздалегідь, на землі, вирішує, в який бік апарат помилятиметься, і записує це рішення в конфігурацію, де його можна переглянути. Парашут у Цюриху — саме цей квадрант: рішення про припинення польоту ухвалили задовго до того, і воно було правильним. Відмовив механізм, що мав його виконати.

У правого стовпця є наслідок, який часто пропускають: щоб утримати рішення, апарат мусить уміти безпечно чекати. Система, яка має спитати людину, але не може зависнути, не може зберегти запит і не може розумно поводитися, якщо відповіді не буде, не реалізувала вимогу — вона її записала. Чекання — це здатність із власним бюджетом енергії, власним тайм-аутом і власним фейлсейфом. Бік оператора в утриманому рішенні — що йому показують, скільки часу він має, як записують відмову — належить сторінці про C2C2Command and control — системи командування й управлінняПЗ, що зводить доповіді з багатьох джерел в одну спільну картину, за якою можна діяти, і несе рішення, ухвалені за нею. Його центральна робота — кореляція: вирішити, чи описують дві доповіді одну річ чи дві, — і тому воно складніше за мапу, якою його зазвичай малюють.Докладніше в статті →Усі терміни. Бік апарата — цій.

Симуляція — це тестове середовище, а не зручність

Кожен важливий тут випадок збою — це те, чого не відтвориш на справжньому апараті: утрата позиції на двохстах метрах, зупинка мотора в розвороті, зникнення звʼязку на дальньому кінці маршруту, батарея з хибним показанням. Літати такі тести дорого, небезпечно й повільно, а ті, які пережив, не повториш однаково. Продакшн-трафіку, з якого можна вчитися, теж немає. Зворотний звʼязок, який вебкоманда отримує з живої телеметрії, приходить сюди файлом логу після посадки — якщо апарат сів. Тож головним тестовим середовищем є симулятор, і зрілість симуляційного стенду добре описує зрілість команди.

Дві практики перетворюють цю драбину на регресійний набір, а не на три місця, де люди іноді щось тестують. Збої — це скриптовані кейси, а не експерименти, — рядок 6.3, — тож обірвати звʼязок на дальній точці маршруту — це тест, що запускається на кожен мердж і падає на конкретному рядку. І кожен політний лог — вхідні дані тесту, рядок 6.4. Збій, побачений у повітрі раз, відтворюють у симуляції, і він лишається в наборі назавжди — це те саме правило, що й у будь-якому регресійному наборі, і саме воно робить набір кращим щоразу, коли щось іде не так. Збій міток часу в Ingenuity нижче — саме такий, який скриптований кейс ловить дешево: зсуньте мітки часу одного входу й перевірте, що оцінювач це помічає.

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

Сім аварій — і рядок, що покриває кожну

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

Де це вироджується

Чесне обмеження всього на цій сторінці в тому, що фейлсейф відповідає лише на ті збої, які хтось уявив. Кожен із семи випадків був, якщо дивитися назад, умовою, під яку ніхто не написав рядка: важіль із двома значеннями, дощ на лідарі, пісок, на якому нічого не видно. Симуляція відтворює збої, які ви заскриптували, а небезпечний саме той, який нікому не спало на думку заскриптувати. Це не аргумент проти драбини. Це аргумент за те, щоб зберігати кожен політний лог, відтворювати його й ставитися до кожної несподіванки як до нового рядка, а не як до невдачі.

• Таблиця фейлсейфів, що існує як документ і жодного разу не виконувалася — ні в симуляції, ні деінде.
• Межа, яку забезпечує наземна станція, — компонент, якого гарантовано не буде, коли це важить.
• «Повертатися на 30%», скопійоване з форуму в кожен планер, хай яка в нього дальність і хай який вітер.
• Параметри, змінені на польовому ноутбуці, які так і не повернулися в систему контролю версій.
• Набір симуляцій, що сотні разів пролітає щасливу місію й не вкидає жодного збою.
• Політний лог, який зберігають лише для розбору інцидентів і ніколи не відтворюють як тест.
• Вимога «людина в контурі» для рішення, на яке апарат не може чекати.
• Демонстрація в гарну погоду, на повній батареї, із сильним звʼязком і автором поруч, подана як доказ бодай чогось.
• Процес релізів, скопійований із веброзробки — розгортати часто, лагодити вперед, — для апарата, що може бути недосяжним тижнями.

Коли це застосовувати

Пов’язані сторінки

• DeftechКібербезпекаКібербезпека оборонної системи — це проєктні рішення, що лишають її надійною проти фінансованого, терплячого супротивника, який може тримати сам пристрій. Звичайна безпека застосунків припускає випадкового зловмисника по той бік мережевої межі й патч, що виходить у вівторок; тут межа зрештою падає повністю, а патч може йти до пристрою місяцями. Сторінка починається з чеклиста живучості на двадцять пʼять рядків; далі — модель загроз і те, що вона приймає, захоплений пристрій, ланцюг завантаження й шлях оновлення, ланцюг постачання, двадцять років служби, вісім задокументованих компрометацій і те, де практика перетворюється на театр.
• DeftechКомпʼютерний зірКомпʼютерний зір — це практика перетворювати зображення з камери на детекції, за якими може діяти машина чи людина, і модель тут рідко є складною частиною. Складно тут тому, що він працює на пристрої з бюджетом живлення й без мережі, на зображеннях, не схожих на ті, на яких його навчали, і живить рішення, у якому за два типи помилок платять різні люди. Сторінка починається з дванадцяти польових збоїв — причини кожного й перевірки, що його ловить; далі — бюджет на пристрої, проблема даних, поріг як політика, що треба записувати, і сім задокументованих збоїв.
• DeftechСистеми C2Система командування й управління (C2) — це софт, який зводить доповіді з багатьох джерел в одну спільну картину, за якою можна діяти. Краще розуміти її як механізм кореляції з прикріпленою мапою, чия центральна робота — вирішити, одна річ описана у двох доповідях чи дві. Сторінка починається з чеклиста спільної картини на двадцять пʼять рядків; далі — кореляція, два часи й годинник, які несе кожен запис, що стається, коли два вузли втрачають контакт, сумісність як вимога, людина в контурі як властивості, які можна перевірити, і сім задокументованих збоїв.