Записывайте, обучайте и развёртывайте в одном месте с Strands Agents, LeRobot и Hugging Face Storage Buckets

Записывайте, обучайте и развёртывайте из одного места с Strands Agents, LeRobot и хранилищами Hugging Face Пошаговое описание цикла потоковой обработки данных в Strands Robots: один агент записывает демонстрации робота, обучается на них, считывая данные напрямую из Hub, а затем развёртывает политику обратно на оборудование. При этом на всём пути набор данных сохраняется в том же дисковом формате LeRobot.

У вас уже есть агент, который умеет записывать демонстрацию и отправлять её в Hugging Face Hub. Теперь вы хотите выполнять этот цикл непрерывно: собирать эпизоды в течение дня, обучать политику на растущем наборе данных, развёртывать её и получать следующую порцию данных для улучшения. Однократный запуск цикла работает полностью. Но при ежедневном запуске вы начинаете снова и снова платить за передачу одних и тех же байтов. Объём загружаемых записей постоянно растёт, каждый запуск обучения копирует весь набор данных на GPU перед началом работы, а каждая новая контрольная точка отправляется наружу, пока следующая партия записей поступает обратно.

В первой статье этой серии были представлены Strands Robots — SDK с открытым исходным кодом от AWS (Apache 2.0), предоставляющий абстракции роботов, симуляцию и стек LeRobot в виде AgentTools, которые можно объединить в одного агента Strands. В ней рассматривались фабрика Robot(), запись демонстрации в симуляции, запуск политики и развёртывание того же кода агента на физическом SO-101. Фабрика сопоставляет имя с реестром манипуляторов, гуманоидов, мобильных платформ и кистей, поэтому используемый в этой статье SO-100 — лишь один из множества поддерживаемых вариантов. В каталоге роботов перечислены все роботы, известные фабрике. Формат наборов данных LeRobot уже используется более чем в 90 000 наборов данных и моделей на Hub, опубликованных более чем 8 000 авторами (LeRobot Project Pulse). Запись Strands Robots — ещё один такой набор, поэтому любой инструмент, умеющий читать данные LeRobot, сможет работать с ним без конвертации. Если вы впервые знакомитесь с Strands Robots, начните с той статьи: в этой предполагается, что базовая настройка уже выполнена.

В первой статье цикл агента рассматривался в одном направлении — от набора данных в Hub к физическому роботу. Здесь мы проследим движение данных в обратную сторону: от первого записанного кадра до развёрнутой политики через хранилища Hugging Face Storage Buckets — изменяемый, не поддерживающий версионирование тип репозитория объектного хранилища на базе Xet, анонсированный в марте 2026 года. Bucket находится рядом с репозиториями наборов данных в том же пространстве имён hf:// и использует уже имеющийся у вас CLI hf, становясь рабочим слоем, в котором данные хранятся между днём записи и днём обучения.

Кто-то должен решить, какие эпизоды оставить, когда сцена изменилась настолько, что требуется новая запись, достаточно ли сегодняшней партии для обучения и какая контрольная точка заменит текущую на манипуляторе. Каждое из этих решений возникает десятки раз за кампанию сбора данных, и для каждого требуется посмотреть на полученный результат до отправки следующей команды. Именно для этого нужен агент. В этой статье показан цикл данных внутри одного агента: запись демонстрации в Storage Bucket, сохранение так, чтобы при каждой синхронизации отправлялись только изменившиеся байты, обучение с потоковой передачей набора данных напрямую из Hub вместо скачивания и развёртывание контрольной точки обратно на оборудование изменением одного именованного аргумента. Запускаемый пример находится в examples/notebooks/05_streaming_data_loop.ipynb.

Что вы создадите

Если в первой статье набор данных записывался и отправлялся в Hub, то агент из этой статьи записывает LeRobotDataset по запросу на естественном языке, синхронизирует его с Storage Bucket и потоково считывает тот же набор данных кадр за кадром, декодируя видео с камер на лету и не создавая локальную копию. Вы считываете данные в том же процессе, который их записал: тот же Strands Robots Robot(), записавший набор данных, выполняет его потоковую передачу. Обученная контрольная точка затем развёртывается на том же Robot() изменением одного именованного аргумента, а демонстрации, записанные на оборудовании, возвращаются в тот же bucket.

Рисунок 1. Все четыре этапа используют один бэкенд. Robot("so100") записывает LeRobotDataset через общий DatasetRecorder; sync_dataset_to_bucket(...) синхронизирует его со Storage Bucket; stream_dataset(...) считывает его обратно через Hub без полной загрузки; а обученная контрольная точка развёртывается на том же Robot с помощью mode="real". Формат на диске остаётся в точности таким, каким его записал LeRobot.

Поскольку один Robot() и записывает набор данных, и считывает его обратно, сбор данных и обучение на нём — это два метода одного объекта, работающие с одним бэкендом. Агент принимает решение запустить эпизод и вызывает один инструмент; затем выполнение продолжается с частотой управления роботом до завершения эпизода, а обученная политика генерирует каждое действие. Весь цикл в нескольких строках:

from strands import Agent
from strands_robots import Robot

sim = Robot("so100")                 
agent = Agent(tools=[sim])


agent("Запиши демонстрацию подъёма кубика и синхронизируй её с my-org/robot-fave.")


for batch in sim.stream_dataset("my-org/robot-fave/cube_pick", repo_type="bucket").dataloader(batch_size=64):
    ...

Далее пошагово объясняется, что именно происходит внутри этого цикла.

Предварительные требования

Минимальные (стандартный путь симуляции)

• Python 3.12+ в Linux или macOS (Apple Silicon поддерживается бэкендом MuJoCo).
• Совместимый с Strands провайдер моделей для рассуждений агента. Amazon Bedrock с учётными данными AWS, Anthropic API, OpenAI или локально запущенный Ollama.
• Strands Robots с дополнительными компонентами для работы с наборами данных: uv pip install -U "strands-robots[sim-mujoco,lerobot]>=0.5.1". Дополнение lerobot устанавливает LeRobot (>=0.6.1), datasets, av и torchcodec, поэтому запись и декодирование видео работают без дополнительной настройки. См. руководство по установке.

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

Расширенные (bucket, оборудование, реальные политики)

• Учётная запись Hugging Face и токен с правами записи, а также CLI hf для создания bucket и синхронизации наборов данных: pip install -U "huggingface-hub>=1.6.0,<2.0.0", затем hf auth login.
• Для работы с оборудованием: пара follower и leader SO-101 либо любой другой робот, поддерживаемый LeRobot, с файлами калибровки в ~/.cache/huggingface/lerobot/calibration/.
• Для локального вывода vision-language-action (VLA): GPU NVIDIA. Для обучения в масштабе — кластер GPU, считывающий данные из Hub.
• Для запуска обучения: uv pip install "lerobot[training]". Для записи и потоковой передачи этот пакет не нужен. Если его не установить, trainer.train() вернёт результат с ошибкой вместо контрольной точки. В руководстве по устранению неполадок указаны эта ошибка и установка, которая её исправляет.

Шаг 1 — Запись демонстрации в bucket

В течение дня вы записываете новые эпизоды, каждый из которых представляет собой непрерывную последовательность кадров с камер и телеметрии состояния и действий суставов. LeRobot записывает это в виде небольшого набора крупных файлов, увеличивающихся по мере записи. Если отправлять их в версионируемый репозиторий наборов данных, каждое добавление становится коммитом, а каждая ревизия сохраняется. Сбор данных требует обратного: места, куда можно записывать байты и перезаписывать их на месте. Это и есть Storage Bucket, расположенный внутри вашего рабочего пространства Hugging Face и использующий уже имеющиеся права доступа. Не нужно настраивать роли управления доступом и идентификацией (IAM), правила совместного использования ресурсов между источниками (CORS) или поддерживать отдельный сервис загрузки.

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

from strands import Agent
from strands_robots import Robot, sync_dataset_to_bucket

sim = Robot("so100")                 
agent = Agent(tools=[sim])

agent(
    "Создай мир с роботом so100, добавь красный кубик и фронтальную камеру, "
    "начни запись (repo_id='local/cube_pick', root='/tmp/cube_pick', fps=30, "
    "overwrite=True, task='поднять красный кубик'), запусти имитацию политики на "
    "60 шагов, затем останови запись."
)

sync_dataset_to_bucket("/tmp/cube_pick", "my-org/robot-fave")

Синхронизация записывает данные в hf://buckets/{bucket}/{run_id}, где run_id по умолчанию совпадает с именем каталога набора данных. Потоковое чтение на шаге 3 также указывает запуск: первые два сегмента идентификатора — это bucket, а всё после них — путь внутри него.

sync_dataset_to_bucket(root, bucket, run_id=...) проверяет набор данных и синхронизирует его через CLI hf, отдельно от жизненного цикла записи. Та же возможность доступна через DatasetRecorder.sync_to_bucket(bucket, run_id=...), если вы напрямую управляете открытым рекордером, а stop_recording(bucket=...) синхронизирует данные в момент остановки активной записи. Bucket — это рабочий слой, в который вы записываете в течение дня; для версионируемого опубликованного артефакта по-прежнему используется push_to_hub(). Оба варианта используют один и тот же формат.

Эпизод структурно завершён, но действия являются заполнителями, поэтому это не те обучающие данные, которые вам нужны. Для реального захвата замените их настоящей политикой с помощью create_policy("<hf_repo>"); запрос, формат и синхронизация с bucket останутся прежними.

Запись на оборудовании

Для записи на физическом SO-101 CLI записи LeRobot выполняет настройку пары leader-follower:

lerobot-record \
  --robot.type=so101_follower --robot.id=my_follower \
  --teleop.type=so101_leader  --teleop.id=my_leader \
  --dataset.repo_id=my_user/cube_picking \
  --dataset.single_task='Pick up the red cube'

Набор данных сохраняется на диске в том же формате, что и запись в симуляции, поэтому тот же вызов синхронизации отправит его в bucket: sync_dataset_to_bucket("./recordings", "my-org/robot-fave", run_id="run-021") (либо обёрнутый им CLI hf sync ./recordings hf://buckets/my-org/robot-fave/run-021). Сбор данных добавляет записи в одно место, а опубликованные репозитории получают только те версии, которые вы выбрали для публикации.

Шаг 2 — Хранение с дедупликацией на уровне байтов

Теперь, когда набор данных находится в bucket, возникает вопрос о стоимости следующей синхронизации. Если направить две стационарные камеры на манипулятор, очищающий один и тот же стол в течение восьми часов, большая часть записанного — это уже имеющиеся пиксели: одинаковое освещение, одинаковое шасси, одинаковый фон в тысячах эпизодов. В версионируемом репозитории ситуация ещё хуже: изменение одного кадра в видеошарде размером несколько гигабайт приводит к повторной загрузке всего файла.

В основе bucket лежит Xet, который дедуплицирует загрузки на уровне байтов с помощью разбиения содержимого на фрагменты. Границы фрагментов зависят от содержимого, поэтому добавление нескольких байтов изменяет только тот фрагмент, в который они попали, а не сдвигает все последующие границы. Согласно собственным измерениям Hugging Face (HF Storage), разбиение содержимого снижает объём передаваемых данных примерно в четыре раза по всему Hub, а в тарифах Enterprise оплата рассчитывается по дедуплицированному объёму. В тестах bucket показано, как это выглядит для одного файла. При исходной загрузке 500 МБ изменение 1% байтов и повторная загрузка передали 5,5 МБ, изменение 5% — 27,5 МБ, а изменение 10% — 55 МБ. Без дедупликации на уровне фрагментов перезапись объекта означает повторную отправку всех его байтов независимо от того, изменились они или нет.

Размер экономии зависит от структуры файлов, а рекордер Strands Robots использует структуру LeRobot. Эпизоды записываются в Parquet-шарды (data/chunk-000/file-000.parquet) и отдельные MP4-шарды для каждой камеры (videos/observation.images.front/chunk-000/file-000.mp4), причём новый файл создаётся только после заполнения текущего; значения по умолчанию LeRobot составляют 100 МБ для Parquet с данными и 200 МБ для MP4-видео. Поэтому синхронизация после дня записи загружает новые завершающие шарды и один частично заполненный шард, который увеличился, а не весь набор данных. При повторной синхронизации того же bucket на следующий день Xet выполнит дедупликацию.

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

Шаг 3 — Обучение с потоковой передачей из Hub

Для обучения GPU подключаются к вашему набору данных. Если сначала скачать его, GPU будут простаивать, пока не завершится копирование сотен гигабайт. Потоковая передача напрямую из Hub работает здесь благодаря структуре шардов из шага 2: одна партия превращается в несколько чтений диапазонов байтов из крупных шардов, а не в тысячи небольших запросов. StreamingLeRobotDataset из LeRobot превращает это в готовый к использованию итерируемый объект torch, а Strands Robots предоставляет его через stream_dataset():

Рисунок 3. Используйте потоковую передачу, а не скачивание. При скачивании весь набор данных сначала копируется на локальный диск, поэтому GPU ждёт; stream_dataset() считывает партии непосредственно из bucket без размещения данных на локальном диске, поэтому GPU начинает обучение с первой партии.

reader = sim.stream_dataset("my-org/robot-fave/cube_pick", repo_type="bucket",
    shuffle=False, max_num_shards=1, buffer_size=1,  
)

print(reader.num_episodes, reader.num_frames, reader.fps)
for frame in reader:
    frame["observation.images.front"]   
    frame["observation.state"]           
    frame["action"]
    break

На локальный диск попадает только небольшая папка meta/ со схемой, статистикой и индексом эпизодов. Кадры с камер декодируются из удалённых MP4-шардов по мере итерации, а состояние и действия считываются из Parquet-шардов. Этот цикл считывает по одному кадру, что удобно для проверки эпизода. Для обучения передайте reader в DataLoader и вместо этого итерируйтесь по партиям. Потоковый набор данных выполняет внутреннее перемешивание с помощью ограниченного буфера reservoir, поэтому декодирование видео распараллеливается между рабочими процессами, а сам этап обучения остаётся обычным этапом PyTorch:

for batch in reader.dataloader(batch_size=64, num_workers=4):
    loss, _ = policy(batch)   
    loss.backward()

Если вы не хотите писать цикл вручную, собственный тренер LeRobot считывает данные через тот же механизм, поэтому собранный агентом набор данных можно обучать без единой новой строки кода. Bucket передаётся через тот же именованный аргумент, который использует встроенный reader:

lerobot-train --policy.type=act \
  --dataset.repo_id=my-org/robot-fave/cube_pick \
  --dataset.repo_type=bucket \
  --dataset.streaming=true \
  --num_workers=4

Bucket поддерживает только потоковую передачу, поэтому --dataset.repo_type=bucket требует --dataset.streaming=true, а конфигурация отклоняет такую комбинацию без него. Используйте stream_dataset(), если хотите встроить цикл в собственный процесс: проверять эпизод, воспроизводить его в симуляции или передавать данные в пользовательский цикл оценки. Для потоковой передачи только проприоцептивных данных параметр drop_videos=True полностью отключает декодирование видео, что позволяет запускать это на периферийном устройстве без пакета torchcodec. В руководстве по записи и наборам данных описан этот аргумент, а также необходимая ему карта delta_timestamps.

Имена провайдеров общие для запуска и обучения политики. create_trainer("lerobot_local") возвращает Trainer, работающий подобно create_policy(), а TrainSpec описывает запуск; после этого цикл «запись — обучение — развёртывание» замыкается несколькими строками:

import os
os.environ["STRANDS_TRUST_REMOTE_CODE"] = "1"   

from strands_robots import create_policy
from strands_robots.training import TrainSpec, create_trainer

trainer = create_trainer("lerobot_local", device="cuda")
spec = TrainSpec(dataset_root="/tmp/cube_pick", output_dir="/tmp/cube_pick_ft",
                 base_model="", steps=500, extra={"policy_type": "act"})
result = trainer.train(spec)                    
policy = create_policy(result.checkpoint_dir)   

На одном NVIDIA L4 (g6.4xlarge) 500 шагов оптимизатора ACT (51,6 млн параметров, эффективный размер партии 8) для эпизода из 120 кадров заняли 133 секунды и создали контрольную точку, которую create_policy() снова загружает через ту же точку входа, что используется для запуска любой другой политики. Время обучения зависит от размера набора данных, размера партии и числа шагов, поэтому рассматривайте это как одну измеренную конфигурацию, а не как бенчмарк. Провайдеры "groot" и "cosmos3" используют тот же жизненный цикл TrainSpec и Trainer, поэтому окружающий цикл не меняется; каждый сначала проверяет собственные обязательные поля: для запуска GR00T нужны base_model и тег embodiment, а для Cosmos 3 — base_model и рецепт SFT. Вызовите trainer.validate(spec) до train(), и он вернёт точный список недостающих параметров для данного бэкенда.

Механизм предварительного прогрева Hugging Face кэширует данные bucket в периферийных точках рядом с облаком и регионом, где выполняются ваши задания, поэтому кластер читает данные локально, а загрузчик данных опережает GPU. Согласно собственным тестам bucket Hugging Face, попадание в прогретый CDN достигало примерно 1 086 МБ/с при полезной нагрузке 10 ГБ против 780 МБ/с в холодном состоянии и около 1 124 МБ/с в прогретом состоянии при 100 ГБ; измерения проводились на m5dn.24xlarge в us-east-1. Полное сравнение с обычным объектным хранилищем, включая загрузку и скачивание, приведено на этой панели. Выбор места хранения данных задаётся настройкой Storage Regions в тарифах Team и Enterprise; на момент написания доступны США и ЕС, а регионы Азиатско-Тихоокеанского региона и Совета сотрудничества арабских государств Персидского залива (GCC) заявлены как будущие. Вне этих тарифов репозитории хранятся в США.

В macOS команда import strands_robots сама добавляет ffmpeg из Homebrew в путь загрузчика, поэтому torchcodec декодирует потоковое видео без дополнительной настройки.

Шаг 4 — Развёртывание политики и возврат данных в цикл

На этом шаге вы берёте только что обученную контрольную точку, запускаете её на физическом роботе и записываете следующий набор демонстраций. Это тот же код агента из первой статьи, но с изменённым именованным аргументом mode="real":

robot = Robot("so100", mode="real", port="/dev/ttyACM0",
              cameras={"front": {"type": "opencv", "index_or_path": "/dev/video0", "fps": 30}})
agent = Agent(tools=[robot])
agent("Подними красный кубик.")

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

Если ваши данные уже находятся в Amazon Simple Storage Service (Amazon S3), форматная часть этой статьи не меняется. LeRobotDataset представляет собой каталог Parquet- и MP4-шардов, поэтому в Amazon S3 он хранится так же, как и в любом другом месте, а этапы записи, обучения и развёртывания считывают этот формат независимо от расположения. Bucket добавляет маршрут, нативный для Hub: sync_dataset_to_bucket и stream_dataset(repo_type="bucket") напрямую работают с hf://, поэтому синхронизация и потоковое чтение доступны без настройки отдельного пути хранения. Оба варианта реализуют один и тот же цикл: Amazon S3, если данные уже находятся там, или bucket, если вы хотите синхронизацию и потоковое чтение без предварительного выделения хранилища.

Запустите цикл снова завтра — и вы будете записывать данные в этот bucket, синхронизируя только изменившиеся байты и передавая их на GPU без ожидания скачивания. Данные не покидают формат LeRobot и не покидают Hub.

Попробуйте с помощью примерного приложения

Полный пример Strands Robots находится на GitHub: strands-labs/robots, файл examples/notebooks/05_streaming_data_loop.ipynb. Он пошагово проводит через весь цикл: запись, визуализацию, синхронизацию с bucket, потоковое чтение, обучение и загрузку контрольной точки. Каждая ячейка работает в симуляции с имитацией политики, поэтому не нужны ни GPU, ни Docker, ни учётные данные Hugging Face.

git clone https://github.com/strands-labs/robots.git
cd robots
uv pip install -U "strands-robots[sim-mujoco,lerobot]>=0.5.1"
jupyter notebook examples/notebooks/05_streaming_data_loop.ipynb

Запускайте ячейки сверху вниз. Записанный набор данных появится в /tmp/nb5_dataset. Чтобы синхронизировать его с bucket, задайте BUCKET = "my-org/robot-fave" в первой ячейке (после hf auth login); соседний параметр RUN_ID задаёт имя папки внутри bucket, а notebook считывает данные из f"{BUCKET}/{RUN_ID}". Для обучения на GPU увеличьте steps до 500 и задайте device="cuda". Версия того же цикла под управлением агента находится в examples/06_agent_collect_and_stream.py.

Вопросы безопасности

Приведённые здесь фрагменты — это «Hello World» цикла данных Strands Robots. При работе с реальными данными меняются пять аспектов.

• Инъекция в запросы. Передача агенту ненадёжных данных может привести к инъекции в запросы, когда недостоверный контекст воспринимается как инструкции для LLM. Эти агенты управляют роботами, а теперь ещё записывают данные в общее хранилище и считывают их оттуда, поэтому за этим риском важно следить. Передавайте агенту только данные из доверенных источников. Если доверять можно не всем входным данным, ограничьте доступные агенту инструменты, чтобы он не мог выполнять критически важные для безопасности действия или перезаписывать содержимое bucket.

• Обучающие данные — граница доверия. Агент, способный записывать данные в bucket сбора, также может записывать эпизоды, на которых позднее будет обучаться политика, управляющая физическим манипулятором. Разделяйте учётные данные для записи данных сбора и для чтения данных заданием обучения, синхронизируйте каждый запуск под собственным run_id, чтобы эпизод можно было связать с создавшим его запуском и удалить отдельно, и рассматривайте версионируемый репозиторий набора данных как проверенный артефакт, поскольку bucket не хранит ревизий для аудита.

• Учётные данные и область действия bucket. sync_dataset_to_bucket(...), stop_recording(bucket=...) и sync_to_bucket загружают данные через CLI hf, используя токен из hf auth login. Используйте токен с областью действия, ограниченной конкретным пространством имён, в которое выполняется запись, предпочитайте для данных сбора приватные bucket с параметром --private и отделяйте bucket от версионируемого репозитория наборов данных, в который вы выполняете push_to_hub и которым делитесь.

• Перезапись на месте не сохраняет ревизии. Bucket перезаписывает данные на месте и не хранит ревизии, что делает его рабочим слоем, но означает, что повторное использование run_id заменяет уже сохранённый запуск. Передавайте явный run_id для каждого запуска сбора, например sync_dataset_to_bucket("./recordings", "my-org/robot-fave", run_id="run-021"). Для всего, к чему нужно иметь возможность вернуться, используйте push_to_hub() в версионируемый репозиторий наборов данных, где сохраняется каждая ревизия.

• Используйте только доверенные организации Hugging Face. Локальный путь вывода загружает модели Hugging Face с параметром trust_remote_code=True. Установите STRANDS_TRUST_REMOTE_CODE=1, чтобы явно разрешить это, и загружайте контрольные точки только из организаций, которым доверяете. При загрузке предварительно обученных весов из Hub (например, через pretrained_name_or_path) проверьте надёжность организации до загрузки. Веса моделей могут содержать произвольный код (контрольные точки на основе pickle). По возможности отдавайте предпочтение контрольным точкам в формате safetensors.

Очистка

После цикла останутся bucket, наборы данных в /tmp и контрольная точка на диске. Содержимое bucket учитывается в объёме хранилища, поэтому удалите ненужные данные:

hf buckets rm my-org/robot-fave/cube_pick/ --recursive --dry-run  # перечисляет, ничего не удаляет
hf buckets rm my-org/robot-fave/cube_pick/ --recursive            # --yes пропускает запрос подтверждения
hf buckets delete my-org/robot-fave                               # удаляет всё его содержимое
rm -rf /tmp/cube_pick /tmp/cube_pick_ft /tmp/nb5_dataset /tmp/nb5_ft

Остановите все процессы обучения, которые ещё работают на экземпляре GPU, и сам экземпляр. Если вы запускали notebook, подставьте его RUN_ID (по умолчанию nb5_demo) вместо cube_pick. Всё опубликованное с помощью push_to_hub() находится в версионируемом репозитории и не затрагивается.

Что делать дальше

В документации Strands Robots подробно описаны каталог роботов, симуляция, провайдеры политик, запись и mesh. В руководстве по записи и наборам данных полностью документированы API DatasetRecorder, sync_dataset_to_bucket / sync_to_bucket и stream_dataset.

Если вы собираете данные более чем с одного робота, назначьте каждому собственный run_id, и они смогут параллельно записывать данные в один bucket. Mesh для нескольких роботов распределяет одного агента между этими роботами, превращая тот же цикл в сбор данных флотом в течение дня в общем хранилище. Потоковый reader считывает по одному запуску за раз. В руководстве по записи и наборам данных описано, как обучаться на нескольких запусках.

Если вам нужна политика крупнее ACT, жизненный цикл TrainSpec и Trainer из шага 3 поддерживает GR00T и Cosmos 3 через собственные имена провайдеров, поэтому дообучение VLA на только что считанном наборе данных выполняется теми же вызовами, но с другой строкой провайдера и базовой моделью. Запуск результата — это место, где пути расходятся: контрольная точка VLA развёртывается на оборудовании, а не в симуляторе, на котором вы обучались. Для более сложной симуляции, предназначенной для генерации этих данных, бэкенды Newton (sim-newton) и Isaac Sim (isaac) работают через ту же фабрику Robot(), поэтому код агента не меняется при масштабировании.

Потоковая работа bucket появилась в LeRobot благодаря вкладу команд Strands Robots и LeRobot непосредственно в LeRobot, поэтому наборы данных, собранные вашим агентом, доступны для чтения всем инструментам этой экосистемы. Это работает и в обратную сторону: reader на шаге 3 открывает любые уже опубликованные на Hub наборы данных LeRobot, поэтому агент может воспроизводить и оценивать существующие демонстрации ещё до записи собственных.

Вклад приветствуется на условиях Apache 2.0. Если вы создадите что-то с помощью этого цикла, сообщите в issue, что сработало, а что нет.

Ресурсы

Strands Robots

• SDK, AgentTools и фабрика Robot(): github.com/strands-labs/robots, Apache 2.0
• Документация:

  Переведено автоматически с английского. Оригинал статьи — по ссылке ниже.