Sådan træner du GR00T N1.7 på dit eget SO-100 datasæt

NVIDIA leverer et finjusteringseksempel for præcis den arm, du sandsynligvis ejer. Inde i Isaac-GR00T-repositoryet findes der en mappe kaldet demo_data/cube_to_bowl_5: fem episoder, 4.148 billeder ved 30 fps, allerede skrevet som LeRobot v2.1, med en matchende modalitetskonfiguration under examples/SO100/. Dens meta/info.json rapporterer robot_type: so101_follower, som i LeRobot er den samme konfigurationsklasse som so100_follower. Det er virkelig nyttigt, fordi det betyder, at referencevejen for GR00T N1.7 på en seks-frihedsgraders hobbyarm vedligeholdes af de folk, der skrev modellen. Det er ikke en nedskaleret humanoid demo, det er den samme arm.

Den dårlige nyhed er afstanden mellem I recorded 60 episodes og the arm does the task. Der er omkring seks steder, hvor denne pipeline fejler stille snarere end højlydt, og fire af dem findes i filer, de fleste aldrig åbner: meta/modality.json, Python-datakonfigurationen, meta/relative_stats.json, og datasættets egen versionsstreng. Denne guide gennemgår den manuelle rute fra start til slut med de rigtige kommandoer og viser derefter det samme job som en formular på AY-Robots. Alt nedenfor blev kontrolleret mod Isaac-GR00T main-grenen pr. 20. august 2026 (n1.7-release-linjen) og lerobot 0.6.1, udgivet på PyPI den 3. august 2026. Upstream bevæger sig hurtigt, og hvor et flag blev omdøbt, nævner denne artikel det.

Hvad GR00T N1.7 egentlig er

GR00T N1.7 er en syns-sprog-handlingsmodel med det dobbeltsystemlayout, der er beskrevet i den originale GR00T N1-artikel: et syns-sprog-modul, der læser kameraerne og instruktionen, og en diffusionstransformer, der omdanner dette til en blok af kontinuerlige motoriske kommandoer. N1.7 erstattede den første halvdel. Eagle-backbonen fra N1.6 er væk, udskiftet med nvidia/Cosmos-Reason2-2B på en Qwen3-VL-arkitektur, og modellen blev fortrænet på cirka 20.000 timers egocentrisk menneskevideo ud over robotdataene. NVIDIAs egen rapport angiver tallet til 20.854 timer og rapporterer, at en stigning fra 1k til 20k timer mere end fordobler den gennemsnitlige opgavefuldførelse.

Den anden halvdel ændrede sig også, på måder der er relevante for din kørsel. Handlingshovedet faldt fra 32 diffusionslag til 16, den forudsagte handlingsklump voksede fra 16 trin til 40, og den maksimale tilstands- og handlingsbredde gik fra 29 til 132. Disse tre tal kommer fra ændringsloggen i repositoryets README; NVIDIAs egen lanceringspost beskriver stadig System 1 som en 32-lags DiT, så hvor de to er uenige, skal du stole på det repo, du er ved at klone. Handlinger udtrykkes som standard i et relativt end-effector-rum, deltaer fra den nuværende position snarere end absolutte mål, hvilket er det, der overhovedet tillader manipulation priors lært fra menneskevideo at overføres til robotkontrol. Selve hovedet er en flow-matching diffusionstransformer, den samme familie som Pi0.5, men med en anden backbone foran den. Hvis du stadig er på den tidligere generation, N1.7 mod N1.5 dækker, om opgraderingen retfærdiggør at gentage din pipeline.

De sidste tre rækker forklarer det meste af den skuffelse, folk rapporterer. Overskriften på 27.9 ms er en TensorRT-motor på en H100 med ét kamera og fire denoising-trin. Ren PyTorch på det samme kort er 85.8 ms, og modelkortet angiver forskellen til 3.08x. Ingen af tallene inkluderer et serving-lag, et andet kamera eller et netværkshop. De 152 ms per handlingstrin, AY-Robots angiver for sin serverede GR00T N1.7, er tallet med serving i loopet, og en offentlig internet-roundtrip kommer oveni. Mere om dette til sidst. For tallene ved siden af andre modeller, GR00T N1.7 mod Pi0.5 og GR00T N1.7 mod SmolVLA præsenterer dem side om side.

Hvad kørslen kræver, før du taster noget

Trin 0: episoderne selv

Alt nedenfor forudsætter, at du allerede har optaget episoder. Hvis ikke, er det det virkelige første skridt, og det er det, der afgør, hvor godt resultatet kan blive, fordi imitationslæring ikke kan gendanne information, der ikke er i dataene. Kalibrer begge arme først, og kør derefter følgeren med en lederarm mens lerobot-record skriver parquet-filerne og kamerastrømmene. Hvis kalibrering er forkert, beskriver ledværdierne i dit datasæt en lidt anden robot end den, der senere vil udføre politikken, og ingen mængde træning kan rette op på 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 at optage mindst 50 episoder med omkring 10 pr. objektplacering, holde kameraerne faste og holde gribeadfærden konsekvent. Tilføj variation senere, ikke i starten. Tommelfingerreglen, der er værd at huske: hvis du ikke selv kunne udføre opgaven ud fra kamerabillederne alene, kan politikken heller ikke. For den armspecifikke opsætning dækker SO-100 igangsætning og SO-100 LeRobot-siden porte, kalibrering og kamera-indekser. På AY-Robots kan du også gøre dette over internettet fra browseren ved hjælp af fjernbetjening og optage direkte fra sessionen.

Trin 1: datasættet skal være LeRobot v2.1

Dette er den mest almindelige forhindring. LeRobots nuværende CODEBASE_VERSION på main er v3.0, så alt, hvad du optager i dag med en nuværende værktøjskæde, kommer ud som v3.0. GR00Ts loader forventer v2. Repository'et er eksplicit omkring hvorfor: mange upstream datasæt som DROID, LIBERO og Bridge er udgivet i v2, og indbygget understøttelse for begge er planlagt, men ikke leveret. Konverteringen er derfor dit ansvar, og den kører i sit eget virtualenv af en konkret årsag: scripts/lerobot_conversion medbringer sit eget pyproject, der kræver Python 3.10 eller 3.11 og fastlåser lerobot til én git commit, mens Isaac-GR00T selv kræver Python 3.12. Installer konverteren fra repository-roden, og du får gr00t-pakken i stedet, hvilket er den fejl, dens README advarer om. Hvis du er ny til formatet, forklarer LeRobot-datasæt ordlisteindgangen, hvad der faktisk er inde i et.

# 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 efter konvertering er det klassiske v2-layout: 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. Denne ekstra fil er der, hvor de fleste af de resterende fejl findes.

Trin 2: modality.json, de seks tal der afgør alt

I et LeRobot datasæt gemmes robotstatus og handling som flade float32-arrays. For en SO-100 har begge formen [6]: fem armled og en gribeklo. Demo-datasættet navngiver dem shoulder_pan.pos, shoulder_lift.pos, elbow_flex.pos, wrist_flex.pos, wrist_roll.pos, gripper.pos, men disse navne findes i info.json og intet i parquet-filen angiver, hvilket indeks der er hvad. meta/modality.json leverer denne mapping, og GR00T vil ikke træne uden den. Her er den, som repository'et leverer til SO-100, ordret.

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

Kopiér den til dit konverterede datasæt på meta/modality.json og omdøb videonøglerne til det, dine kameraer faktisk hedder. Hvis du optog med et enkelt overliggende kamera kaldet top, så er original_key observation.images.top, og det venlige navn er det, din datakonfiguration vil referere til. De to skal stemme overens, og ingen af dem kontrollerer den anden for dig. Sprogannoteringen er værre, fordi den samme nøgle skal optræde tre steder.

Trin 3: datakonfigurationen, relativ arm og absolut griber

Modalitetskonfigurationen er en Python-fil snarere end JSON, fordi den også bestemmer, hvordan hver handlingsgruppe repræsenteres. Dette er den del af N1.7-workflowet, der ikke eksisterede i samme form i N1.5, og den del, der er værd at læse to gange. Den medfølgende SO-100-konfiguration forudsiger de fem armled som RELATIVE deltaer fra den nuværende tilstand og gribekloen som en ABSOLUTE målposition, fordi et binært åben-eller-lukket signal fungerer bedre som et mål end 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 dig en dag, hvis du ikke kender dem. For det første, action_configs er positionel: dokumentationen kræver samme længde og samme rækkefølge som modality_keys, og de er meget tydelige omkring konsekvensen af at gøre det forkert, hvilket er, at den forkerte repræsentation anvendes lydløst. Din gribeklo trænes som et delta, og din arm som et absolut mål, og der er ingen fejlmeddelelse. For det andet, register_modality_config bekræfter, at tagget ikke allerede er registreret, så en anden NEW_EMBODIMENT-konfiguration i samme Python-proces dør med Embodiment tag ... already registered. Du kan ikke importere to af disse i ét script. En tredje regel håndhæves senere, ved implementering: handlingen delta_indices skal være det sammenhængende område, der starter ved nul. Et spredt vindue som [0, 4, 8] afvises, fordi alt downstream indekserer den forudsagte chunk lineært og ellers ville udføre de forkerte rækker.

Trin 4: miljøet

N1.7 flyttede repository'et til og Python 3.12. Den gamle conda plus pip install -e . sti eksisterer stadig i en sammenklappet sektion af README, men den advarer om, at GPU-afhængigheder, herunder flash-attn og TensorRT, muligvis kræver manuel installation. Brug uv, medmindre du har en specifik grund til ikke at gøre det. Hvad angår flash-attn, sparer én detalje forvirring: du vil se Installing flash-attn udskrevet ved hver uv run. Den genopbygges ikke. uv genvaliderer et URL-fastgjort wheel, der allerede er cachet, og det tager to eller tre sekunder.

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

   git-lfs er påkrævet, ikke valgfrit. Uden det downloades parquet-filerne i demo_data/ som pointer-stubs, og demo-kørslen mislykkes på et datasæt, der ser ud til at være til stede i filoversigten.

   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

   Standardinstallationen trækker GPU-afhængighederne, herunder flash-attn og TensorRT. På et nyt A100- eller H100-image er dette det længste enkelttrin, så gør det, før du begynder at være opmærksom på noget andet.

   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
   Autentificer mod Hugging Face

   Gør dette før den første træningsstart, ikke efter den fejler otte minutter inde.

   bash

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

4. 4
   Sanitetskontrol på de medfølgende SO-100 demo-data

   Før du rører ved din egen optagelse, kør 2000 trin på demo_data/cube_to_bowl_5. Det er fem episoder, det afsluttes hurtigt, og det beviser miljøet snarere end dine data. Hvis denne kørsel mislykkes, vil intet, du gør med dit datasæt, hjælpe.

   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

Trin 5: fine-tune kommandoen og hvad dens flags reelt er standard for

Udskift demo-datasættet med dit eget og tilføj de indstillinger, du faktisk ønsker. Nedenfor er den fulde form, som repository'et bruger i sin egen new-embodiment tutorial, inklusive de augmentering- og checkpointing-flags, som det korte README-eksempel udelader. Dette er i snæver forstand: sprog-backbonen og den visuelle encoder forbliver frosne, og det, der trænes, er projektoren og diffusion action head'en.

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 sidste række er ikke en slåfejl. launch_finetune.py er en tyro CLI genereret fra en dataclass, og den dataclass har intet seed-felt. README bemærker separat en varians på 5 til 6 procent mellem kørsler forårsaget af ikke-deterministisk billedaugmentation. To kørsler med identiske flag vil ikke producere identiske checkpoints, hvilket betyder meget, når man forsøger at afgøre, om en hyperparameterændring hjalp, eller om man var heldig. Til sammenligning bruger lerobots egen træner standardværdien seed 1000, og LeRobot GR00T-opskriften sender --seed=42 eksplicit.

Hvad en 20000-trins kørsel koster

GR00T N1.7 kræver et 80 GB kort, så omkostningsspørgsmålet har et snævert svar. På AY-Robots kører groot1.7-træneren på A100 80 GB eller H100 80 GB-niveauet, hvor en kørsel tager 3 til 6 timer til 1.20 til 2.00 USD per time på spotmarkedet. Det er cirka 4 til 12 USD for standard 20000-trins jobbet. Den samme opgave 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 kørsel. Det er den virkelige afvejning: GR00T koster omkring fire gange så meget per forsøg, og du kan ikke køre det på 4090'eren under dit skrivebord.

De 50-episode minimum er et gulv, ikke et mål. NVIDIAs egen FAQ er mere krævende: cirka 100 trajektorier for en simpel pick-and-place med fast placering, 500 eller mere for komplekse eller flertrins-scener, og 100 til 500 for fin manipulation. Hvis du sidder med 20 episoder, så brug eftermiddagen på at optage i stedet for aftenen på at finjustere. vejledning til dataindsamling dækker, hvad der adskiller en nyttig episode fra en spildt, optag dit første datasæt er den korte version, og SO-100 dataindsamling er den armspecifikke.

Trin 6: open-loop evaluering før du rører armen

Sæt ikke en frisk kontrolpunkt på en fysisk arm for at finde ud af, om træningen virkede. Kør open-loop evalueringen først. Den afspiller en optaget episode, beder modellen om handlinger ved hvert trin og plotter forudsigelse mod sandhed med MSE og MAE. Det koster intet, og det fanger mapping-fejlene fra trin 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

Repository'et nægter bevidst at offentliggøre en mål-MSE for brugerdefinerede data, og det er den rigtige beslutning: tallet afhænger af dine handlingsenheder, din opgave og din datasætstørrelse, så en tærskel kopieret fra en andens arm betyder intet. Hvad der er meningsfuldt, er tendensen. Her er referencekørslen, som repo'et dokumenterer på en enkelt H100 med det fem-episode demo-datasæt og 2000 trin.

Formen er signalet, ikke de absolutte værdier. Fejlen bør falde støt, efterhånden som akkumuleres. Gennemsnitligt over alle fem træningsepisoder i stedet for kun bane 0, scorede repoets endelige checkpoint cirka 7.5 MSE og 1.5 MAE, så selv referencekørslen læses forskelligt afhængigt af hvilke episoder du gennemsnitliggør. Optag din egen baseline med den umodificerede demo-kommando, før du ændrer noget ved dine egne data: hvis du ikke kan reproducere en kendt-god kørsel, kan du ikke skelne en opsætningsfejl fra et dataproblem. Repositoryet kortlægger også de almindelige symptomer til årsager, og hver af dem er operationel snarere end en modelbug.

Den anden vej: lerobot-train i stedet for Isaac-GR00T

Den nuværende LeRobot-udgivelse, 0.6.1 på PyPI siden 3. august 2026, tilbyder en anden og ret forskellig måde at finjustere de samme basisvægte på. LeRobot eksponerer GR00T N1.7 som en policy type og træner den via sit eget lerobot-train indgangspunkt. To ting er vigtige her. LeRobot CLI er et sæt konsolscripts, så alt hvad du læser, der siger python lerobot/scripts/train.py er forældet og vil ikke køre. Og LeRobot fjernede GR00T N1.5-understøttelse fuldstændigt, idet den afviste N1.5 checkpoints og configs med en migrationsnote, så hvis du har brug for N1.5 via LeRobot, skal du fastlåse lerobot==0.5.1, den sidste udgivelse, der understøtter det, udgivet 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åder at opnå det samme checkpoint på

Få checkpointet tilbage på armen

Isaac-GR00T anvender en server-klient-opdeling over ZMQ. Politikken kører på GPU'en, og en tynd klient på robotmaskinen sender observationer og modtager handlingssegmenter. SO-100-eksemplet er tilstrækkeligt komplet til at kopiere: start run_gr00t_server.py med dit checkpoint og --embodiment-tag NEW_EMBODIMENT, kør derefter eval_so100.py på robotsiden med serielporten, robot-ID'et, kamera-indekserne og sproginstruktionen. Kameranavnene i den kommando skal matche de venlige navne fra din modality.json, ikke OS-enhedsnumrene.

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

Nu den ærlige del om, hvor policyen kører, for træning og serving har forskellige hardwarehistorier. Finjustering kræver 40 GB eller mere. Inferens gør ikke: README'en angiver det til 16 GB eller mere og nævner RTX 4090 eksplicit, så et kort, du allerede ejer, kan serve et checkpoint, det aldrig kunne have produceret. Hvad der afgør, om policyen føles responsiv, er ikke VRAM, det er, hvor serveren sidder. På AY-Robots er GR00T N1.7 kun i skyen, så kontrolsløjfen betaler en offentlig internet-tur-retur ud over de 152 ms pr. handlingstrin, og kun SmolVLA og ACT kører også lokalt. Til langsom pick and place er en fjern pod overlevelig. Til noget reaktivt er det ikke: policyen bliver tøvende på en måde, der ligner en træningsfejl, men ikke er det. ACT med 20 ms pr. handlingstrin er den model, der tolererer den strammeste sløjfe, SmolVLA ligger på 245 ms, og ingen mængde af latency-justering køber en tur-retur, der allerede er brugt, tilbage. Kør din første policy gennemgår serving-siden fra ende til anden.

Hvad der faktisk går galt

• GatedRepoError ved første kørsel. Du har ikke fået adgang til nvidia/Cosmos-Reason2-2B, eller du har ikke godkendt dig. Dette sker, efter at GPU-uret allerede er startet.
• Datasæt afvist ved indlæsning. Næsten altid et v3.0-datasæt. Konverter det ned. Se datasæt afvist som v3.
• IndexError vedrørende uoverensstemmende boolske dimensioner. Du ændrede delta_indices og regenererede ikke statistikken.
• Mangel på hukommelse ved batch 32. Reducer --global-batch-size og øg --gradient-accumulation-steps, eller reducer --num-shards-per-epoch, hvilket konfigurationen eksplicit foreslår, når VRAM er begrænset. Se mangel på hukommelse under træning.
• Tab falder, politik gør intet. Der er ingen valideringsopdeling som standard, så en ren træningskurve beviser meget lidt. Denne side dækker diagnosen.
• Virker i dit setup og ingen andre steder. Forventeligt med et lille datasæt filmet under én lysforhold. NVIDIA anbefaler farve-jitter-augmentation plus 20 til 50 episoder under forskellige lysforhold. Mere her.
• Gribeklo lukker aldrig ordentligt. Kontroller, at gribekloens handling er ABSOLUT og armleddene RELATIVE, i den rækkefølge i action_configs. Gribeklo lukker ikke lister de andre årsager.
• Et kamera falder lydløst ud midt under optagelsen. Episoden gemmes stadig, og videonøglen eksisterer stadig, hvilket er grunden til, at denne er ubehagelig. Kamera ikke fundet dækker det.

Hele indekset over fejltyper findes på rettelsessiderne. Hvis du vælger mellem modeller frem for at fejlfinde en, har politiksammenligningen og arena-indgangen for GR00T N1.7 benchmark-tal med kilder vedhæftet, og ACT mod GR00T N1.7 er den sammenligning de fleste faktisk har brug for, fordi det er valget mellem en model, du kan træne på kortet under dit skrivebord, og en, du skal leje en 80 GB node for at finjustere. For baggrund om, hvorfor disse modeller opfører sig, som de gør, er VLA-oversigten og SO-100 den komplette guide værd at læse først. Og hvis du endnu ikke ejer en arm, streamer den levende arm en fysisk SO-100 uden tilmelding.