cd ~/
Smart GlassesRay-BanVPSWearablesMeta

VPS for Smart Glasses: Ray-Ban Stories Considerations

Adapting visual positioning for smart glasses form factor - different sensors, different constraints, different use cases.

Evyatar Bluzer
3 min read

Meta is launching smart glasses with Ray-Ban. VPS is not in V1, but we are already planning for future integration, and the constraints look nothing like Quest.

Ray-Ban vs Quest

AspectQuestSmart Glasses
Form factorHeadset (500g)Glasses (50g)
ComputeSnapdragon XR2Low-power SoC
CameraWide-angle stereoSmall forward-facing
Battery3-4 hours activeAll-day target
Use caseImmersive XRAmbient assist

The power and compute constraints are dramatically tighter. A 50g pair of glasses chasing an all-day battery cannot spend what a 500g headset spends.

What does VPS on glasses actually need?

The power budget is under 10mW average, against the 150mW target the Quest MVP came in over. That rules out continuous feature extraction entirely; everything has to be event-triggered. The camera is consumer-grade with fixed focus, which means lower resolution, more noise, and a less controlled viewpoint.

The use cases differ from Quest too. Navigation assistance, POI information, contextual reminders, sharing your location socially - none of that needs VIO-level continuous tracking. Occasional localization is sufficient, and that one fact reshapes the whole design.

Sparse Localization Architecture

Instead of running VPS continuously, we trigger on events: the user requests location context, GPS detects a significant location change, an app requires precise location, or a periodic background check fires. The query pattern becomes once per minute rather than 60 times per second.

Event-triggered localizationFour trigger boxes stacked on the left feed arrows into one highlighted query box in the middle, which connects by a single labeled arrow to a cloud matching box on the right. User asks forlocation contextGPS sees a significantlocation changeAn app requiresprecise locationPeriodic backgroundcheck firesOne VPS query per eventonce a minute,not 60 times a secondunder 10 mW averageCloud matching, 1-2 sPose for navigation,POI info, reminders,location sharing one fixed-focus,forward-facing frame
Sparse localization on glasses: four event triggers feed a single VPS query about once a minute instead of 60 times a second, which is what fits under a 10 mW average and makes 1-2 s of cloud latency acceptable.

That changes the architecture top to bottom. Latency matters less (1-2 seconds is acceptable), power per query can be higher, cloud processing becomes more acceptable, and on-device simplicity is worth paying for.

Sensor Adaptation

The glasses camera is forward-facing only, with no stereo pair and no rear cameras, a smaller and noisier sensor, fixed focus optimized for outdoors, and a lower frame rate. So the features have to survive single-view geometry, motion blur from head movement during capture, and variable focus quality. We are training specifically for this sensor profile rather than hoping Quest-trained models transfer.

Privacy Sensitivity

Glasses are more privacy-sensitive than headsets. They are worn in public constantly, it is less obvious when they are capturing, and bystanders have every reason to care. The extra precautions, on top of the on-device feature pipeline that already keeps images off the server: an explicit visual indicator during capture (a partial measure, as it was on the headset), stricter limits on capture frequency, and enhanced face blurring in processing.

Timeline

Ray-Ban Stories V1 ships late 2021 without VPS. A future generation is the integration target. In the meantime the V1 period is useful on its own: we get to understand real sensor characteristics, collect consented data for training, refine ultra-low-power algorithms, and build glasses-specific map layers. When glasses finally get spatial awareness, I want the groundwork already done.

Comments