Максимально эффективная интеграция ИИ в робототехнику

Каждую неделю появляется видео: «Я подключил GPT‑4 к своему роботу!». Робот слушает команду, «думает», затем выполняет действие. Всё выглядит впечатляюще… пока вы не замечаете, что робот выполняет короткое действие, затем «думает» около 4 секунд, а оператор тем временем держит палец над аварийной кнопкой, не понимая, какое именно действие предпримет сие инженерное чудо.

Проблема не в том, что LLM «глупые». Проблема в архитектуре интеграции. Большинство разработчиков пытаются использовать LLM как контроллер нижнего уровня, пытаются синхронизировать с быстрыми сенсорами, отправляют сырые данные в качестве контекста, что приводит к катастрофической задержке, отсутствию безопасности и множеству сопутствующих проблем.

В конце статьи я предоставлю весь исходный код, всю архитектуру, почти готовый фреймворк, просто так, в OpenSource. Ну а пока я расскажу, как мы решили эти проблемы в проекте OpenGrall.

1. Безопасность: LLM не должна управлять двигателями

Проблема

LLM имеют недетерминированную природу. Один и тот же промпт может дать разные ответы. Если доверить LLM прямое управление моторами, рано или поздно она выдаст move_forward, когда перед роботом стена или человек.

Решение: гибридная архитектура с TinyML

В нашей системе TinyML имеет абсолютное право вето. Даже если LLM или оператор отдают команду «вперёд», а дальномер показывает препятствие ближе 10 см — команда игнорируется. Робот моментально остановится при внезапном возникновении препятствия, самостоятельно объедет его, лишь уведомляя вышестоящую логику об объезде. Время реакции на аварийную остановку — менее 10 миллисекунд. Никаких компромиссов.

TinyML обучается в симуляторе на точной модели платформы. Колёсная база, гексапод, бипед, квадрокоптер — неважно. Нейросеть учится чувствовать железо идеально: разгон, торможение, инерция. На входе — только дальномеры, одометрия, возможно IMU.

LLM получает лишь габариты робота, тип передвижения и сжатые данные с дальномеров. Она принимает стратегические решения («объехать слева», «осмотреть комнату»). А как именно повернуть колёса — решает TinyML. (Кстати, TinyML также реализует инерционное движение с плавным затуханием, но об этом позже.)

Что даёт такой подход:

• Безопасность становится гарантированной, а не вероятностной.

• LLM не нужно знать физику — модель может быть легче и быстрее.

• Платформа легко заменяется: переобучили TinyML в симуляторе — робот поехал по‑новому.

• Разработка идёт параллельно: физика и логика не мешают друг другу.

2. Какие модели выбрать для проекта

Последние пару лет набирают популярность VLA-модели, сочетающие визуальное восприятие (VLM) и «мышление» (LLM). На мой взгляд, это нишевое решение, которое вряд ли догонит LLM и VLM по масштабу.

VLA требуют гигантских вычислительных ресурсов. В то же время LLM и VLM совершенствуют миллионы пользователей: дата-сайентисты, исследователи, энтузиасты и даже фрики, создающие виртуальных партнёров — все они ежедневно вкладывают лепту в развитие этих моделей. Системы «умный город», автопилоты, облачные сервисы видеонаблюдения — везде нужны VLM. Это понятные кейсы с понятными инвестициями. VLA же остаются преимущественно в лабораториях. Даже колоссальными вливаниями невозможно подровнять их к такому масштабу.

Вторая проблема — «чёрный ящик». VLA созданы выдавать векторные команды прямо на моторы. Вопрос безопасности такого подхода остаётся открытым: если VLA ошиблась, она не способна объяснить своё решение. А значит, нужно просто дообучать модель в надежде что этого больше не повторится.

Модульность даёт важное преимущество: мы можем заменять LLM и VLM под конкретные задачи и доступные ресурсы, не трогая остальную систему. На смартфоне запускаем лёгкую модель, на мощном мини-ПК — более тяжёлую, хоть в облаке 70B+ модели или через API, так же VLM. Всё остальное — сбор сенсоров, управление моторами, эволюция стратегий — остаётся неизменным.

Режим «Концентрации». Более того, архитектура позволяет роботу переключаться в режим «концентрации»: когда локальная модель не справляется со сложной задачей (например, составление многошагового плана или поиск в интернете), агент может обратиться к облачной LLM (YandexGPT, DeepSeek), получить качественный ответ, сохранить его как образец и продолжить работу на локальной модели. Это даёт «интеллект по требованию» в условиях ограниченного железа или вовсе отсутствия локальных LLM

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

3. Архитектура: никто никого не ждёт

Мы выбрали WebSocket. Простой, легковесный протокол, который работает везде: на Android, на Linux, на ESP32 и даже в браузере.

• Сервер — центральное ядро, может быть запущен где угодно (на смартфоне, ПК, в облаке).

• Клиенты регистрируются с указанием роли (operator, agent, esp, lidar).

• Все сообщения — обычный JSON (стандартизированный по нашему протоколу). Никаких .msg файлов, которые нужно компилировать.

• Интеграция нового сенсора — просто регистрация. Например, лидар на отдельной ESP32 — и данные пошли.

Один «мозг» управляет несколькими телами. Представьте: колёсная платформа подъезжает, с неё взлетает дрон, осматривает местность, передаёт данные, садится обратно. Один агент, один сервер, разные ESP32 с разными TinyML-моделями.

Схема проста: LLM → решение и целевая скорость → TinyML → рефлексы → моторы.
LLM говорит «езжай туда», а не «шаг левой, шаг правой».

SensorMemory + WeightCalculator . В OpenGrall сенсоры не просто шлют данные. Каждый источник имеет вес, который динамически меняется. Лидар загрязнился? Его вес падает. VLM ослеплён солнцем? Его вес падает. WeightCalculator анализирует аномалии (например, все сектора лидара показывают одинаковое расстояние — это грязь) и снижает доверие к сенсору ещё до того, как данные попадут в LLM. Агент автоматически полагается на те сенсоры, которым сейчас можно доверять

4. Оптимизация: всё важное, ничего лишнего

Главное, что мы сделали — избавили LLM от лишнего. Все данные собираются, сортируются, и в момент создания промпта агент забирает их и оборачивает в максимально компактный и информативный промпт с одной лишь целью — получить взвешенное решение, используя интеллект LLM, затем извлечь его и отправить на сервер и в файлы памяти.

LLM хороши тем, что понимают естественный язык. Но они ужасно медленны, если контекст не подготовлен. Однако в нашей архитектуре даже LLM <1B справляется. Не нужен суперкомпьютер.

Пример лидара: от облака точек к восьми секторам. Лидар выдаёт тысячи точек в секунду. Отправлять их все в LLM — безумие. Мы превращаем сырое облако в восемь секторов — этого достаточно. Если объект ближе 80 см — формируем список ближних объектов с углом, расстоянием, размером и скоростью (со стрелкой: ↑ ↓ ← →).

Чтобы вы не просто читали, а могли «пощупать» логику робота, вот реальный промпт, который OpenGrall отправляет в LLM. Скопируйте его и протестируйте в своём ChatGPT или локальной модели:

Ты робот д51×ш32×в37см
0°=↑=прямо
Отвечай JSON: {"action":"move","params":{"l":300,"r":300},"reasoning":"..."}
action: move,stop,light,say,talk,ask,remember,find,search,plan
params: move{l,r}, light{s}, say{t}, talk{t}, ask{q}, remember{n}, find{n}, search{q}, plan{g}

ТЕКУЩАЯ СИТУАЦИЯ:
Время: 1712345720.45
Текущее намерение: исследовать коридор

ДИАЛОГ:
Человек: Гралл, посмотри что там впереди
Робот: Понял, исследую

ДАННЫЕ СЕНСОРОВ (по важности):
  • lidar: front=0.4м, front_left=1.2м, left=3.5м, back_left=5.0м, back=6.0м, back_right=5.5м, right=3.2м, front_right=1.0м | ближе 80см: -15°;15° ~40см, 0.6м, v=0.0м/с [вес: 0.95, возраст: 0.02с]
  • vlm: сцена: коридор, объекты: человек 2.0м слева, путь: free [вес: 0.65, возраст: 0.50с]
  • odometry: vл=0.3, vп=0.3, курс(global, 0°=nord)=0° [вес: 0.68, возраст: 0.04с]

Доступно: move_forward, move_backward, turn_left, turn_right, stop, set_light, speak, speak_to_human, ask_human, remember_object, find_object, search_by_text, compose_plan

Этот промпт так-же демонстрирует работу системы весов, как LLM понимает что необходимо ориентироваться на более свежий скан лидара, а устаревший VLM лишь принять к сведению, что препятствием является человек.

LLM ответит JSON с действием. Но главное даже не компактность. Мы вообще не пишем алгоритмы слияния данных. В классической робототехнике противоречивые показания — это проблема, требующая сложных фильтров. У нас LLM сама выступает арбитром: видит вес, возраст и источник и решает, чему верить.

Например, мы спаяли экспериментальный ультразвуковой сонар на трёх микрофонах, написали простой драйвер, зарегистрировали его на сервере с ролью ultrasonic, и он начал добавлять в SensorMemory вот такую строку:

room 4.5m×6.2m, exit 45° 0.9m, obj1 1.2m -15° hard med, obj2 2.0m 30° soft small

Бортовая LLM видит это и мгновенно сопоставляет с лидаром и VLM. Она понимает: выход из комнаты находится под углом 45 градусов, ширина проёма 0.9 метра. Объект справа-спереди — твёрдый и среднего размера (вероятно, комод). Объект дальше и левее — мягкий и маленький (возможно, человек или домашнее животное). LLM отличает мебель от людей, стены от текстиля, не имея камеры, в этом конкретном направлении. Сопоставляя с кластером точек лидара она “подтверждает свои догадки”.

Без изменения кода агента, без правки промптов, без единой строчки алгоритмов слияния. Любой новый модуль, даже самый «размытый», делает робота умнее просто потому, что LLM умеет извлекать смысл из чего угодно.

Системный промпт зашит в модель. При создании модели в Ollama прописываем системный промпт один раз. Он занимает место в контексте, но не расходует токены в каждом запросе. Экономия — сотни токенов на цикл.

Вот как выглядит «голый» промпт, который фактически отправляется в LLM (всё, что выше — это системный промпт, уже зашитый в модель):

ТЕКУЩАЯ СИТУАЦИЯ:
Время: 1712345720.45
Текущее намерение: исследовать коридор

ДИАЛОГ:
Человек: Гралл, посмотри что там впереди
Робот: Понял, исследую

ДАННЫЕ СЕНСОРОВ (по важности):
  • lidar: front=0.4м, front_left=1.2м, left=3.5м, back_left=5.0м, back=6.0м, back_right=5.5м, right=3.2м, front_right=1.0м | ближе 80см: -15°;15° ~40см, 0.6м, v=0.0м/с [вес: 0.95, возраст: 0.02с]
  • vlm: сцена: коридор, объекты: человек 2.0м слева, путь: free [вес: 0.65, возраст: 0.50с]
  • odometry: vл=0.3, vп=0.3, курс(global, 0°=nord)=0° [вес: 0.68, возраст: 0.04с]

• Полный промпт (то, что вы скопировали выше) — ~450 токенов.

• «Голый» промпт (то, что фактически отправляется) — ~150 токенов.

5. «Тормознутость» подобных систем и как мы её победили

Проблема принудительной синхронизации

В классических робототехнических фреймворках, таких как ROS, сенсорные потоки синхронизируются по самому медленному звену. Если VLM выдаёт данные раз в секунду, а лидар — 50 раз в секунду, система будет ждать VLM, прежде чем принять решение. Это называется «принудительная синхронизация по отстающему», и она убивает отзывчивость.

Робот буквально замирает на секунду, ожидая, пока «самый умный» сенсор соизволит ответить. В это время лидар продолжает видеть мир, но его данные игнорируются. В результате робот выглядит задумчивым и медлительным.

Наш подход: асинхронность и свежесть данных

В OpenGrall мы отказались от принудительной синхронизации. Все сенсоры работают независимо и складывают данные в SensorMemory по мере поступления. Лидар обновляется 50 раз в секунду, VLM — раз в 0.5 секунд, одометрия — постоянно.

Когда приходит время формировать промпт для LLM, агент просто забирает из памяти самые свежие данные с наивысшими весами. Ему не нужно ждать VLM, если тот ещё не отработал. Если VLM устарел, его вес снижается, и агент принимает решение на основе лидара и одометрии, которые всегда свежие.

Это значит, что робот никогда не ждёт «медленный» сенсор. Он принимает решение на том, что есть сейчас, а следующее решение будет через 0.5–1 секунду, когда VLM, возможно, уже обновится.

Инерционное движение: робот не замирает

Но даже этого недостаточно. LLM всё равно «думает» сотни миллисекунд. В классических системах робот стоял бы на месте всё это время, а потом дёргался. Это выглядит неестественно и повышает риски (например, если препятствие возникло в момент «мышления»).

Мы решили эту проблему на стороне TinyML. ESP32, который управляет моторами, не останавливает робота полностью, если не поступает команда «стоп» или не сработал аварийный рефлекс. Вместо этого он поддерживает инерционное движение с затуханием:

• Если последняя команда была move_forward, ESP32 продолжает движение, плавно снижая скорость к концу цикла.

• Когда приходит новая команда (например, turn_right), он плавно перестраивается без рывков.

• Если команды нет (LLM ещё думает), робот не стоит столбом, а медленно катится по инерции, сохраняя естественность поведения.

Это выглядит «живее» — робот не замирает на каждом шагу, а плавно движется, корректируя курс по мере поступления новых решений.

Кэширование решений: LLM не думает дважды об одном и том же

Большинство ситуаций типичны. Если перед роботом ровный коридор, команда move_forward будет повторяться десятки раз подряд. Зачем каждый раз вызывать LLM?

Мы добавили кэш решений. Каждое решение LLM сохраняется вместе с хешем контекста. Когда ситуация повторяется, агент просто берёт прошлое решение из кэша. Это занимает миллисекунды вместо сотен.

StrategyLearner: выработка привычек. Более того, эволюционные стратегии со временем вытесняют LLM. Робот не просто кэширует решения — он эволюционирует. Стратегии конкурируют, скрещиваются, получают баллы за успех и штрафы за провал. Если стратегия (например, «двигаться вперёд в свободном коридоре») набрала высокий вес, она выполняется без вызова LLM вообще. В итоге LLM вызывается только в новых, нестандартных ситуациях, а рутина работает на стратегиях. Это не кэш, это формирование рефлексов высокого уровня.

Похвала от человека. Если человек говорит «молодец», стратегия получает +4 балла мгновенно. Это самый сильный сигнал обучения.

Эпизодическая память: обучение у человека

Робот запоминает не только свои действия, но и инструкции человека. Если он спросил «Где лежит пульт?» и получил ответ «На журнальном столике», он запомнит это в эпизодической памяти. Через неделю, в похожей ситуации, он не переспросит — он сразу поедет к столику. Это обучение у человека, которое делает робота умнее с каждым днём.

Модульность на уровне устройств

Хотите добавить вторую камеру? Просто подключите ESP32-CAM к серверу с ролью camera_back. Агент автоматически увидит новый сенсор в SensorMemory. Ни строчки кода менять не нужно. Это настоящая plug-and-play архитектура.

6. Вишенка на торте: автономное целеполагание

А теперь представьте, что робот бездействует какое-то время. В интерактивном режиме агент не ждёт команд — он сам генерирует себе задачу. Вот реальный промпт, который отправляется в LLM для автономного целеполагания:

text

Ты робот Гралл. Габариты: 51×32×37см.
0°=↑=прямо
Отвечай JSON: {"action":"move","params":{"l":300,"r":300},"reasoning":"..."}

ТЕКУЩАЯ СИТУАЦИЯ:
Время: 1712345720.45
Текущее намерение: ты свободен, можешь заняться чем хочешь

ДАННЫЕ СЕНСОРОВ (по важности):
  • lidar: front=5.0м, front_left=4.8м, left=4.0м, back_left=5.0м, back=6.0м, back_right=5.5м, right=3.2м, front_right=4.9м [вес: 0.94, возраст: 0.02с]
  • vlm: сцена: комната, объекты: человек 2.5м (сидит за столом), стул, стол, путь: free [вес: 0.70, возраст: 0.15с]
  • odometry: vл=0.0, vп=0.0, курс(global, 0°=nord)=90° [вес: 0.69, возраст: 0.05с]
  • battery: 85% [вес: 0.80, возраст: 2.0с]

ПАМЯТЬ:
- Исследованные зоны: кухня, коридор
- Интересные объекты: зарядная станция (кухня), стул (комната)
- Недавние события: нет

ИНТЕРАКТИВНЫЙ РЕЖИМ:
НЕ используй move_forward, move_backward, turn_left, turn_right.
Вместо этого используй:
- compose_plan — если хочешь выполнить сложное действие (подъехать, осмотреть, запомнить)
- speak_to_human — если хочешь инициировать разговор с человеком
- ask_human — если хочешь задать вопрос человеку
- remember_object / find_object / search_by_text — если хочешь работать с памятью

Ты можешь:
- общаться с человеком (speak_to_human, ask_human)
- запоминать объекты (remember_object)
- искать объекты (find_object, search_by_text)
- составлять планы (compose_plan)

Делай что хочешь. Прояви инициативу.

LLM сама решит: заговорить с человеком, исследовать комнату, запомнить новый объект или составить план. Это зачатки внутренней мотивации.

Заключение

Весь исходный код доступен на GitHub: https://github.com/Ferum93/OpenGrall. Фреймворк включает всё, что вы видели в статье: взвешенные сенсоры, кэширование решений, эволюционные стратегии, эпизодическую память и интерактивный режим, всё очень подробно задокументировано и легко кастомизируется. Проект на стадии альфа, но вся логика реализована, как скоро мне хватит времени и ресурсов отладить на железе обещать не могу, потому архитектурой решил поделиться уже сейчас. Постарался уместить в одну статью чтобы обрисовать картину целиком, но на самом деле в проекте буквально о каждом файле есть что написать. Могу запустить цикл статей с подробным описанием работы каждого узла системы и что он привносит собой, с нетерпением жду ваших комментариев.

Главный вывод: LLM в робототехнике работает, если вы используете её только там, где она действительно нужна — для стратегического планирования и социального взаимодействия. Всё остальное должны делать специализированные подсистемы: TinyML для безопасности, WeightCalculator для адаптации к деградации сенсоров, StrategyLearner для рутины.