We build a medical scanning app. A practitioner walks a slow orbit (~1 m radius, two laps, 25–35 s) around a standing subject while an ARSession runs, and we capture ~50 high-resolution stills with captureHighResolutionFrame. The ARKit camera poses for those frames are later used to set the metric scale of a photogrammetry reconstruction. We need the resulting scale to be within about 2 % of true. What we observe, measured against a printed A4 sheet on the floor in every scan: Devices with LiDAR (iPhone 16 Pro Max, iPad Pro), using the sceneDepth frame semantic as a check: scale within ±0.8 % across 11 sessions. Devices without LiDAR (iPhone 13, iPad 9th and 11th gen, plus non-LiDAR runs on the Pro devices): the world-frame metre is on average 2–3 % short of true, and varies by a further ±2 % from one session to the next, across 24 sessions in four rooms. Within a session the scale is stable: lap-to-lap variation is under 0.4 %. The error appears to be set during initialisation and held. Nothing we record about capture correlates with the error: time spent before capture, distance walked, vertical camera movement, orbit radius, rotation speed, tracking state, or the residual of our pose fit. Questions: Is there any session setup, initialisation practice, or motion during the first seconds of tracking that is known to improve the metric scale estimate on devices without LiDAR? Does the choice of video format, resolution or frame rate affect scale estimation? Is there any signal, beyond ARCamera.trackingState, that indicates how well scale has been determined for a session, so we could flag sessions rather than accept them? Does anything in the configuration above, in particular locking exposure on the capture device or using the high-resolution video format, work against tracking quality or scale?

Improving metric scale consistency of ARWorldTrackingConfiguration on devices without LiDAR

We build a medical scanning app. A practitioner walks a slow orbit (~1 m radius, two laps,
25–35 s) around a standing subject while an ARSession runs, and we capture ~50 high-resolution
stills with captureHighResolutionFrame. The ARKit camera poses for those frames are later used
to set the metric scale of a photogrammetry reconstruction. We need the resulting scale to be
within about 2 % of true.

What we observe, measured against a printed A4 sheet on the floor in every scan:

Devices with LiDAR (iPhone 16 Pro Max, iPad Pro), using the sceneDepth frame semantic as a
check: scale within ±0.8 % across 11 sessions.
Devices without LiDAR (iPhone 13, iPad 9th and 11th gen, plus non-LiDAR runs on the Pro
devices): the world-frame metre is on average 2–3 % short of true, and varies by a further
±2 % from one session to the next, across 24 sessions in four rooms. Within a session the
scale is stable: lap-to-lap variation is under 0.4 %. The error appears to be set during
initialisation and held.
Nothing we record about capture correlates with the error: time spent before capture,
distance walked, vertical camera movement, orbit radius, rotation speed, tracking state, or
the residual of our pose fit.

Questions:

Is there any session setup, initialisation practice, or motion during the first seconds of
tracking that is known to improve the metric scale estimate on devices without LiDAR?
Does the choice of video format, resolution or frame rate affect scale estimation?
Is there any signal, beyond ARCamera.trackingState, that indicates how well scale has been
determined for a session, so we could flag sessions rather than accept them?
Does anything in the configuration above, in particular locking exposure on the capture
device or using the high-resolution video format, work against tracking quality or scale?