Gazebo Jetty LTS: Zenoh, новий симулятор і підтримка робототехнічних проєктів

Gazebo Jetty — десятий major-реліз симулятора та довгострокова гілка. Він переходить на Qt 6, додає Zenoh як альтернативний transport, оновлює фізичні й графічні залежності та пропонує server-only installation для headless і CI-середовищ. LTS зменшує частоту великих міграцій, але не гарантує однакової фізики чи performance зі старим світом.

Zenoh поруч із ZeroMQ

Gazebo історично використовував ZeroMQ для transport. Jetty додає Zenoh із прицілом на discovery, interoperability й інтеграцію з ROS. Зміна transport впливає на topology, QoS, discovery та діагностику. Її треба тестувати окремо від оновлення симулятора, щоб розуміти джерело затримки або втрати повідомлень.

Qt 6 та інтерфейс

Перехід з Qt 5 пов’язаний із завершенням його життєвого циклу. Власні GUI plugins потрібно перебудувати та перевірити. Headless-сценарії можуть використовувати server-only package без GUI, Qt і частини X11-залежностей, що робить CI images меншими й зменшує attack surface.

Симуляція не доводить роботу реального робота

Після оновлення порівняйте частоту physics step, sensor noise, contact behavior, rendering і real-time factor. Навіть невелика зміна engine або dependency може змінити результат тесту. Для regression suite краще зберігати не лише відео, а числові траєкторії, collisions, timestamps і контрольні метрики.

План переходу

• зафіксувати версії всіх Gazebo libraries і SDF;
• перебудувати custom system та GUI plugins;
• перевірити світи, sensors, physics і rendering;
• окремо протестувати Zenoh transport;
• запустити headless CI на server-only package;
• повторити hardware-in-the-loop тести до rollout.

Для нових ROS-проєктів також потрібно звірити сумісність distribution; актуальний LTS описано у статті про ROS 2 Lyrical Luth. А якість computer vision залежить від реальних даних, про що нагадує матеріал про production-дані роботизованого зору.

LTS-реліз не скасовує перевірку сумісності

Тривала підтримка корисна для продукту з довгим життєвим циклом, але сумісність залежить від повного набору: Gazebo, ROS 2, плагінів, фізичного рушія, драйверів GPU та власних моделей. Створіть матрицю версій і відтворюваний образ середовища. Якщо проєкт ще використовує старі API або Classic, винесіть їх у список міграційних ризиків і не намагайтеся приховати адаптаційним шаром без тестів.

Zenoh потрібно оцінювати на реальній мережевій топології

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

Модель має бути калібрована за фізичним роботом

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

Regression suite має працювати без графічного інтерфейсу

Винесіть ключові світи, сценарії та очікувані метрики в headless-тести CI. Фіксуйте seed випадковості, версії ресурсів і допустимі відхилення, щоб дрібна зміна фізики не створювала нестабільних результатів. До набору включіть зіткнення, втрату сенсора, перешкоду на маршруті, аварійну зупинку й перезапуск. Артефакти прогону повинні містити журнали, метрики та коротке відео лише для невдалих випадків.

Перехід виконуйте окремо від зміни поведінки робота

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

Критерії готовності симуляції до командного використання

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

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

Коли не варто переносити весь проєкт

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

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

Першоджерело: офіційні release notes Gazebo Jetty.