G92 sowie arctan2

This commit is contained in:
chk
2026-06-26 06:44:11 +02:00
parent 497d0fbc7b
commit 29b5f2ae4b
5 changed files with 445 additions and 236 deletions

View File

@@ -32,6 +32,94 @@ G92 X158.14 Y4.19 Z57.74 A91.85 B-45.46 C-69.92 E21.20
---
## Geometrische Bedeutung der Winkel (Driver-Konvention)
> **Wichtig für appRobotHoming:** Der Driver interpretiert die G92-Winkel in einer
> **eigenen** Konvention. appRobotHoming muss die physisch gemessenen Gelenkwinkel
> **in diese Konvention umrechnen**, bevor sie als G92 gesendet werden. Die folgenden
> Tabellen sind aus der Kinematik (`Arm3SegmentLinearX`) **verifiziert** (jeweils eine
> Achse isoliert variiert).
### Koordinatenrahmen
- **z = 0** ist die Achse zwischen Base und Arm1 (Schulter) — kein Offset darunter.
- y = nach hinten (Hauptarbeitsrichtung), z = nach oben, x = Linearschiene.
- Alle Armwinkel liegen in der y-z-Ebene (bei fixer x-Schiene).
### Y = α (Oberarm) und Z = β (Unterarm) — ABSOLUT
Beide werden **absolut gegen die Horizontale (+y)** gemessen, **nicht** relativ zueinander:
| Wert | Oberarm (Y) bzw. Unterarm (Z) |
|------|-------------------------------|
| 0° | waagerecht nach +y |
| 90° | senkrecht nach oben |
⚠️ **Z ist der absolute Unterarmwinkel**, nicht der Ellbogen-Knick gegen den Oberarm.
Misst appRobotHoming den Ellbogen relativ zum Oberarm: `Z = Oberarmwinkel + Ellbogen_relativ`.
(Erst bei der Weiterleitung an FluidNC wird daraus `(β α)` zurückgerechnet, siehe unten.)
### B = Handgelenk-Knick
Verifizierte Referenz (α=0, β=90, A=0, C=0):
| B (G92) | physischer Knick Unterarm↔Hand |
|---------|--------------------------------|
| 0° | 180° (Hand voll zurückgeklappt) |
| 90° | 90° (Hand ⊥ Unterarm) |
| 180° | 0° (Hand **gerade**, in Verlängerung des Unterarms) |
**Gerade Hand = B 180°.** Allgemein: `physischer Knick = 180° B`, also `B = 180° Knick`.
Der Driver (IK) erzeugt B nur im Bereich [0°, 180°].
### A = Unterarm-Dreher (Ellbogen-Roll)
A dreht die **Richtung**, in die das Handgelenk knickt, um die Unterarm-Längsachse —
die Knick-**Größe** bleibt dabei gleich. Verifiziert (α=0, β=90, B=90, C=0):
A=0 → Fingerspitze auf der y-Seite, A=90 → x-Seite, A=180 → +y-Seite; Knick konstant 90°.
### C = Hand-Dreher (Roll)
C dreht die Hand um ihre eigene Achse. Verifizierte Referenz (α=0, β=90, A=0, B=90):
| C (G92) | Hand-Roll ψ |
|---------|-------------|
| 0° | 90° |
| 90° | 0° (neutral) |
| 180° | +90° |
→ In dieser Stellung gilt `ψ = C 90°`. **Achtung:** der genaue Zusammenhang hängt von
der Armstellung ab — exakt `ψ = C acos(cos β · sin A)` (Winkel in rad). C selbst ist der
physische Hand-Roll-Gelenkwinkel; nur der Bezug zum Welt-ψ verschiebt sich mit der Pose.
### E = Greifer-Öffnung (mm) + Sehnen-Kopplung
E ist die **Finger-Öffnung in mm** (ein Finger ab Null-Position) — keine Winkel-Umrechnung.
Der Driver leitet daraus den Motorwert ab:
```
eMotor = E b c (b, c in RADIANT!)
= E B°/57.2958 C°/57.2958
```
Grund: die Greifer-Sehne läuft durchs Handgelenk; Knick (B) und Roll (C) ziehen an der Sehne.
appRobotHoming sendet die **reine Öffnung** als E; die Kopplung macht der Driver. Bewegt sich
nur das Handgelenk, kompensiert eMotor, damit die Öffnung konstant bleibt.
### Zusammenfassung: was appRobotHoming senden muss
| Achse | Driver erwartet | Typische Falle |
|-------|------------------------------------------------|-----------------------------------------|
| X | xMotor in mm | — |
| Y | Oberarm absolut (0=waagerecht, 90=hoch) | — |
| Z | Unterarm **absolut** (nicht relativ zum Oberarm) | relativ statt absolut gesendet |
| A | Unterarm-Dreher (Richtung des Knicks) | Nullpunkt/Vorzeichen |
| B | **180° = gerade Hand**; Knick = 180° B | gemessenen Knick direkt gesendet |
| C | Hand-Roll, **90° = neutral** | Nullpunkt/Vorzeichen |
| E | Öffnung in mm | Motorwert statt Öffnung gesendet |
---
## Interne Verarbeitung (`RobotController.js`)
Winkel-Achsen werden von Grad nach Radiant umgerechnet (D = 180/π):