Quality checks for a robot episode: continuity, timestamps, dropped frames, drift
Four checks to run on every episode before annotation, with the signal each one catches and how to set its threshold.
Most robot data defects are visible in the numbers before anyone watches the video. A camera that dropped a third of its frames, a joint stream that stalled and repeated its last sample, a clock that drifted forty milliseconds over a session — all of these are detectable in code. The practical approach is an automated pass at ingest that runs on every episode, emits a pass or fail with a reason code, and blocks anything that fails from reaching annotation, because annotation is the expensive step and a defect that reaches it has already cost more than the check that would have caught it.
Trajectory continuity
Check the per-step change in every joint angle against the control rate. At a fifty-hertz control loop, a step larger than the joint's maximum speed divided by fifty is physically impossible, which means an encoder glitch, a teleoperation jump, or a packet loss that was interpolated badly.
Look for flat stretches as well as spikes. A joint reporting the identical value for a long run in the middle of a motion usually means the stream stalled and the last sample was repeated, and a policy trained on that learns to hold still at arbitrary moments. Set the threshold from the hardware, using the arm's rated maximum joint velocity, then tighten it if you also want to flag fast operator corrections, which are valid motion but often mark the moment a demonstration went wrong.
Timestamp alignment
Every stream carries its own timestamps — joints, gripper, each camera, any tactile sensor — and they will not agree. Measure the offset rather than trusting the nominal recording start. Have the operator move the arm so a rigid marker crosses a fixed point, or flash an LED visible in every camera at once, then take the difference between the timestamps in each stream.
Check monotonicity first, since a timestamp that goes backwards means the clock source changed mid-session and invalidates the episode. Then check drift by repeating the event at the end. Consumer clocks can drift by tens of milliseconds over an hour, which is enough to misalign actions against frames. Fix the alignment in code rather than by hand: resample every stream to one control rate and store the original timestamps alongside the resampled series.
Dropped frames and short streams
Compare the actual frame count against the nominal rate multiplied by the duration. A thirty-frames-per-second camera over a twenty-second episode should deliver roughly six hundred frames, and a shortfall means frames were lost. The worst case is a camera that drops frames only under fast motion, which is where the data matters most. Check the interval between consecutive frames as well, since a gap longer than about one and a half times the nominal interval is real even when the total count looks close.
Verify that every stream has the same episode length within a tolerance. An action array a few hundred steps shorter than the image array is a conversion bug, and it will silently truncate or pad the episode inside the training loader, where nobody is looking.
Calibration drift
Re-run the hand-eye check at the start and end of every session with a fiducial marker at a known pose. If the camera-to-arm transform has moved, every episode in that session carries wrong spatial labels, and nothing else in the pipeline will catch it. The sources worth knowing are a bumped mount, a camera whose intrinsics shift as it warms up, a gripper swapped without recalibration, and a cable-driven mechanism that stretches gradually over a long session.
Store the calibration identifier in every episode's metadata. When drift is found, that identifier is what lets you pull exactly the affected episodes instead of discarding a week of work or, worse, keeping it.
Watch the pass rate, not only the failures
Track pass rate by operator, by day, and by task. A drop for one operator means that operator needs retraining. A drop on one day across all operators means hardware. A drop on one task means the task is harder than the pilot suggested, which is a planning problem rather than a collection problem. Keep every rejected episode with its reason code rather than deleting it, because the rejects are the diagnostic signal and a defect that is not understood will be re-recorded next month at the same cost as the first time.