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

Записвайте, обучавайте и внедрявайте от едно място със Strands Agents, LeRobot и Storage Buckets на Hugging Face Ръководство за цикъла на поточните данни в Strands Robots: един агентен цикъл, който записва демонстрации на робот, обучава се с тях, като ги прочита директно от Hub, и внедрява политиката обратно в хардуера — през цялото време с набора от данни в същия дисков формат LeRobot.

Вече разполагате с агент, който може да запише демонстрация и да я изпрати в Hugging Face Hub. Сега искате да изпълнявате този цикъл непрекъснато: да събирате епизоди през деня, да обучавате политика върху нарастващия набор от данни, да я внедрявате и да извличате следващата партида, за да я подобрите. Изпълнете цикъла веднъж и всяка част работи. Изпълнявайте го всеки ден и започвате да плащате за едни и същи прехвърляния на байтове отново и отново. Качените записи продължават да растат, всяко обучение копира целия набор от данни към графичните процесори, преди да започне, а всяка нова контролна точка се изпраща навън, докато следващата партида записи се връща.

Първата публикация от тази поредица представи 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("Record a pick-the-cube demo and sync it to 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, така че и записът, и декодирането на видео работят без допълнителна настройка. Вижте ръководството за инсталиране.

Това е всичко. Всеки етап в тази публикация работи на лаптоп с тези три компонента. Работи цикълът, а не полезна политика: пътят по подразбиране използва фиктивна политика, която записва валиден набор от данни, но не и полезен.

Разширени изисквания (buckets, хардуер, реални политики)

• Акаунт в Hugging Face и токен с разрешение за запис, както и CLI инструментът hf за създаване на buckets и синхронизиране на набори от данни: 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): графичен процесор NVIDIA. За обучение в мащаб — клъстер от графични процесори, който чете от Hub.
• За изпълнение на стъпката за обучение: uv pip install "lerobot[training]". Записът и поточното четене не се нуждаят от нея. Ако я пропуснете, trainer.train() връща резултат с грешка вместо контролна точка. Ръководството за отстраняване на проблеми посочва тази грешка и инсталацията, която я отстранява.

Стъпка 1 — Записване на демонстрация в bucket

През деня записвате нови епизоди, всеки от които представлява непрекъсната поредица от кадри от камерата и телеметрия за състоянието и действията на ставите. LeRobot записва това като малък набор от големи файлове, които нарастват с продължаването на записа. Изпратете ги във версионирано хранилище за набори от данни и всяко добавяне се превръща в commit, като всяка ревизия се запазва. Събирането изисква обратното: място, в което да записвате байтове и да ги презаписвате на място. Това е 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(
    "Create a world with the so100 robot, add a red cube and a front camera, "
    "start recording (repo_id='local/cube_pick', root='/tmp/cube_pick', fps=30, "
    "overwrite=True, task='pick up the red cube'), run the mock policy for "
    "60 steps, then stop recording."
)

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, въпросът е колко ще ви струва следващата синхронизация. Насочете две фиксирани камери към манипулатор, който разчиства една и съща маса в продължение на осем часа, и по-голямата част от записаното са вече налични пиксели: същото осветление, същото шаси, същият фон в хиляди епизоди. Във версионирано хранилище ситуацията е още по-лоша, защото промяната на един кадър във видео фрагмент от няколко гигабайта качва целия файл отново.

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

Размерът на спестяванията зависи от подредбата на файловете, а записващият модул на Strands Robots използва тази на LeRobot. Епизодите се записват във фрагменти Parquet (data/chunk-000/file-000.parquet) и MP4 фрагменти за всяка камера (videos/observation.images.front/chunk-000/file-000.mp4), като се преминава към нов файл само когато текущият се запълни — при зададените от LeRobot стойности по подразбиране от 100 MB за Parquet с данни и 200 MB за MP4 видео. Така синхронизацията след ден запис качва новите крайни фрагменти плюс частично запълнения фрагмент, който е нараснал, вместо целия набор от данни. Синхронизирайте същия bucket отново утре и Xet ще се погрижи за дедупликацията.

Фигура 2. Синхронизацията качва само промененото. Първата синхронизация на нов набор от данни качва всяка част; след записването на още епизоди разделянето на части според съдържанието в Xet означава, че следващата синхронизация качва само новите части и пропуска вече съхранените.

Стъпка 3 — Обучение чрез поточно четене от Hub

За да обучавате, насочвате графичните процесори към набора от данни. Ако първо го изтеглите, графичните процесори бездействат, докато се копират стотици гигабайти. Поточното четене директно от Hub работи тук благодарение на подредбата на фрагментите от стъпка 2: една партида се превръща в няколко четения на диапазони от байтове върху големи фрагменти, вместо в хиляди малки извличания. StreamingLeRobotDataset на LeRobot превръща това в готов за използване torch iterable, а Strands Robots го предоставя чрез stream_dataset():

Фигура 3. Поточна обработка, а не изтегляне. Пътят на изтеглянето първо копира целия набор от данни на локалния диск, така че графичният процесор чака; stream_dataset() прочита партидите директно от bucket без нищо на локалния диск, така че графичният процесор започва обучение още от първата партида.

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

Buckets поддържат само поточно четене, така че --dataset.repo_type=bucket изисква --dataset.streaming=true, а конфигурацията отхвърля комбинацията в противен случай. Използвайте stream_dataset(), когато искате цикълът да се изпълнява във вашия собствен процес: за проверка на епизод, повторното му възпроизвеждане в симулация или подаването му към персонализиран цикъл за оценяване. При поточно четене само на проприоцептивни данни drop_videos=True изцяло пропуска декодирането на видео, което позволява работа на периферно устройство без wheel пакет за 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 в периферни местоположения близо до облака и региона, където работят задачите ви, така че клъстерът ви чете локално, а dataloader-ът остава пред графичния процесор. В собствените бенчмаркове за buckets на Hugging Face четенето от затоплената мрежа за доставка на съдържание (CDN) достига около 1 086 MB/s при полезен товар от 10 GB спрямо 780 MB/s при студен кеш и приблизително 1 124 MB/s при затоплен кеш и 100 GB, измерено на m5dn.24xlarge в us-east-1. Пълното сравнение с обикновено обектно хранилище — както за качване, така и за изтегляне — е на това табло. Изборът къде да се съхраняват тези данни е настройка Storage Regions при плановете Team и Enterprise — към момента US и EU, като регионите Asia-Pacific и Gulf Cooperation Council (GCC) са обявени като предстоящи; извън тези планове хранилищата се съхраняват в US.

В 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("Pick up the red cube.")

Контролната точка се изпълнява върху физическия манипулатор, а демонстрациите, които той записва, се съхраняват на диска в същия формат 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, ще синхронизирате само променените байтове и ще поточно предавате тези байтове към графичните процесори, без да чакате изтегляне. Данните никога не напускат формата LeRobot и никога не напускат Hub.

Изпробвайте го чрез примерното приложение

Пълният пример за Strands Robots се намира в GitHub на strands-labs/robots, в examples/notebooks/05_streaming_data_loop.ipynb. Той ви превежда през целия цикъл клетка по клетка: запис, визуализация, синхронизация в bucket, поточно четене обратно, обучение и зареждане на контролната точка. Всяка клетка работи в симулация с фиктивната политика, така че не са необходими графичен процесор, 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}". За обучение на графичен процесор увеличете steps до 500 и задайте device="cuda". Версията на същия цикъл, управлявана от агент, се намира в examples/06_agent_collect_and_stream.py.

Съображения за сигурността

Фрагментите тук са „hello world“ на цикъла от данни на Strands Robots. Пет неща се променят, когато го изпълнявате с реални данни.

• Инжектиране на подкана. Подаването на ненадеждни данни към агент може да доведе до инжектиране на подкана, при което ненадежден контекст се приема за инструкции на LLM. Тези агенти управляват роботи и вече записват и четат от споделено хранилище, така че това е важен риск, който трябва да следите. Подавaйте на агента само данни от надеждни източници. Ако не всички входове могат да бъдат надеждни, ограничете наличните за агента инструменти, така че той да не може да извършва критични за безопасността действия или да презаписва съдържанието на bucket.

• Данните за обучение са граница на доверие. Агент, който може да записва в bucket-а за събиране, може също да записва епизоди, върху които по-късно се обучава политика, а тази политика управлява физически манипулатор. Дръжте идентификационните данни за запис на данни от събирането отделно от тези, с които задачата за обучение чете; синхронизирайте всяко изпълнение със собствен run_id, за да може епизодът да бъде проследен до изпълнението, което го е създало, и да бъде премахнат самостоятелно; и приемайте версионираното хранилище на набори от данни за прегледан артефакт, защото bucket не запазва ревизии за одит.

• Идентификационни данни и обхват на bucket. sync_dataset_to_bucket(...), stop_recording(bucket=...) и sync_to_bucket качват чрез CLI инструмента hf, използвайки токена от hf auth login. Използвайте токен с обхват до конкретното пространство от имена, в което записвате, предпочитайте --private buckets за данни от събирането и дръжте 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

Спрете всеки процес за обучение, който все още работи на инстанция с графичен процесор, и спрете самата инстанция. Ако сте изпълнявали notebook-а, заменете cube_pick с неговия RUN_ID (nb5_demo по подразбиране). Всичко, което сте публикували чрез push_to_hub(), се намира във версионирано хранилище и не е засегнато.

Как да продължите

Документацията на Strands Robots разглежда подробно каталога на роботите, симулацията, доставчиците на политики, записването и мрежата. Ръководството за запис и набори от данни документира изцяло API на DatasetRecorder, sync_dataset_to_bucket / sync_to_bucket и stream_dataset.

Ако събирате данни от повече от един робот, дайте на всеки собствен run_id и те ще записват паралелно в един и същ bucket. Мрежата за множество роботи разпределя един агент между тези роботи, така че същият цикъл се превръща във флотилия, която събира данни през деня в споделено хранилище. Поточният reader чете по едно изпълнение наведнъж. Ръководството за запис и набори от данни описва как да обучавате върху няколко от тях.

Ако искате по-голяма политика от ACT, жизненият цикъл TrainSpec и Trainer от стъпка 3 обхваща GR00T и Cosmos 3 чрез собствените им имена на доставчици, така че дообучаването на VLA върху току-що поточно прочетения набор от данни използва същите извиквания с различен низ за доставчик и базов модел. Изпълнението на резултата е мястото, където пътищата се разделят, защото VLA контролната точка се внедрява в хардуера, а не в симулатора, от който сте обучавали. За по-тежка симулация за генериране на тези данни бекендите Newton (sim-newton) и Isaac Sim (isaac) стоят зад същата фабрика Robot(), така че кодът на агента не се променя с увеличаването на мащаба.

Поточната работа с buckets достигна LeRobot чрез приноса както на екипите на Strands Robots, така и на LeRobot — директно в самия LeRobot, така че наборите от данни, които агентът ви събира, могат да се четат от всеки инструмент в тази екосистема. Това работи и в двете посоки: reader-ът от стъпка 3 отваря всеки от вече публикуваните в Hub набори от данни на LeRobot, така че агентът може да възпроизвежда и оценява съществуващи демонстрации, преди да запише собствена.

Приносите са добре дошли съгласно Apache 2.0. Ако изградите нещо с този цикъл, отворете issue с описание на работещото и неработещото.

Ресурси