Extend AeroAlign with mixed CoG planning and telemetry base

2026-03-11 23:14:33 +01:00
parent 538c3081bf
commit 56890272a0
28 changed files with 1631 additions and 1332 deletions
@@ -0,0 +1,61 @@
+# AeroAlign + CoG Scale Integration
+
+## Zielbild
+
+Das System wird von einem reinen digitalen Einstellwinkelmesser zu einer gemeinsamen RC-Setup-Plattform erweitert:
+
+- AeroAlign-Knoten messen Pitch/Roll fuer EWD, Ruderausschlag und Bezugswinkel.
+- CoG-Scale-Knoten messen Front- und Heckauflagegewicht ueber Load Cells.
+- Ein gemeinsamer ESP32-Master sammelt beide Geraeteklassen ueber ESP-NOW und stellt alles in derselben Web-Oberflaeche bereit.
+
+## Externe Referenz
+
+Die geplante CoG-Funktion orientiert sich konzeptionell an diesem Projekt:
+
+- [RC plane Center of Gravity finder | Hackaday.io](https://hackaday.io/project/202834-rc-plane-center-of-gravity-finder/details)
+
+Aus der Referenz uebernommen:
+
+- zwei digitale Waagen mit ESP32
+- Front- und Heckgewicht als Echtzeitdaten
+- CoG-Berechnung aus dem Abstand der Auflagepunkte
+- Speicherung modellspezifischer Parameter im Geraet
+
+## Mechanisches Modell
+
+Wenn die vordere Auflage bei `x = 0` und die hintere bei `x = L` liegt, dann gilt aus dem Momentengleichgewicht:
+
+`x_cog_from_front_support = rear_weight / (front_weight + rear_weight) * L`
+
+Das ist eine technische Ableitung aus der in der Hackaday-Referenz gezeigten Zwei-Waagen-Anordnung.
+
+Um die Lage relativ zur Fluegelvorderkante zu erhalten:
+
+`x_cog_from_leading_edge = support_offset_from_leading_edge + x_cog_from_front_support`
+
+## Netzwerkmodell
+
+Ein gemeinsames ESP-NOW-Protokoll transportiert nun Geraetetypen:
+
+- `IMU`: klassische AeroAlign-Sensoren
+- `CoG Scale`: Waagenknoten mit Front/Heck/CoG
+- `Hybrid`: spaeter fuer kombinierte Vorrichtungen
+
+Der Master muss deshalb keine getrennten Netze oder Apps mehr betreiben.
+
+## Empfohlene Phase 5
+
+1. Eigenen CoG-Slave auf Basis `firmware/slave` anlegen.
+2. HX711-Treiber und Tare/Kalibrierung integrieren.
+3. Master-API um Modellparameter `support_distance_mm` und `leading_edge_offset_mm` erweitern.
+4. Web-UI um CoG-Ansicht mit Livewerten, Sollwert und Ballast-Rechner erweitern.
+5. NVS-Datenmodell fuer Flugzeugprofile einfuehren.
+
+## Firmware-Schnittstelle
+
+Aktuell ist im Protokoll nur die Transportbasis vorbereitet:
+
+- `pitch/roll/yaw` bleiben fuer IMU-Knoten erhalten.
+- CoG-Scale-Knoten belegen dieselben drei Float-Felder mit `front_weight_g`, `rear_weight_g` und `cog_position_mm`.
+
+Das ist bewusst pragmatisch, damit bestehende ESP-NOW-Kommunikation erhalten bleibt und die eigentliche HX711-Integration als naechster Schritt isoliert umgesetzt werden kann.
@@ -0,0 +1,268 @@
+# Aircraft Profile Model
+
+## Zweck
+
+Diese Datei ist die verbindliche Fachvorgabe fuer das Modul, das AeroAlign und CoG gemeinsam bedienen soll.
+
+Sie legt fest:
+
+- welche Flugzeugprofile es gibt
+- welche Flaechenarten unterschieden werden
+- welche Workflows pro Profil aktiv sind
+- welche Spezialfaelle ausdruecklich anders behandelt werden
+
+## Begriffe
+
+### Feste Flaechen
+
+Feste, nicht verstellte aerodynamische Referenzflaechen.
+
+Beispiele:
+
+- Tragflaeche
+- Dämpfungsflosse Hoehenleitwerk
+- Dämpfungsflosse Seitenleitwerk
+- feste Canard-Flaeche
+
+### Bewegliche Flaechen
+
+Aktiv angelenkte Flaechen oder Klappen.
+
+Beispiele:
+
+- Querruder
+- Hoehenruder
+- Seitenruder
+- Wölbklappe
+- Spoiler
+- Taileron
+- Pendelleitwerk
+
+### Referenzflaeche
+
+Die Flaeche, gegen die eine andere Flaeche gemessen wird.
+
+Regel:
+
+Bewegliche Flaechen werden gegen ihre zugehoerige feste Referenz gemessen, nicht pauschal gegen andere bewegliche Flaechen.
+
+## Grundsaetze
+
+1. `EWD / Referenzgeometrie` ist ein eigener Workflow.
+2. `CG / Schwerpunkt` ist ein eigener Workflow.
+3. `Ruder- und Klappeneinstellung` ist ein eigener Workflow.
+4. `90 Grad Servoarm` ist keine universelle Fachregel und darf nur als optionale Montagehilfe behandelt werden.
+5. `Pendelleitwerk` und `Taileron` sind keine normalen Hoehenruder.
+
+## Profiltypen
+
+### 1. `classic`
+
+Klassisches Flaechenflugzeug mit:
+
+- Tragflaeche
+- Dämpfungsflosse Hoehenleitwerk
+- Hoehenruder
+- Dämpfungsflosse Seitenleitwerk
+- Seitenruder
+- Querruder
+
+Aktive Workflows:
+
+- `reference`
+- `surfaces`
+- `cog`
+- spaeter `throw`
+
+MVP-Status:
+
+- dies ist das primäre Startprofil fuer das System
+
+### 2. `jet_taileron`
+
+Jet mit kombiniertem Hoehen-/Querruder an beweglichen Heckflaechen.
+
+Merkmale:
+
+- keine klassische Trennung zwischen Hoehenruder und Querruder hinten
+- linke und rechte Tailerons muessen symmetrisch und differenziert pruefbar sein
+
+Aktive Workflows:
+
+- `reference`
+- `surfaces`
+- `cog`
+- spaeter `mixing_check`
+
+Sonderregel:
+
+Tailerons werden nicht wie normale Hoehenruder gegen eine Dämpfungsflosse behandelt.
+
+### 3. `stabilator`
+
+All-flying stabilizer oder Pendelhöhenleitwerk.
+
+Merkmale:
+
+- gesamte Flaeche bewegt sich
+- keine feste Dämpfungsflosse als lokale Referenzflaeche
+
+Aktive Workflows:
+
+- `reference`
+- `surfaces`
+- `cog`
+
+Sonderregel:
+
+Die bewegliche Gesamtflaeche wird gegen eine externe Referenz gemessen, typischerweise Tragflaeche oder definierte Vorrichtung.
+
+### 4. `glider_flap`
+
+Segler mit Querrudern, Wölbklappen und oft mehreren Flugphasen.
+
+Merkmale:
+
+- Grundneutralstellung kann je nach Flugphase bewusst nicht null sein
+- Butterfly, Speed, Thermik und Cruise koennen unterschiedliche Sollwerte haben
+
+Aktive Workflows:
+
+- `reference`
+- `surfaces`
+- `cog`
+- spaeter `flight_mode_offsets`
+
+### 5. `delta_elevon`
+
+Delta oder Nurfluegel mit kombinierten Elevons.
+
+Merkmale:
+
+- keine klassische EWD wie beim Leitwerksflugzeug
+- linke und rechte Elevons sind kombinierte Hoehen-/Querruderflaechen
+
+Aktive Workflows:
+
+- `reference`
+- `surfaces`
+- `cog`
+
+Sonderregel:
+
+Es gibt keine klassische Leitwerksreferenz. Das Profil darf keine Leitwerkslogik erzwingen.
+
+## Flaechentypen fuer das Datenmodell
+
+Das Modul soll mindestens folgende Typen unterscheiden:
+
+- `wing_reference`
+- `tailplane_fixed`
+- `fin_fixed`
+- `aileron`
+- `elevator`
+- `rudder`
+- `flap`
+- `spoiler`
+- `taileron`
+- `stabilator`
+- `elevon`
+- `canard_fixed`
+- `canard_control`
+
+## Workflow-Freigabe pro Profil
+
+| Profil | Reference | Surfaces | CoG | Throw später | Speziallogik |
+|--------|-----------|----------|-----|--------------|--------------|
+| `classic` | ja | ja | ja | ja | gering |
+| `jet_taileron` | ja | ja | ja | ja | hoch |
+| `stabilator` | ja | ja | ja | ja | hoch |
+| `glider_flap` | ja | ja | ja | ja | mittel |
+| `delta_elevon` | ja | ja | ja | ja | hoch |
+
+## Messregeln pro Flaechenart
+
+### Querruder
+
+Gegen:
+
+- linke oder rechte Tragflaechenreferenz
+
+### Hoehenruder
+
+Gegen:
+
+- Dämpfungsflosse Hoehenleitwerk
+
+### Seitenruder
+
+Gegen:
+
+- Dämpfungsflosse Seitenleitwerk
+
+### Wölbklappen
+
+Gegen:
+
+- zugehoerige Tragflaechenreferenz
+
+Hinweis:
+
+Die Sollstellung muss nicht `0.0` sein.
+
+### Taileron
+
+Gegen:
+
+- profilabhaengige Heckreferenz oder externe Referenz
+
+### Stabilator
+
+Gegen:
+
+- externe Referenzflaeche
+
+Nicht gegen:
+
+- nicht vorhandene Dämpfungsflosse
+
+## UI-Folgen
+
+Die UI darf nicht einfach fuer alle Modelle dieselben Labels oder Buttons anzeigen.
+
+Pflicht:
+
+- Profilwahl beim Anlegen des Modells
+- sprechende Flaechenrollen
+- nur die fuer das Profil gueltigen Workflows anzeigen
+- Sonderflaechen mit eigenen Begriffen benennen
+
+Beispiele:
+
+- `Elevator` nur bei `classic`
+- `Stabilator` bei `stabilator`
+- `Taileron Left/Right` bei `jet_taileron`
+- `Flap Left/Right` bei `glider_flap`
+
+## MVP-Grenze
+
+Fuer den ersten echten Produktstand soll das Modul fachlich vorbereitet sein, aber operativ auf `classic` optimiert werden.
+
+MVP in der Praxis:
+
+- klassische Tragflaeche
+- Dämpfungsflosse Hoehenleitwerk
+- Hoehenruder
+- Querruder links/rechts
+- Seitenruder optional
+- CoG-Messung
+
+Andere Profile muessen im Datenmodell vorgesehen sein, auch wenn sie anfangs noch nicht vollstaendig in der UI freigeschaltet sind.
+
+## Verbindliche Anweisung fuer die weitere Implementierung
+
+1. Keine harte Verdrahtung auf nur `elevator`, `aileron`, `rudder`.
+2. Workflow-Entscheidungen muessen profilabhaengig sein.
+3. `EWD`, `CG` und `surface setup` bleiben getrennte Modi.
+4. `Dämpfungsflosse` ist der Standardbegriff fuer den feststehenden Leitwerksteil.
+5. `90 Grad Servoarm` darf nie als alleinige Sollbedingung modelliert werden.
@@ -0,0 +1,281 @@
+# AeroAlign + CoG - Workflow and System Plan
+
+## Ziel
+
+Das System soll in der Werkstatt ohne Umdenken bedienbar sein und drei unterschiedliche Aufgaben sauber trennen:
+
+1. feste Referenzflaechen ausrichten
+2. Ruder neutral oder symmetrisch einstellen
+3. Schwerpunkt messen und verschieben
+
+Der wichtigste Grundsatz ist:
+
+Ruder werden nicht primaer gegeneinander verglichen, sondern gegen ihre jeweilige feste Bezugsflaeche.
+
+Zusatz fuer Spezialfaelle:
+
+- EWD, CG und Rudereinstellung bleiben getrennte Ablaeufe
+- Dämpfungsflosse ist der bevorzugte Begriff fuer den feststehenden Leitwerksteil
+- Pendelleitwerk und Taileron werden als eigene Flaechentypen behandelt
+- 90 Grad am Servoarm ist keine universelle aerodynamische Regel
+
+## Bedienlogik
+
+### Was nicht ideal ist
+
+Dieser Ablauf ist fehleranfaellig:
+
+- Modell auf die CoG-Waage stellen
+- Querruder und Hoehenruder direkt miteinander vergleichen
+- eines davon so lange verstellen, bis beide denselben Winkel zeigen
+
+Warum das problematisch ist:
+
+- Tragflaeche und Hoehenleitwerk haben oft unterschiedliche Sollwinkel
+- ein neutrales Hoehenruder ist nicht automatisch derselbe Winkel wie ein neutrales Querruder
+- Sender-Subtrim sollte nicht die mechanische Grundjustage ersetzen
+
+### Besserer Ablauf
+
+1. Modell mechanisch neutralisieren
+2. feste Flaechen und Leitwerke referenzieren
+3. Ruder gegen die zugehoerige feste Flaeche einstellen
+4. Schwerpunkt auf der CoG-Waage einstellen
+5. Neutralstellungen danach kurz erneut pruefen
+
+## Empfohlene Werkstattmodi
+
+### 1. Referenzmodus
+
+Ziel:
+
+- Tragflaeche gegen Hoehenleitwerk
+- Tragflaeche links gegen Tragflaeche rechts
+- EWD oder andere feste Bezugswinkel
+
+Hinweis:
+
+Dieser Modus ist fachlich eigenstaendig und darf nicht mit CoG oder Ruderneutralitaet vermischt werden.
+
+Empfohlene Sensoren:
+
+- ein Sensor auf einer festen Tragflaechen-Referenz
+- ein Sensor auf Hoehenleitwerk oder anderer Referenzflaeche
+
+### 2. Rudermodus
+
+Ziel:
+
+- Querruder links gegen linke Tragflaeche
+- Querruder rechts gegen rechte Tragflaeche
+- Hoehenruder gegen Hoehenleitwerk
+- Seitenruder gegen Seitenleitwerk
+
+Regel:
+
+Jedes bewegliche Ruder wird gegen seine feste Nachbarflaeche verglichen.
+
+Ausnahmen:
+
+- Stabilator gegen externe Referenz
+- Taileron nach Profilregel
+- Wölbklappen mit moeglichem Grundoffset je Flugphase
+
+### 3. CoG-Modus
+
+Ziel:
+
+- Frontgewicht
+- Heckgewicht
+- Schwerpunktlage in mm
+- Abweichung zum Soll-CoG
+
+Hier spielen die IMU-Sensoren nur indirekt mit:
+
+- sie helfen vorher und nachher bei der Neutral- und Referenzpruefung
+- die CoG-Messung selbst basiert auf den Lastzellen
+
+## Minimal sinnvolles Hardware-Set
+
+### Variante A: praxisnahes Basisset
+
+- `1x Master` mit Web UI
+- `2x IMU Slave`
+- `1x CoG Scale` mit zwei Lastzellen
+
+Einsatz:
+
+- Sensor 1 auf fester Tragflaeche oder Referenzlehre
+- Sensor 2 auf Hoehenleitwerk oder Hoehenruder
+- CoG-System separat fuer den Schwerpunkt
+
+Das reicht fuer EWD, Hoehenruder-Neutralitaet und Schwerpunkt.
+
+### Variante B: guter Alltagsausbau
+
+- `1x Master`
+- `4x IMU Slave`
+- `1x CoG Scale`
+
+Einsatz:
+
+- linke Tragflaeche Referenz
+- rechtes Querruder
+- linkes Querruder
+- Hoehenleitwerk oder Hoehenruder
+- CoG-Jig parallel verfuegbar
+
+Damit werden Querruder-Symmetrie und Leitwerksabgleich deutlich komfortabler.
+
+### Variante C: Vollausbau
+
+- `1x Master`
+- `5-6x IMU Slave`
+- `1x CoG Scale`
+
+Zusaetzlich:
+
+- Seitenruder
+- zweite Flaechenreferenz
+- weitere Klappen oder Spoiler
+
+## Empfohlene Hardware-Rollen
+
+### Master
+
+- stationaeres Bediengeraet
+- optional eigener IMU-Sensor fuer Referenzaufgaben
+- WiFi AP und Web UI
+
+### IMU Slaves
+
+- kleine, leichte Clip-Sensoren
+- identische Gehaeuse und Halter, damit Bedienung einheitlich bleibt
+- eindeutige Rollen im UI statt nur Node-IDs
+
+Beispielrollen:
+
+- `Wing Ref Left`
+- `Wing Ref Right`
+- `Aileron Left`
+- `Aileron Right`
+- `Elevator`
+- `Fin / Rudder`
+
+### CoG Scale
+
+- ein eigenes Geraet mit zwei Auflagepunkten
+- zwei Lastzellen
+- fester, reproduzierbarer Auflageabstand
+- idealerweise mit definierter LE-Referenz oder verstellbarem Anschlag
+
+## Bedienbarkeit in der UI
+
+Die UI sollte nicht nur Nodes anzeigen, sondern gefuehrte Aufgaben.
+
+### Empfohlene Hauptansichten
+
+- `Setup`
+  - verbundene Geraete
+  - Akkustand
+  - Rollenbezeichnungen
+- `Reference`
+  - Flaeche gegen Leitwerk
+  - Referenzwinkel
+- `Surfaces`
+  - Querruder, Hoehe, Seite
+  - linke/rechte Symmetrie
+- `CoG`
+  - Frontgewicht
+  - Heckgewicht
+  - aktueller CoG
+  - Soll-CoG
+  - Delta zum Ziel
+
+### Wichtige UX-Regeln
+
+- keine reinen Node-IDs als primaere Anzeige
+- jede Messung braucht eine sprechende Rolle
+- gefuehrte Schritte statt nur Rohdaten
+- CoG-Ansicht und Ruder-Ansicht getrennt halten
+- Kalibrieren klar unterscheiden:
+  - IMU `Zero`
+  - Scale `Tare`
+  - Scale `Weight calibration`
+
+## Datenmodell, das dafuer noetig ist
+
+Pro Modellprofil sollten spaeter gespeichert werden:
+
+- Modellname
+- Flaechenreferenz
+- support distance `L`
+- offset der vorderen Auflage zur Nasenleiste
+- Soll-CoG
+- Rollenbelegung der Sensoren
+- optionale Servotests oder Sollwerte fuer Ruderausschlaege
+
+Die verbindliche Profil- und Flaechentyp-Definition steht in:
+
+- [AIRCRAFT_PROFILE_MODEL.md](/Users/florianklaner/Github/AeroAlign/docs/AIRCRAFT_PROFILE_MODEL.md)
+
+## Mechanische Anforderungen an die CoG-Hardware
+
+Damit das gut zusammenspielt, muss die CoG-Hardware nicht nur elektrisch, sondern auch mechanisch sauber sein.
+
+Pflichtpunkte:
+
+- reproduzierbarer Abstand der beiden Auflagen
+- rutschfeste Kontaktpunkte
+- definierte Flugzeugposition in Längsrichtung
+- steife Basis, damit Lasten nicht durchbiegen
+- einfache Nullstellung ohne Modell
+
+Sinnvoll:
+
+- verstellbare Auflagehoehen
+- verstellbarer LE-Anschlag
+- modulare Auflagen fuer verschiedene Rumpf-/Flaechenformen
+
+## Empfohlener End-to-End-Werkstattablauf
+
+1. Sender auf neutral, Trims und Subtrims auf Ausgangszustand
+2. Servoarme und Gestänge mechanisch sauber einstellen
+3. IMU-Sensor auf Tragflaechen-Referenz setzen
+4. IMU-Sensor auf Hoehenleitwerk oder Hoehenruder setzen
+5. Referenz- und EWD-Werte einstellen
+6. Querruder links und rechts gegen ihre jeweilige Referenz einstellen
+7. Modell auf die CoG-Waage stellen
+8. Akku oder Ballast verschieben, bis Soll-CoG erreicht ist
+9. Danach Ruderneutralitaet und Referenzwerte kurz nachpruefen
+10. Profil speichern
+
+## Konkrete Repo-Folgen
+
+### Naechste Firmware-Schritte
+
+1. `firmware/cog_slave` anlegen
+2. HX711 lesen und mitteln
+3. Tare und Skalierungsfaktoren speichern
+4. Rollen-/Profilverwaltung im Master ergaenzen
+5. neue UI-Ansichten `Reference`, `Surfaces`, `CoG`
+
+### Naechste Hardware-Schritte
+
+1. zwei Lastzellen mechanisch auf definierter Basis montieren
+2. Support-Abstand als feste Konstruktionsgroesse festlegen
+3. LE-Anschlag oder Referenzmarke vorsehen
+4. IMU-Halter fuer feste Bezugsflaechen vereinheitlichen
+
+## Fazit
+
+Ja: dein Gedanke geht in die richtige Richtung.  
+Nein: Hoehenruder und Querruder sollten nicht direkt als gemeinsame Soll-Referenz behandelt werden.
+
+Das bessere System trennt:
+
+- Referenzflaechen
+- Ruderneutralitaet
+- Schwerpunkt
+
+Genau so sollte auch die Hardware und die UI aufgebaut werden.