Hogyan képezzük a GR00T N1.7-et saját SO-100 adatkészletünkön

Az NVIDIA szállít egy finomhangolási példát pontosan ahhoz a karhoz, amellyel valószínűleg rendelkezik. Az Isaac-GR00T tárolóban található egy mappa, melynek neve demo_data/cube_to_bowl_5: öt epizód, 4148 képkocka 30 fps sebességgel, már LeRobot v2.1 formátumban írva, hozzáillő modalitás konfigurációval a examples/SO100/ alatt. A meta/info.json a következőket jelenti: robot_type: so101_follower, ami a LeRobotban ugyanaz a konfigurációs osztály, mint a so100_follower. Ez valóban hasznos, mert azt jelenti, hogy a referenciaútvonal a GR00T N1.7 egy hat-szabadságfokú hobbi karhoz a modellt írók tartják karban. Ez nem egy lekicsinyített humanoid demó, hanem ugyanaz a kar.

A rossz hír az, hogy mekkora a távolság a 60 epizódot rögzítettem és a a kar elvégzi a feladatot között. Körülbelül hat helyen hibázik ez a pipeline csendesen, nem pedig hangosan, és ezek közül négy olyan fájlban található, amelyet a legtöbb ember soha nem nyit meg: meta/modality.json, a Python adatkonfiguráció, meta/relative_stats.json, valamint az adatkészlet saját verziószáma. Ez az útmutató végigvezeti a manuális útvonalon a valós parancsokkal, majd bemutatja ugyanezt a feladatot űrlapként a AY-Robots platformon. Az alábbiak mindegyike ellenőrizve lett az Isaac-GR00T fő ágával szemben 2026. augusztus 20-án (az n1.7-kiadási vonal), valamint a lerobot 0.6.1-gyel, amelyet 2026. augusztus 3-án tettek közzé a PyPI-n. Az upstream gyorsan változik, és ahol egy flag átnevezésre került, ott ez a cikk jelzi.

Mi is valójában a GR00T N1.7

A GR00T N1.7 egy látás-nyelv-akció modell, amely az eredeti GR00T N1 tanulmányban leírt kettős rendszerű elrendezést használja: egy látás-nyelv modult, amely beolvassa a kamerákat és az utasítást, valamint egy diffúziós transzformert, amely ezt folyamatos motorparancsokká alakítja. Az N1.7 az első felét cserélte le. Az N1.6-ból származó Eagle gerinc eltűnt, helyette nvidia/Cosmos-Reason2-2B egy Qwen3-VL architektúrán, és a modellt nagyjából 20 000 órányi egocentrikus emberi videón előképezték a robotadatok mellett. Az NVIDIA saját leírása 20 854 órára teszi az adatot, és arról számol be, hogy 1k-ról 20k órára növelve az átlagos feladatvégzés több mint kétszeresére nő.

A második fele is megváltozott, olyan módon, ami fontos a futtatás szempontjából. Az akciófej 32 diffúziós rétegről 16-ra csökkent, az előre jelzett akciócsomag 16 lépésről 40-re nőtt, és a maximális állapot- és akciószélesség 29-ről 132-re emelkedett. Ez a három szám a tároló README-jében található változásnaplóból származik; az NVIDIA saját bejelentő posztja továbbra is 32 rétegű DiT-ként írja le az 1. rendszert, így ahol a kettő eltér, bízzon abban a tárolóban, amelyet klónozni készül. Az akciók alapértelmezés szerint relatív végrehajtó térben vannak kifejezve, az aktuális pózból származó deltaként, nem pedig abszolút célpontokként, ami lehetővé teszi, hogy az emberi videókból tanult manipulációs előismeretek egyáltalán átkerüljenek a robotvezérlésbe. Maga a fej egy áramlás-illesztő diffúziós transzformer, ugyanaz a család, mint a Pi0.5, de más gerinccel előtte. Ha még az előző generációnál tart, a N1.7 az N1.5 ellen tárgyalja, hogy a frissítés indokolja-e a pipeline újbóli elkészítését.

Az utolsó három sor magyarázza az emberek által jelentett csalódások nagy részét. A címlapon szereplő 27.9 ms egy TensorRT motor egy H100-on, egy kamerával és négy zajcsökkentő lépéssel. Az egyszerű PyTorch ugyanazon a kártyán 85.8 ms, és a modellkártya 3.08x-es különbséget jelez. Egyik szám sem tartalmazza a kiszolgáló réteget, egy második kamerát vagy egy hálózati ugrást. Az AY-Robots által a szolgáltatott GR00T N1.7-hez idézett 152 ms akció lépésenként az a szám, amely a kiszolgálást is tartalmazza, és ehhez jön még egy nyilvános internetes oda-vissza út. Erről bővebben a végén. Más modellek melletti számokhoz, GR00T N1.7 a Pi0.5 ellen és GR00T N1.7 a SmolVLA ellen egymás mellé helyezi őket.

Amire a futtatásnak szüksége van, mielőtt bármit beírna

0. lépés: maguk az epizódok

Minden alábbi feltételezés szerint már rögzített epizódokkal rendelkezik. Ha nem, az az igazi első lépés, és ez dönti el, milyen jó lehet az eredmény, mert utánzásos tanulás nem tudja visszanyerni az adatban nem szereplő információkat. Először kalibrálja mindkét kart, majd vezesse a követő kart egy vezető karral miközben lerobot-record írja a parquet fájlokat és a kamera streameket. Ha a kalibráció pontatlan, az adatkészletében lévő ízületi értékek kissé eltérő robotot írnak le, mint az, amelyik később végrehajtja a házirendet, és ezt semmilyen mennyiségű képzés nem orvosolja.

lerobot-record \
    --robot.type=so100_follower \
    --robot.port=/dev/ttyACM0 \
    --robot.id=my_follower_arm \
    --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30}}" \
    --teleop.type=so100_leader \
    --teleop.port=/dev/ttyACM1 \
    --teleop.id=my_leader_arm \
    --dataset.repo_id=${HF_USER}/cube-into-bowl \
    --dataset.num_episodes=60 \
    --dataset.single_task="put the cube in the yellow bowl" \
    --display_data=true

A LeRobot saját tanácsa szerint legalább 50 epizódot kell rögzíteni, körülbelül 10-et tárgyhelyenként, a kamerákat rögzítve kell tartani, és a megfogási viselkedést konzisztensen kell tartani. A variációkat később, ne az elején adja hozzá. Az emlékezetes ökölszabály: ha Ön sem tudta volna elvégezni a feladatot pusztán a kamera képei alapján, akkor a házirend sem tudja. A kar-specifikus beállításhoz a SO-100 első lépések és a SO-100 LeRobot oldal tárgyalja a portokat, a kalibrációt és a kamera indexeket. Az AY-Robots rendszereken ezt az interneten keresztül is megteheti a böngészőből, a távvezérlés segítségével, és közvetlenül a munkamenetből rögzíthet.

1. lépés: az adathalmaznak LeRobot v2.1 formátumúnak kell lennie

Ez a leggyakoribb akadály. A LeRobot aktuális CODEBASE_VERSION a fő ágon v3.0, így bármi, amit ma egy aktuális eszközkészlettel rögzít, v3.0-ként jelenik meg. A GR00T betöltője v2-t vár. Az adattár egyértelműen megmagyarázza, miért: számos upstream adathalmaz, mint például a DROID, LIBERO és Bridge, v2-ben van közzétéve, és mindkettő natív támogatása tervezett, de még nem került kiadásra. Tehát az átalakítás az Ön feladata, és egy konkrét okból kifolyólag saját virtualenv-ben fut: scripts/lerobot_conversion saját pyproject-et tartalmaz, amely Python 3.10 vagy 3.11-et igényel, és a lerobot-ot egy adott git commit-hoz rögzíti, míg maga az Isaac-GR00T Python 3.12-t igényel. Telepítse az átalakítót az adattár gyökeréből, és a gr00t csomagot kapja helyette, ami az a hiba, amire a README figyelmeztet. Ha még új a formátumban, a LeRobot adathalmaz szószedet bejegyzés elmagyarázza, mi is van valójában benne.

# from the Isaac-GR00T repo root
cd scripts/lerobot_conversion
uv venv
source .venv/bin/activate
uv pip install -e . --verbose

# pulls the dataset from the Hub and writes a v2.1 copy into the default cache
python convert_v3_to_v2.py --repo-id <your-hf-user>/<your-dataset>

# or, back in the repo root, keep it next to the SO-100 example
uv run --project scripts/lerobot_conversion \
  python scripts/lerobot_conversion/convert_v3_to_v2.py \
  --repo-id <your-hf-user>/<your-dataset> \
  --root examples/SO100/my_dataset_lerobot

A GR00T által konverzió után elvárt struktúra a klasszikus v2 elrendezés: meta/info.json, meta/episodes.jsonl, meta/tasks.jsonl, parquet fájlok a data/chunk-000/ alatt, MP4 fájlok a videos/chunk-000/observation.images./ alatt, és egy extra fájl, amivel a standard LeRobot nem rendelkezik. Ez az extra fájl az, ahol a fennmaradó hibák nagy része található.

2. lépés: modality.json, a hat szám, ami mindent eldönt

Egy LeRobot adatkészletben a robot állapota és az akció lapos float32 tömbökként vannak tárolva. Egy SO-100 esetében mindkettő alakja [6]: öt karízület és egy megfogó. A demó adatkészlet a következőképpen nevezi el őket: shoulder_pan.pos, shoulder_lift.pos, elbow_flex.pos, wrist_flex.pos, wrist_roll.pos, gripper.pos, de ezek a nevek az info.json fájlban találhatók, és a parquet fájlban semmi sem jelzi, hogy melyik index melyik. A meta/modality.json biztosítja ezt a leképezést, és a GR00T enélkül nem fog betanulni. Íme az, amit a tároló szállít az SO-100-hoz, szó szerint.

{
  "state": {
    "single_arm": {
      "start": 0,
      "end": 5
    },
    "gripper": {
      "start": 5,
      "end": 6
    }
  },
  "action": {
    "single_arm": {
      "start": 0,
      "end": 5
    },
    "gripper": {
      "start": 5,
      "end": 6
    }
  },
  "video": {
    "front": {
      "original_key": "observation.images.front"
    },
    "wrist": {
      "original_key": "observation.images.wrist"
    }
  },
  "annotation": {
    "human.task_description": {
      "original_key": "task_index"
    }
  }
}

Másolja be az átalakított adathalmazba a meta/modality.json és nevezze át a videó kulcsokat arra, ahogyan a kamerái valójában hívják őket. Ha egyetlen, felülről elhelyezett kamerával rögzített, melynek neve top, akkor original_key az observation.images.top és a felhasználóbarát név az, amire az adatkonfigurációja hivatkozni fog. A kettőnek egyeznie kell, és egyik sem ellenőrzi a másikat Ön helyett. A nyelvi annotáció rosszabb, mert ugyanannak a kulcsnak három helyen kell megjelennie.

3. lépés: az adatkonfiguráció, relatív kar és abszolút megfogó

A modalitás konfiguráció egy Python fájl JSON helyett, mert az is eldönti, hogyan reprezentálódik minden egyes akciócsoport. Ez az N1.7 munkafolyamat azon része, amely N1.5-ben nem létezett ugyanebben a formában, és az a rész, amit érdemes kétszer is elolvasni. A szállított SO-100 konfiguráció az öt karízületet RELATIVE deltákként prediktálja az aktuális állapotból, a megfogót pedig ABSOLUTE célpozícióként, mert egy bináris nyitott-vagy-zárt jel jobban viselkedik célként, mint deltájaként.

from gr00t.configs.data.embodiment_configs import register_modality_config
from gr00t.data.embodiment_tags import EmbodimentTag
from gr00t.data.types import (
    ActionConfig, ActionFormat, ActionRepresentation, ActionType, ModalityConfig,
)

so100_config = {
    "video": ModalityConfig(
        delta_indices=[0],                       # current frame only
        modality_keys=["front", "wrist"],        # must match modality.json
    ),
    "state": ModalityConfig(
        delta_indices=[0],
        modality_keys=["single_arm", "gripper"],
    ),
    "action": ModalityConfig(
        delta_indices=list(range(0, 16)),        # predict 16 future steps
        modality_keys=["single_arm", "gripper"],
        action_configs=[
            ActionConfig(rep=ActionRepresentation.RELATIVE,   # arm joints
                         type=ActionType.NON_EEF,
                         format=ActionFormat.DEFAULT),
            ActionConfig(rep=ActionRepresentation.ABSOLUTE,   # gripper
                         type=ActionType.NON_EEF,
                         format=ActionFormat.DEFAULT),
        ],
    ),
    "language": ModalityConfig(
        delta_indices=[0],
        modality_keys=["annotation.human.task_description"],
    ),
}

register_modality_config(so100_config, embodiment_tag=EmbodimentTag.NEW_EMBODIMENT)

Két részlet, ami egy napodba kerülhet, ha nem tudod őket. Először is, az action_configs pozicionális: a dokumentáció ugyanazt a hosszt és sorrendet írja elő, mint a modality_keys, és nyersen fogalmaznak a hibás beállítás következményeiről, miszerint a rossz reprezentáció csendben alkalmazódik. A megfogód deltájaként, a karod pedig abszolút célként lesz betanítva, és nincs hibaüzenet. Másodszor, a register_modality_config ellenőrzi, hogy a címke még nincs regisztrálva, így egy második NEW_EMBODIMENT konfiguráció ugyanabban a Python folyamatban leáll a következő üzenettel: Embodiment tag ... already registered. Nem importálhatsz kettőt ezek közül egy szkriptbe. Egy harmadik szabályt később, a telepítéskor érvényesítenek: az akció delta_indices mezőjének nullától kezdődő, összefüggő tartománynak kell lennie. Egy ritka ablak, mint például a [0, 4, 8], elutasításra kerül, mert minden downstream elem lineárisan indexeli az előrejelzett darabot, és egyébként rossz sorokat hajtana végre.

4. lépés: a környezet

Az N1.7 áthelyezte a tárolót ide: és Python 3.12. A régi conda plus pip install -e . útvonal még létezik a README egy összecsukott szakaszában, de figyelmeztet, hogy a GPU függőségek, beleértve a flash-attn-t és a TensorRT-t, manuális telepítést igényelhetnek. Használja az uv-t, hacsak nincs különleges oka ennek elkerülésére. A flash-attn-nel kapcsolatban egy részlet elkerüli a zavart: látni fogja, hogy Installing flash-attn kiírva minden uv run. Nem épül újra. Az uv újraérvényesíti egy URL-hez rögzített, már gyorsítótárazott wheel-t, és ez két-három másodpercet vesz igénybe.

1. 1
   Telepítse a git-lfs-t, majd klónozza az almodulokkal

   A git-lfs kötelező, nem opcionális. Enélkül a demo_data/ mappában lévő parquet fájlok mutató csonkokként töltődnek le, és a demó futtatása meghiúsul egy olyan adathalmazon, amely a fájllistában jelenlévőnek tűnik.

   bash

   sudo apt install git-lfs && git lfs install
   git clone --recurse-submodules https://github.com/NVIDIA/Isaac-GR00T
   cd Isaac-GR00T

2. 2
   Telepítse az uv-t és szinkronizálja a környezetet

   Az alapértelmezett telepítés letölti a GPU függőségeket, beleértve a flash-attn-t és a TensorRT-t. Egy friss A100 vagy H100 image-en ez a leghosszabb lépés, ezért végezze el, mielőtt bármi másra figyelne.

   bash

   curl -LsSf https://astral.sh/uv/install.sh | sh
   sudo apt-get update && sudo apt-get install -y ffmpeg
   uv sync --python 3.12
   uv run python -c "import gr00t; print('GR00T installed successfully')"

3. 3
   Hitelesítés a Hugging Face-szel

   Ezt az első tréning indítása előtt tegye meg, ne azután, hogy nyolc perc után meghiúsul.

   bash

   uv run huggingface-cli login   # or: export HF_TOKEN=<your_token>

4. 4
   Egészségügyi ellenőrzés a mellékelt SO-100 demó adatokon

   Mielőtt hozzányúlna a saját felvételéhez, futtasson 2000 lépést a demo_data/cube_to_bowl_5 adathalmazon. Ez öt epizódot jelent, gyorsan befejeződik, és a környezetet igazolja, nem az adatait. Ha ez a futtatás meghiúsul, semmi, amit az adathalmazával tesz, nem fog segíteni.

   bash

   CUDA_VISIBLE_DEVICES=0 uv run python \
       gr00t/experiment/launch_finetune.py \
       --base-model-path nvidia/GR00T-N1.7-3B \
       --dataset-path demo_data/cube_to_bowl_5 \
       --embodiment-tag NEW_EMBODIMENT \
       --modality-config-path examples/SO100/so100_config.py \
       --num-gpus 1 \
       --output-dir /tmp/test_finetune \
       --max-steps 2000 \
       --global-batch-size 32 \
       --dataloader-num-workers 4

5. lépés: a finomhangolási parancs és a jelzőinek tényleges alapértelmezett értékei

Cserélje le a demó adatkészletet a sajátjára, és adja hozzá a kívánt beállításokat. Alább látható a teljes forma, amelyet a tároló használ a saját új-megtestesülési oktatóanyagában, beleértve az augmentációs és ellenőrzőpont-jelzőket, amelyeket a rövid README példa kihagy. Ez a szűkebb értelemben: a nyelvi gerinc és a vizuális kódoló befagyasztva marad, és ami edzésre kerül, az a projektor és a diffúziós akciófej.

export NUM_GPUS=1
CUDA_VISIBLE_DEVICES=0 uv run python \
    gr00t/experiment/launch_finetune.py \
    --base-model-path nvidia/GR00T-N1.7-3B \
    --dataset-path ./my_dataset_lerobot \
    --embodiment-tag NEW_EMBODIMENT \
    --modality-config-path examples/SO100/so100_config.py \
    --num-gpus $NUM_GPUS \
    --output-dir /tmp/so100 \
    --save-total-limit 5 \
    --save-steps 2000 \
    --max-steps 20000 \
    --use-wandb \
    --global-batch-size 32 \
    --color-jitter-params brightness 0.3 contrast 0.4 saturation 0.5 hue 0.08 \
    --dataloader-num-workers 4

Az utolsó sor nem elírás. launch_finetune.py egy tyro CLI, amelyet egy adatosztályból generáltak, és ez az adatosztály nem tartalmaz seed mezőt. A README külön megjegyzi, hogy a futtatások között 5-6 százalékos eltérés tapasztalható a nem determinisztikus képaugmentáció miatt. Két, azonos flaggel futtatott folyamat nem fog azonos ellenőrzőpontokat eredményezni, ami nagyon fontos, amikor azt próbálja eldönteni, hogy egy hiperparaméter-változtatás segített-e, vagy csak szerencséje volt. Összehasonlításképpen, a lerobot saját trénere alapértelmezetten 1000-es seedet használ, és a LeRobot GR00T receptje expliciten átadja a --seed=42 értéket.

Mennyibe kerül egy 20000 lépéses futtatás

A GR00T N1.7-nek 80 GB-os kártyára van szüksége, így a költségkérdésre szűk a válasz. Az AY-Robots platformon a groot1.7 tréner az A100 80 GB vagy H100 80 GB szinten fut, ahol egy futtatás 3-6 órát vesz igénybe, óránként 1.20-2.00 USD áron a spot piacon. Ez nagyjából 4-12 USD a 20000 lépéses alapértelmezett feladatra. Ugyanez a feladat a SmolVLA vagy ACT egy 24 GB-os kártyán fut, óránként 0.30-0.60 USD áron, és 1-3 USD futtatásonként. Ez az igazi kompromisszum: a GR00T körülbelül négyszer annyiba kerül kísérletenként, és nem futtathatja az asztala alatt lévő 4090-en.

Az 50-epizód minimum egy alsó határ, nem cél. Az NVIDIA saját GYIK-je igényesebb: nagyjából 100 trajektória egy egyszerű, rögzített helyű felvételhez és elhelyezéshez, 500 vagy több komplex vagy többlépéses jelenetekhez, és 100-500 finom manipulációhoz. Ha 20 epizódnál tart, inkább délután rögzítsen, mint este hangoljon. A adatgyűjtési útmutató lefedi, mi különbözteti meg a hasznos epizódot az elpazarolttól, rögzítse első adatkészletét a rövid változat, és SO-100 adatgyűjtés a kar-specifikus.

6. lépés: nyílt hurkú kiértékelés, mielőtt hozzáérne a karhoz

Ne tegyen friss ellenőrzőpontot egy fizikai karra, hogy megtudja, működött-e a tréning. Először futtassa az open-loop kiértékelést. Ez visszajátssza egy rögzített epizódot, minden lépésnél akciókat kér a modelltől, és ábrázolja az előrejelzést a valósággal szemben MSE és MAE értékekkel. Semmibe sem kerül, és elkapja a 2. és 3. lépésből származó leképezési hibákat.

uv run python gr00t/eval/open_loop_eval.py \
    --dataset-path ./my_dataset_lerobot \
    --embodiment-tag NEW_EMBODIMENT \
    --model-path /tmp/so100/checkpoint-20000 \
    --traj-ids 0 \
    --execution-horizon 16 \
    --steps 400 \
    --modality-keys single_arm gripper

A tároló szándékosan nem tesz közzé cél MSE értéket egyedi adatokhoz, és ez a helyes döntés: a szám az akcióegységektől, a feladattól és az adathalmaz méretétől függ, így egy más karjáról másolt küszöbérték semmit sem jelent. Ami értelmes, az a trend. Itt van a referencia futtatás, amelyet a tároló dokumentál egyetlen H100-on az ötepizódos demo adathalmazzal és 2000 lépéssel.

Az alak a jel, nem az abszolút értékek. A hiba egyenletesen csökkenjen, ahogy képzési lépések halmozódnak. Az összes öt képzési epizód átlagában, nem csak a 0. trajektória alapján, a tároló utolsó ellenőrzőpontja körülbelül 7.5 MSE és 1.5 MAE pontszámot ért el, így még a referencia futás is eltérően olvasható attól függően, hogy mely epizódokat átlagolja. Rögzítse saját alapvonalát a módosítatlan demo paranccsal, mielőtt bármit is változtatna a saját adataival kapcsolatban: ha nem tud reprodukálni egy ismert, jól működő futtatást, akkor nem tudja megkülönböztetni a beállítási hibát az adatproblémától. A tároló a gyakori tüneteket is okokhoz rendeli, és mindegyikük működési, nem pedig modellhiba.

A másik út: lerobot-train Isaac-GR00T helyett

A LeRobot jelenlegi kiadása, a 0.6.1 a PyPI-n 2026. augusztus 3. óta, egy második és egészen más módot kínál ugyanazoknak az alap súlyoknak a finomhangolására. A LeRobot a GR00T N1.7-et házirend típusként teszi elérhetővé, és a saját lerobot-train belépési pontján keresztül képzi. Két dolog fontos itt. A LeRobot CLI konzol szkriptek halmaza, így bármi, amit olvas, és azt mondja, hogy python lerobot/scripts/train.py elavult és nem fog futni. A LeRobot teljesen eltávolította a GR00T N1.5 támogatását, elutasítva az N1.5 ellenőrzőpontokat és konfigurációkat egy migrációs megjegyzéssel, így ha N1.5-re van szüksége a LeRoboton keresztül, akkor rögzítenie kell a lerobot==0.5.1, az utolsó kiadást, amely támogatja, 2026. április 7-én jelent meg.

pip install "lerobot[groot]" "lerobot[training]"
hf auth login

lerobot-train \
  --dataset.repo_id=$HF_USER/$DATASET_NAME \
  --dataset.image_transforms.enable=true \
  --policy.type=groot \
  --policy.device=cuda \
  --policy.base_model_path=nvidia/GR00T-N1.7-3B \
  --policy.embodiment_tag=new_embodiment \
  --policy.chunk_size=16 \
  --policy.n_action_steps=16 \
  --policy.use_relative_actions=true \
  --policy.relative_exclude_joints='["gripper"]' \
  --policy.use_bf16=true \
  --seed=42 \
  --batch_size=64 \
  --steps=20000 \
  --save_freq=5000 \
  --output_dir=$OUTPUT_DIR

Két módja ugyanazon checkpoint elérésének

Az ellenőrzőpont visszahelyezése a karra

Az Isaac-GR00T szerver-kliens felosztást használ ZMQ-n keresztül. A szabályzat a GPU-n fut, és egy vékony kliens a robotgépen megfigyeléseket küld és akció darabokat fogad. Az SO-100 példa elég teljes ahhoz, hogy lemásolható legyen: indítsd el a run_gr00t_server.py fájlt az ellenőrzőpontoddal és a --embodiment-tag NEW_EMBODIMENT flaggel, majd futtasd az eval_so100.py fájlt a robot oldalon a soros porttal, a robot azonosítóval, a kamera indexekkel és a nyelvi utasítással. A kamera neveknek ebben a parancsban meg kell egyezniük a modality.json fájlban szereplő barátságos nevekkel, nem az operációs rendszer eszközszámaival.

# GPU side
uv run python gr00t/eval/run_gr00t_server.py \
  --model-path /tmp/so100/checkpoint-20000 \
  --embodiment-tag NEW_EMBODIMENT \
  --device cuda:0 \
  --host 0.0.0.0 --port 5555

# robot side, from gr00t/eval/real_robot/SO100
uv run --no-sync python eval_so100.py \
  --robot.type=so101_follower \
  --robot.port=/dev/ttyACM2 \
  --robot.id=orange_follower \
  --robot.cameras="{ front: {type: opencv, index_or_path: 6, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30}}" \
  --policy_host=localhost --policy_port=5555 \
  --lang_instruction="put the cube in the yellow bowl"

Most jöjjön az őszinte rész arról, hogy hol fut a policy, mert a képzésnek és a kiszolgálásnak eltérő hardverigényei vannak. A finomhangoláshoz 40 GB vagy több szükséges. Az inferenciához nem: a README 16 GB-ot vagy többet említ, és kifejezetten megnevezi az RTX 4090-et, így egy már meglévő kártya is képes kiszolgálni egy olyan checkpointot, amelyet soha nem tudott volna előállítani. Azt, hogy a policy mennyire érződik reszponzívnak, nem a VRAM dönti el, hanem az, hogy hol található a szerver. Az AY-Robots GR00T N1.7 csak felhőben érhető el, így a vezérlőhurok a műveleti lépésenkénti 152 ms-on felül egy nyilvános internetes oda-vissza utat is fizet, és csak SmolVLA és ACT is fut helyben. Lassú pick and place feladatokhoz egy távoli pod túlélhető. Bármilyen reaktív feladathoz azonban nem az: a policy tétovázóvá válik, ami pontosan úgy néz ki, mint egy képzési hiba, pedig nem az. Az ACT 20 ms-os műveleti lépésenkénti sebességgel a legszűkebb hurkot toleráló modell, a SmolVLA 245 ms-nál tart, és semmilyen mértékű késleltetés hangolás nem hozza vissza az már elköltött oda-vissza utat. Futtassa első policy-jét végigvezeti a kiszolgálási oldalon, elejétől a végéig.

Mi romlik el valójában

• GatedRepoError az első futtatáskor. Nem kapott hozzáférést az nvidia/Cosmos-Reason2-2B-hez, vagy nem hitelesítette magát. Ez azután történik, hogy a GPU órajele már elindult.
• Adatkészlet elutasítva betöltéskor. Szinte mindig v3.0 adatkészlet. Konvertálja lefelé. Lásd: v3-ként elutasított adatkészlet.
• IndexError az eltérő logikai dimenziókról. Megváltoztatta a delta_indices-t, és nem generálta újra a statisztikákat.
• Memóriahiány a 32. batch-nél. Csökkentse a --global-batch-size értéket és növelje a --gradient-accumulation-steps értéket, vagy csökkentse a --num-shards-per-epoch értéket, amit a konfiguráció kifejezetten javasol, ha a VRAM korlátozott. Lásd: memóriahiány a képzés során.
• A veszteség csökken, a policy nem csinál semmit. Alapértelmezés szerint nincs validációs felosztás, így egy tiszta képzési görbe nagyon keveset bizonyít. Ez az oldal tárgyalja a diagnózist.
• Csak az Ön beállításában működik, máshol nem. Várható egy kis adatkészlettel, amelyet egyetlen fényviszonyok között rögzítettek. Az NVIDIA színjitter augmentációt, valamint 20-50 epizódot javasol különböző megvilágítások mellett. További információ itt.
• A gripper soha nem záródik be megfelelően. Ellenőrizze, hogy a gripper művelet ABSOLUTE, és a kar ízületei RELATIVE értékűek, ebben a sorrendben az action_configs-ban. A gripper nem záródik be felsorolja a többi okot.
• Egy kamera csendben kiesik a felvétel közben. Az epizód továbbra is mentésre kerül, és a videókulcs is létezik, ezért ez különösen kellemetlen. Kamera nem észlelhető tárgyalja.

A hibamódok teljes indexe itt található: . Ha modellek közül választ, ahelyett, hogy egyet hibakeresne, és tartalmaz benchmark számokat mellékelt forrásokkal, és az az összehasonlítás, amire a legtöbb embernek szüksége van, mert ez a választás egy olyan modell között, amelyet az asztala alatt lévő kártyán képezhet, és egy olyan között, amelyhez egy 80 GB-os csomópontot kell bérelnie a finomhangoláshoz. Annak hátteréhez, hogy ezek a modellek miért viselkednek úgy, ahogy, a és a érdemes először elolvasni. És ha még nem rendelkezik karral, streamel egy fizikai SO-100-at regisztráció nélkül.