Cum să antrenezi GR00T N1.7 pe propriul tău set de date SO-100

NVIDIA livrează un exemplu de reglaj fin (fine-tuning) pentru exact brațul pe care probabil îl dețineți. În cadrul depozitului Isaac-GR00T există un folder numit demo_data/cube_to_bowl_5: cinci episoade, 4.148 de cadre la 30 fps, deja scrise ca LeRobot v2.1, cu o configurație de modalitate corespunzătoare sub examples/SO100/. Fișierul său meta/info.json raportează robot_type: so101_follower, care în LeRobot este aceeași clasă de configurare ca și so100_follower. Acest lucru este cu adevărat util, deoarece înseamnă că calea de referință pentru GR00T N1.7 pe un braț hobby cu șase grade de libertate este menținută de persoanele care au scris modelul. Nu este o demonstrație umanoidă redusă, este același braț.

Vestea proastă este distanța dintre I recorded 60 episodes și the arm does the task. Există aproximativ șase locuri unde această conductă eșuează în liniște, mai degrabă decât zgomotos, iar patru dintre ele se găsesc în fișiere pe care majoritatea oamenilor nu le deschid niciodată: meta/modality.json, configurația de date Python, meta/relative_stats.json, și șirul de versiune propriu al setului de date. Acest ghid parcurge ruta manuală de la un capăt la altul cu comenzile reale, apoi arată aceeași sarcină ca un formular pe AY-Robots. Tot ce urmează a fost verificat în raport cu ramura principală Isaac-GR00T la data de 20 august 2026 (linia de lansare n1.7) și lerobot 0.6.1, publicat pe PyPI la 3 august 2026. Dezvoltarea este rapidă, iar acolo unde un flag a fost redenumit, acest articol menționează acest lucru.

Ce este de fapt GR00T N1.7

GR00T N1.7 este un model viziune-limbaj-acțiune cu arhitectura dual-sistem descrisă în lucrarea originală GR00T N1: un modul viziune-limbaj care citește camerele și instrucțiunea, și un transformator de difuzie care transformă asta într-o secvență de comenzi motorii continue. N1.7 a înlocuit prima jumătate. Backbone-ul Eagle de la N1.6 a fost eliminat, înlocuit cu nvidia/Cosmos-Reason2-2B pe o arhitectură Qwen3-VL, iar modelul a fost preantrenat pe aproximativ 20.000 de ore de înregistrări video umane egocentrice, pe lângă datele robotului. Propria descriere a NVIDIA indică cifra de 20.854 de ore și raportează că trecerea de la 1k la 20k ore mai mult decât dublează rata medie de finalizare a sarcinilor.

A doua jumătate s-a schimbat și ea, în moduri care contează pentru execuția dumneavoastră. Capul de acțiune a scăzut de la 32 de straturi de difuzie la 16, secvența de acțiuni a crescut de la 16 pași la 40, iar lățimea maximă a stării și acțiunii a trecut de la 29 la 132. Aceste trei numere provin din jurnalul de modificări din README-ul depozitului; propria postare de lansare a NVIDIA descrie în continuare Sistemul 1 ca un DiT cu 32 de straturi, așa că, acolo unde cele două nu sunt de acord, aveți încredere în depozitul pe care sunteți pe cale să-l clonați. Acțiunile sunt exprimate implicit într-un spațiu relativ al efectorului final , delte față de poziția curentă, mai degrabă decât ținte absolute, ceea ce permite transferul priorităților de manipulare învățate din video-uri umane în controlul robotului. Capul în sine este un transformator de difuzie flow-matching , aceeași familie ca Pi0.5, dar cu un backbone diferit în față. Dacă sunteți încă la generația anterioară, N1.7 versus N1.5 acoperă dacă actualizarea justifică refacerea pipeline-ului dumneavoastră.

Ultimele trei rânduri explică cea mai mare parte a dezamăgirii raportate de oameni. Titlul de 27.9 ms reprezintă un motor TensorRT pe un H100 cu o cameră și patru pași de denoising. PyTorch simplu pe aceeași placă este de 85.8 ms, iar fișa modelului indică un decalaj de 3.08x. Niciunul dintre numere nu include un strat de servire, o a doua cameră sau un salt de rețea. Cei 152 ms per pas de acțiune citați de AY-Robots pentru GR00T N1.7 servit este cifra cu servirea în buclă, iar o călătorie dus-întors pe internetul public se adaugă la aceasta. Mai multe despre acest subiect la final. Pentru numerele alături de alte modele, GR00T N1.7 versus Pi0.5 și GR00T N1.7 versus SmolVLA le prezintă una lângă alta.

Ce necesită rularea înainte de a introduce orice

Pasul 0: episoadele în sine

Tot ce urmează presupune că aveți deja episoade înregistrate. Dacă nu, acesta este adevăratul prim pas și este cel care decide cât de bun poate fi rezultatul, deoarece nu poate recupera informații care nu se află în date. Calibrați ambele brațe mai întâi, apoi conduceți brațul urmăritor cu un braț lider în timp ce lerobot-record scrie fișierele parquet și fluxurile camerei. Dacă este incorectă, valorile articulațiilor din setul de date descriu un robot ușor diferit de cel care va executa ulterior politica, și nicio cantitate de antrenament nu poate remedia asta.

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

Recomandarea LeRobot este să înregistrați cel puțin 50 de episoade, cu aproximativ 10 pentru fiecare locație a obiectului, să mențineți camerele fixe și să păstrați un comportament de prindere consistent. Adăugați variații mai târziu, nu la început. Regula generală de reținut: dacă nu ați putea îndeplini sarcina singur doar din imaginile camerei, nici nu poate. Pentru configurarea specifică brațului, și acoperă porturile, calibrarea și indicii camerei. Pe AY-Robots puteți face acest lucru și prin internet din browser folosind și înregistra direct din sesiune.

Pasul 1: setul de date trebuie să fie LeRobot v2.1

Acesta este cel mai frecvent obstacol. Versiunea curentă a CODEBASE_VERSION a LeRobot pe ramura principală este v3.0, deci orice înregistrați astăzi cu un set de instrumente actual va fi v3.0. Încărcătorul GR00T se așteaptă la v2. Depozitul este explicit cu privire la motiv: multe seturi de date upstream, cum ar fi DROID, LIBERO și Bridge, sunt publicate în v2, iar suportul nativ pentru ambele este planificat, dar nu a fost încă livrat. Așadar, conversia vă revine, și rulează în propriul său virtualenv dintr-un motiv concret: scripts/lerobot_conversion conține propriul său pyproject care solicită Python 3.10 sau 3.11 și fixează lerobot la un anumit commit git, în timp ce Isaac-GR00T însuși necesită Python 3.12. Instalați convertorul din rădăcina depozitului și veți obține pachetul gr00t în schimb, ceea ce este greșeala despre care avertizează README-ul său. Dacă sunteți nou în format, intrarea din glosar setul de date LeRobot explică ce se află de fapt în interiorul acestuia.

# 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

Structura pe care GR00T o dorește după conversie este layout-ul clasic v2: meta/info.json, meta/episodes.jsonl, meta/tasks.jsonl, fișiere parquet sub data/chunk-000/, fișiere MP4 sub videos/chunk-000/observation.images./, și un fișier suplimentar pe care LeRobot standard nu îl are. Acel fișier suplimentar este locul unde se găsesc majoritatea eșecurilor rămase.

Pasul 2: modality.json, cele șase numere care decid totul

Într-un set de date LeRobot, starea robotului și acțiunea sunt stocate ca array-uri plate float32. Pentru un SO-100, ambele au forma [6]: cinci articulații ale brațului și un gripper. Setul de date demo le denumește shoulder_pan.pos, shoulder_lift.pos, elbow_flex.pos, wrist_flex.pos, wrist_roll.pos, gripper.pos, dar acele nume se găsesc în info.json și nimic din fișierul parquet nu indică ce index este ce. meta/modality.json furnizează acea mapare, iar GR00T nu se va antrena fără ea. Iată cea pe care o livrează repository-ul pentru SO-100, verbatim.

{
  "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"
    }
  }
}

Copiați-l în setul de date convertit la meta/modality.json și redenumiți cheile video la numele reale ale camerelor dumneavoastră. Dacă ați înregistrat cu o singură cameră de deasupra numită top, atunci original_key este observation.images.top și numele prietenos este cel la care va face referire configurația dumneavoastră de date. Cele două trebuie să se potrivească, și niciuna dintre ele nu o verifică pe cealaltă pentru dumneavoastră. Adnotarea limbajului este mai complicată, deoarece aceeași cheie trebuie să apară în trei locuri.

Pasul 3: configurația datelor, brațul relativ și gripperul absolut

Fișierul de configurare a modalității este un fișier Python, nu JSON, deoarece decide și modul în care este reprezentat fiecare grup de acțiuni. Aceasta este partea fluxului de lucru N1.7 care nu a existat în aceeași formă în N1.5 și partea care merită citită de două ori. Configurația SO-100 livrată prezice cele cinci articulații ale brațului ca delte relative față de starea curentă și prehensorul ca o poziție țintă absolută, deoarece un semnal binar deschis-sau-închis se comportă mai bine ca o țintă decât ca o deltă.

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)

Două detalii aici te vor costa o zi dacă nu le cunoști. În primul rând, action_configs este pozițional: documentația cere aceeași lungime și aceeași ordine ca modality_keys, și este directă în privința consecinței unei greșeli, și anume că reprezentarea greșită este aplicată în mod silențios. Prehensorul tău este antrenat ca o deltă și brațul tău ca o țintă absolută, și nu există niciun mesaj de eroare. În al doilea rând, register_modality_config afirmă că eticheta nu este deja înregistrată, astfel încât o a doua configurație NEW_EMBODIMENT în același proces Python eșuează cu Embodiment tag ... already registered. Nu poți importa două dintre acestea într-un singur script. O a treia regulă este aplicată ulterior, la implementare: delta_indices pentru acțiune trebuie să fie un interval contiguu începând de la zero. O fereastră rară, cum ar fi [0, 4, 8], este respinsă, deoarece tot ce urmează indexează liniar segmentul prezis și altfel ar executa rândurile greșite.

Pasul 4: mediul

N1.7 a mutat depozitul la și Python 3.12. Vechea cale conda plus pip install -e . încă există într-o secțiune restrânsă a fișierului README, dar avertizează că dependențele GPU, inclusiv flash-attn și TensorRT, ar putea necesita instalare manuală. Utilizați uv, cu excepția cazului în care aveți un motiv specific să nu o faceți. În ceea ce privește flash-attn, un detaliu evită confuzia: veți vedea Installing flash-attn afișat la fiecare uv run. Nu se reconstruiește. uv re-validează o roată fixată prin URL care este deja în cache și durează două sau trei secunde.

1. 1
   Instalați git-lfs, apoi clonați cu submoduluri

   git-lfs este necesar, nu opțional. Fără el, fișierele parquet din demo_data/ sunt descărcate ca stub-uri de pointer, iar rularea demo-ului eșuează pe un set de date care pare prezent în lista de fișiere.

   bash

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

2. 2
   Instalați uv și sincronizați mediul

   Instalarea implicită descarcă dependențele GPU, inclusiv flash-attn și TensorRT. Pe o imagine proaspătă A100 sau H100, acesta este cel mai lung pas, așa că faceți-l înainte de a acorda atenție oricărui altceva.

   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
   Autentificați-vă la Hugging Face

   Faceți acest lucru înainte de prima lansare a antrenamentului, nu după ce eșuează după opt minute.

   bash

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

4. 4
   Verificare de bază pe datele demo SO-100 livrate

   Înainte de a utiliza propria înregistrare, rulați 2000 de pași pe demo_data/cube_to_bowl_5. Sunt cinci episoade, se termină rapid și validează mediul, nu datele dumneavoastră. Dacă această rulare eșuează, nimic din ceea ce faceți cu setul dumneavoastră de date nu va ajuta.

   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

Pasul 5: comanda de fine-tuning și valorile implicite reale ale flag-urilor sale

Înlocuiți setul de date demo cu al dumneavoastră și adăugați parametrii pe care îi doriți cu adevărat. Mai jos este forma completă pe care o folosește depozitul în propriul său tutorial de nou-încarnare, incluzând flag-urile de augmentare și checkpointing pe care exemplul scurt din README le omite. Acesta este în sens restrâns: coloana vertebrală lingvistică și codificatorul vizual rămân înghețate, iar ceea ce se antrenează este proiectorul și capul de acțiune de difuzie.

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

Ultimul rând nu este o greșeală de tipar. launch_finetune.py este un CLI tyro generat dintr-o clasă de date, iar acea clasă de date nu are un câmp pentru seed. README-ul menționează separat o variație de 5 până la 6 procente între rulări, cauzată de augmentarea nedeterministică a imaginilor. Două rulări cu flag-uri identice nu vor produce checkpoint-uri identice, ceea ce contează mult atunci când încerci să decizi dacă o modificare a hiperparametrilor a ajutat sau dacă ai avut noroc. Pentru comparație, propriul antrenor al lerobot folosește implicit seed 1000, iar rețeta LeRobot GR00T transmite --seed=42 în mod explicit.

Cât costă o rulare de 20000 de pași

GR00T N1.7 necesită o placă de 80 GB, deci întrebarea costului are un răspuns restrâns. Pe AY-Robots, antrenorul groot1.7 rulează pe nivelul A100 80 GB sau H100 80 GB, unde o rulare durează 3 până la 6 ore la 1.20 până la 2.00 USD pe oră pe piața spot. Asta înseamnă aproximativ 4 până la 12 USD pentru job-ul implicit de 20000 de pași. Aceeași sarcină pe SmolVLA sau ACT rulează pe o placă de 24 GB la 0.30 până la 0.60 USD pe oră și 1 până la 3 USD pe rulare. Aceasta este adevărata compensație: GR00T costă de aproximativ patru ori mai mult per încercare și nu îl poți rula pe 4090-ul de sub biroul tău.

Minimul de 50 de episoade nu este o țintă, ci un prag minim. FAQ-ul NVIDIA este mai exigent: aproximativ 100 de traiectorii pentru o operațiune simplă de ridicare și plasare într-o locație fixă, 500 sau mai multe pentru scene complexe sau cu mai mulți pași și 100 până la 500 pentru manipulare fină. Dacă aveți 20 de episoade, petreceți după-amiaza înregistrând, mai degrabă decât seara ajustând. Ghidul de colectare a datelor acoperă ce anume separă un episod util de unul irosit, înregistrați primul dvs. set de date este versiunea scurtă, iar colectarea datelor SO-100 este cea specifică brațului.

Pasul 6: evaluare în buclă deschisă înainte de a atinge brațul

Nu aplica un nou punct de control pe un braț fizic pentru a afla dacă antrenamentul a funcționat. Rulează mai întâi evaluarea în buclă deschisă. Aceasta redă un episod înregistrat, cere modelului acțiuni la fiecare pas și trasează predicția în raport cu adevărul fundamental, folosind MSE și MAE. Nu costă nimic și prinde erorile de mapare de la pașii 2 și 3.

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

Repozitoriul refuză în mod deliberat să publice un MSE țintă pentru date personalizate, și aceasta este decizia corectă: numărul depinde de unitățile dvs. de acțiune, de sarcina dvs. și de dimensiunea setului de date, astfel încât un prag copiat de la brațul altcuiva nu înseamnă nimic. Ceea ce este semnificativ este tendința. Iată rularea de referință documentată de repozitoriu pe un singur H100 cu setul de date demonstrativ de cinci episoade și 2000 de pași.

Forma este semnalul, nu valorile absolute. Eroarea ar trebui să scadă constant pe măsură ce se acumulează. Mediat pe toate cele cinci episoade de antrenament, mai degrabă decât doar pe traiectoria 0, punctul de control final al depozitului a obținut aproximativ 7.5 MSE și 1.5 MAE, astfel încât chiar și rularea de referință este interpretată diferit în funcție de episoadele pe care le mediați. Înregistrați-vă propria linie de bază folosind comanda demo nemodificată înainte de a schimba orice legat de propriile date: dacă nu puteți reproduce o rulare validă cunoscută, nu puteți distinge o eroare de configurare de o problemă de date. Depozitul mapează, de asemenea, simptomele comune la cauze, și fiecare dintre ele este operațională, mai degrabă decât o eroare de model.

Cealaltă cale: lerobot-train în loc de Isaac-GR00T

Versiunea actuală LeRobot, 0.6.1 pe PyPI începând cu 3 august 2026, oferă o a doua modalitate, destul de diferită, de a ajusta aceleași ponderi de bază. LeRobot expune GR00T N1.7 ca tip de politică și îl antrenează prin propriul său lerobot-train punct de intrare. Două lucruri contează aici. CLI-ul LeRobot este un set de scripturi de consolă, deci orice citiți care spune python lerobot/scripts/train.py este învechit și nu va rula. Și LeRobot a eliminat complet suportul pentru GR00T N1.5, respingând punctele de control și configurațiile N1.5 cu o notă de migrare, deci dacă aveți nevoie de N1.5 prin LeRobot trebuie să fixați versiunea lerobot==0.5.1, ultima versiune care îl suportă, publicată pe 7 aprilie 2026.

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

Două moduri de a obține același checkpoint

Reîncărcarea punctului de control pe braț

Isaac-GR00T utilizează o arhitectură server-client peste ZMQ. Politica rulează pe GPU, iar un client subțire de pe mașina robotului trimite observații și primește fragmente de acțiuni. Exemplul SO-100 este suficient de complet pentru a fi copiat: pornește run_gr00t_server.py cu punctul tău de control și --embodiment-tag NEW_EMBODIMENT, apoi rulează eval_so100.py pe partea robotului cu portul serial, ID-ul robotului, indicii camerei și instrucțiunea lingvistică. Numele camerelor din acea comandă trebuie să se potrivească cu numele prietenoase din modality.json, nu cu numerele dispozitivelor din sistemul de operare.

# 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"

Acum partea sinceră despre unde rulează politica, deoarece antrenamentul și servirea au istorii hardware diferite. Fine-tuning-ul necesită 40 GB sau mai mult. Inferența nu: README-ul o plasează la 16 GB sau mai mult și menționează explicit RTX 4090, deci o placă pe care o dețineți deja poate servi un checkpoint pe care nu l-ar fi putut produce niciodată. Ceea ce decide dacă politica se simte responsivă nu este VRAM-ul, ci unde se află serverul. Pe AY-Robots GR00T N1.7 este doar în cloud, deci bucla de control plătește o călătorie dus-întors prin internetul public pe lângă cei 152 ms per pas de acțiune, și doar SmolVLA și ACT rulează și local. Pentru operațiuni lente de pick and place, un pod la distanță este suportabil. Pentru orice reactiv, nu este: politica devine ezitantă într-un mod care arată exact ca o eroare de antrenament și nu este una. ACT la 20 ms per pas de acțiune este modelul care tolerează cea mai strânsă buclă, SmolVLA se situează la 245 ms, și nicio cantitate de reglaj al latenței nu recuperează o călătorie dus-întors care a fost deja cheltuită. Rulați prima dvs. politică parcurge partea de servire de la un capăt la altul.

Ce merge de fapt greșit

• GatedRepoError la prima rulare. Nu vi s-a acordat acces la nvidia/Cosmos-Reason2-2B sau nu v-ați autentificat. Acest lucru se întâmplă după ce ceasul GPU a pornit deja.
• Set de date respins la încărcare. Aproape întotdeauna un set de date v3.0. Convertiți-l la o versiune anterioară. Vezi set de date respins ca v3.
• IndexError privind dimensiunile booleene neconcordante. Ați modificat delta_indices și nu ați regenerat statisticile.
• Memorie insuficientă la lotul 32. Reduceți --global-batch-size și creșteți --gradient-accumulation-steps, sau reduceți --num-shards-per-epoch, ceea ce configurația sugerează explicit când VRAM este limitată. Vezi memorie insuficientă în timpul antrenamentului.
• Pierderea scade, politica nu face nimic. Nu există o împărțire de validare implicită, deci o curbă de antrenament curată demonstrează foarte puțin. Această pagină acoperă diagnosticul.
• Funcționează în configurația dvs. și nicăieri altundeva. De așteptat cu un set de date mic filmat într-o singură condiție de iluminare. NVIDIA recomandă augmentarea cu variații de culoare (colour jitter) plus 20 până la 50 de episoade în condiții de iluminare diferite. Mai multe aici.
• Prehensorul nu se închide niciodată corect. Verificați ca acțiunea prehensorului să fie ABSOLUTĂ și articulațiile brațului RELATIVE, în această ordine în action_configs. Prehensorul nu se închide listează celelalte cauze.
• O cameră se deconectează silențios în timpul înregistrării. Episodul se salvează în continuare și cheia video încă există, motiv pentru care aceasta este o problemă neplăcută. Camera nu este detectată acoperă acest aspect.

Întregul index de moduri de eșec se găsește la . Dacă alegeți între modele, mai degrabă decât să depanați unul, și au numere de referință cu surse atașate, iar este comparația de care majoritatea oamenilor au nevoie de fapt, deoarece este alegerea între un model pe care îl puteți antrena pe placa de sub birou și unul pentru care trebuie să închiriați un nod de 80 GB pentru a-l ajusta fin. Pentru contextul motivului pentru care aceste modele se comportă așa cum o fac, și merită citite mai întâi. Și dacă nu dețineți încă un braț, transmite în flux un SO-100 fizic fără înregistrare.