
В 2024 году большие языковые модели (LLM) внезапно начали дешифровать хаос реального мира: распознавать объекты, объяснять намерения и даже писать код для микроконтроллеров. Для робототехники это стало тем же, чем Li‑ion стал для ноутбуков — мгновенным ускорителем эволюции.
LLM открыли окно возможностей: вместо того чтобы вручную программировать каждую задачу, мы можем дать роботу текстовую инструкцию, а он сам разберётся, какие навыки подключить.
Vision‑Language Agents, RLHF, MPC… В робототехнике сегодня аббревиатур больше, чем сервоприводов в суставе. Разобраться, что скрывает каждая комбинация букв, — ключ к тому, чтобы не остаться сторонним наблюдателем в союзе железа и ИИ.
В этой статье я делюсь своим взглядом на ряд актуальных вопросов:
чем GPT‑мозг круче старой цепочки perception → planning → control;
зачем скрещивать Classic Stack, RL‑контроллеры и VLA вместо того, чтобы выбирать лучший;
как можно прокачать робота от базовых движений до уверенной работы офис‑ассистентом, охранником и курьером.
Погрузитесь в детали — и посмотрите, как будущее шагает к нам на двух механических ногах.
Что дало толчок к развитию LLM / VLA‑роботов
Последние пару лет (2024–2025 годы) в ML и робототехнике произошло много важных событий, повлиявших на сферы в целом.
Появились фундаментальные модели под конкретный форм‑фактор. После релиза Robotic Transformer 2 (RT‑2) Google DeepMind показал, что классический VLM можно дообучить на робототраекториях и превратить в VLA‑модель (Vision‑Language‑Action), которая напрямую выдаёт векторы управляющих команд. То есть та же модель, которая распознаёт кота на фото из интернета, теперь может распознать чашку в руке робота и понять, как её взять. Не нужно учить робота с нуля — достаточно показать, как применить уже имеющиеся знания о мире к управлению манипулятором.
Данные масштаба интернета перекочевали в моторы роботов. Открытый корпус Open X‑Embodiment (RT‑X) объединил более миллиона реальных траекторий от 22 платформ (руки, квадропеды, гуманоиды). Впервые данные оказались разнообразнее любого лабораторного сетапа.
Железо и софт созрели одновременно. Jetson Orin, Apple M‑series, RTX‑40/50xx дают 10–20 tok/s на 7–8B моделей в 4‑bit — этого вполне хватает для планирования 1–2 Гц прямо на роботе. А в июне 2025 NVIDIA выĸатила Isaac GR00T N1.5 — первую foundation model с API уровня skills вместо поз во фрейме URDF.
Промышленные демонстрации сняли главный скепсис. Tesla Optimus сложил футболки, Figure‑01 подписал контракт на пилот с BMW, Sanctuary Phoenix закрыл 110 задач ритейла за неделю, 1X EVE вышел на сторожевую службу.
Зачем нужны LLM в робототехнике
LLM дал роботам то, чего мы ждали десятилетиями — универсальный модуль понимания и планирования. Раньше гуманоид опирался на жёсткий пайплайн: perception → planning → control. Теперь мы вставляем между perception и control «мозг», который:
принимает задачи в свободной форме («Марина, сходи в рецепцию за бейджами»);
раскладывает их в пошаговый план;
координирует роли сразу нескольких низкоуровневых контроллеров.
В целом технологии, которые сегодня куют роботов, можно поделить на три класса:

Наиболее целесообразно не выбирать лучший класс, а складывать их. Classic даёт гарантии, RL — плавность, VLA — мозги. Вот как может выглядеть схема взаимодействия всех трёх компонентов.

VLA (LLM‑модуль) — понимает мир, строит high‑level планы, даёт dense‑feedback на исполнение.
RL (PPO) — управляет суставами на частоте 1 кГц.
Classic Stack — тот самый пайплайн, который на этапе Foundation делает всё, а по мере прогресса становится подушкой безопасности.
А вот так может выглядеть дорожная карта эволюции архитектуры управления роботом:

Такой поэтапный подход даёт три бонуса:
Safety‑first — классический стек всегда готов перехватить.
Iterative ROI — можно поставить робота в поле ещё до AGI.
Dev‑stability — каждая фаза добавляет функциональность, не ломая прежнее.
Мы последовательно выстраиваем связку RL, VLA и Classic Stack. Сейчас идёт отработка ключевых модулей: для Classic реализуем навигацию и локализацию, на стороне RL отлаживаем стабильную походку (19 DoF, >450 шагов в симуляции), параллельно экспериментируя с Lipschitz‑регуляризацией.
В блоке VLA мы работаем над интерпретацией команд и собираем телеметрию для последующего дообучения. Уже работает механизм преобразования команд вроде «подними руку» в пространственные цели, совместимые с низкоуровневым контролем. В дополнение закладываем логику гибридного роутинга: система будет динамически переключаться между политиками в зависимости от уверенности и условий.
Почему лучше начинать с классики
Тут хочется вспомнить известную мысль из стартап‑культуры, популяризированную Рейдом Хоффманом: «If you’re not embarrassed by the first version of your product, you’ve launched too late» (перевожу как «Если вы не чувствуете дискомфорта от простоты или несовершенства первой версии, значит вы слишком долго тянули с запуском»).
И действительно, на этапе Foundation простота — не компромисс, а стратегическая необходимость. Именно она позволяет быстрее проверять гипотезы, безопасно интегрировать новые компоненты и заложить надёжную основу под RL и VLA.
Вот почему:
Сертификация (например, ISO 13 482 / 10 218) требует предсказуемого, детерминированного поведения — это легче обеспечить с классическим pipeline.
Быстрый debug: траектории визуализируемы, PID‑параметры редактируются в Excel, всё контролируемо вручную.
Нет данных для RL/VLA, а это значит, что нужен работающий baseline, который потом можно использовать как teacher, fallback или источник экспериментов.
На мой взгляд, важно как можно раньше выходить в реальные условия с минимально жизнеспособным решением, чтобы оттачивать архитектуру не в теории, а в действии. Даже простая демонстрация — это не компромисс, а способ проверить ключевые элементы системы в связке.
На раннем этапе робот может выглядеть так:
делает 2–3 команды из 100, но делает их стабильно;
ходит как будто пьяный, но не падает;
общается однострочно, но с LLM‑контекстом;
выглядит технологически скромно, но уже интегрирован в цикл RL/VLA/Classic.
Именно это позволяет раньше собрать обратную связь от пользователей, а также выявить слабые места в сенсоре, кинетике и обучении.
Почему мы используем именно RL?
Low‑level‑контроль походки — это ад. Более 20 степеней свободы, нелинейные приводы, неполная обратная связь. Алгоритмический DDP + MPC + PD‑тюнинг скатывается в перманентный «правый голеностоп поехал, быстро фиксите gains».
Мы пошли путём «сами не знаем, как ходить, ‑ пусть робот найдёт». В симуляции агент получает наблюдения [θ суставов, ω, линейные ускорения, контактные силы]
и выдаёт торки (подробнее об этом я рассказывал в предыдущей статье).
Decision Router — сердце гибридки
Мы реализуем гибридную архитектуру, в которой решение о том, кто управляет роботом в каждый момент времени — RL или классический стек, принимает специальный модуль маршрутизации решений (Decision Router). Вот базовая схема его работы:
Сенсоры и State Estimator формируют наблюдение.
Далее система оценивает уверенность в текущем режиме: достаточно ли надёжна RL‑политика? корректно ли работает SLAM?
-
В зависимости от этого Decision Router переключает источник управляющих воздействий:
если всё стабильно → система остаётся на основной политике;
если есть сомнения → fallback на классический планировщик.

Такой подход позволяет гибко сочетать адаптивность RL с детерминизмом классики, оставаясь в зоне безопасности.
Онлайн-метрики уверенности: зачем они нужны и как работают
В гибридной архитектуре робота управление может исходить из нескольких источников:
основной интеллектуальной политики (например, RL‑контроллер или VLA‑модель);
классического fallback‑планировщика, гарантирующего безопасное поведение.
Чтобы в каждый момент времени выбирать наиболее надёжный источник, мы используем онлайн‑мониторинг качества выполнения — набор метрик уверенности. Их анализом занимается модуль Decision Router (DR).
Что именно можно отслеживать?
σ_pose — дисперсия локализации из SLAM‑системы (напр. ORB‑SLAM3)
Показывает, насколько устойчиво и точно робот понимает, где он находится.
Высокая дисперсия = плохая локализация = риск потери управления.Δτ (torque ripple) — амплитуда дрожания управляющего torque в RL‑политике
Используется как индикатор нестабильности low‑level‑контроллера (например, если политика колеблется или застревает в неопределённости).NLP log‑prob — логарифмическая вероятность текущего шага плана от VLA‑модуля
Позволяет оценивать, насколько VLA уверена в своём семантическом планировании (особенно важно при обработке сложных команд с Natural Language Input).
Когда хотя бы одна из метрик выходит за порог, Decision Router мгновенно переключает источник управляющих действий:
# Псевдокод
if pose_var > σ_thr or torque_ripple > Δτ_thr:
cmd = classic_ctrl(obs) # безопасный fallback
else:
cmd = rl_ctrl(obs) # продолжаем через RL
Почему же это важно?
Такой подход позволяет использовать гибкие RL/VLA‑модули в реальном времени, не теряя гарантированной безопасности.
Переключение занимает всего 1 цикл ≈ 1 мс, что делает его незаметным ни для внешнего наблюдателя, ни для оператора.
Это критически важно для эксплуатации в сложных средах (непредсказуемые поверхности, взаимодействие с людьми, дрейф сенсоров).
Если нужно, можно добавить real‑world‑пример (например: «робот начинает скользить → torque ripple возрастает → DR включает классический стабилизатор походки») или оформить это в презентационную карточку.
VLA‑слой: зачем роботу LLM
VLA отвечает за три важных умения робота:
Понимать: «Принеси красную кружку, но не трогай ноутбук».
Планировать: разложить команду на атомарные навыки.
Учиться: дообучаться на наших же логах через RAG + human feedback.
У большой языковой модели есть четыре роли в управлении роботом:

Над low‑level‑контроллером у нас будет работать VLA‑подсистема — LLM с доступом к зрению, карте окружения и доменным действиям (grasp, move, place). В её основе — одна из Foundation‑моделей и адаптеры для ROS и топологической семантики сцены.
Запуск VLA-подсистемы поверх low-level-контроллеров позволяет:
Принимать команды на естественном языке — без скриптов, интерфейсов и жёсткой привязки к шаблонам.
Строить поведенческий план на уровне задач (grasp, move, place), а не только траекторий и поз.
Интерпретировать сцену семантически: кухня — это не просто меши и координаты, а связанное пространство с назначением объектов.
Объяснять действия и ошибки: LLM может комментировать свои решения, помогая отладке и оператору.
Дообучаться на реальных логах: со временем поведение становится всё более адаптированным к окружению, задачам и особенностям эксплуатации.
Как всё связать: high‑level-обзор

VLA‑LLM — это языково‑визуальная модель, которая занимается высокоуровневым планированием. Она получает команду от человека (например, «Принеси бутылку») и генерирует пошаговый план в виде DSL — специального языка для робота, где есть команды типа goto, grasp, place.
HLC (High‑Level Controller) — контроллер среднего уровня. Он превращает команды из DSL в конкретные движения: например, если нужно подойти к точке, он рассчитывает путь COM (центра масс) и активирует нужные фазы походки. По сути, это FSM (конечный автомат) с набором простых эвристик по скелету.
RL‑LLC (Low‑Level Controller) — это policy на базе PPO, обученная в симуляции. Работает на частоте 50 Гц и выдаёт непрерывные команды в виде торков для всех суставов. Обеспечивает устойчивость и плавность движений на уровне моторики.
Percep — perception‑модуль: детектирует объекты и сегментирует сцену. Построен по мотивам RT–2 и SAM — умеет распознавать, например красную чашку на столе, и передаёт координаты вверх по стеку.
World‑Sim — это предсказательный симулятор. Позволяет моделировать ближайшие 5 секунд движения вперёд, чтобы VLA могла принять более обоснованное решение: стоит ли тянуться за объектом, не приведёт ли это к падению и т. п.
Как взаимодействуют VLA и RL: кейс «Принеси бутылку воды»
Разберём поэтапно, как робот справился с задачей подать стакан принести бутылку воды.
Шаг 1. LLM получает промт.
USER: "Принеси бутылку воды с кухни и поставь на мой стол."
CONTEXT: map.graphml, robot_loc=(x=1.2,y=4.1), desk_loc=(x=5.6,y=3.9)
Шаг 2. LLM формирует план в DSL (Domain‑Specific Language).
- goto: kitchen_sink
- detect: ["bottle","cup"]
- grasp: bottle by neck
- goto: desk_loc
- place: bottle center_of(desk_loc)+offset(0.0,0.2)
Шаг 3. HLC строит траекторию движения центра масс (COM) до целевой точки, когда план включает команду goto
. Каждый промежуточный waypoint по этой траектории передаётся в RL‑политику, которая на каждом шаге получает актуальное наблюдение (obs
) и выдаёт управляющее воздействие (, т. е. вектор торков на суставы).
Шаг 4. LLM генерирует последовательность промежуточных положений руки для захвата (grasp
) — от исходного (pre-grasp
) до финального (lift
), включая момент зажатия (close
). Эти waypoints задают ключевые позы манипулятора, а низкоуровневая RL‑политика обеспечивает плавную и устойчивую траекторию между ними, в том числе с учётом реакций от контакта и динамики кисти.
Какие ещё задачи может подобным образом решать робот:

Что уже работает и куда мы идём дальше
Вот что нам удалось сделать на текущий момент:
На Unitree H1 / Fourier GR–1 бот уверенно ходит по коридору со скоростью 1 м/с.
Lipschitz‑PPO даёт улучшение стабильности в симуляции, в том числе на скользких поверхностях — мы уже проводим реальные тесты.
Реализована начальная версия VLA‑инференсов: OpenVLA и Groot — они интерпретируют простые команды («Подними руку») в пространственные позы конечностей, пригодные для низкоуровневого исполнения.
И вот что мы планируем делать в обозримом будущем:
Multimodal VLA — добавляем карту глубины и аудиоканал как контекст в LLM, чтобы планы учитывали текущую обстановку.
Dynamic‑Safety Proofs — формализуем reachability‑анализ в Classic, чтобы математически гарантировать отсутствие коллизий на горизонте T.
Self‑improving RL — роботы дистиллируют накопленный real‑world experience обратно в симуляторы, ускоряя последующие итерации.
Выводы
LLM‑буст превращает классического робота из маршрутизатора траекторий в понятливого ассистента.
Hybrid Control (RL + VLA + Classic) — мост между надёжностью старых пайплайнов и гибкостью новых моделей.
Поэтапный rollout сохраняет safety и приносит пользу проекту задолго до полной автономии.
LLM — это не замена классике или RL. Это клей, который связывает perception, планирование и контроль в единый цикл «команда → действие → обратная связь». Classic обеспечивает safety, RL — физику, VLA — гибкость.
Мы только в начале пути, но базовые кирпичи уже заложены. Дальше — больше данных, больше навыков, меньше кода.
SnakeSolid
Можете подробнее объяснить как робот ориентируется на местности. Например вы ему говорите - "Принеси бутылку воды с кухни и поставь на мой стол". Как робот понимает где находится кухня и что это такое? Ему за ранее показывают локацию, он как-то ищет кухню по предметам (холодильник, плита), он просто ищет бутылку?
И второй момент, я правильно понимаю, что робот может делать только те действия, которые описаны в DSL у VLA модели? То есть если я его попрошу повторять за мной какое-то действие, например погладить кота, то но не сможет его повторить без переобучения моделей. Какие сейчас действия он может выполнять, есть ли какое-то ограничение по количеству или сложности? Например чтобы помыть пол нужно отслеживать не только состояние швабры, но и чистоту воды и уже помытую область, более того нужно стараться мыть так, чтобы не ходить по чистому. Сможет ли робот с подобной архитектурой это все отслеживать?
Alozarian Автор
Отвечу тремя частями.
1) Архитектура устроена так, чтобы не жёстко прошивать все локации, а позволить роботу привязывать семантические объекты к известной карте — как раз этим занимается VLA-модуль + perception-слой.
Вот как это работает на практике:
Карта помещения (например,
.graphml
или топологический план) заранее создаётся с помощью SLAM (на базе камер, LiDAR и IMU).Названия локаций («кухня», «мой стол», «рецепция») не жёстко заданы, а привязываются к узлам карты через семантический маппинг (пример:
“Kitchen-1” ↔ node#12
).При команде «принеси бутылку из кухни»:
LLM‑планировщик распознаёт “кухня” как логическую цель;
находит ближайший узел в карте, к которому привязана метка
kitchen
;далее маршрут строится по этому топо‑графу → waypoint’ы идут в HLC (High-Level Controller), который уже запускает походку.
Также возможно и объектное распознавание “по признакам” — например, если кухня не размечена, но в комнате обнаружены плита, стол и холодильник, робот может сопоставить это с понятием “кухня”, особенно при дообучении на логах.
Для команды "Принеси бутылку с кухни и поставь на стол": модель разбивает на шаги — иди на кухню (по карте), найди бутылку (детекция объектов), возьми, вернись:
Пример плана (в простом языке для робота):
идти: кухня
найти: бутылка
взять: бутылка за горлышко
идти: стол
положить: бутылка на центр стола
Alozarian Автор
2) Про действия и DSL
Список действий ограничен текущим action-DSL, и без переобучения робот не сможет “с нуля” повторять произвольные телодвижения вроде “погладь кота”. Но тут важно понимать, что DSL — это не минус, а способ задать набор доступных примитивов, которые можно:
легко проверить, ограничить, обезопасить;
использовать в связке с RL‑политиками и fallback’ами;
динамически комбинировать в планы через VLA - базовые примитивы (goto, grasp, place) фиксированы, но VLA может их комбинировать по-новому. "Погладить кота" = detect(cat) → approach → gentle_touch().
Для совсем новых движений:
Быстро: добавить примитив
stroke(obj)
в кодУниверсально: показать движение (через телеоперацию), RL дообучится
Alozarian Автор
3) Вопрос про швабру — супер. Это уже сценарий уровня "multistep + multisensory + constraints".
В такой задаче потребуется комбинация perception, memory и планирования. С текущей архитектурой это реализуемо, но поэтапно:
отслеживание карты покрытия пола можно делать через SLAM + grid-accumulation;
контроль состояния швабры и воды — через multisensor fusion (влагомер, давление, цвет);
избегание хождения по чистому полу — это констрейнт в планировщике (как в path planning с динамическими зонами).
В целом - по моему мнению - это реально, но нужно perception на тему “чисто / грязно”, трекинг покрытой области и грамотный планировщик. VLA сможет этим управлять, если в DSL есть команды вроде
sweep(area)
и ограниченияavoid(cleaned_zone)
.В целом DSL ограничивает действия — но именно это делает поведение предсказуемым, контролируемым и пригодным для гибридного управления.