Einbaulage: Verdrehung um die Hochachse messen – und Geräte dabei nicht verlieren

Sitzt der Sensor schräg statt längs im Fahrzeug, verteilt sich eine reine
Querneigung auf beide Achsen: Das Fahrzeug kippt zur Seite, und die
Längsanzeige kippt sichtbar mit – bei 20° Verdrehung mit gut einem
Drittel des Werts. Achsentausch und Vorzeichen halfen dagegen nicht, die
springen in 90°-Schritten.

SensorOrientation bekommt deshalb "twist", einen stufenlosen Winkel. Der
Einbaulage-Assistent misst ihn ohne zusätzlichen Handgriff mit: Beim
Kippen der Front nach unten dürfte sich nur die Längsneigung ändern;
wandert die Querneigung mit, ist das der gesuchte Winkel. Unter zwei Grad
gilt es als Wackeln der Hand. Angezeigt wird er in der Zusammenfassung
("um 20° verdreht"), herausgerechnet bei jeder Anzeige.

Beim Kalibrieren liesse sich das grundsätzlich nicht ermitteln: Es misst
eine einzige Lage und zieht sie als Nullpunkt ab. Eine Drehung um die
Hochachse steckt darin nicht – eben sieht in jeder Verdrehung gleich aus.

Das neue Feld hat beim Aufspielen sämtliche eingerichteten Geräte
gekostet, und der Grund gehört hierher: Swifts erzeugte Codable-Umsetzung
verlangt beim Lesen jedes Feld, Standardwerte im Code zählen nicht.
Gespeicherte Einbaulagen hatten kein "twist", also scheiterte das Lesen
der Einbaulage, damit des Geräts, damit der ganzen Liste – und das
nächste Speichern schrieb die leere Liste über den Bestand.

Zwei Vorkehrungen dagegen:

* SensorOrientation liest jetzt von Hand und nachsichtig, mit
  decodeIfPresent und Rückfallwerten, wie Profile und ConfiguredDevice es
  längst tun. Jedes künftige Feld gehört dort hinein.
* DeviceStore liest die Liste zweistufig: scheitert sie als Ganzes, wird
  jedes Gerät einzeln versucht und behalten, was lesbar ist. Die
  Rohdaten wandern zusätzlich in einen eigenen Schlüssel, statt beim
  nächsten Speichern überschrieben zu werden.

Beides in run-tests.sh abgesichert: die Erkennung und Rückrechnung der
Verdrehung samt Gegenprobe ohne Korrektur, und das Lesen gespeicherter
Geräte ohne "twist", ganz ohne Einbaulage und mit unbrauchbarer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
BiasF
2026-08-31 19:40:45 +02:00
co-authored by Claude Opus 5
parent 4936a767a3
commit a9a44b49d6
4 changed files with 217 additions and 5 deletions
+13
View File
@@ -175,6 +175,19 @@ Vorzeichen. Der Assistent unter *Sensor → Einbaulage* klärt das durch zwei
Kippbewegungen: einmal die Front nach unten, einmal die linke Seite. Aus der
Reaktion ergibt sich die Zuordnung geraten wird nichts.
Dabei wird auch eine **Verdrehung um die Hochachse** mitgemessen, also der
Fall, dass der Sensor schräg statt längs im Fahrzeug klebt. Ohne diese
Korrektur verteilt sich eine reine Querneigung auf beide Achsen: Das Fahrzeug
kippt zur Seite, und die Längsanzeige kippt sichtbar mit bei 20° Verdrehung
mit gut einem Drittel des Werts. Der Winkel steht im Ergebnis des Assistenten
(„um 20° verdreht") und wird von da an herausgerechnet.
Beim **Kalibrieren** liesse sich das nicht ermitteln, und zwar grundsätzlich
nicht: Es misst eine einzige Lage und zieht sie als Nullpunkt ab. Eine Drehung
um die Hochachse steckt darin nicht eben sieht in jeder Verdrehung gleich
aus. Dafür braucht es zwei Kippbewegungen in bekannte Richtungen, und genau die
macht der Einbaulage-Assistent.
**Danach kalibrieren:** Fahrzeug eben stellen, dann *Auf
aktuelle Lage kalibrieren*. Ohne das zeigt die Anzeige die Lage des Sensors,
nicht die des Fahrzeugs je nachdem, wie schief er eingebaut ist.