Wall ends still land in the wrong place: at the meter on a short side, or 13 ft from where the phone went #71

Activity

1. AidenJohnston

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   size:M30-99 effective changed lines.30-99 effective changed lines.

   on Sep 27, 2026
2. AidenJohnston commented on Sep 27, 2026

   

   AidenJohnston

   on Sep 27, 2026

   CollaboratorAuthor

   More actions

   Screen recordings from the build 4.1 field test (TestFlight 4.1, iPhone 14 without LiDAR). Click a link to play.

   • Run 2: "Wall ends here" at the post puts the end at the meter (1:38–1:50)

   Times are in each run's recording. Full analyses: PR #60.
3. AidenJohnston commented on Sep 27, 2026

   

   AidenJohnston

   on Sep 27, 2026

   CollaboratorAuthor

   More actions

   Where a side's end goes when the phone is past the last kept photo (#71, follow-up to #24)

   This doesn't pick an option. It sets out how the build 4.1 runs bear on the options already posted on #24 and the fix directions in #71, and what is still needed to choose. Read at t3/ios-mvf 4b71161.

   What the code does. Since 3c7b83a, "Wall ends here" and "Can't get there" during the walk end a side at the phone's position along the wall, capped at the farthest kept photo on that side (WalkedEnd.end, fed by CoverageMap.walkedPositions). With the phone across the meter or its place lost, the end goes to that farthest kept photo. A side with no kept photo ends at the meter. WalkedEndTests encodes this on purpose: straightWallEndsWhereThePhoneIs caps a phone at s = -4 m to the farthest photo at -3 m, and sideNeverWalkedEndsAtTheMeter sends a phone at -1 m with no photo on the left to 0. Auto-capture keeps a photo about every 0.5 m moved (AutoCaptureConfig.spacingMeters), so the cap trails the phone by up to that much, and on a side shorter than that it is 0.

   What 4.1 showed

   • Run 1 (mock wall): the rule worked. Ends at 1 ft 0 in left and 20 ft 3 in right, where the phone walked.
   • Run 2 (mock wall, short left side, A41-2015-03): the tester walked to the end post a few feet left, and the strip showed cells about 1–4 ft left of the meter. The two photos kept on that walk were at s = +0.32 m and +0.11 m, both right of the meter, so the cap was 0. "Wall ends here" put the end at the meter, and the strip dropped the cells left of it.
   • Run 3 (real house, A41-2055-06): left end 13 ft 2 in left, although no kept photo or trajectory point is past about 6 ft 8 in left; right end 1 ft 9 in, with the phone at about 5 ft right. The rule as written doesn't give either. In that run the wall line was about 1.1 m behind the real wall and 46° off (Meter tap on an estimated plane put the wall 1.1 m behind the real wall and 46° off, and nothing corrects it #69), the meter anchor sat on an estimated plane that ARKit may have moved (the export uses the final pose), and both ends came from 7 rapid "Can't get there" taps (No way to finish a scan early: stopping took 7 rapid "Can't get there" taps, each silently setting ends #82). The logEnd line (phone s, walked extent, covered reach) wasn't collected.

   How that bears on the posted options

   The #24 options for parts 1–3 were set aside after 3c7b83a. Part 1's question is the one #71 reopens.

   • "Can't get there" during the walk can put the wall's end at the meter, and the rest of the walk is dropped #24 1A (the farther of reach and the phone, capped at seenExtent; don't set an end within ~1 ft of the meter, ask to walk first): seenExtent already exists on CoverageMap, and the strip draws from it. In run 2 it reached about 1–4 ft left, so the end would likely have landed at the post. But seen cells follow where the camera looked, not where the phone went: in run 3 the strip showed about 13 ft of seen wall on the wrong line right after the taps, so a seen cap wouldn't have bounded that end. The 1 ft guard wouldn't have fired in run 2.
   • "Can't get there" during the walk can put the wall's end at the meter, and the rest of the walk is dropped #24 1B (refuse the tap while the side is under ~1 ft and say what's missing): read against today's walked extent, it would have refused in run 2. The tester was already at the post and couldn't walk farther, so the prompt would need a way to satisfy it from where they stand.
   • "Can't get there" during the walk can put the wall's end at the meter, and the rest of the walk is dropped #24 1C (warn only): run 2's end still lands at the meter.
   • "Can't get there" during the walk can put the wall's end at the meter, and the rest of the walk is dropped #24 part 4 (past an end): 4.1 doesn't bear on it. Photos past an unexplored end are already refused, and marks past an end are Marks past the wall's ends are still listed, exported and measured #42.
   • Wall ends still land in the wrong place: at the meter on a short side, or 13 ft from where the phone went #71, maximum of the phone, the farthest kept photo and the farthest seen cell: fixes run 2. On the phone's side it lets an end reach past the phone to wherever the camera saw, which is looser than today's "no farther than the walk has evidence for".
   • Wall ends still land in the wrong place: at the meter on a short side, or 13 ft from where the phone went #71, keep a photo at the tap: keeps today's rule and its tests, since the new photo moves the cap to the phone. It fails when that frame doesn't pass the capture gates (dark, blurry, limited tracking). Run 3's kept photos sat just above the darkness gate.
   • Wall ends still land in the wrong place: at the meter on a short side, or 13 ft from where the phone went #71, cap by the tracked trajectory plus a margin, and log when the cap fires: the packet already records every pose (CaptureRecorder), but WalkedEnd sees only kept photos, so this needs positions recorded in session (in ScanEngine.walk, stored on CoverageMap or the engine). The phone's current pose is itself on the trajectory, so on the phone's side this amounts to "end at the phone"; the cap only matters across the meter or with tracking lost. It would bound run 3's left end to about 6 ft 8 in if the frame stayed consistent, but not if the anchor moved.
   • Wall ends still land in the wrong place: at the meter on a short side, or 13 ft from where the phone went #71, never silently drop cells the strip was showing: independent of the cap. Any option that ends at the phone in run 2 also keeps those cells.

   Any option that lets an end land at the phone without a kept photo there changes the two WalkedEndTests expectations above, and may change #56's FieldRunReplayTests.

   Still needed to decide

   1. What counts as evidence that the wall reaches the phone: a kept photo (today), a photo forced at the tap, seen cells, or the tracked pose. Put simply: may an end land where the phone stands when no photo was kept there?
   2. Whether an end that would land within ~1 ft of the meter on a side the phone did walk should be refused with a prompt, and what that prompt offers when the homeowner can't walk farther.
   3. For run 3: the logEnd device log line for each end, and a re-test on a build with the Meter tap on an estimated plane put the wall 1.1 m behind the real wall and 46° off, and nothing corrects it #69 fix, before treating it as an end-rule bug.

   Once decided, run 2 is a unit test: kept views at s = +0.32 m and +0.11 m, the phone left of the meter, and "Wall ends here" on the left must not return 0.

   🤖 Generated with Claude Code
4. AidenJohnston commented on Sep 27, 2026

   

   AidenJohnston

   on Sep 27, 2026

   CollaboratorAuthor

   More actions

   Team decision (2026-09-27): on the phone's own side with tracking normal, the end goes where the phone is, even past the last kept photo; the kept-photo cap stays only across the meter or with tracking limited or lost, in PR #136.
5. AidenJohnston

   added 3 commits that reference this issue on Sep 27, 2026

   ios: an end at the phone out along the wall counts as walked

   ...

   057cfd4

   Merge pull request #136 from SamGu-NRX/t3/41-ends-corner

   ...

   c60e6ff

   Merge origin/beta into t3/41-ends-corner-2; drop the tracking debounce

   ...

   8383eb5