Ask two robotics teams where to mount the cameras and you will get two confident, opposite answers. The wrist camera vs head camera question decides what your policy can see at the moment it matters most, and it is far harder to fix after collection than before.
This guide compares the two viewpoints directly, explains the specific way each one fails when used alone, gives you five questions for when you can only afford one, and shares what we observe in headset-driven household capture.
The two viewpoints, and what each one is good at
Head camera
Mounted at roughly eye level and moving with the operator or the robot’s head. It sees the whole workspace, the approach, and the surrounding scene. Crucially, where it points encodes attention: it tells the model which object mattered at each moment.
Wrist camera
Mounted on the forearm or just behind the gripper. It sees the contact point at close range, with the object filling the frame at the moment that matters most. It is nearly immune to the occlusion problem that plagues every other viewpoint.
| Property | Head camera | Wrist camera |
|---|---|---|
| Scene context | Strong | Almost none |
| Contact and grasp detail | Weak at range | Strong |
| Occlusion by the arm | Frequent | Rare |
| Attention signal | Yes, implicitly | No |
| Motion blur | High during head turns | High during fast reaches |
| Calibration stability | Moderate | Poor; it lives on a moving joint |
| Transfers across embodiments | Weakly | Surprisingly well |
| Useful alone | For navigation and approach | For final alignment only |
What the trade-off actually costs you
Head-only datasets fail in a specific and predictable way. The policy learns to approach the right object and then becomes unreliable in the last few centimeters, because at exactly that moment the gripper and forearm block the view. Success rates look acceptable in aggregate and collapse on anything requiring precise alignment.
Wrist-only datasets fail differently. The policy handles contact well but cannot decide what to do or where to go, because it has never seen the scene. It performs beautifully once positioned and cannot position itself.
This is why the honest answer to “which one” is “both, and here is how to weight them.” The interesting question is what you do when bandwidth, storage, or rig constraints force a choice.
How to decide when you can only have one
- Is the task contact-critical? Insertion, deformable handling, and tool use need the wrist view. Transport and sorting can survive without it.
- Does the robot navigate? Anything that moves through an environment needs scene context, so the head view becomes non-negotiable. See mobile manipulation.
- Will this data be pooled across robots? Wrist views transfer better because the relationship between camera and gripper stays roughly constant across embodiments, which matters for cross-embodiment data.
- How long is the task? Long-horizon sequences need the head view to keep track of phase and progress. Our guide to long-horizon capture goes deeper.
- Where is the compute at inference? Two streams at full rate is a meaningful inference cost on an embedded platform. Decide this before you collect, not after.
What we see in headset-driven capture
We run everyday household task capture for a humanoid robotics developer building general-purpose home and service robots, using headset teleoperation where the operator sees through the robot’s own head camera.
That setup makes the trade-off unusually visible, because the operator is working from the head view alone while the wrist cameras record silently alongside. Three things stand out.
- Operators instinctively lean in. When a task gets precise, they move the robot’s head closer, effectively converting the head camera into a near-field camera. That behavior is captured in the data and it is genuinely useful supervision, but it only exists if your rig allows head motion.
- Household clutter punishes head-only capture badly. Kitchen and laundry scenes are dense and reflective. The arm occludes constantly. Wrist views recover episodes that would otherwise be unusable.
- Wrist calibration drifts fastest. It sits on the most-moved joint on the robot. Per-session calibration is not optional here, it is the difference between a usable batch and a wasted week.
The full picture of that program is in VR headset teleoperation for everyday tasks.
Practical setup guidance
- Run both, weight the head view higher for policy input unless the task is contact-dominated.
- Lock exposure per session. Auto-exposure on a wrist camera swings wildly as it approaches surfaces, and the model learns lighting instead of geometry.
- Use a wider lens on the wrist than feels right. Narrow fields of view lose the object during the final approach.
- Record camera extrinsics per session and store the reference in the episode log, as covered in demonstration log design.
- Keep the raw streams. Downsampling decisions look obvious at collection time and wrong a year later.
- Add a third fixed view if you can afford it. Not for training, but for evaluation and dispute resolution during QA.
Paired viewpoints pay off outside manipulation too. Our aerial perception case study reports a 3x detection rate from paired drone-and-ground capture.
Frequently asked questions
Is a head camera the same as an egocentric camera?
A head camera is one type of egocentric camera. Wrist cameras are also egocentric in the sense that they move with the actor. The broader concept is covered in what egocentric data collection means.
Can we add a wrist camera to a dataset we already collected?
No. You can re-collect a representative subset and study whether the missing view explains your failure mode, which is usually cheaper than re-collecting everything.
Do wrist cameras need depth?
Often not. At close range, monocular wrist views carry enough geometric cue for grasping. Depth earns its place more at the scene level, where reach distance matters.
How many cameras is too many?
The limit is usually sync and storage rather than model capacity. Three to four synchronized streams is the practical sweet spot for most manipulation programs.
Viewpoint is not a hardware detail. It decides which half of the task your policy will be bad at. If you are specifying a rig and want the camera plan reviewed against your task list, tell us what you are building.
