Hvordan trene GR00T N1.7 på ditt eget SO-100 datasett

NVIDIA leverer et finjusteringseksempel for akkurat den armen du sannsynligvis eier. Inne i Isaac-GR00T-arkivet finnes det en mappe kalt demo_data/cube_to_bowl_5: fem episoder, 4 148 bilder ved 30 fps, allerede skrevet som LeRobot v2.1, med en matchende modalitetskonfigurasjon under examples/SO100/. Dens meta/info.json rapporterer robot_type: so101_follower, som i LeRobot er den samme konfigurasjonsklassen som so100_follower. Det er genuint nyttig, fordi det betyr at referansebanen for GR00T N1.7 på en seks-frihetsgrad hobbyarm vedlikeholdes av personene som skrev modellen. Det er ikke en nedskalert humanoid demo, det er den samme armen.

Den dårlige nyheten er avstanden mellom I recorded 60 episodes og the arm does the task. Det er omtrent seks steder hvor denne pipelinen feiler stille i stedet for høyt, og fire av dem ligger i filer de fleste aldri åpner: meta/modality.json, Python-datakonfigurasjonen, meta/relative_stats.json, og datasettets egen versjonsstreng. Denne guiden går gjennom den manuelle ruten fra start til slutt med de virkelige kommandoene, og viser deretter den samme jobben som et skjema på AY-Robots. Alt nedenfor ble sjekket mot Isaac-GR00T main-grenen per 20. august 2026 (n1.7-release-linjen) og lerobot 0.6.1, publisert til PyPI 3. august 2026. Oppstrøms beveger seg raskt, og der et flagg ble omdøpt, sier denne artikkelen det.

Hva GR00T N1.7 faktisk er

GR00T N1.7 er en syn-språk-handlingsmodell med dobbelt-systemoppsettet beskrevet i det originale GR00T N1-dokumentet: en syn-språk-modul som leser kameraene og instruksjonen, og en diffusjonstransformator som omdanner dette til en del kontinuerlige motorkommandoer. N1.7 erstattet den første halvdelen. Eagle-ryggraden fra N1.6 er borte, byttet ut med nvidia/Cosmos-Reason2-2B på en Qwen3-VL-arkitektur, og modellen ble forhåndstrent på omtrent 20 000 timer med egosentrisk menneskevideo i tillegg til robotdataene. NVIDIAs egen rapport angir tallet til 20 854 timer og rapporterer at å gå fra 1k til 20k timer mer enn dobler gjennomsnittlig oppgavefullføring.

Den andre halvdelen endret seg også, på måter som er viktige for din kjøring. Handlingshodet falt fra 32 diffusjonslag til 16, den predikerte handlingsbiten vokste fra 16 trinn til 40, og maksimal tilstands- og handlingsbredde gikk fra 29 til 132. Disse tre tallene kommer fra endringsloggen i depotets README; NVIDIAs egen lanseringspost beskriver fortsatt System 1 som en 32-lags DiT, så der de to er uenige, stol på depotet du er i ferd med å klone. Handlinger uttrykkes som standard i et relativt end-effektor-rom, deltaer fra den nåværende posituren snarere enn absolutte mål, noe som er det som lar manipulasjonsprioriteringer lært fra menneskevideo overføres til robotkontroll i det hele tatt. Selve hodet er en strømningsmatchende diffusjonstransformator, samme familie som Pi0.5, men med en annen ryggrad foran den. Hvis du fortsatt er på forrige generasjon, dekker N1.7 mot N1.5 om oppgraderingen rettferdiggjør å gjøre om pipelinen din.

De siste tre radene forklarer det meste av skuffelsen folk rapporterer. Overskriftens 27.9 ms er en TensorRT-motor på en H100 med ett kamera og fire denoising-trinn. Ren PyTorch på samme kort er 85.8 ms, og modellkortet angir gapet til 3.08x. Ingen av tallene inkluderer et serving-lag, et andre kamera eller et nettverkshopp. De 152 ms per handlingstrinn som AY-Robots oppgir for sin servert GR00T N1.7 er tallet med serving i loopen, og en offentlig-internett rundtur kommer i tillegg til det. Mer om dette på slutten. For tallene ved siden av andre modeller, legger GR00T N1.7 mot Pi0.5 og GR00T N1.7 mot SmolVLA dem ut side ved side.

Hva kjøringen trenger før du skriver noe

Trinn 0: episodene selv

Alt nedenfor forutsetter at du allerede har spilt inn episoder. Hvis ikke, er det det virkelige første trinnet, og det er det som avgjør hvor godt resultatet kan bli, fordi imitasjonslæring ikke kan gjenopprette informasjon som ikke er i dataene. Kalibrer begge armene først, kjør deretter følgeren med en lederarm mens lerobot-record skriver parquet-filene og kamerastrømmene. Hvis kalibrering er feil, beskriver leddverdiene i datasettet ditt en litt annen robot enn den som senere vil utføre policyen, og ingen mengde trening fikser det.

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

LeRobots eget råd er å spille inn minst 50 episoder med omtrent 10 per objektplassering, holde kameraene faste og holde gripeatferden konsistent. Legg til variasjon senere, ikke i starten. Tommelfingerregelen verdt å huske: hvis du ikke kunne utføre oppgaven selv fra kamerabildene alene, kan heller ikke policyen det. For det armspesifikke oppsettet, SO-100 komme i gang og SO-100 LeRobot-siden dekker porter, kalibrering og kamera-indekser. På AY-Robots kan du også gjøre dette over internett fra nettleseren ved hjelp av teleoperasjon og ta opp direkte fra økten.

Trinn 1: datasettet må være LeRobot v2.1

Dette er den vanligste hindringen. LeRobots nåværende CODEBASE_VERSION på main er v3.0, så alt du tar opp i dag med en nåværende verktøykjede kommer ut som v3.0. GR00Ts laster forventer v2. Repositoriet er eksplisitt om hvorfor: mange oppstrøms datasett som DROID, LIBERO og Bridge er publisert i v2, og native støtte for begge er planlagt, men ikke levert. Så konverteringen er opp til deg, og den kjører i sitt eget virtualenv av en konkret grunn: scripts/lerobot_conversion har sitt eget pyproject som krever Python 3.10 eller 3.11 og fester lerobot til én git-commit, mens Isaac-GR00T selv krever Python 3.12. Installer konverteren fra rotmappen til repositoriet, og du får gr00t pakken i stedet, noe som er feilen README advarer om. Hvis du er ny i formatet, forklarer LeRobot-datasett ordlisteoppføringen hva som faktisk er inni et slikt.

# 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

Strukturen GR00T ønsker etter konvertering er det klassiske v2-oppsettet: meta/info.json, meta/episodes.jsonl, meta/tasks.jsonl, parquet-filer under data/chunk-000/, MP4-filer under videos/chunk-000/observation.images./, og én ekstra fil som standard LeRobot ikke har. Den ekstra filen er der de fleste av de gjenværende feilene ligger.

Trinn 2: modality.json, de seks tallene som bestemmer alt

I et LeRobot-datasett lagres robotens tilstand og handling som flate float32-arrayer. For en SO-100 har begge formen [6]: fem armledd og en griper. Demodatasettet navngir dem shoulder_pan.pos, shoulder_lift.pos, elbow_flex.pos, wrist_flex.pos, wrist_roll.pos, gripper.pos, men disse navnene finnes i info.json og ingenting i parquet-filen sier hvilken indeks som er hvilken. meta/modality.json leverer denne tilordningen, og GR00T vil ikke trene uten den. Her er den som repositoryet leverer for SO-100, ordrett.

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

Kopier den inn i ditt konverterte datasett på meta/modality.json og gi videonøklene nytt navn til det kameraene dine faktisk heter. Hvis du spilte inn med et enkelt overliggende kamera kalt top, da er original_key observation.images.top og det vennlige navnet er det datakonfigurasjonen din vil referere til. De to må stemme overens, og ingen av dem sjekker den andre for deg. Språkannoteringen er verre, fordi den samme nøkkelen må vises tre steder.

Trinn 3: datakonfigurasjonen, relativ arm og absolutt griper

Modalitetskonfigurasjonen er en Python-fil snarere enn JSON, fordi den også bestemmer hvordan hver handlingsgruppe representeres. Dette er den delen av N1.7-arbeidsflyten som ikke eksisterte i samme form i N1.5, og den delen som er verdt å lese to ganger. Den leverte SO-100-konfigurasjonen forutsier de fem armleddene som RELATIVE deltaer fra gjeldende tilstand og griperen som en ABSOLUTE målposisjon, fordi et binært åpen-eller-lukket signal fungerer bedre som et mål enn som et delta.

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)

To detaljer her vil koste deg en dag hvis du ikke kjenner dem. For det første, action_configs er posisjonsbasert: dokumentasjonen krever samme lengde og samme rekkefølge som modality_keys, og de er tydelige på konsekvensen av å gjøre feil, som er at feil representasjon blir brukt uten varsel. Griperen din blir trent som et delta og armen din som et absolutt mål, og det er ingen feilmelding. For det andre, register_modality_config hevder at taggen ikke allerede er registrert, så en andre NEW_EMBODIMENT-konfigurasjon i samme Python-prosess dør med Embodiment tag ... already registered. Du kan ikke importere to av disse inn i ett skript. En tredje regel håndheves senere, ved utrulling: handlingens delta_indices må være det sammenhengende området som starter på null. Et spredt vindu som [0, 4, 8] avvises, fordi alt nedstrøms indekserer den predikerte biten lineært og ellers ville utført feil rader.

Trinn 4: miljøet

N1.7 flyttet depotet til og Python 3.12. Den gamle conda pluss pip install -e . -stien eksisterer fortsatt i en skjult del av README, men den advarer om at GPU-avhengigheter, inkludert flash-attn og TensorRT, kan kreve manuell installasjon. Bruk uv med mindre du har en spesifikk grunn til å ikke gjøre det. Når det gjelder flash-attn, sparer én detalj forvirring: du vil se Installing flash-attn skrevet ut ved hver uv run. Den bygges ikke på nytt. uv re-validerer et URL-festet hjul som allerede er bufret, og det tar to eller tre sekunder.

1. 1
   Installer git-lfs, deretter klon med submoduler

   git-lfs er påkrevd, ikke valgfritt. Uten det vil parquet-filene i demo_data/ lastes ned som pekerstubber, og demo-kjøringen vil mislykkes på et datasett som ser ut til å være til stede i filoversikten.

   bash

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

2. 2
   Installer uv og synkroniser miljøet

   Standardinstallasjonen trekker inn GPU-avhengighetene, inkludert flash-attn og TensorRT. På et ferskt A100- eller H100-bilde er dette det lengste enkelttrinnet, så gjør det før du begynner å vie oppmerksomhet til noe annet.

   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
   Autentiser mot Hugging Face

   Gjør dette før den første treningslanseringen, ikke etter at den feiler åtte minutter ut i prosessen.

   bash

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

4. 4
   Sanity-sjekk på de medfølgende SO-100 demo-dataene

   Før du rører ditt eget opptak, kjør 2000 trinn på demo_data/cube_to_bowl_5. Det er fem episoder, det fullføres raskt, og det beviser miljøet snarere enn dataene dine. Hvis denne kjøringen mislykkes, vil ingenting du gjør med datasettet ditt hjelpe.

   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

Trinn 5: `fine-tune`-kommandoen og hva dens flagg egentlig er satt til som standard

Bytt ut demo-datasettet med ditt eget og legg til de innstillingene du faktisk ønsker. Nedenfor er den fullstendige formen som repositoriet bruker i sin egen `new-embodiment`-veiledning, inkludert augmentering- og sjekkpunktflaggene som det korte README-eksemplet utelater. Dette er i snever forstand: språkryggraden og den visuelle koderen forblir frosne, og det som trenes er projektoren og diffusjonsaksjonshodet.

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

Den siste raden er ikke en skrivefeil. launch_finetune.py er en tyro CLI generert fra en dataklasse, og den dataklassen har ingen seed-felt. README-filen bemerker separat 5 til 6 prosent varians mellom kjøringer forårsaket av ikke-deterministisk bildeaugmentering. To kjøringer med identiske flagg vil ikke produsere identiske sjekkpunkter, noe som betyr mye når du prøver å avgjøre om en hyperparameterendring hjalp eller om du var heldig. Til sammenligning bruker lerobots egen trener standardinnstillingen seed 1000, og LeRobot GR00T-oppskriften sender --seed=42 eksplisitt.

Hva en 20000-trinns kjøring koster

GR00T N1.7 trenger et 80 GB kort, så kostnadsspørsmålet har et snevert svar. På AY-Robots kjører groot1.7-treneren på A100 80 GB eller H100 80 GB-nivået, hvor en kjøring tar 3 til 6 timer til 1.20 til 2.00 USD per time på spotmarkedet. Det er omtrent 4 til 12 USD for standard 20000-trinns jobben. Den samme oppgaven på SmolVLA eller ACT lander på et 24 GB kort til 0.30 til 0.60 USD per time og 1 til 3 USD per kjøring. Det er den virkelige avveiningen: GR00T koster omtrent fire ganger så mye per forsøk, og du kan ikke kjøre det på 4090 under skrivebordet ditt.

Minimum 50-episode er et gulv, ikke et mål. NVIDIAs egen FAQ er mer krevende: omtrent 100 trajektorier for en enkel plukk-og-plasser-oppgave på et fast sted, 500 eller mer for komplekse eller flertrinns-scener, og 100 til 500 for finmanipulasjon. Hvis du sitter med 20 episoder, bruk ettermiddagen på å spille inn i stedet for kvelden på å finjustere. Den datainnsamlingsguiden dekker hva som skiller en nyttig episode fra en bortkastet,spill inn ditt første datasett er kortversjonen, og SO-100 datainnsamling er den armspesifikke.

Trinn 6: åpen-sløyfe evaluering før du rører armen

Ikke legg en fersk sjekkpunkt på en fysisk arm for å finne ut om treningen fungerte. Kjør den åpen-sløyfe evalueringen først. Den spiller av en innspilt episode, ber modellen om handlinger ved hvert trinn, og plotter prediksjon mot sannhet med MSE og MAE. Det koster ingenting og fanger opp kartleggingsfeilene fra trinn 2 og 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

Repositoriet nekter bevisst å publisere en mål-MSE for egendefinerte data, og det er riktig: tallet avhenger av dine handlingsenheter, din oppgave og din datasettstørrelse, så en terskel kopiert fra en annens arm betyr ingenting. Det som er meningsfullt er trenden. Her er referansekjøringen som repositoriet dokumenterer på en enkelt H100 med demo-datasettet på fem episoder og 2000 trinn.

Formen er signalet, ikke de absolutte verdiene. Feilen bør falle jevnt etter hvert som akkumuleres. Gjennomsnittlig over alle fem treningsepisodene, i stedet for kun bane 0, scoret repoets siste sjekkpunkt omtrent 7.5 MSE og 1.5 MAE, så selv referansekjøringen leses annerledes avhengig av hvilke episoder du gjennomsnittsberegner. Registrer din egen grunnlinje på den umodifiserte demo-kommandoen før du endrer noe med dine egne data: hvis du ikke kan reprodusere en kjent-god kjøring, kan du ikke skille en oppsettfeil fra et dataproblem. Repositoriet kartlegger også de vanlige symptomene til årsaker, og hver av dem er operasjonelle snarere enn en modellfeil.

Den andre ruten: lerobot-train i stedet for Isaac-GR00T

Den nåværende LeRobot-utgivelsen, 0.6.1 på PyPI siden 3. august 2026, tilbyr en annen og ganske annerledes måte å finjustere de samme basisvektene på. LeRobot eksponerer GR00T N1.7 som en policytype og trener den gjennom sitt eget lerobot-train-inngangspunkt. To ting er viktige her. LeRobot CLI er et sett med konsollskript, så alt du leser som sier python lerobot/scripts/train.py er utdatert og vil ikke kjøre. Og LeRobot fjernet GR00T N1.5-støtte fullstendig, og avviste N1.5-sjekkpunkter og -konfigurasjoner med en migreringsmerknad, så hvis du trenger N1.5 gjennom LeRobot må du låse til lerobot==0.5.1, den siste utgivelsen som støtter det, publisert 7. april 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

To måter å få det samme sjekkpunktet på

Sette sjekkpunktet tilbake på armen

Isaac-GR00T bruker en server-klient-deling over ZMQ. Policyen kjører på GPU-en, og en tynn klient på robotmaskinen sender observasjoner og mottar handlingsbiter. SO-100-eksemplet er komplett nok til å kopiere: start run_gr00t_server.py med sjekkpunktet ditt og --embodiment-tag NEW_EMBODIMENT, kjør deretter eval_so100.py på robotsiden med seriellporten, robot-ID-en, kamera-indeksene og språkinstruksjonen. Kameranavnene i den kommandoen må samsvare med de vennlige navnene fra din modality.json, ikke OS-enhetstallene.

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

Nå den ærlige delen om hvor policyen kjører, fordi trening og serving har forskjellige maskinvarehistorier. Finjustering krever 40 GB eller mer. Inferens gjør det ikke: README angir det til 16 GB eller mer og nevner RTX 4090 eksplisitt, så et kort du allerede eier kan serve et sjekkpunkt det aldri kunne ha produsert. Det som avgjør om policyen føles responsiv er ikke VRAM, det er hvor serveren befinner seg. På AY-Robots er GR00T N1.7 kun skybasert, så kontrollsløyfen betaler en offentlig internett-tur-retur i tillegg til de 152 ms per handlingstrinn, og bare SmolVLA og ACT kjører også lokalt. For langsom plukking og plassering er en ekstern pod overlevelig. For alt reaktivt er det ikke: policyen blir nølende på en måte som ser nøyaktig ut som en treningsfeil og er ikke det. ACT på 20 ms per handlingstrinn er modellen som tåler den strammeste sløyfen, SmolVLA ligger på 245 ms, og ingen mengde latensjustering kjøper tilbake en tur-retur som allerede er brukt. Kjør din første policy går gjennom serveringssiden fra ende til ende.

Hva som faktisk går galt

• GatedRepoError ved første kjøring. Du har ikke fått tilgang til nvidia/Cosmos-Reason2-2B, eller du autentiserte deg ikke. Dette skjer etter at GPU-klokken allerede har startet.
• Datasett avvist ved lasting. Nesten alltid et v3.0-datasett. Konverter det ned. Se datasett avvist som v3.
• IndexError om uoverensstemmende boolske dimensjoner. Du endret delta_indices og regenererte ikke statistikken.
• Tom for minne ved batch 32. Reduser --global-batch-size og øk --gradient-accumulation-steps, eller reduser --num-shards-per-epoch, noe konfigurasjonen eksplisitt foreslår når VRAM er begrenset. Se tom for minne under trening.
• Tapet faller, policyen gjør ingenting. Det er ingen valideringssplitt som standard, så en ren treningskurve beviser svært lite. Denne siden dekker diagnosen.
• Fungerer i ditt oppsett og ingen andre steder. Forventet med et lite datasett filmet under én lysforhold. NVIDIA anbefaler fargejitter-augmentering pluss 20 til 50 episoder under forskjellige lysforhold. Mer her.
• Griperen lukker aldri ordentlig. Sjekk at griperhandlingen er ABSOLUTT og armleddene RELATIVE, i den rekkefølgen i action_configs. Griperen lukker ikke lister opp de andre årsakene.
• Et kamera faller stille ut midt under opptak. Episoden lagres fortsatt og videonøkkelen eksisterer fortsatt, derfor er denne ekkel. Kamera ikke oppdaget dekker det.

Hele indeksen over feilmoduser finnes på . Hvis du velger mellom modeller i stedet for å feilsøke en, og har benchmark-tall med kilder vedlagt, og er sammenligningen de fleste faktisk trenger, fordi det er valget mellom en modell du kan trene på kortet under pulten din og en du må leie en 80 GB node for å finjustere. For bakgrunn om hvorfor disse modellene oppfører seg som de gjør, er VLA-oversikten og komplett SO-100-guide verdt å lese først. Og hvis du ikke eier en arm ennå, strømmer en fysisk SO-100 uten registrering.