A successful demonstration can still be a poor training example. I ran into this while building a remote teleoperation and data collection setup: the robot could complete the task on camera while part of the recording quietly stopped describing what was happening.
That experience made data quality feel much more physical. It starts with the sensors, actuators, and collection process long before a dataset reaches a training job.
A convincing video can hide broken feedback
In one collection session, the robot kept moving while its recorded joint feedback stayed frozen. The commands and video looked active; the measured state told a different story.

A sustained feedback failure across several demonstrations.

Comparing commands with measured state makes the failure visible.
This is why I want to look across signals. A flat trace might mean the robot is holding still, or that its feedback has stopped updating. Episode lengths and sudden measurement jumps can flag other recordings worth reviewing. The goal is to understand the interaction behind the numbers.

Simple diagnostics help direct attention to unusual recordings.
The hardware changes during a session
Some problems are subtler than a dead feedback stream. Encoder readings can drift, and temperature, load, and mechanical changes can affect the relationship between a reported angle and the actual tool position.
I want to know how an arm behaves when cold, after sustained use, and with the tool it will actually carry. Repeating a reference pose and checking it against an external view can reveal changes that a clean-looking encoder trace misses. The graphs here show recording faults; they do not establish a thermal cause.
QDD makes the trade-offs tangible
Quasi-direct-drive hardware is appealing for its torque and backdrivability. I also have to account for the mass being moved and how long the arm takes to settle before a precise interaction.
On backdrivable hardware, holding and damping depend strongly on the controller, load, and mechanics. The long settling I have encountered matters at the fingertips, even when the commanded movement appears finished. It can also become part of the demonstrations as operators learn to pause around the arm’s behaviour.
That is why I think the right hardware depends on the task. Continuous load, precision, contact behaviour, and the ease of collecting good demonstrations all matter. A learning algorithm inherits the consequences of those choices. Understanding them is part of building a dataset I can trust.
Original post and graphs · Related: Remote workstation