Hur man tränar GR00T N1.7 på ditt eget SO-100 Dataset

NVIDIA levererar ett finjusteringsexempel för exakt den arm du förmodligen äger. Inuti Isaac-GR00T-förvaret finns en mapp som heter demo_data/cube_to_bowl_5: fem episoder, 4 148 bildrutor vid 30 fps, redan skrivna som LeRobot v2.1, med en matchande modalitetskonfiguration under examples/SO100/. Dess meta/info.json rapporterar robot_type: so101_follower, vilket i LeRobot är samma konfigurationsklass som so100_follower. Det är genuint användbart, eftersom det betyder att referensvägen för GR00T N1.7 på en sex-frihetsgrads-hobbyarm underhålls av personerna som skrev modellen. Det är inte en nedskalad humanoid-demo, det är samma arm.

Den dåliga nyheten är avståndet mellan Jag spelade in 60 episoder och armen utför uppgiften. Det finns ungefär sex ställen där denna pipeline misslyckas tyst snarare än högljutt, och fyra av dem finns i filer som de flesta aldrig öppnar: meta/modality.json, Python-datakonfigurationen, meta/relative_stats.json, och datasetets egen versionssträng. Denna guide går igenom den manuella vägen från början till slut med de verkliga kommandona, och visar sedan samma jobb som ett formulär på AY-Robots. Allt nedan kontrollerades mot Isaac-GR00T:s huvudgren per den 20 augusti 2026 (n1.7-release-linjen) och lerobot 0.6.1, publicerad på PyPI den 3 augusti 2026. Uppströms rör sig snabbt, och där en flagga döptes om anges det i denna artikel.

Vad GR00T N1.7 faktiskt är

GR00T N1.7 är en syn-språk-handlingsmodell med den dubbelsystemslayout som beskrivs i den ursprungliga GR00T N1-rapporten: en syn-språkmodul som läser kamerorna och instruktionen, och en diffusionstransformator som omvandlar detta till en sekvens av kontinuerliga motoriska kommandon. N1.7 ersatte den första halvan. Eagle-ryggraden från N1.6 är borta, utbytt mot nvidia/Cosmos-Reason2-2B på en Qwen3-VL-arkitektur, och modellen förtränades på ungefär 20 000 timmar av egocentrisk mänsklig video utöver robotdata. NVIDIAs egen rapport anger siffran till 20 854 timmar och rapporterar att en ökning från 1k till 20k timmar mer än fördubblar den genomsnittliga uppgiftskompletteringen.

Den andra halvan ändrades också, på sätt som är viktiga för din körning. Aktionshuvudet minskade från 32 diffusionslager till 16, den förutsagda aktionssekvensen växte från 16 steg till 40, och den maximala tillstånds- och aktionsbredden gick från 29 till 132. Dessa tre siffror kommer från ändringsloggen i förrådets README; NVIDIAs egen lanseringspost beskriver fortfarande System 1 som en 32-lagers DiT, så där de två inte stämmer överens, lita på det förråd du är på väg att klona. Aktioner uttrycks som standard i ett relativt gripdon utrymme, deltor från den aktuella posen snarare än absoluta mål, vilket är det som överhuvudtaget möjliggör överföring av manipulationsförkunskaper från mänsklig video till robotstyrning. Huvudet i sig är en flödesmatchande diffusionstransformator, samma familj som Pi0.5 men med en annan ryggrad framför sig. Om du fortfarande använder den tidigare generationen, N1.7 mot N1.5 behandlar huruvida uppgraderingen motiverar att du gör om din pipeline.

Dessa tre sista rader förklarar det mesta av den besvikelse som folk rapporterar. Rubrikens 27.9 ms är en TensorRT-motor på en H100 med en kamera och fyra denoising-steg. Ren PyTorch på samma kort är 85.8 ms, och modellkortet anger skillnaden till 3.08x. Inget av dessa nummer inkluderar ett serving-lager, en andra kamera eller ett nätverkshopp. De 152 ms per aktionssteg som AY-Robots anger för sin serverade GR00T N1.7 är siffran med serving i loopen, och en tur och retur-resa över det publika internet kommer utöver det. Mer om detta i slutet. För siffrorna bredvid andra modeller, GR00T N1.7 mot Pi0.5 och GR00T N1.7 mot SmolVLA lägger ut dem sida vid sida.

Vad körningen behöver innan du skriver något

Steg 0: avsnitten själva

Allt nedan förutsätter att du redan har spelat in avsnitt. Om du inte har det, är det det verkliga första steget och det är det som avgör hur bra resultatet kan bli, eftersom imitationsinlärning inte kan återställa information som inte finns i datan. Kalibrera båda armarna först, kör sedan följaren med en ledararm medan lerobot-record skriver parquet-filerna och kameraströmmarna. Om kalibreringen är felaktig, beskriver ledvärdena i din datamängd en något annorlunda robot än den som senare kommer att utföra policyn, och ingen mängd träning kan åtgärda 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 är att spela in minst 50 avsnitt med cirka 10 per objektplats, hålla kamerorna fixerade och hålla gripbeteendet konsekvent. Lägg till variation senare, inte i början. Tumregeln att komma ihåg: om du inte kunde utföra uppgiften själv enbart från kamerabilderna, kan policyn inte heller. För den armspecifika installationen, komma igång med SO-100 och SO-100 LeRobot-sidan täcker portar, kalibrering och kamera-index. På AY-Robots kan du också göra detta över internet från webbläsaren med hjälp av teleoperation och spela in direkt från sessionen.

Steg 1: datasetet måste vara LeRobot v2.1

Detta är det vanligaste hindret. LeRobots nuvarande CODEBASE_VERSION på main är v3.0, så allt du spelar in idag med en aktuell verktygskedja kommer ut som v3.0. GR00T:s laddare förväntar sig v2. Repositoryt är tydligt med varför: många uppströms dataset som DROID, LIBERO och Bridge publiceras i v2, och inbyggt stöd för båda är planerat men inte levererat. Så konverteringen ligger på dig, och den körs i sin egen virtualenv av en konkret anledning: scripts/lerobot_conversion har sitt eget pyproject som kräver Python 3.10 eller 3.11 och låser lerobot till en specifik git-commit, medan Isaac-GR00T själv kräver Python 3.12. Installera konverteraren från repositoryns rot och du får gr00t paketet istället, vilket är misstaget dess README varnar för. Om du är ny med formatet, förklarar LeRobot-datasetet ordlisteposten vad som faktiskt finns inuti ett sådant.

# 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 vill ha efter konvertering är den klassiska v2-layouten: meta/info.json, meta/episodes.jsonl, meta/tasks.jsonl, parquet-filer under data/chunk-000/, MP4-filer under videos/chunk-000/observation.images./, och en extra fil som standard LeRobot inte har. Den extra filen är där de flesta återstående felen finns.

Steg 2: modality.json, de sex siffrorna som avgör allt

I ett LeRobot-dataset lagras robotens tillstånd och handling som platta float32-arrayer. För en SO-100 har båda formen [6]: fem armleder och en gripklo. Demodatasetet namnger dem shoulder_pan.pos, shoulder_lift.pos, elbow_flex.pos, wrist_flex.pos, wrist_roll.pos, gripper.pos, men dessa namn finns i info.json och inget i parquet-filen anger vilket index som är vilket. meta/modality.json tillhandahåller den mappningen, och GR00T kommer inte att träna utan den. Här är den som lagringsplatsen levererar för SO-100, ordagrant.

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

Kopiera den till din konverterade datamängd på meta/modality.json och byt namn på videonycklarna till vad dina kameror faktiskt heter. Om du spelade in med en enda takkamera med namnet top, då är original_key observation.images.top och det vänliga namnet är det som din datakonfiguration kommer att referera till. De två måste överensstämma, och ingen av dem kontrollerar den andra åt dig. Språkanmärkningen är värre, eftersom samma nyckel måste förekomma på tre ställen.

Steg 3: datakonfigurationen, relativ arm och absolut gripare

Modalitetskonfigurationen är en Python-fil snarare än JSON, eftersom den också bestämmer hur varje åtgärdsgrupp representeras. Detta är den del av N1.7-arbetsflödet som inte fanns i samma form i N1.5, och den del som är värd att läsa två gånger. Den levererade SO-100-konfigurationen förutsäger de fem armlederna som RELATIVE deltan från det aktuella tillståndet och griparen som en ABSOLUTE målposition, eftersom en binär öppen-eller-stängd signal fungerar bättre som ett mål än som ett 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)

Två detaljer här kommer att kosta dig en dag om du inte känner till dem. För det första, action_configs är positionell: dokumentationen kräver samma längd och samma ordning som modality_keys, och de är tydliga med konsekvensen av att göra fel, vilket är att fel representation tillämpas tyst. Din gripare tränas som ett delta och din arm som ett absolut mål, och det finns inget felmeddelande. För det andra, register_modality_config hävdar att taggen inte redan är registrerad, så en andra NEW_EMBODIMENT-konfiguration i samma Python-process dör med Embodiment tag ... already registered. Du kan inte importera två av dessa till ett och samma skript. En tredje regel tillämpas senare, vid driftsättning: åtgärden delta_indices måste vara det sammanhängande intervallet som börjar vid noll. Ett glest fönster som [0, 4, 8] avvisas, eftersom allt nedströms indexerar den förutsagda delen linjärt och annars skulle exekvera fel rader.

Steg 4: miljön

N1.7 flyttade repositoryt till uv och Python 3.12. Den gamla conda plus pip install -e . sökvägen finns fortfarande i en hopfälld sektion av README, men den varnar för att GPU-beroenden inklusive flash-attn och TensorRT kan behöva manuell installation. Använd uv om du inte har en specifik anledning att inte göra det. När det gäller flash-attn, en detalj sparar förvirring: du kommer att se Installing flash-attn utskrivet vid varje uv run. Det byggs inte om. uv validerar om ett URL-fäst wheel som redan är cachat, och det tar två eller tre sekunder.

1. 1
   Installera git-lfs, klona sedan med submoduler

   git-lfs är obligatoriskt, inte valfritt. Utan det laddas parquet-filerna i demo_data/ ner som pekstubbar, och demo-körningen misslyckas på en datamängd som ser ut att finnas i fillistan.

   bash

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

2. 2
   Installera uv och synkronisera miljön

   Standardinstallationen hämtar GPU-beroendena inklusive flash-attn och TensorRT. På en ny A100- eller H100-avbildning är detta det längsta enskilda steget, så gör det innan du börjar ägna uppmärksamhet åt något annat.

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

   Gör detta före den första träningsstarten, inte efter att den misslyckas åtta minuter in.

   bash

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

4. 4
   Sanitetskontroll på den medföljande SO-100 demo-datan

   Innan du rör din egen inspelning, kör 2000 steg på demo_data/cube_to_bowl_5. Det är fem episoder, det slutförs snabbt, och det bevisar miljön snarare än dina data. Om denna körning misslyckas, kommer inget du gör med din datamängd att hjälpa.

   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

Steg 5: kommandot för finjustering och vad dess flaggor faktiskt har för standardvärden

Byt ut demodatauppsättningen mot din egen och lägg till de inställningar du faktiskt vill ha. Nedan är den fullständiga formen som förvaret använder i sin egen handledning för ny förkroppsligande, inklusive flaggorna för augmentation och checkpointing som det korta README-exemplet utelämnar. Detta är i snäv bemärkelse: språkryggraden och den visuella kodaren förblir frysta, och det som tränas är projektorn och diffusionsåtgärdshuvudet.

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 sista raden är inget stavfel. launch_finetune.py är en tyro CLI genererad från en dataklass, och den dataklassen har inget seed-fält. README-filen noterar separat 5 till 6 procents varians mellan körningar orsakad av icke-deterministisk bildförbättring. Två körningar med identiska flaggor kommer inte att producera identiska checkpoints, vilket spelar stor roll när du försöker avgöra om en hyperparameterändring hjälpte eller om du hade tur. Som jämförelse använder lerobots egen tränare seed 1000 som standard, och LeRobot GR00T-receptet skickar --seed=42 explicit.

Vad en körning på 20000 steg kostar

GR00T N1.7 kräver ett 80 GB-kort, så kostnadsfrågan har ett snävt svar. På AY-Robots körs groot1.7-tränaren på A100 80 GB- eller H100 80 GB-nivån, där en körning tar 3 till 6 timmar till 1.20 till 2.00 USD per timme på spotmarknaden. Det är ungefär 4 till 12 USD för standardjobbet på 20000 steg. Samma uppgift på SmolVLA eller ACT hamnar på ett 24 GB-kort till 0.30 till 0.60 USD per timme och 1 till 3 USD per körning. Det är den verkliga avvägningen: GR00T kostar ungefär fyra gånger så mycket per försök, och du kan inte köra det på en 4090 under ditt skrivbord.

Det minsta antalet på 50-episod är ett golv, inte ett mål. NVIDIAs egen FAQ är mer krävande: ungefär 100 trajektorier för en enkel plock-och-placera på fast plats, 500 eller fler för komplexa eller flerstegsscener, och 100 till 500 för finmanipulation. Om du har 20 episoder, ägna eftermiddagen åt att spela in snarare än kvällen åt att finjustera. guiden för datainsamling beskriver vad som skiljer en användbar episod från en bortkastad, spela in din första datamängd är den korta versionen, och SO-100 datainsamling är den armspecifika.

Steg 6: utvärdering i öppen slinga innan du rör armen

Sätt inte en ny kontrollpunkt på en fysisk arm för att ta reda på om träningen fungerade. Kör open-loop-utvärderingen först. Den spelar upp ett inspelat avsnitt, frågar modellen om åtgärder vid varje steg och plottar förutsägelse mot sanning med MSE och MAE. Det kostar ingenting och det fångar upp mappningsfelen från steg 2 och 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

Arkivet vägrar medvetet att publicera ett mål-MSE för anpassad data, och det är rätt beslut: siffran beror på dina åtgärdsenheter, din uppgift och din datasetstorlek, så ett tröskelvärde kopierat från någon annans arm betyder ingenting. Vad som är meningsfullt är trenden. Här är referenskörningen som arkivet dokumenterar på en enda H100 med demo-datasetet med fem avsnitt och 2000 steg.

Formen är signalen, inte de absoluta värdena. Felet bör minska stadigt när träningssteg ackumuleras. Genomsnittligt över alla fem träningsavsnitt snarare än enbart trajektoria 0, fick repots slutliga kontrollpunkt ungefär 7.5 MSE och 1.5 MAE, så även referenskörningen läses annorlunda beroende på vilka avsnitt du genomsnittar. Registrera din egen baslinje med det omodifierade demotkommandot innan du ändrar något i din egen data: om du inte kan reproducera en känd fungerande körning kan du inte skilja ett installationsfel från ett dataproblem. Lagringsplatsen kartlägger också de vanliga symptomen till orsaker, och var och en av dem är operationell snarare än en modellbugg.

Den andra vägen: lerobot-train istället för Isaac-GR00T

Den nuvarande LeRobot-versionen, 0.6.1 på PyPI sedan 3 augusti 2026, erbjuder ett andra och ganska annorlunda sätt att finjustera samma basvikter. LeRobot exponerar GR00T N1.7 som en policytyp och tränar den via sin egen lerobot-train ingångspunkt. Två saker är viktiga här. LeRobot CLI är en uppsättning konsolskript, så allt du läser som säger python lerobot/scripts/train.py är föråldrat och kommer inte att köras. Och LeRobot tog bort stödet för GR00T N1.5 helt, och avvisar N1.5-kontrollpunkter och konfigurationer med en migreringsanteckning, så om du behöver N1.5 via LeRobot måste du låsa till lerobot==0.5.1, den senaste versionen som stöder det, publicerad 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

Två sätt att få samma checkpoint

Få tillbaka kontrollpunkten på armen

Isaac-GR00T använder en server-klient-uppdelning över ZMQ. Policyn körs på GPU:n, och en tunn klient på robotmaskinen skickar observationer och tar emot åtgärdsbitar. SO-100-exemplet är tillräckligt komplett för att kopiera: starta run_gr00t_server.py med din kontrollpunkt och --embodiment-tag NEW_EMBODIMENT, kör sedan eval_so100.py på robotsidan med serieporten, robot-ID:t, kamera-indexen och språkinstruktionen. Kameranamnen i det kommandot måste matcha de vänliga namnen från din modality.json, inte OS-enhetsnumren.

# 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 till den ärliga delen om var policyn körs, eftersom träning och drift har olika hårdvarukrav. Finjustering kräver 40 GB eller mer. Inferens gör det inte: README anger 16 GB eller mer och nämner RTX 4090 explicit, så ett kort du redan äger kan köra en checkpoint som det aldrig hade kunnat producera. Vad som avgör om policyn känns responsiv är inte VRAM, det är var servern är placerad. På AY-Robots är GR00T N1.7 endast molnbaserad, så kontrollslingan betalar en tur och returresa över det publika internet utöver de 152 ms per åtgärdssteg, och endast SmolVLA och ACT körs också lokalt. För långsam plockning och placering är en fjärr-pod hanterbar. För något reaktivt är det inte det: policyn blir tveksam på ett sätt som ser ut exakt som ett träningsfel men inte är det. ACT med 20 ms per åtgärdssteg är modellen som tolererar den snävaste slingan, SmolVLA ligger på 245 ms, och ingen mängd av latensjustering köper tillbaka en tur och returresa som redan har förbrukats. Kör din första policy går igenom serversidan från början till slut.

Vad som faktiskt går fel

• GatedRepoError vid första körningen. Du har inte beviljats åtkomst till nvidia/Cosmos-Reason2-2B, eller så autentiserade du dig inte. Detta inträffar efter att GPU-klockan redan har startat.
• Dataset avvisades vid laddning. Nästan alltid ett v3.0-dataset. Konvertera det nedåt. Se dataset avvisades som v3.
• IndexError om felaktiga booleska dimensioner. Du ändrade delta_indices och återskapade inte statistiken.
• Slut på minne vid batch 32. Minska --global-batch-size och öka --gradient-accumulation-steps, eller minska --num-shards-per-epoch, vilket konfigurationen uttryckligen föreslår när VRAM är begränsat. Se slut på minne under träning.
• Förlusten sjunker, policyn gör ingenting. Det finns ingen valideringsdelning som standard, så en ren träningskurva bevisar väldigt lite. Denna sida täcker diagnosen.
• Fungerar i din installation och ingen annanstans. Förväntat med ett litet dataset filmat under en ljusförhållande. NVIDIA rekommenderar färgjitter-augmentation plus 20 till 50 episoder under olika ljusförhållanden. Mer här.
• Gripdonet stängs aldrig ordentligt. Kontrollera att gripdonets åtgärd är ABSOLUT och armlederna RELATIVA, i den ordningen i action_configs. Gripdonet stängs inte listar de andra orsakerna.
• En kamera slutar tyst att fungera mitt under inspelningen. Episoden sparas fortfarande och videonyckeln finns kvar, vilket är anledningen till att detta är obehagligt. Kamera upptäcks inte täcker detta.

Hela indexet över fellägen finns på . Om du väljer mellan modeller snarare än att felsöka en, och har benchmark-siffror med källor bifogade, och är den jämförelse de flesta faktiskt behöver, eftersom det är valet mellan en modell du kan träna på kortet under ditt skrivbord och en du måste hyra en 80 GB nod för att finjustera. För bakgrund om varför dessa modeller beter sig som de gör, är VLA-översikten och kompletta SO-100-guiden värda att läsa först. Och om du inte äger en arm ännu, strömmar en fysisk SO-100 utan registrering.