GR00T rejects my dataset: LeRobot v3.0 is not supported

What the rejection looks like from the outside

Nothing about the first minute looks wrong. The job takes a slot, a container comes up, the status turns RUNNING, and then it lands on FAILED before the first metric is written. The run page shows an empty chart because there was never a step to plot. The message talks about dataset metadata rather than naming a version, so the natural reading is that the upload broke halfway, and the natural response is to upload the same directory again. That reproduces the failure exactly.

The upload is fine. The GR00T trainer reads the dataset metadata, finds a format it does not load, and stops. Parsing two lines of JSON is cheap, which is precisely why the failure arrives so fast. A slow failure would mean something else went wrong.

The one field that decides

A LeRobot dataset carries its format version in meta/info.json, at the top of the file. GR00T loads v2.1. It does not load v3.0. This applies to both GR00T N1.7 at /policies/groot-n1-7 and GR00T N1.5 at /policies/groot-n1-5, since they share the same data path.

{
  "codebase_version": "v3.0",
  "robot_type": "so100",
  "fps": 30,
  "total_episodes": 58,
  "features": {
    "observation.state":         { "dtype": "float32", "shape": [6] },
    "action":                    { "dtype": "float32", "shape": [6] },
    "observation.images.scene":  { "dtype": "video",   "shape": [480, 640, 3] },
    "observation.images.wrist":  { "dtype": "video",   "shape": [480, 640, 3] }
  }
}

Note what is not wrong here. The robot type is right, the frame rate is right, both camera streams are present with sensible shapes, and 58 episodes clears the 50 that GR00T needs before a result is worth judging. None of that gets read, because the version check comes first.

# Five seconds, before you upload anything
grep codebase_version meta/info.json
#   "codebase_version": "v3.0",

# While you are in there, confirm the episode count matches what you recorded
grep total_episodes meta/info.json
#   "total_episodes": 58,

Why this usually means the data came from somewhere else

The desktop client writes v2.1. That is the default and it is the format the platform records, uploads and trains on end to end. So if every episode in the set came out of ay-robots record on your own machine, a v3.0 tree is close to impossible. The version field is a clue about origin, and in practice it points at an import.

Confirm it in four steps

1. 1
   Read the version field

   Open meta/info.json in the dataset directory, or grep it. If it reads v2.1 the version is not your problem and you should look at the failure message again, because something else stopped the run.

   bash

   grep codebase_version meta/info.json

2. 2
   Confirm the trainer refused it, not the upload

   A dataset that never finished processing cannot be trained on either, and that looks similar from the dashboard. Pull the job record and read status together with errorMessage. A job that reached RUNNING was handed a real container, which means the upload arrived.

   bash

   curl -X POST https://www.ay-robots.com/api/mcp \
     -H "Authorization: Bearer $AY_ROBOTS_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "jsonrpc": "2.0",
       "id": 1,
       "method": "tools/call",
       "params": {
         "name": "get_training_job",
         "arguments": { "job_id": "job_7ad402" }
       }
     }'

3. 3
   Check whether you still have the local original

   If you recorded the episodes yourself, the local copy is the v2.1 source of truth and the cloud copy is the import that went sideways. List what is on the machine before you plan a conversion you may not need.

   bash

   ay-robots datasets list --local

4. 4
   Pick a route and only then re-upload

   Upload the converted copy under a new name rather than replacing the original. Two datasets that differ only in format are worth the storage, because the next time a run fails you want to be able to tell which one you trained on.

   bash

   ay-robots datasets upload cube-pick-v21 --name "SO-100 cube pick v2.1"

The three routes out

The third route needs a caveat, because it is easy to over-read. The hard rejection lives in the GR00T trainer. ACT, SmolVLA and Pi0.5 load through the lerobot dataset layer, which is the code that introduced v3.0 in the first place, so that path is the tolerant one. It is a fallback and not a guarantee: v2.1 is the format this platform records and the format documented for all five models in the catalog. A v2.1 copy is the answer that always works. If you take the fallback, /train/smolvla-on-so-100 is the cheapest way to find out whether the episodes are worth converting at all, and /compare/groot-n1-7-vs-smolvla covers what you give up.

After the conversion

Re-read meta/info.json on the converted copy before you queue anything. A conversion that silently dropped episodes is the second failure in this family, and it does not announce itself: the run starts, the loss falls, and you spend an evening wondering why a policy trained on what you believe were 58 episodes behaves like one trained on 30. Compare total_episodes against the number you recorded, and confirm both camera keys survived under features.

Frequently asked questions