[Hubo1231]

Improves training data-loading throughput and removes periodic pipeline stalls.

Changes

• Skip decoding tactile video streams that are discarded by the configured repack transforms.
• Deliver batches as workers finish with in_order=False, avoiding head-of-line blocking.
• Add an InfiniteSampler to prevent iterator teardown and prefetch warm-up at epoch boundaries.
• Preserve explicitly supplied samplers, including the PyTorch DDP path.
• Add configuration switches (DataConfig.tactile, TrainConfig.strict_batch_order), H100 training examples, regression tests, and benchmark documentation.

Results

Controlled 400-step H100 training A/B:

• Total time: 770.8 s → 715.7 s (1.08x speedup)
• Data stalls over 0.5 s: 20 → 0
• Maximum next_batch wait: 7.83 s → 0.43 s

Selective tactile decoding reduces single-sample __getitem__ latency from 262.4 ms to 153.3 ms (1.71x). It also reduced startup-to-first-batch time by 37.3 s, although it did not improve steady-state end-to-end throughput in the tested H100 configuration because decoding was not the remaining bottleneck.

A separate 64,951-step production run confirmed that stalls at worker-rotation and epoch boundaries were eliminated. The remaining long waits occurred after checkpoint saves. The production comparison documented in this PR is cross-task and is therefore not presented as a controlled experiment — only the 400-step A/B above is.

Full write-up: docs/data-pipeline-stalls.md.

Test coverage

Regression tests in src/openpi/training/data_loader_test.py cover:

• selective tactile-stream decoding
• validation of repack-required streams
• decoding everything when no whitelist is set
• infinite sampler coverage and determinism
• out-of-order delivery defaults
• strict ordering opt-in
• preservation of explicit samplers

Review round

Addressed in bc394fc and eb6d358:

• SelectiveVideoLeRobotDataset.decode_video_keys now defaults to None ("decode everything") rather than an empty whitelist, so a construction site that forgets to set it degrades to plain LeRobotDataset behaviour instead of silently training on missing images.
• Raised the declared torch floor to >=2.6, the release that added DataLoader(in_order=...).
• Fixed a ruff RUF043 failure in the new tests.
• Dropped docs/data-pipeline-stalls.html, which duplicated the .md in the same directory.
• Documented strict_batch_order in configs/_examples/_FULL_REFERENCE.yaml.
• Translated the two new H100 config comments to English, matching the rest of configs/_examples/.

[Vertax42]

Pushed one commit onto this branch (b1f90d7) — docs/tests only, no behaviour change. Flagging it since it is your PR.

Context: #16 renames the tactile camera keys to follow lerobot-xense 1146d034, where the suffix became the jaw the pad sits on (serial parity) instead of USB enumeration order. This PR needs no functional change for that — TACTILE_KEY_MARKER = "tactile" matches by substring, so the new keys are caught exactly as the old ones were, and the two branches touch disjoint files.

What was misleading was that the comment, the doc table and the _XENSE_VIDEO_KEYS fixture all spelled the streams _tactile_{0,1}, which reads as the naming rather than as one of two. Both spellings are on disk — datasets recorded before that commit have one, later ones the other — so the substring match is load-bearing, not incidental. The commit says that where it matters and parametrises the decode-key tests over both key sets, so a future exact-match "cleanup" fails a test instead of silently skipping four streams nobody reads.

pytest src/openpi/training/ → 71 passed, ruff check clean.

One scheduling note, unrelated to the content: main has strict: true + dismiss_stale_reviews: true, so whichever of #15 / #16 merges second needs Update branch → CI re-run → re-approval. Approving after the update rather than before saves a round trip.