Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 6

Можете подробнее объяснить как робот ориентируется на местности. Например вы ему говорите - "Принеси бутылку воды с кухни и поставь на мой стол". Как робот понимает где находится кухня и что это такое? Ему за ранее показывают локацию, он как-то ищет кухню по предметам (холодильник, плита), он просто ищет бутылку?

И второй момент, я правильно понимаю, что робот может делать только те действия, которые описаны в DSL у VLA модели? То есть если я его попрошу повторять за мной какое-то действие, например погладить кота, то но не сможет его повторить без переобучения моделей. Какие сейчас действия он может выполнять, есть ли какое-то ограничение по количеству или сложности? Например чтобы помыть пол нужно отслеживать не только состояние швабры, но и чистоту воды и уже помытую область, более того нужно стараться мыть так, чтобы не ходить по чистому. Сможет ли робот с подобной архитектурой это все отслеживать?

Отвечу тремя частями.

1) Архитектура устроена так, чтобы не жёстко прошивать все локации, а позволить роботу привязывать семантические объекты к известной карте — как раз этим занимается VLA-модуль + perception-слой.

Вот как это работает на практике:

  1. Карта помещения (например, .graphml или топологический план) заранее создаётся с помощью SLAM (на базе камер, LiDAR и IMU).

  2. Названия локаций («кухня», «мой стол», «рецепция») не жёстко заданы, а привязываются к узлам карты через семантический маппинг (пример: “Kitchen-1” ↔ node#12).

  3. При команде «принеси бутылку из кухни»:

    • LLM‑планировщик распознаёт “кухня” как логическую цель;

    • находит ближайший узел в карте, к которому привязана метка kitchen;

    • далее маршрут строится по этому топо‑графу → waypoint’ы идут в HLC (High-Level Controller), который уже запускает походку.

Также возможно и объектное распознавание “по признакам” — например, если кухня не размечена, но в комнате обнаружены плита, стол и холодильник, робот может сопоставить это с понятием “кухня”, особенно при дообучении на логах.

Для команды "Принеси бутылку с кухни и поставь на стол": модель разбивает на шаги — иди на кухню (по карте), найди бутылку (детекция объектов), возьми, вернись:

Пример плана (в простом языке для робота):
идти: кухня
найти: бутылка
взять: бутылка за горлышко
идти: стол
положить: бутылка на центр стола

2) Про действия и DSL

Список действий ограничен текущим action-DSL, и без переобучения робот не сможет “с нуля” повторять произвольные телодвижения вроде “погладь кота”. Но тут важно понимать, что DSL — это не минус, а способ задать набор доступных примитивов, которые можно:

  • легко проверить, ограничить, обезопасить;

  • использовать в связке с RL‑политиками и fallback’ами;

  • динамически комбинировать в планы через VLA - базовые примитивы (goto, grasp, place) фиксированы, но VLA может их комбинировать по-новому. "Погладить кота" = detect(cat) → approach → gentle_touch().

Для совсем новых движений:

  • Быстро: добавить примитив stroke(obj) в код

  • Универсально: показать движение (через телеоперацию), RL дообучится

3) Вопрос про швабру — супер. Это уже сценарий уровня "multistep + multisensory + constraints".

В такой задаче потребуется комбинация perception, memory и планирования. С текущей архитектурой это реализуемо, но поэтапно:

  • отслеживание карты покрытия пола можно делать через SLAM + grid-accumulation;

  • контроль состояния швабры и воды — через multisensor fusion (влагомер, давление, цвет);

  • избегание хождения по чистому полу — это констрейнт в планировщике (как в path planning с динамическими зонами).

В целом - по моему мнению - это реально, но нужно perception на тему “чисто / грязно”, трекинг покрытой области и грамотный планировщик. VLA сможет этим управлять, если в DSL есть команды вроде sweep(area) и ограничения avoid(cleaned_zone).

В целом DSL ограничивает действия — но именно это делает поведение предсказуемым, контролируемым и пригодным для гибридного управления.

Спасибо за интересную статью !

У меня появился вопрос по поводу поведения Decision Router. Получает при ухудшении ситуации, он всегда упрощает режим робота, выбирая надежность. Может ли он при наступлении благоприятных условий (понятном положении на карте), вернуться к более сложному сценарию поведения ?

Также самая идея совмещения подходов показалась мне похожей на развития человеческого мозга, когда появлялись новые отделы в ответ на новые задачи, но при этом базировались они на старых. Поэтому стал интересен вопрос саморефлексии. Планируете ли реализовывать что-то похожее ? Есть намеки в RAG/feedback и Failure explanation, но как будто это не совсем то.

По поводу Decision Router: да, возврат в более “сложный” режим будет предусмотрен.
DR не только умеет «падать на надёжную политику», но и мониторит метрики дальше — если условия нормализуются (например, SLAM стабилен, torque ripple в пределах нормы, VLA выдаёт уверенные планы), происходит возврат к основной политике.

Это, по сути, адаптивный переключатель режима уверенности, и он работает в обе стороны. В будущем мы планируем добавить эксплицитный hysteresis-механизм, чтобы избежать «дёрганья» при граничных значениях метрик.

Про саморефлексию. Идея «новых отделов мозга, наслаивающихся на старые» — это именно то, как мы строим архитектуру: Classic как “стволовой мозг”, RL как “церебеллум”, VLA как “неокортекс”.

То, что вы называете саморефлексией, можно разложить на несколько направлений:

  1. Failure Explanation — модель учится объяснять, почему не получилось, не просто через логоведение, а через языковую обратную связь (что-то вроде LLM‑based stacktrace).

  2. Feedback-Informed Planning — встраиваем feedback loops в VLA: после исполнения шагов робот может скорректировать оставшийся план или даже перепланировать целиком.

  3. RAG + логика на уровне “прошлого опыта” — это early‑этап, но мы хотим, чтобы VLA могла опираться не только на план, но и на подобные ситуации из прошлого — не только “что делать”, но и “чем это кончилось”.

Вопросы - классные! Спасибо!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий