rs1g6r 1
Robot learning runs on shared data, and most of us download a dataset, check that it loads, and start training. I built an open-source checker, rdq, to look at what we usually skip: whether we’re allowed to use the data, and whether the camera footage is usable. Full write-up: rdq/docs/findings-2026-10.md at main · s1g6r/rdq · GitHub
Licences (3,000 most-downloaded LeRobot datasets):
- 56.5% carry apache-2.0 on an unedited template card, most likely the upload tool’s default rather than the owner’s choice.
- 200 of the 304 that trace to a known public dataset declare a different licence from the original, mostly CC BY 4.0 data relabelled apache-2.0 or MIT (still usable, but the credit requirement drops off on paper).
- On LeBoard, 9 of 91 datasets carry a licence that matches their source, and 4 have no dataset card.
Video (every frame of about 4,600 episodes in 20 datasets, every flag checked by eye): a second camera that freezes at the start of six episodes, a camera moved halfway through a dataset, and a few near-identical 5-second episodes with no task in them. I’ve told the owners. (Update: the owners say those short clips are deliberate no-bottle examples, so that one isn’t a defect. rdq can flag an episode as unusual, not tell you why.) Three false alarms came up on the way and were fixed; the write-up explains them.
Try it: `pip install "rdq[video] @ git+https://github.com/s1g6r/rdq"`, then `rdq check owner/dataset --video-full`. There’s also a no-install licence check as a Space (rs1g6r/rdq).
If you maintain, collect or buy robot data, I’d like to hear which checks you wish existed. Send me a dataset or a sample delivery and I’ll send back the report.
[rs1g6r](https://discuss.huggingface.co/u/rs1g6r)
2
Update, five days on:
- rdq is on PyPI now:
pip install "rdq[video]", thenrdq check owner/dataset --video-full. - I ran the frame-by-frame check on about 100 more datasets, including 62 of LeBoard’s at the versions it pins. Two more problems held up and were reported to the owners: an episode that renders black in both cameras of
zima-robot/liftplace-ee-xyz-500-v2, and inlerobot/berkeley_rpttwo episodes with no video at all (the file ends where the episode should start) plus one episode that repeats another. - False alarms are at 14 now (from 3), each checked by eye, fixed and turned into a test: a humanoid’s stereo head cameras read as swapped, a precise industrial robot whose repeat takes looked like copies, a white table read as a covered lens, a 1 fps camera whose scripted takes matched over an empty table.
The write-up is updated with all of it: [rdq/docs/findings-2026-10.md at main · s1g6r/rdq · GitHub](https://github.com/s1g6r/rdq/blob/main/docs/findings-2026-10.md)
[nootxlm](https://discuss.huggingface.co/u/nootxlm)
3
The check I’d most want is the one that separates a defect from a deliberate example: compare each flagged episode’s frame change against its own action and state log. If the robot moved on paper while the frame stayed frozen, black, or missing, that could be a capture defect; if both stayed still, it is more likely an intentional idle or no-task clip — that one comparison could turn several of the eye-checked false alarms into an automatic verdict.