G28 und Phase2 Arbeiten

doc/Info_Koordinaten.md

@@ -126,6 +126,8 @@ Umgesetzt:
   Stellung (`|y| = l1+l2+l3`) ist eine Handgelenk-Singularität, in der die IK `a`/`c` nicht
   bestimmen kann (Müll wie `a=135°, c=45°` → Finger schräg). G28 setzt dort die Motorwerte
   **direkt** (`alpha=beta=a=c=0`, `b=π` = gerade Hand) und füllt die Pose per FK.
+  **Interim:** G28 lässt den Greifer (`e`/`eMotor`) **unangetastet** — sonst ergäbe
+  `eMotor = e−b−c` bei `b=π` den Wert −180° → Finger-Anschlag-Slam (Phase 2 behebt das mit `b=0`).
 - **Tests:** `test/Robot.Kinematics.NegativeY.test.js` (Grundstellung −590, Homing-Pose
   in −y, Round-Trip in −y, a=0 → Knick-Achse ∥ x).
 - **Migration:** `Robot.02_UpperArm` und der G28-Test auf −y umgestellt.
@@ -176,9 +178,21 @@ Fundstellen:
    - Aufgabe: Kopplung gegen die echte Sehnenmechanik validieren, toten x-Port-Pfad +
      `factorOpenTurn` aufräumen, **Vorzeichen** je nach Motor-Verkabelung prüfen.
 
-3. **B-Konvention (gerade = 0°).** Durchgängig:
+3. **B-Konvention (gerade = 0°).**
+
+   **Verifizierter Mismatch Homing ↔ Driver:** Das appRobotHoming meldet für die **gerade**
+   Hand **B ≈ 0** (Messung: `B=-6.92`), der Driver rechnet aber mit **gerade = b = 180°**.
+   Der Driver interpretiert das empfangene `b≈0` daher als Knick `180−0 = 180°` (fast voll
+   zurückgeklappt) → im Modell zeigt der Finger nach **+y (rückwärts)** statt −y. D.h. **nach
+   dem Homing ist der interne Hand-Zustand des Drivers falsch** (gefaltet), was Folge-Moves
+   verfälscht. Das ist das beobachtete „Driver interpretiert als B=180".
+   → Konsequenz: Driver auf **B=0=gerade** umstellen (passt dann ohne Umrechnung zum Homing),
+   **oder** appRobotHoming sendet `B+180`. (C ist konsistent: Homing `C=90`=flach = Driver `c=90`=flach,
+   also `C=0`=aufrecht — kein Versatz.)
+
+   Umstellung durchgängig:
    - FK/IK in `Arm3SegmentLinearX` (b-Definition / acos-Zweig),
-   - `gripperMotorFromOpening` nachziehen,
+   - `gripperMotorFromOpening` nachziehen (behebt auch den G28-Greifer-Slam),
    - G92-Eingabe (`b = B/D`) + M1 + G28,
    - `portInverse.js` (Umkehrung),
    - **Sender-Formeln so kompensieren, dass die FluidNC-Ports unverändert bleiben** —
@@ -193,8 +207,9 @@ Fundstellen:
    (`|Hand.to[1]| + |FingerA.to[1]|` = 35 + 60 = **95**) statt aus dem Ellbogen-Versatz (90).
    Zusätzlich sind `kinematics.l1/l2/l3` in robot.json **explizit überschreibbar** (Vorrang
    vor der Ableitung) — zum Kalibrieren auf die gemessene Reichweite.
-   ⚠️ Geometrie liefert Reichweite 595, beobachtet wurden **~550** → l3 (oder l1/l2) sollte
-   per `kinematics.l3` explizit kalibriert werden (deutet auf l3 ≈ 50, falls l1=l2=250 stimmen).
+   Reichweite damit 595 — passt zur aktuellen Hardware (60 mm Finger). Die früher beobachteten
+   ~550 stammten von **kürzeren 50 mm-Greifern**. Bei Greifer-Wechsel `kinematics.l3` per
+   Override anpassen (oder Finger-Geometrie in robot.json pflegen).
 
 6. **Tests + Doku** nachziehen: Round-Trip mit neuer Konvention, Greifer-Kopplung,
    G92-Referenztabellen in `Info_G92.md`, sowie diese Datei.