Каждую неделю появляется видео: «Я подключил GPT‑4 к своему роботу!». Робот слушает команду, «думает», затем выполняет действие. Всё выглядит впечатляюще… пока вы не замечаете, что робот выполняет короткое действие, затем «думает» около 4 секунд, а оператор тем временем держит палец над аварийной кнопкой, не понимая, какое именно действие предпримет сие инженерное чудо.
Проблема не в том, что LLM «глупые». Проблема в архитектуре интеграции. Большинство разработчиков пытаются использовать LLM как контроллер нижнего уровня, синхронизируют её с быстрыми сенсорами и отправляют сырые данные в качестве контекста. Это приводит к катастрофической задержке, отсутствию безопасности и множеству других проблем.
В проекте OpenGrall мы решили эти проблемы. Ниже — как.
1. Безопасность: LLM не должна управлять двигателями
LLM имеют недетерминированную природу. Один и тот же промпт может дать разные ответы. Если доверить LLM прямое управление моторами, рано или поздно она выдаст move_forward, когда перед роботом стена или человек.
Решение: гибридная архитектура с TinyML
TinyML — это запуск нейросетей на микроконтроллерах (ESP32, STM32 и т.д.). Модели весят десятки килобайт, работают годами даже на батарейке и опрашивают датчики с частотой 50–100 Гц. В OpenGrall именно такой «спинной мозг» живёт на борту робота. Он не понимает речь и не строит планов, но знает главное: как не врезаться в стену и как эффективно использовать возможности платформы.
Эта система управляет рычажной системой для преодоления препятствий, активной подвеской и моментально компенсирует неровности. Она «живёт» в реальном времени и выполняет действия, которые даже оператор не смог бы повторить вручную.
В нашей системе TinyML имеет абсолютное право вето. Даже если LLM или оператор отдают команду «вперёд», а дальномер показывает препятствие ближе 10 см — команда игнорируется. Робот остановится мгновенно, объедет препятствие и лишь уведомит вышестоящую логику. Время реакции — менее 10 миллисекунд. Никаких компромиссов.
TinyML обучается в симуляторе на точной модели платформы — колёсной, гексаподной, бипедальной или квадрокоптерной. На входе — только дальномеры, одометрия, возможно IMU. Нейросеть учится чувствовать железо: разгон, торможение, инерция.
LLM получает лишь габариты робота, тип передвижения и сжатые данные с дальномеров. Она принимает стратегические решения: «объехать слева», «осмотреть комнату». А как именно повернуть колёса — решает TinyML.
Преимущества такого подхода:
- Безопасность становится гарантированной, а не вероятностной.
- LLM не нужно знать физику — модель может быть легче и быстрее.
- Платформа легко заменяется: переобучили TinyML в симуляторе — робот поехал по-новому.
- Разработка идёт параллельно: физика и логика не мешают друг другу.
2. Какие модели выбрать для проекта
Последние пару лет набирают популярность VLA-модели, сочетающие визуальное восприятие (VLM) и «мышление» (LLM). На мой взгляд, это нишевое решение, которое вряд ли догонит LLM и VLM по масштабу.
VLA требуют гигантских вычислительных ресурсов. В то же время LLM и VLM развиваются благодаря миллионам пользователей: дата-сайентистов, исследователей, энтузиастов. Системы «умный город», автопилоты, видеонаблюдение — везде нужны VLM. Это понятные кейсы с инвестициями. VLA же остаются преимущественно в лабораториях.
Вторая проблема — «чёрный ящик». VLA созданы выдавать векторные команды прямо на моторы. Если VLA ошиблась, она не способна объяснить своё решение. Остаётся лишь дообучать модель в надежде, что ошибка не повторится.
Модульность даёт важное преимущество: мы можем заменять LLM и VLM под конкретные задачи и ресурсы, не переписывая систему. На смартфоне — лёгкая модель, на мощном ПК — тяжёлая, в облаке — 70B+ или через API. Всё остальное — сенсоры, моторы, стратегии — остаётся неизменным.
Архитектура позволяет переключаться в режим «концентрации»: когда локальная модель не справляется, агент обращается к облачной LLM (YandexGPT, DeepSeek), получает качественный ответ, сохраняет его как образец и продолжает работу локально. Это даёт «интеллект по требованию» даже на слабом железе.
Так мы получаем и эволюцию моделей всего человечества, и прозрачность, и адаптацию под любое оборудование.
3. Архитектура: никто никого не ждёт
Мы выбрали WebSocket — простой, легковесный протокол, работающий везде: на Android, Linux, ESP32 и даже в браузере.
- Сервер — центральное ядро, может быть запущен где угодно.
- Клиенты регистрируются с указанием роли: operator, agent, esp, lidar.
- Все сообщения — обычный JSON по стандартизированному протоколу. Никаких .msg файлов.
- Интеграция нового сенсора — просто регистрация. Например, лидар на отдельной ESP32 — и данные пошли.
Один «мозг» может управлять несколькими телами. Колёсная платформа подъезжает, с неё взлетает дрон, осматривает местность, передаёт данные, садится обратно. Один агент, один сервер, разные ESP32 с разными TinyML-моделями.
Схема проста: LLM → решение и целевая скорость → TinyML → рефлексы → моторы. LLM говорит «езжай туда», а не «шаг левой, шаг правой».
Каждый сенсор в системе имеет вес, который динамически меняется. Лидар загрязнился? Его вес падает. VLM ослеплён солнцем? Его вес падает. WeightCalculator анализирует аномалии (например, все сектора лидара показывают одинаковое расстояние — это грязь) и снижает доверие к сенсору до того, как данные попадут в LLM. Агент автоматически полагается на те сенсоры, которым можно доверять.
4. Оптимизация: всё важное, ничего лишнего
Главное — избавить LLM от лишнего. Все данные собираются, сортируются, и в момент создания промпта агент забирает их и оборачивает в максимально компактный и информативный промпт. Цель — получить взвешенное решение, используя интеллект LLM, затем извлечь его и отправить дальше.
LLM хороши в понимании естественного языка, но ужасно медленны с неподготовленным контекстом. В нашей архитектуре даже LLM <1B справляется. Не нужен суперкомпьютер.
Пример с лидаром: от облака точек к восьми секторам. Лидар выдаёт тысячи точек в секунду. Отправлять их все в LLM — безумие. Мы превращаем сырое облако в восемь секторов. Если объект ближе 80 см — формируем список ближних объектов с углом, расстоянием, размером и скоростью (со стрелкой: ↑ ↓ ← →).
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:
- Полный промпт — ~450 токенов.
- «Голый» промпт — ~150 токенов.
5. «Тормознутость» подобных систем и как мы её победили
Проблема принудительной синхронизации
В классических фреймворках, таких как ROS, сенсорные потоки синхронизируются по самому медленному звену. Если VLM выдаёт данные раз в секунду, а лидар — 50 раз в секунду, система будет ждать VLM. Это называется «принудительная синхронизация по отстающему» и убивает отзывчивость.
Робот замирает на секунду, ожидая 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 решает: заговорить с человеком, исследовать комнату, запомнить новый объект или составить план. Это зачатки внутренней мотивации.
Заключение
Главный вывод: LLM в робототехнике работает, если использовать её только там, где она действительно нужна — для стратегического планирования и социального взаимодействия. Всё остальное должны делать специализированные подсистемы: TinyML для безопасности, WeightCalculator для адаптации к деградации сенсоров, StrategyLearner для рутины.