das siehst du am besten und genauesten, wenn du dir dort den Code ansiehst.
Die momentane Postion wird über unabh. Threads (Multithreading) ständig in real-time aus Odometrie und IMU-Daten berechnet und die Bewegungsänderungen (Winkel/Länge, also quasi Polarkoordinaten-Änderungen) in kartesische Koordinaten umgerechnet. Bezugssystem ist die geografische (Kompass-) Kartengeometrie, also 90° versetzt und im Drehsinn negativ zu mathematischen Koordinaten, damit die Bewegungen und Positionen auch sofort kompatibel zu GPS-Daten sind/wären.
Per Default ist der Nullpunkt des Koordinatenkreuzes der allererste Startpunkt (also nach dem Einschalten und Hochfahren des Systems), es sei denn, man definiert andere Defaults (z.B. aus GPS, oder mutwillige, ganz andere als rel. Bezugssystem).
Wenn ein Kompass verwendet wird (wie bei mir entweder zusätzlich zum Gyro oder den eingebauten im IMU), dann berechnet das System seine Ausrichtung hier nach, also absolut.
Damit bezieht sich dann das goto(x,y) immer auf den relativen Nullpunkt, will man eine absolute geografische Position anfahren, kann man das aber ebenso ganz einfach über die x,y offsets machen (die auch für den rel. Nullpunkt dann identisch sind), und Richtung nach vorn ist immer Kompass-Heading (Kompasskurs).
Ich habe bisher aber immer ausschließlich den relativen Nullpunkt verwendet (Startpunkt (0,0) für die relativen Koordinaten im jeweiligen Zimmer.
- - - Aktualisiert - - -
PS,
beim Lego-Modell mit getrenntem Gyro + Kompass werden alle Sensordaten für Strecke+Richtung (inkl. Odometrie) per einfacher statistischer Filter (Lowpass, Median)gewichtet und nach Plausibilität gefiltert (Ausreißer eliminieren, Gyro Drift beseitigen, Werte glätten), beim IMU (Arduino, Raspi) erledigt das für die Fahrtrichtung der im IMU eingebaute Signalprozessor per eigenem Kalmanfilter, wobei dann also nur die fusionierten IMU-Daten für die Richtung und nur die Odometrie-Daten für die Strecke verwendet werden (arithm. Mittel aus beiden Radencodern).
Zitieren
Lesezeichen