Defining V2: Learning from V1 in the Field

Translating field feedback and technical learnings into requirements for the next-generation device.

Evyatar Bluzer
3 min read

V2 planning is underway, and this time we get to ask a better question than "what do we want?" We can ask what V1 taught us we need.

V1 Pain Points (Perception)

From telemetry and user feedback, four pain points dominate.

Tracking failures in challenging lighting account for 35% of reported issues. People want to use the device near windows, in dim rooms in the evening, and in transitions like walking between rooms. Relocalization is unreliable at a 12% failure rate - maps go stale, users don't understand map management, and content "jumps" unexpectedly. Hand tracking is a frequent complaint: gesture recognition was cut, the tracking range is too limited, and performance degrades with occlusion. Two of those trace back to calls I made in writing. In July I cut gestures on the theory that a robust core beats shipping everything mediocre; the core is robust, and the missing gestures are still the complaint. A year ago I wrote that most interactions happen at 30-60cm, so covering that range would suffice. It doesn't. And battery life caps sessions. Heavy use drains the pack in 2.5 hours, with thermal throttling kicking in sooner. In September I read the 8-minute median session as proof that battery life mattered less than we designed for. The median was the wrong statistic to design around.

V2 Perception Requirements

Tracking Robustness

  • Target: under 1 tracking loss per hour of normal use (10x improvement)
  • Approach: Better sensors + smarter algorithms + wider operating envelope

Sensor Upgrades Needed

V1V2 TargetWhy
Tracking cam: 640x4801280x720+More features, better low-light
Depth: 320x240 ToF640x480Better meshing, hand tracking
Eye cam: 320x320480x480+More accurate gaze
IMU: 1kHz2kHz+Better fast motion handling

Hand Tracking

  • Full gesture recognition (pinch, grab, point, palm)
  • Near-range: 20-60cm from face
  • Far-range: 40-100cm (arm's length)
  • under 5° fingertip accuracy

Power Budget

  • Target: Same or better battery life with more capability
  • Approach: New chip architecture, algorithmic efficiency, smart power management

Architecture Decisions

Three decisions are already firm. V2 gets a dedicated ML accelerator; V1 ran ML on the GPU, and we need an NPU for efficiency. More compute moves on-device, because the cloud isn't reliable enough for real-time - process locally, sync when possible. And sensors and algorithms get co-designed this time, rather than picking sensors first and adapting algorithms to whatever arrives.

What We're Not Changing

Some V1 decisions hold up. The visual-inertial approach to tracking is proven and robust. ToF stays for depth, since it handles outdoor conditions better than structured light. And we keep stereo tracking cameras, which we need as a stereo depth backup.

Timeline Pressure

Chip tape-out is in 6 months and sensor orders lock in 4, so requirements have to be finalized NOW for hardware that ships in 2+ years.

V2 lock-in timelineA horizontal timeline with four points: requirements final now, highlighted; sensor orders lock at 4 months with four sensor targets listed; chip tape-out at 6 months with a dedicated NPU; V2 hardware ships at 2 plus years.Requirements finalnow, January 2019Chip tape-out, 6 monthsSensor orders lock, 4 monthsV2 hardware ships, 2+ yearsdedicated ML accelerator (NPU)tracking cam 1280x720+, depth 640x480 ToFeye cam 480x480+, IMU 2 kHz+
What locks when for V2: sensor orders in 4 months and chip tape-out in 6, for hardware that ships 2+ years out, which is why the requirements are being frozen now.

The V1 experience helps because we know what matters this time. We will still get some things wrong anyway, which is why we're building in flexibility wherever we can.

Comments