🤖 Как управлять флотом из тысяч автономных роботов

Привет, это Дмитрий Ивахненко, старший разработчик сервисов удалённого управления из команды Автономного транспорта Яндекса. Сегодня я хочу рассказать, как работает система управления нашим флотом. Речь про единую инфраструктуру для тысяч устройств: роботов-доставщиков, роботакси и беспилотных грузовиков. Все они ездят в реальных городских условиях среди непредсказуемых пешеходов и водителей.

Иногда робот не может справиться с ситуацией на дороге сам. Поэтому мы реализовали сразу два режима управления конкретным юнитом.

🅰️ Во-первых, мы можем напрямую передавать команды

В случае с роботом-доставщиком всё как в компьютерной игре: нажал стрелку, юнит поехал. Интуитивно, понятно и быстро. Но с машинами или грузовиками такая история уже не работает: нужно учитывать наличие прицепа, массу и инерцию движения. При этом стрелочки чувствительны к задержкам связи. Например, если несколько пакетов потеряется по дороге, то картинка начнёт тормозить, действия рассинхронизируются с реальностью, и после нескольких => => машина может оказаться в кювете.

🅰️ Во-вторых, мы можем задавать траекторию

Оператор рисует в интерфейсе зелёную линию, по которой должен проехать юнит. Дальше её обрабатывают ML-модель и алгоритмы, а после она идёт в финальный контур безопасности. Он проверяет, что мы не нарушаем ПДД, не ведём к коллизиям и вообще предлагаем безопасный путь. И если маршрут дошёл до юнита, машина ещё раз проверит, что мы не заставляем её сделать что-то странное. Например, что грузовик действительно сможет корректно объехать препятствие, а не уткнётся в дорожный знак.

🅰️ Команды и траектории нужно как-то передать на устройство

Мы стремимся минимизировать потери данных. Конечно, нельзя полностью от этого защититься: грузовик может оказаться далеко от базовой станции, а роботакси часто ездит по городу, где сигнал нестабилен. Роботы-доставщики маленькие и могут прятаться от вышек за киоском или машиной. При этом мы не можем буферизировать команды: если очередь переполнится, то при восстановлении связи может начаться конфликт с новыми инструкциями из других источников. А кроме всего прочего, сигнал может потеряться на юните: автоматика на устройстве получит поручение и не успеет никак ответить.

➕ Поэтому мы придерживаемся золотого правила: единственный источник правды о выполнении команд — это сам робот. Только он сам знает, что уже сделал, а что нет. Аудит мы делаем асинхронно: команды, которые проходят через наши прокси, отправляются в Kafka, а уже оттуда асинхронно записываются в PostgreSQL. Так можно разбирать инциденты и смотреть историю, не влияя на скорость доставки команд.

⏩️ Больше интересного читайте в статье на Хабре. Там я показываю, как роботы видят окружающее пространство, какими способами мы оптимизируем видеостриминг и какую архитектуру мы в итоге построили.

Подписывайтесь:
💬 @Yandex4Developers