Identify what the video provides
Human task footage can show object use, task order, and visible outcomes. An egocentric camera can also reveal a participant’s working perspective. Those observations may be useful for particular research designs, but the video does not inherently contain the robot joint commands, controller states, or synchronized action targets needed by a policy training pipeline.
Name the missing control information
If the project requires robot action supervision, specify the embodiment, controller interface, action representation, and timing association. Ask whether those records actually exist rather than assuming they can be extracted directly from a person’s movement. Human and robot bodies can interact with objects differently, and a visible human gesture should not be relabeled as a compatible robot command.
Describe supplementary uses precisely
A project may use human footage for task descriptions, visual understanding, or another explicitly designed component. State that role and keep it distinguishable from robot trajectory data. If annotations or derived representations are proposed, document how they are created and what assumptions they introduce. Evaluation should test the intended contribution rather than imply that the two data types are interchangeable.
Write separate acceptance requirements
Review human footage for visibility, task context, and annotations; review robot data for embodiment, action semantics, sensor integrity, and timing. Both need source-specific use review. Send Fiund the purpose of each requested data type and the evidence your model requires. This supports a concrete sourcing discussion without presenting ordinary video as executable robot experience.
Review checklist
- State the role of human footage
- List required robot control records
- Document any derived representations
- Use distinct technical acceptance criteria