Draft 4ecken

doc/Homing_5_Pose_MultiPoint_Weighted.md

@@ -222,15 +222,43 @@ umsetzbar und (wo möglich) einzeln testbar, bevor der nächste beginnt.
 | 2 | **(Punkt 3)** `residual_vector()` nutzt das neue Gewicht, hinter einem Schalter (`pose_estimation.use_marker_weight`, Default `false`) | A/B-Vergleich auf den appRobotRendering-Simulationsszenen (mit/ohne Schalter) gegen bekannte Grundwahrheit — genau der Test, der laut Nutzer beim ersten Versuch wenig brachte, jetzt wiederholbar | **Nein bei Default aus.** Mit `true`: Ergebnisse ändern sich gewollt — muss vor Produktiv-Default separat validiert werden |
 | 3 | **(Punkt 1)** `robot_fk.py`: neue Methode liefert die 4 lokalen Eckpunkte eines Markers im Weltsystem (Baustein, noch ohne Anbindung) | Isoliert testbar, ganz ohne `5_pose_estimation.py`: gegen die wahren Eckpositionen aus `render_*.json` (Simulation liefert das schon) | **Nein.** Neue, bisher von niemandem aufgerufene Methode |
 | 4 | **(Punkt 1)** Neuer `marker_observation`-Modus (z. B. `"corner_points"`) nutzt die 12 Eck-Residuen statt 6 Center/Normal-Residuen | Direkter Vorher/Nachher-Vergleich gegen dieselbe Validierungstabelle wie in `Homing_5_Pose.md` (10 Simulationsposen, bekannte GT) | **Nein als Opt-in** (Default bleibt `"corner_pose"`). Tuning-Punkt: `huber_delta_mm` ist auf die heutige Residuumsgröße kalibriert — mit 12 statt 6 Werten/Marker verschiebt sich die RMS-Größenordnung, müsste neu eingeordnet werden |
-| 5 | **(Punkt 2)** 3b nimmt 1-Kamera-Beobachtungen mit auf (rohe 2D-Ecken + Kamera-Referenz), statt sie zu verwerfen | Output-Diff: nur neue Einträge für vorher fehlende Marker, bestehende ≥2-Kamera-Einträge unverändert | **Potenziell ja.** Jeder Code, der `aruco_marker_poses.json` liest und für *jeden* Markereintrag eine triangulierte `position_mm` erwartet (Viewer, `9_evaluateMarker.py`, CSV-Export) müsste Einträge ohne 3D-Position vertragen — vor diesem Schritt prüfen, welche Consumer das betrifft |
+| 5 | **(Punkt 2)** 3b nimmt 1-Kamera-Beobachtungen mit auf (rohe 2D-Ecken + Kamera-Referenz), statt sie zu verwerfen | Output-Diff: nur neue Einträge für vorher fehlende Marker, bestehende ≥2-Kamera-Einträge unverändert | **Ja, konkret** — siehe Konsumenten-Recherche direkt unter der Tabelle. Mehrere Stellen brauchen einen Guard, **bevor** dieser Schritt scharf geschaltet wird |
 | 6 | **(Punkt 2)** `residual_vector()` um Reprojektions-Residuen erweitert; `load_observations()`/`estimate_pose()` lesen zusätzlich Kamerakalibrierung | Zuerst an Simulationsszenen, bei denen gut beobachtete Marker künstlich auf „nur 1 Kamera" reduziert werden (GT bekannt) — saubere Kontrolle, ob das Residuum tatsächlich hilft, bevor reale Finger-Marker überhaupt existieren | **Nein strukturell** (additiver Residuumstyp), aber Regressionsrisiko durch falsche mm/px-Gewichtung — vor Produktiv-Default gegen die bestehende Validierungstabelle gegenprüfen (wie Schritt 4) |
 | 7 | Zusammenführen: ein gemeinsames Gewichtsschema (Quality × Kamera-Anzahl × Residuumstyp) statt drei separater Schalter | End-to-End gegen Simulationsbenchmark **und** die drei realen Fixtures aus `Homing_5_Pose.md` | **Nein**, wenn alle Vorstufen additive Defaults hatten |
 
+### Recherche zu Schritt 5: wer liest `aruco_marker_poses.json`? (2026-06-16)
+
+Alle Dateien mit Referenz auf `aruco_marker_poses` im Projekt durchsucht und
+geprüft, ob sie `position_mm` (o. ä.) ungeschützt voraussetzen oder schon einen
+Guard haben:
+
+| Datei | Nutzung | Wenn `position_mm` fehlt | Guard schon da? |
+|---|---|---|---|
+| `public/yAxisCompute.js:109-111` | Y-Rotationsachse Base↔Arm1 (Kalibrierung [4], Kreisfit über 3 Posen) | **Crash** — `ma.position_mm.map(Number)` direkt auf evtl. `undefined` | ❌ Nein |
+| `public/boardViewer.html` (≥9 Stellen, u. a. Z. 416, 607, 629, 736, 899-900, 1092, 1125) | X-Achsen-Richtung (Kalibrierung [3]) **und** Y-Achsen-Viewer **und** allgemeiner Pos-A/B/C-Vergleich | **Crash** an den meisten der ≥9 Stellen (`.map(Number)`/`r2vArr()` ungeschützt) | ⚠️ Nur 1 von ~9 Stellen (Z. 661: `if (!cp.position_mm) continue;`) |
+| `public/homing.js:96` | Homing-Marker-Tabelle | Keiner — `m.position_mm ?? [null,null,null]` | ✅ Ja |
+| `server/editRobot.js` → `assignByZRange()` | Marker-Z-Bereich-Zuordnung (Kalibrierung „Board"-Tab) | Keiner — `Array.isArray(emPos)`-Check, sonst `continue` | ✅ Ja |
+| `server/editRobot.js` → `alignSetToMeasured()` | Set-Ausrichtung (Kabsch-Fit) | Keiner — Marker ohne `position_mm` werden beim Aufbau der Messwert-Map einfach ausgelassen | ✅ Ja |
+| `server/editRobot.js` → `assignMarkerId()` | Einzelnen Marker manuell per ID zuordnen | Ungeprüft im Detail — aber einzelne, von Hand ausgelöste Aktion, kein Batch-Durchlauf | ⚠️ Geringes Risiko, nicht im Detail verifiziert |
+| `scripts/4_yAxis_rotation_reconstruction.py` | Python-Variante der Y-Achsen-Rekonstruktion (offline, parallel zu `yAxisCompute.js`) | Kein Crash, aber **stiller Fehler**: `.get('position_mm', [0,0,0])` — ein fehlender Marker würde als `[0,0,0]` in den Kreisfit eingehen | ⚠️ Falscher „Schutz" — Default ist selbst Falschdaten |
+| `scripts/9_evaluateMarker.py` | Offline-Benchmark gegen Simulations-GT, **nicht** im Live-Homing-Pfad | **Crash** — `o["position_m"]` ohne `.get()` | ❌ Nein, aber kein Produktionscode |
+| `public/client.js` | Nur CSV-Anzeige/Zahlenformat | Keine Berechnung, nur Darstellung | n/a |
+
+**Bestätigt deine Vermutung, aber breiter als gedacht:** Es betrifft tatsächlich
+nur die **X-Achsen-** und **Y-Rotationsachsen-Kalibrierung** (Schritt [3]/[4]
+in `Kalibrierung.md`) plus den Offline-Benchmark — aber **nicht nur ein
+Filter an einer Stelle**, sondern `yAxisCompute.js` **und** mehrere Stellen in
+`boardViewer.html` (das Viewer-File bedient beide Kalibrierschritte). Die
+Homing-Seite selbst (`editRobot.js`, `homing.js`) ist bereits robust.
+
 ## Offene Punkte
 
 - [ ] Keiner der drei Punkte/Schritte ist priorisiert/entschieden — reine Optionen.
-- [ ] Schritt 5 zuerst: welche Tools lesen `aruco_marker_poses.json` und setzen
+- [x] Schritt 5: Konsumenten-Recherche erledigt (Tabelle oben) — vor Schritt 5
-  eine triangulierte Position für jeden Eintrag voraus? (Viewer, Eval-Skripte)
+  müssen mindestens `yAxisCompute.js` (1 Stelle) und `boardViewer.html`
+  (≥9 Stellen) einen Guard bekommen (fehlende Marker überspringen statt
+  crashen), sonst brechen X-/Y-Achsen-Kalibrierung beim nächsten Lauf mit
+  1-Kamera-Markern.
 - [ ] Für Schritt 3/4: Eckreihenfolge/Spin-Konvention zuerst exakt verifizieren,
   bevor Residuen darauf aufbauen.
 - [ ] Für Schritt 2: erneute Simulationsvalidierung, bevor eine Wiedereinführung