Decide: bake-off design — comparands, ground truth, decision rule #10

New Issue

2026-08-11T15:41:39Z

lars commented

2026-08-11 15:41:39 +00:00

Question

Design Session 0: how visual relocalization and BLE trilateration get compared, and what decides the winner.

Settle:

What exactly is compared — which visual approach, which BLE estimator (nearest-beacon zone, weighted trilateration, or both).
The ground truth: how true position is established at each test point, to what precision, and how many points.
The test conditions: standing vs walking, clear vs obstructed line of sight, lights on vs off, phone held up vs at the side.
The decision rule — decided in advance, so the result isn't argued after the fact. Median and p95 error, not a single accuracy number, since the tail is what makes navigation feel broken.
What result means "neither wins, fuse them" or "neither works, stop".
Explicitly: which conclusions are not licensed by a single office room, and what would have to be re-tested at ship scale.

Part of the wayfinder map #1.

## Question Design Session 0: how visual relocalization and BLE trilateration get compared, and what decides the winner. Settle: - What exactly is compared — which visual approach, which BLE estimator (nearest-beacon zone, weighted trilateration, or both). - The **ground truth**: how true position is established at each test point, to what precision, and how many points. - The test conditions: standing vs walking, clear vs obstructed line of sight, lights on vs off, phone held up vs at the side. - The **decision rule** — decided in advance, so the result isn't argued after the fact. Median and p95 error, not a single accuracy number, since the tail is what makes navigation feel broken. - What result means "neither wins, fuse them" or "neither works, stop". - Explicitly: which conclusions are **not** licensed by a single office room, and what would have to be re-tested at ship scale. --- Part of the wayfinder map #1.

lars added this to the Wayfinder: RN prototyping spec milestone 2026-08-11 15:41:39 +00:00

lars added the wayfinder:grilling label 2026-08-11 15:41:39 +00:00

lars added a new dependency 2026-08-11 15:42:12 +00:00

#2 Research: on-device visual relocalization against a gaussian splat

lars added a new dependency 2026-08-11 15:42:12 +00:00

#4 Research: MikroTik TG-BTS-IN beacon capabilities and configuration

lars added a new dependency 2026-08-11 15:42:13 +00:00

#13 Write the Session 0 spec (positioning bake-off)

lars added a new dependency 2026-08-11 15:52:11 +00:00

#15 Decide: how the user's pose origin gets fixed, and re-fixed as it drifts

lars commented

2026-08-11 15:52:11 +00:00

Reframed by #2 — the comparands have changed.

The original framing was visual relocalization against the splat vs BLE trilateration. #2 establishes that the first option does not exist on a phone in 2026: all 3DGS localization work (GSFeatLoc, GSplatLoc, SplatLoc, Hi2-GSLoc) is desktop-GPU pose refinement needing a prior pose, with no mobile runtime. Sparse-feature VPS against your own scan does ship, but MultiSet is $149/mo, Immersal is Unity-only (closed to RN), and Vuforia Area Targets licences are reportedly EOL.

So the bake-off should compare:

A — ARKit VIO with a manual origin fix (free from RN via @reactvision/react-viro's onCameraTransformUpdate; ~0.5% drift, 0.79m over 145m in published indoor tests). Relative, accurate, drifts.
B — BLE trilateration alone (#4 says expect 1.5–3m — quadrant-level, absolute, jittery, no heading).
C — the hybrid, which is what both findings point at: VIO for smooth pose, BLE or markers as periodic origin re-fixes. Worth measuring directly rather than inferring from A and B.

Two consequences for this ticket's design:

Heading is now a discriminator, not a footnote. VIO gives usable relative heading with a known start; BLE gives none. If the rendered splat view is the product, heading error is as visible as position error — so measure it explicitly, don't just measure position.
The decision rule needs a "both, fused" outcome, since C is a live candidate rather than a consolation prize.

Blocked additionally on #15 (origin fix), because A and C cannot be specified until origin acquisition is decided.

**Reframed by #2 — the comparands have changed.** The original framing was *visual relocalization against the splat* vs *BLE trilateration*. #2 establishes that the first option does not exist on a phone in 2026: all 3DGS localization work (GSFeatLoc, GSplatLoc, SplatLoc, Hi2-GSLoc) is desktop-GPU pose *refinement* needing a prior pose, with no mobile runtime. Sparse-feature VPS against your own scan does ship, but MultiSet is $149/mo, Immersal is Unity-only (closed to RN), and Vuforia Area Targets licences are reportedly EOL. So the bake-off should compare: - **A — ARKit VIO with a manual origin fix** (free from RN via `@reactvision/react-viro`'s `onCameraTransformUpdate`; ~0.5% drift, 0.79m over 145m in published indoor tests). Relative, accurate, drifts. - **B — BLE trilateration alone** (#4 says expect 1.5–3m — quadrant-level, absolute, jittery, no heading). - **C — the hybrid**, which is what both findings point at: VIO for smooth pose, BLE or markers as periodic origin re-fixes. Worth measuring directly rather than inferring from A and B. Two consequences for this ticket's design: 1. **Heading is now a discriminator, not a footnote.** VIO gives usable relative heading with a known start; BLE gives none. If the rendered splat view is the product, heading error is as visible as position error — so measure it explicitly, don't just measure position. 2. **The decision rule needs a "both, fused" outcome**, since C is a live candidate rather than a consolation prize. Blocked additionally on #15 (origin fix), because A and C cannot be specified until origin acquisition is decided.

lars referenced this issue

2026-08-11 15:52:11 +00:00

Wayfinder: React Native ship-navigation prototyping spec #1

lars commented

2026-08-11 16:02:01 +00:00

Arm A is cheaper than assumed, and its error model is now known.

@reactvision/react-viro 2.57.5 gives ARKit pose in JS with zero Swift — onCameraTransformUpdate (≤60Hz), onTrackingUpdated with ARKit's tracking state and reasons, worldAlignment as a prop, and ViroARImageMarker for fiducial fixes. So arm A ("ARKit VIO + manual origin") is a JS-only build for the bake-off. Its limits: no ARWorldMap, no raw frames, no depth to JS, legacy-arch views.
Expected drift: 0.5–8% of distance travelled (0.79 m over 145 m in a poor-texture corridor with loop closure disabled, but ~7.9% on an older device over 19 m). Measure the rate, not a single displacement — the bake-off should report error as a function of distance walked, because that is the shape of VIO error, whereas BLE error is roughly constant with distance. A single-point comparison would flatter BLE and mislead.
An absolute re-fix every ~20–30 m is what keeps VIO under 1 m. That makes arm C (hybrid) the one to beat, and means the bake-off should measure fix interval as an explicit variable.
Throttle pose to JS at 10–15 Hz, not 60 — Viro's own default in comparable wrappers is 15 Hz. Don't let a bridge-rate artifact contaminate the positioning comparison.
Practical note from a chest-height study (PAReNt, Sensors 2023): ARKit alone drifted; only fused with another source did it reach ~70 cm median. Occluding pedestrians "were not handled at all" — relevant to a crowded ship, and worth one obstruction condition in the test matrix.

**Arm A is cheaper than assumed, and its error model is now known.** - **`@reactvision/react-viro` 2.57.5 gives ARKit pose in JS with zero Swift** — `onCameraTransformUpdate` (≤60Hz), `onTrackingUpdated` with ARKit's tracking state and reasons, `worldAlignment` as a prop, and `ViroARImageMarker` for fiducial fixes. So arm A ("ARKit VIO + manual origin") is a JS-only build for the bake-off. Its limits: no `ARWorldMap`, no raw frames, no depth to JS, legacy-arch views. - **Expected drift: 0.5–8% of distance travelled** (0.79 m over 145 m in a poor-texture corridor with loop closure disabled, but ~7.9% on an older device over 19 m). Measure the *rate*, not a single displacement — the bake-off should report error as a function of distance walked, because that is the shape of VIO error, whereas BLE error is roughly constant with distance. **A single-point comparison would flatter BLE and mislead.** - **An absolute re-fix every ~20–30 m** is what keeps VIO under 1 m. That makes arm C (hybrid) the one to beat, and means the bake-off should measure *fix interval* as an explicit variable. - **Throttle pose to JS at 10–15 Hz**, not 60 — Viro's own default in comparable wrappers is 15 Hz. Don't let a bridge-rate artifact contaminate the positioning comparison. - Practical note from a chest-height study (PAReNt, *Sensors* 2023): ARKit alone drifted; only **fused** with another source did it reach ~70 cm median. Occluding pedestrians *"were not handled at all"* — relevant to a crowded ship, and worth one obstruction condition in the test matrix.

lars referenced this issue

2026-08-11 16:03:08 +00:00

Research: on-device visual relocalization against a gaussian splat #2

lars commented

2026-08-11 16:03:08 +00:00

One more measurement this bake-off must make: recall, not just accuracy.

From #2's vendor addendum — every visual-positioning vendor publishes 6–8 cm accuracy, comfortably inside the 1 m target, but none publishes a recall or success rate, and none documents behaviour at chest height while walking. So the interesting question is not "how accurate when it works" but how often it fails, and how it fails.

Add to the test matrix:

Fix success rate per attempt, not just error when successful. Report it as a percentage alongside median/p95 error.
Chest height, walking as a first-class condition — the way a passenger actually holds a phone — rather than held up and stationary.
Failure mode on a wrong fix. A confidently wrong pose is worse than no pose when the display is photorealistic. Log whether the system knows it failed.
If a VPS arm is included: MultiSet is the practical candidate (native Swift xcframework, localize() returning pose and confidence, ~6 cm claimed, ~3–4 s per on-device fix, $0/$49/$249 tiers) — but on-device offline is Enterprise-gated and map bundles run 100s of MB per ~50k sq ft. Treat it as a costed third arm, not a free one.

Note the two error models differ in shape and the report must not hide it: VIO error grows with distance travelled; BLE error is roughly constant; VPS error is bimodal — small when a fix lands, unbounded when it doesn't.

**One more measurement this bake-off must make: recall, not just accuracy.** From #2's vendor addendum — every visual-positioning vendor publishes 6–8 cm accuracy, comfortably inside the 1 m target, but **none publishes a recall or success rate, and none documents behaviour at chest height while walking**. So the interesting question is not "how accurate when it works" but **how often it fails, and how it fails**. Add to the test matrix: - **Fix success rate** per attempt, not just error when successful. Report it as a percentage alongside median/p95 error. - **Chest height, walking** as a first-class condition — the way a passenger actually holds a phone — rather than held up and stationary. - **Failure mode on a wrong fix.** A confidently wrong pose is worse than no pose when the display is photorealistic. Log whether the system knows it failed. - If a VPS arm is included: **MultiSet** is the practical candidate (native Swift `xcframework`, `localize()` returning pose *and* confidence, ~6 cm claimed, ~3–4 s per on-device fix, $0/$49/$249 tiers) — but on-device offline is Enterprise-gated and map bundles run 100s of MB per ~50k sq ft. Treat it as a costed third arm, not a free one. Note the two error models differ in shape and the report must not hide it: **VIO error grows with distance travelled; BLE error is roughly constant; VPS error is bimodal** — small when a fix lands, unbounded when it doesn't.

Sign in to join this conversation.