Вбудовуємо AI в ROS 2: від камери до керування

Де розсипається ROS AI інтеграція на борту робота

Модуль сприйняття впевнено знаходить об’єкт на тестовому записі, а на борту робота все розсипається: команда в контур керування йде за координатами, які встигли застаріти.

Справа не в якості моделі, а в стику — у ROS 2 сприйняття й керування живуть у різних вузлах і спілкуються через черги повідомлень, і саме на цій межі втрачається час.

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

Розходження годинників дає зсув на кадр-два, і маніпулятор їде за об’єктом, якого там уже немає: втрата об’єкта виглядає як помилка моделі, хоча причина в синхронізації.

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

Затримка відгуку й втрата об’єкта на цих ділянках складаються в один клас відмов, який не видно при налагодженні на столі.

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

Що дає єдиний граф ROS: сприйняття й керування в одному контурі

Єдиний граф ROS 2 — це коли детектор, трекер, планувальник і драйвери приводів обмінюються повідомленнями в одному контурі, а не живуть ізольованими сервісами зі своїми годинниками й буферами.

У кожного топіка задано профіль якості зв’язку: командам приводу — надійна доставка, відеопотоку — відмова від повторного передавання застарілих кадрів. Спостережуваність наскрізна — за журналом видно, на якому вузлі кадр перетворився на ціль і де ціль загубилася.

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

У спільному графі мітки часу приходять з одного джерела, а переповнення буфера видно діагностичним повідомленням до того, як робот зупиниться.

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

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

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

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

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

Режимів роботи три: бортовий контур, винесений на станцію, і гібридна схема. У кожному по-своєму налаштовується транспорт ROS 2 і розподіляються ролі між нодами.

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

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

Межі режимів фіксуємо в документації: який контур що публікує й за якої деградації каналу схема перемикається. Тоді модель можна перенести між бортом і станцією без переписування логіки.

Етапи впровадження: від обстеження стенда до передачі в експлуатацію

Роботу починаємо з обстеження стенда: знімаємо карту вузлів ROS 2, частоти публікації топіків, доступні обчислювачі та те, де зараз втрачається час — на захопленні кадру, інференсі чи передаванні команди виконавчому механізму.

За цією картою видно, що можна повторно використати, а що доведеться переписувати; без неї будь-яка оцінка перетворюється на здогад.

1. Обстеження стенда. Інвентаризація вузлів, топіків і сервісів, замір реальних частот і затримок, перевірка живлення й обчислювачів, перелік обмежень майданчика.
2. Схема графа. Проєктуємо граф: хто публікує й хто підписується, де ставляться буфери й політики доставки повідомлень, як розводяться контури сприйняття й керування, щоб падіння одного вузла не зупиняло платформу.
3. Налаштування вузлів. Збираємо й конфігуруємо компоненти, виносимо параметри у файли, вмикаємо запис телеметрії та режим відтворення — на ньому налагоджуємо без виїзду на об’єкт.
4. Перевірка на полігоні. Проганяємо сценарії з повторюваними умовами, заміряємо затримку від кадру до команди й частку спрацьовувань, ловимо деградацію при засвітленні, вібрації та втраті зв’язку.
5. Дослідна експлуатація. Система працює на об’єкті під наглядом інженера: розбираємо кожну відмову за логами, правимо пороги й логіку перемикань.
6. Передача в експлуатацію. Схема графа, конфігурації, регламент запуску й відновлення, навчання зміни та узгоджений план відкату на попередню конфігурацію.

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

Так перехід до наступного кроку не виглядає як стрибок у невідомість — у замовника на руках завжди є актуальний стан системи.

Пакет передачі: конфігурації, схеми графа, регламенти й доступи

Проєкт на ROS 2 здається не демонстрацією працюючого робота, а набором артефактів, за якими ваша команда зможе експлуатувати систему без нас.

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

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

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

Кейс: як лінія перестала зупинятися через збій сприйняття

На лінії з машинним зором детектор дефектів працював у контурі ROS 2 і на кожній зміні помилявся на сприйнятті: відблиск від металу та зміна освітлення читалися як брак.

Лінія зупинялася через хибну тривогу, оператор ішов до пульта й вручну підтверджував кадри, які система не змогла розібрати.

Із десяти зупинок за зміну сім припадали на сприйняття, а не на реальний дефект. Відновлення циклу займало до дванадцяти хвилин простою, ручних втручань набиралося понад двадцять за зміну.

Що змінили

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

Що стало

Оператор перестав бути обов’язковою ланкою циклу — втручання залишилося для справжніх дефектів. Спірні кадри тепер накопичуються в наборі для донавчання моделі, тому поріг упевненості та калібрування уточнюються за фактом, без зупинки лінії.

Що робити, якщо свій модуль сприйняття вже розгорнуто?

Працюючий модуль сприйняття — це актив, а не перешкода: ми не переписуємо його з нуля, а добудовуємо навколо нього зв’язку.

Першим ділом фіксуємо контракт: у якому вигляді модуль віддає результат (повідомлення, набір координат, мітка об’єкта), у якій системі координат, із якою частотою та якою затримкою.

Саме тут найчастіше виявляється причина розсинхронізації — вузли формально сумісні, але живуть у різних системах відліку та різному часі.

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

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

Кожен крок оборотний: повернення на попередню схему — одна команда, без переналаштування обладнання та без зупинки лінії.

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

Сумніви перед стартом: розбираємо технічні ризики

Більшість питань перед стартом — не про модель, а про те, як вузол ROS 2 уживеться з уже працюючим контуром. Це і є основні технічні ризики: сумісність, поведінка при збоях, затримки в контурі.

Що буде при втраті зв’язку або збої вузла?

У контурі залишається сторожовий таймер: при втраті потоку даних вузол знімає керування й уводить систему в безпечний режим, а не продовжує рух за застарілими даними. Окремо перевіряємо, що після відновлення зв’язку контур повертається до роботи без ручного перезапуску.

Як ви перевіряєте затримки в контурі?

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

Що відбувається після передачі?

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

Обговоримо задачу та повернемося з оцінкою й планом робіт

Оцінка за описом «потрібне розпізнавання на камерах» завжди виходить приблизною. Щоб порахувати склад робіт, нам потрібен поточний граф вузлів, склад сенсорів і вимоги до контуру керування — за ними видно, вбудовується сприйняття в наявні топіки чи потребує окремої гілки обміну.

Що надіслати для оцінки:

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

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

Опишіть задачу та надішліть матеріали — повернемося з оцінкою, порядком етапів і умовами запуску.