Удалённый вывод

Крупным политикам требуется GPU, а при синхронном rollout робот останавливается каждый раз, когда политика вычисляет следующий блок действий. Удалённый инференс разделяет задачу на две части: policy server выполняет чекпоинт на GPU, а robot computer сохраняет управление камерами, моторами, телеуправлением и записью. Робот продолжает выполнять уже имеющиеся действия, пока сервер вычисляет следующие, поэтому движение больше не прерывается на время инференса.

Используйте, когда:

• компьютер, подключенный к роботу, не имеет GPU или он слишком мал для политики: ноутбук или одноплатный компьютер рядом с манипулятором и рабочая станция с GPU в другой части лаборатории;
• inference занимает заметную долю времени каждого чанка действий, и вам требуется непрерывное движение;
• вы хотите определить, как часто робот должен пересчитывать план, не изменяя контрольную точку.

Единственный компромисс, который вы настраиваете, — это свежесть данных против непрерывности. Запрос нового плана раньше позволяет роботу реагировать на то, что он видит; следование большей части текущего плана сохраняет прогресс в выполнении задачи.

Как это работает

Компьютер робота хранит буфер предстоящих действий. Когда буфер становится малым, он отправляет свежее наблюдение, продолжает движение по буферу, пока сервер вычисляет, и вставляет новый фрагмент в ту часть плана, которая ещё не была выполнена.

Три параметра клиента определяют это поведение. refill_seconds задаёт, насколько заранее запрашивать следующий план, chunk_merge определяет, как новый план встраивается в старый, а сглаживание смягчает стык между ними. Серверу достаточно контрольной точки и описания робота, для которого он был обучен. Разделы ниже начинаются с рабочей конфигурации, а затем формируют интуицию для каждого параметра.

Локальный RTC (--inference.type=rtc) — это другой вариант асинхронного режима: инференс выполняется в фоновом потоке процесса rollout на той же машине, без сервера. Удалённый инференс на том же хосте по-прежнему использует два процесса и --inference.type=remote и обеспечивает выравнивание и смешивание для политик без RTC. См. как RTC соотносится с удалённым инференсом.

Поддерживаемые политики и роботы

Чекпоинт может быть использован для обслуживания, если его сохранённые процессоры предсказывают блок действий на основе одного текущего наблюдения; для ACT необходимо отключить временное ансамблирование. Чекпоинты ACT, SmolVLA, XVLA, EVO1 и LaWAM успешно работали на реальных роботах через этот путь. Несколько других политик поддерживаются на уровне контракта, но не были проверены на аппаратном обеспечении, а политики, зависящие от истории, требуют дополнительной интеграции. В таблице поддержки политик указан статус и ограничения каждой политики.

Драйвер робота должен объявить поддержку удержания позиции, поскольку клиент обновляет последнее применённое целевое значение, ожидая действий. SO, OMX, Koch, HopeJr, Rebot и последователи YAM объявляют её; OpenArm, Reachy2 и бимануальные обёртки зависят от своей конфигурации; Unitree G1 объявляет её только с контроллером SONIC, у которого удерживаемое целевое значение — это последний токен движения; мобильные платформы не объявляют. См. таблицу оборудования. Неподдерживаемые контракты робота или политики отклоняются на этапе допуска, до начала любого движения.

Начните с рабочего rollout

В качестве эталона используйте успешно выполненную синхронную команду lerobot-rollout и сохраните её настройки робота, камер, задачи, FPS, телеоператора и интерполяции. Чекпоинт и устройство модели перемещаются на сервер; удалённый клиент не загружает веса.

Приведённые ниже примеры описывают универсальный SO-101 с шестью актуаторами и одной фронтальной камерой. Согласованно адаптируйте контрольную точку, виды камеры, порядок компонентов и единицы измерения.

1. Установите на обоих компьютерах

Обе стороны требуют дополнительный пакет remote. Оставляйте аппаратные дополнительные пакеты на клиенте, а дополнительный пакет выбранной политики — на сервере:

uv sync --locked --extra remote --extra core_scripts --extra feetech
# Add the policy extra on the server when required, for example --extra pi.

Поддерживаемый диапазон версий Zenoh — >=1.9.0,<1.11.0; команда uv sync --locked устанавливает версию из lockfile, в настоящее время 1.10.1.

2. Настройте и запустите сервер

Скопируйте универсальную конфигурацию, затем отредактируйте её:

cp examples/remote_inference/server.yaml server.yaml

Установите model.repo_or_path и model.device. Для контрольной точки из Hub зафиксируйте model.revision на том коммите, который вы планируете валидировать. Приведите features, action_feature, semantics, robot_type и execution.action_fps в соответствие с вашей рабочей конфигурацией; см. примеры схемы и переименования камер ниже.

uv run --no-sync lerobot-policy-server --config_path=server.yaml

Сервер загружает контрольную точку, проверяет её объявления, выполняет разминку, а затем записывает в журнал Policy server ready: deployment=<name> instance=<id>; awaiting one client. Каждое поле YAML поддерживает вложенное переопределение через CLI:

uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --model.device=cuda \
  --execution.idle_timeout_s=10

3. Запустите клиент робота

В другом терминале настройте аргументы оборудования для той же конфигурации:

uv run --no-sync lerobot-rollout \
  --inference.type=remote \
  --inference.endpoint=tcp/127.0.0.1:7447 \
  --inference.deployment=manipulation \
  --inference.mode=chunk \
  --inference.chunk_merge=aligned \
  --inference.semantics=so101-degrees-gripper-percent-v1 \
  --robot.type=so101_follower \
  --robot.port=/dev/ttyACM0 \
  --robot.use_degrees=true \
  --robot.cameras='{front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}' \
  --fps=30 \
  --task="pick up the cube" \
  --interactive=true

После подключения введите /start. /stop завершает выполнение; см. что делает робот во время ожидания или остановки. Сохраните параметры телеуправления и записи из вашей рабочей сессии. Не передавайте в удалённый клиент --policy.path, локальные переопределения модели или устройства, а также флаги компиляции.

deployment выбирает сервер, а semantics задаёт имена и порядок валидированных единиц действия; оба параметра должны соответствовать конфигурации сервера. В примере используются углы суставов тела и откалиброванный диапазон захвата 0–100.

uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --zenoh.listen_endpoints='[tcp/172.18.133.214:7447]'

Выберите способ продолжения движения

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

Настройки в этой таблице используют префикс --inference.. Для обычных чанков по умолчанию используется выравнивание с отключённым смешиванием. Целевой объект, который уже интерполируется, фиксируется и не может быть заменён.

Alignment отбрасывает входящие шаги, которые уже были зафиксированы. Blending усредняет пересекающиеся будущие цели. Interpolation добавляет промежуточные команды управления между конечными точками. RTC изменяет способ генерации предсказания. Ни один из этих методов не гарантирует плавное движение или успешный захват.

--inference.chunk_merge=aligned \
--inference.blend_steps=5 \
--inference.blend_weight=0.5 \
--inference.blend_components='[shoulder_pan.pos, shoulder_lift.pos, elbow_flex.pos, wrist_flex.pos, wrist_roll.pos]'

uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --execution.supported_modes='[rtc_guided]' \
  --execution.rtc.enabled=true \
  --execution.rtc.mode=guided \
  --execution.rtc.execution_horizon=15

Параметры, которые имеют значение

Опции клиента, перечисленные ниже, используют префикс --inference., если не указано иное. Значения по умолчанию являются начальными, а не гарантированными для конкретного робота.

Эффективное пополнение составляет max(refill_seconds, recent maximum turnaround + 1 / fps). Turnaround включает кодирование, передачу по сети, ожидание в очереди, инференс и декодирование. Первая принятая заявка задаёт начальную оценку; последующие оценки используют до 100 выборок в стационарном режиме.

Таким образом, Refill — это ни фиксированный период запросов, ни гарантированное количество выполненных действий. Проверяйте настроенные и фактические значения Refill в логах. Порог, охватывающий весь горизонт выполнения, приводит к очень частой замене.

Что делает робот во время ожидания или остановки

Во время поддерживаемого ожидания клиент обновляет последнюю цель, фактически применённую драйвером, включая интерполяцию, обрезание и захват. До первой команды его инициализирует измеренная поза. Это останавливает продвижение по траектории; робот всё ещё может стабилизироваться в направлении этой цели. Это не отключает крутящий момент и не гарантирует неподвижность. Локальный RTC использует такое же ограниченное ожидание на поддерживаемых роботах и немедленно сигнализирует об ошибке при исчерпании лимита в остальных случаях.

Восстановление после голодания (starvation) отбрасывает устаревшее предсказание, находящееся в обработке, и получает новое предсказание из снимка, сделанного после начала ожидания. Старые результаты не могут перезапустить движение. Пакеты и непригодные результаты не продлевают период ожидания (grace). Частые ожидания указывают на недостаточное покрытие воспроизведения или задержки.

Потеря сервера или соединения не восстанавливается автоматически. Валидные буферизованные действия могут быть обработаны, после чего система переходит в ожидание до истечения grace-периода или другого дедлайна. Как только потеря присутствия сервера будет зафиксирована, возобновление этой сессии при восстановлении соединения невозможно; для новой сессии необходимо перезапустить rollout. Во время работы с текстом зафиксированная потеря сервера приводит к сбою запроса.

При исправном получении наблюдений и управлении актуаторами завершение терминала выполняет возврат в исходное положение, если задан параметр --return_to_initial_position=true (значение по умолчанию), а затем отключается. Для возврата требуется полное наблюдение, поэтому устойчивый сбой камеры может его предотвратить. Сбой действия или применения удержания блокирует дальнейшее движение. Если установить параметр в false, возврат будет пропущен, но отключение всё равно выполнится. При отключении момент вращения может быть снят в соответствии с конфигурацией робота. Сбои в терминале приводят к выходу с ненулевым кодом после завершения очистки; принудительно завершённый процесс не может гарантировать выполнение очистки.

Настройка одной рабочей задачи

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

1. Сначала используйте выравнивание без смешивания. Зафиксируйте FPS, интерполяцию и конфигурацию. Проанализируйте горизонт выполнения, полное время цикла и медленные запросы.
2. Выберите покрытие пополнения с запасом. Оставьте достаточно времени воспроизведения для следующего запроса и вариаций задержки, не заменяя план непрерывно.
3. Добавьте короткое смешивание с такой частотой. Сравнивайте завершение задачи, захват/отпускание и столкновения отдельно. Плавное усреднение несовместимых планов может привести к пропуску объекта.
4. Запрашивайте ранее только ради выгоды. Увеличение частоты пополнения может повысить отзывчивость, но прервать полезный прогресс. Если производительность задачи ухудшается, возвращайтесь к стабильному темпу.
5. Изменяйте по одному параметру за раз. Увеличение таймаутов или grace не компенсирует отсутствие действий. Уменьшение refill не является универсальным решением проблемы исчерпания ресурсов.

Для горизонта выполнения 0.8 s и стабильного успешного выравнивания интервал между запросами составляет примерно 0.8 - effective_refill:

Это исключает эффекты запуска, удержания, насыщения и тактов управления. Запрос, начинающийся с оставшимся временем 0.2 s и занимающий 0.1 s, оставляет лишь 0.1 s на смешивание, то есть три шага при 30 Гц. Таким образом, для почти синхронного ритма может потребоваться лишь короткое смешивание.

Для выравнивания и RTC проверяйте доступное время воспроизведения после обрезки, а не номинальную длину фрагмента. Если инференс занимает 1 секунду из прогноза на 1,67 секунды, остаётся лишь около 0,67 секунды. Ещё один запрос на 1 секунду не влезет; никакое значение пополнения это не исправит. Сократите время отклика, используйте более длинный поддерживаемый горизонт или проверьте другую частоту действий.

Возраст источника включает время выполнения. Для режима добавления (append) допустимо примерно execution horizon + effective refill плюс запас на захват и инференс. Чанк из 100 шагов при 30 Гц уже охватывает 3,33 секунды. Выравнивание обычно снижает возраст, но многократное смешивание может сохранять более старые компоненты.

Чтение журналов и диагностика запуска

Лог-записи уровня INFO отображают параметры приёма и эффективные настройки, результаты текстовых запросов, переходы в режим ожидания/остановки, а также сводку активности примерно каждые пять секунд. Чтение и очередь воспроизведения следует рассматривать совместно. Для получения подробных сведений используйте сервер с --log_level=DEBUG и клиент с --inference.log_level=DEBUG. В интерактивных сессиях клиентские логи ниже уровня ERROR отключаются; для сбора живых данных о времени выполнения используйте неинтерактивный запуск.

При сохранении журналов используйте 2>&1 | tee -i server.log (или client.log). Флаг -i позволяет tee продолжать работу, когда Ctrl+C достигает всего конвейера, благодаря чему фиксируются и сообщения о корректном завершении работы.

DEBUG включает воспроизведение каждого запроса при отправке, возраст наблюдения и прогресс курсора, а также обрезанные/используемые шаги и перекрытие для каждого результата. Эти данные описывают заданный прогресс, а не фактическое физическое выполнение.

Конфигурация и сетевые настройки

Держите один YAML-файл деплоя для чекпоинта, схемы робота и настроек сервера; используйте вложенные переопределения CLI для экспериментов. Назначайте независимым экспериментам разные имена деплоя. Оба процесса записывают в лог версии пакета и протокола; проверка допуска проверяет протокол и контракты выполнения/данных, не требуя идентичных версий пакета.

features:
  - name: observation.state
    shape: [6]
    dtype: float32
    names:
      [
        shoulder_pan.pos,
        shoulder_lift.pos,
        elbow_flex.pos,
        wrist_flex.pos,
        wrist_roll.pos,
        gripper.pos,
      ]
    semantics: so101-degrees-gripper-percent-v1
  - name: observation.images.front
    shape: [480, 640, 3]
    dtype: uint8
    kind: rgb
    semantics: rgb-front-table-v1

zenohd --config examples/remote_inference/zenoh/router.json5

uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --zenoh.mode=client \
  --zenoh.listen_endpoints='[]' \
  --zenoh.connect_endpoints='[tls/localhost:7447]' \
  --zenoh.config_file=examples/remote_inference/zenoh/server.json5

--inference.endpoint=tls/localhost:7447 \
--inference.zenoh_mode=client \
--inference.zenoh_config_path=examples/remote_inference/zenoh/robot.json5

LEROBOT_ZENOHD=/absolute/path/to/zenohd \
  uv run --no-sync pytest tests/remote_inference/test_zenoh.py -q -rs

Язык и запись

Используйте /vqa, /subtask и /autosteer через интерактивный rollout. Включите параметр сервера language.enabled=true только для чекпоинта, реализующего генерацию текста; для autosteering дополнительно требуется чекпоинт, обученный для генерации подзадач с совместимым промптингом целей/подзадач. Сервер предоставляет эти команды, если чекпоинт декларирует соответствующую возможность; полезность ответов и подзадач зависит от чекпоинта.

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

Запись использует стандартный формат локального набора данных. Метки задач соответствуют выполняемому действию. Диагностические данные остаются в журналах приложения; они не записываются в набор данных и не загружаются. При использовании набора данных применяйте --dataset.single_task для начальной инструкции; в противном случае используйте --task. Рекомендуется выбрать один из вариантов, чтобы избежать конфликтов конфигурации.

Использование из Python

Общие движки и конфигурация находятся в lerobot.inference; удалённый клиент, движок и сервер — в lerobot.remote_inference. Внешний по отношению к lerobot-rollout цикл управления подключает и принимает клиента, оборачивает его в движок, публикует снимки и передаёт каждый такт мотора через dispatch_tick, который применяет тот же контракт разрешений, удержания и подтверждения, что и CLI:

import time

import numpy as np

from lerobot.inference import RemoteInferenceConfig, dispatch_tick
from lerobot.remote_inference import RemoteClient, RemoteInferenceEngine
from lerobot.utils.action_interpolator import ActionInterpolator

config = RemoteInferenceConfig(
    endpoint="tcp/127.0.0.1:7447",
    deployment="manipulation",
    semantics="so101-degrees-gripper-percent-v1",
)
client = RemoteClient.connect(config)
caps = client.capabilities
client.admit(
    features=caps.features,
    action_feature=caps.action_feature,
    semantics=config.semantics,
    action_interval=caps.action_interval,
    mode=config.mode,
)
engine = RemoteInferenceEngine(client, config, task="pick up the cube")
interpolator = ActionInterpolator(multiplier=1)

engine.start()
engine.resume()
try:
    while running():
        captured = time.monotonic()
        engine.submit_observation(
            {"observation.state": state_vector(), "observation.images.front": front_rgb()},
            capture_time=captured,
        )
        # send() receives a torch tensor in the deployment's action order; hold() refreshes
        # the last applied target. Returns None when the tick was held or starved.
        dispatch_tick(engine, interpolator, send=robot_send, hold=robot_hold)
finally:
    engine.stop()  # revokes motion and closes the client

Наблюдения индексируются по именам признаков, ориентированных на контрольные точки, и должны соответствовать схеме сервера: векторы float32 в объявленном порядке компонентов, изображения RGB uint8 объявленного размера. tests/remote_inference/test_library_client.py проверяет этот путь на loopback-сервере и служит эталоном для последовательности вызовов. lerobot-rollout добавляет поверх этого преобразование драйвера, проверки удержания позиции, интерактивные команды и запись; lerobot-policy-server является точкой входа для обслуживания и настраивается только через свои YAML-файлы и переопределения CLI.

См. справочник по инженерному проектированию для информации об архитектуре, контрактах выполнения и запланированных расширениях.