n0tst3v3andClaude Opus 5
5d98f474ae
The pin sat dead ahead of the heading arrow no matter which way the user turned, so the arrow looked like it was aiming at the item and the item looked like it was always straight down the path of travel. The cause is geometric, not a UI link. addSample() only accepts a sample after 5 m of movement, so every sample lies on the line the user walked. gradientBearing() correlates RSSI against centred position, and on a collinear track each centred position is t*u for a single unit vector u along the walk - so the sum is exactly parallel to u regardless of the signal. The "estimated" bearing was the direction of travel, echoed back. That bearing then placed the pin in three separate paths: preliminaryEstimate() projects along it, solve() overrides a converged trilateration with it, and consensusEstimate() averages the result. All three produced a pin straight ahead. Refuse the bearing until the track has real width across its own axis - the smaller eigenvalue of the position covariance, against max(4 m, meanAccuracy/2). A straight walk with GPS jitter measures about 1 m of spread and is rejected; an L of two 20 m legs measures about 5 m and is accepted. Distances still place the item off-axis on a straight walk, but which side is a real mirror ambiguity, so the UI now says so and asks for a leg at 90 degrees instead of inventing a side. Also drops showFallbackPin(), which projected the pin along the raw compass heading whenever no estimate was solved - a fourth route to the same wrong place. With no estimate the pin now shows the item's last known GPS fix, or nothing at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
