TLDR: Zuvor haben wir die Navigations-Engine als eine Reihe von Modulen dargestellt: Messmodellierung, Dynamikmodellierung, den Schätzer und die RTK-Positionsbestimmung. In diesem Beitrag öffnen wir das Modul des Schätzers. Die eigentliche Aufgabe des Schätzers besteht nicht darin, einem einzelnen Sensor zu vertrauen, sondern jede Messung anhand des bereits bekannten Wissens zu gewichten und sie dann zu einem Filterzustand zusammenzufassen, während er gleichzeitig verfolgt, wie sicher er sich hinsichtlich des Ergebnisses ist.
Mittlerweile sind die Messdaten in gutem Zustand. Durch die Zeitsynchronisation wurde für alle Daten eine gemeinsame Zeitbasis geschaffen. Im Rahmen der Vorverarbeitung wurden die Rohdatenströme bereinigt. Die Navigations-Engine hat modelliert, welche Werte die einzelnen Sensoren liefern sollten, und die RTK-Positionsbestimmung hat die GNSS-Messungen auf Zentimetergenauigkeit gebracht.
Im Mittelpunkt all dessen steht der Schätzer. Er ist der Teil des Systems, der einzelne, manchmal kaum miteinander in Zusammenhang stehende Messwerte, die alle etwas über den Zustand der Welt aussagen, zu einer einzigen Antwort zusammenfasst.
In diesem Beitrag geht es darum, was eigentlich im Inneren der Schätzbox vor sich geht.
Der Zustandsvektor: Was der Schätzer tatsächlich schätzt
Der Filterzustand, auch Zustandsvektor genannt, ist die Menge an Zahlen, die der Schätzer zu bestimmen versucht. Position, Geschwindigkeit und Ausrichtung sind die offensichtlichsten davon. Der Zustand umfasst jedoch in der Regel auch weniger offensichtliche Größen: Korrekturen für Sensoren mit zugrunde liegenden Fehlern sowie andere Werte, die das System lediglich als Nebenprodukte schätzt, da es diese benötigt, um eine genaue Position zu ermitteln.
Manche Messungen geben direkt Aufschluss über einen Bestandteil dieses Zustandsvektors. Eine Positionsmessung ist der einfachste Fall: Man erhält einfach eine Position. Andere Messungen sind indirekt. Die Radgeschwindigkeiten geben Auskunft darüber, wie schnell man sich bewegt, nicht aber darüber, wo man sich befindet. Die Entfernung zu einem Satelliten liefert zwar Informationen über die Position, jedoch nur in Kombination mit vielen anderen Entfernungswerten.
Die Aufgabe des Schätzers besteht darin, all diese direkten und indirekten Daten zu berücksichtigen und sie so zu verarbeiten, dass eine aktualisierte Schätzung dessen entsteht, was für Sie tatsächlich von Bedeutung ist. Das gelingt nicht auf Anhieb. Er lernt den Zustand im Laufe der Zeit kennen und verfeinert ihn mit jeder neuen Messung.
Gewichtung: Konfidenz versus erwarteter Fehler
Die wichtigste Aufgabe des Schätzers besteht darin, jede Messung zu gewichten.
Jede Messung weist einen gewissen Spielraum auf, also einen erwarteten Fehler. Der Schätzer vergleicht diesen mit der Sicherheit, die er bereits hinsichtlich seiner aktuellen Schätzung hat. Wie gut glaube ich, meine Position im Moment zu kennen? Meine Ausrichtung? Eine Messung, die verrauscht ist oder nur einen losen Bezug zum Zustand hat, erhält weniger Gewicht als eine, die präzise und zuverlässig ist.
Dieses Gleichgewicht verschiebt sich im Laufe der Zeit. Wenn Sie ein Gerät zum allerersten Mal einschalten, weiß der Schätzer so gut wie nichts. Position, Ausrichtung, Sensorfehler: All das ist ungewiss. In diesem Zustand ist selbst eine verrauschte Messung wertvoll, denn irgendetwas ist besser als gar nichts, und das System stützt sich auf eingehende Daten, um zu lernen.
Sobald das System läuft und sich seiner Position sicher ist, kehrt sich das Verhältnis um. Angenommen, Sie haben eine RTK-Position und kennen Ihre Position sehr genau, und dann trifft eine fehlerhafte GNSS-Messung ein, die durch ein Gebäude oder eine andere Fehlerquelle verfälscht wurde. Der Schätzer kann diese Messung und den Fehler, den sie normalerweise aufweisen sollte, mit dem vergleichen, was er bereits als richtig ansieht. Liegt die Messung weit außerhalb des erwarteten Fehlerbereichs, kann der Schätzer sie heruntergewichten oder gänzlich verwerfen. (Teil 3 behandelt diesen Umgang mit Ausreißern ausführlicher.)
Komplementäre Sensoren: Das Beste aus beiden Welten
Eine fehlerhafte GNSS-Messung zu verwerfen, bedeutet nicht, dass man plötzlich nichts mehr sieht. Die anderen Sensoren liefern weiterhin Daten.
Das ist die Stärke der Multisensor-Fusion: Die Sensoren ergänzen sich. Die Radgeschwindigkeiten wissen nichts von dem hohen Gebäude am Ende des Blocks, und es ist ihnen auch egal. Die GNSS-Messungen können durch dieses Gebäude beeinträchtigt werden, aber wenn dies nicht der Fall ist, können sie hervorragend sein. Die IMU (Trägheitsmesseinheit) arbeitet schnell, schneller als die GNSS-Aktualisierungen, und füllt so die Bewegungsdaten zwischen diesen Lücken. Radgeschwindigkeitsdaten kommen möglicherweise mit einer geringeren Frequenz an, manchmal sogar seltener als GNSS-Daten. Im Laufe der Zeit unterstützen sie sich gegenseitig. Kombiniert man sie, gleicht jedes die Schwäche des anderen aus: die absolute Genauigkeit von GNSS, wenn es einwandfrei funktioniert, und ein konstantes Bewegungsgefühl, wenn dies nicht der Fall ist.
Zwei Familien: INS versus reines GNSS
Bevor der Schätzer vorhersagen kann, wie sich der Zustand zwischen den Messungen verändert, muss er wissen, auf welcher Art von System er läuft. Hier gibt es eine klare Trennlinie, und es kommt letztlich auf einen einzigen Sensor an.
Ein Trägheitsnavigationssystem (INS) verfügt über eine IMU. Ein reines GNSS-System hingegen nicht. Dieser Unterschied ist für die Engine wichtiger als fast alles andere.
Eine IMU misst Beschleunigungen und Drehgeschwindigkeiten sehr präzise. Integriert man diese Werte über die Zeit, erhält man ein direktes Bild davon, wie sich Position und Geschwindigkeit verändern. Die IMU liefert Informationen darüber, wie sich der Zustand während der Bewegung der Plattform entwickelt, und ergänzt damit absolute Messungen wie GNSS oder Computer Vision, die Aufschluss über die Welt außerhalb des Geräts geben. Die Qualität der IMU, die von Kosten, Stromverbrauch und anderen Faktoren abhängt, bestimmt die erreichbare Präzision.
Nimmt man die IMU weg, gerät man in eine viel schwierigere Lage. Stellen Sie sich vor, Sie fahren auf einer Autobahn und biegen in einen Tunnel ein. Vor dem Tunneleingang funktionierte das GNSS einwandfrei und alles war in Ordnung. Im Tunnel ist das GNSS-Signal nicht mehr vorhanden. Mit einer IMU (oder Radgeschwindigkeitssensoren oder anderen Sensoren zur Erfassung relativer Bewegungen) kann man während dieser Unterbrechung die Position durch Koppelnavigation bestimmen. Ohne diese Hilfsmittel kann man vielleicht ein paar Sekunden lang raten, doch danach liegt man einfach falsch.
Wenn man diese Relativbewegungssensoren nicht hat, kann man sich bestenfalls darauf stützen, wie sich ein solches Fahrzeug normalerweise bewegt. Wir haben eine ziemlich gute Vorstellung davon, wie sich Autos verhalten: Sie fahren im Allgemeinen weder bergauf noch bergab, schwanken kaum seitlich und überschlagen sich schon gar nicht. Bei einem Boot oder einem Flugzeug sieht die Sache anders aus. Diese Annahmen, auf die sich ein INS weitaus weniger stützt, da die IMU die Bewegung direkt misst, sind das, womit sich ein reines GNSS-System begnügen muss. (Zur Dynamik der einzelnen Plattformen – Autos im Vergleich zu Flugzeugen im Vergleich zu Motorrädern – siehe Teil 3.)
Diese Aufteilung in „INS“ und „nur GNSS“ bildet die Grundlage des Atlas-INS-Ansatzes: Eine leistungsfähige Positionierungs-Engine wird mit einer Trägheitsmessung kombiniert, sodass das System auch dann weiterhin eine verwertbare Position liefert, wenn keine Sichtverbindung zum Himmel besteht.
Pseudomessungen: Erfinden von Daten, die Sie nie gemessen haben
Das ist einer der interessanteren Tricks, die der Schätzer zu bieten hat. Wissenschaftler bezeichnen solche Verfahren oft als Pseudomessungen: Man nutzt das eigene Wissen über ein Fahrzeug, um einzuschränken, was das System tun darf und was schlichtweg keinen Sinn ergibt.
Die Erkennung des Stillstands ist das eindeutigste Beispiel. Nehmen wir an, die IMU meldet, dass Sie sich nicht drehen – denn die Drehgeschwindigkeit ist genau das, was sie misst – und dass Sie auch nicht beschleunigen. Streng genommen bedeutet keine Beschleunigung, dass sich Ihre Geschwindigkeit nicht ändert, nicht aber, dass sie null ist. Da echte Fahrzeuge jedoch fast nie eine vollkommen konstante Geschwindigkeit beibehalten, kann man in der Praxis davon ausgehen, dass Sie stehen geblieben sind, wenn die IMU weder Beschleunigung noch Drehung anzeigt.
In der Praxis lesen wir die Rohwerte für Drehung und Beschleunigung nicht aus und vergleichen sie nicht mit Null. Die Beschleunigung ist ohnehin nie wirklich null, da die Schwerkraft immer vorhanden ist und sich über die Achsen verteilt, es sei denn, das Gerät befindet sich zufällig in perfekter Waagerechte. Stattdessen beobachten wir, wie sich diese Signale über einen bestimmten Zeitraum hinweg verändern und wie stark sie verrauscht sind. Ein Fahrzeug, das wirklich zum Stillstand gekommen ist, erzeugt ein charakteristisches, gleichmäßiges Signalmuster, und durch diese Art der Auswertung können wir den Stillstand erkennen und gleichzeitig die sensoreigenen Abweichungen ignorieren.
Sobald wir wissen, dass das Fahrzeug steht, zahlt sich der Trick aus. Ein stehendes Auto rollt nicht und neigt sich nicht, sodass wir davon ausgehen können, dass die tatsächliche Drehgeschwindigkeit null und die tatsächliche Geschwindigkeit null ist. Diese Werte geben wir als Pseudomesswerte zurück und messen, wie stark die Sensoren davon abweichen. Diese Abweichung ist der Sensorfehler, der sich hier offenbart. Daraus leiten wir Sensorkorrekturen ab – Aussagen wie „Dieser bestimmte Sensor weicht um diesen Betrag in dieser Weise ab“ – und wenden sie auf das Dynamikmodell und die eingehenden Messwerte an, sodass die gesamte Lösung mit der Zeit präziser wird.
Diese Korrekturen sind nicht statisch. Sie entwickeln sich weiter. Temperatur und andere Umweltfaktoren beeinflussen sie, sodass das System sie im Laufe der Zeit immer wieder neu lernt. Aber sobald man sie gut im Griff hat, kann man aus Messungen, die auf dem Papier eigentlich nicht so gut sein sollten, echte Präzision herausholen.
Modul versus Host: Wo der Schätzer ausgeführt wird
Das klingt alles nach reiner Mathematik, und das ist es auch, aber diese Mathematik ist nicht umsonst. Die Vorwärtsberechnung des Schätzers und die Durchführung der Dynamikmodellierung erfordern echte Rechenleistung.
Zunächst zu den beiden Orten, an denen die Berechnung stattfinden kann. Wenn die Positionsbestimmung auf einem Modul läuft, befindet sich der Schätzer auf einem kleinen, in sich geschlossenen Gerät mit eigenem Prozessor und eigenem Stromverbrauch, einer Platine, die ausschließlich für diese eine Aufgabe vorgesehen ist. Wenn sie auf einem Host läuft, wird der Schätzer auf dem größeren Hauptcomputer ausgeführt, der bereits im Fahrzeug oder Roboter verbaut ist – auf derselben Prozessorklasse, die auch für die Wahrnehmung, Planung und den Rest der Anwendung zuständig ist. Ein Modul ist kompakt, energieeffizient und lässt sich leicht in ein Design integrieren. Ein Host verfügt über weitaus mehr Rechenleistung und Speicherreserven. Um diesen Unterschied in der Leistungsreserve geht es im weiteren Verlauf dieses Abschnitts.
Hier gibt es einen historischen Hintergrund, der erwähnenswert ist: Vieles von dem, was wir heute mit Schätzern tun, entstand aus dem Bestreben, diese Art von Berechnungen für kleine Computer kostengünstig genug zu machen – eine Entwicklung, deren Wurzeln bis zum Apollo-Navigationscomputer zurückreichen. In gewisser Hinsicht ging es in diesem Fachgebiet also schon immer darum, Schätzverfahren an die Gegebenheiten begrenzter Hardware anzupassen. Aber das ist alles relativ.
Auf einem weniger leistungsfähigen Gerät, beispielsweise dem eingebetteten Prozessor eines Moduls, kann es einfach zu einem Mangel an Rechenkapazität kommen. Wenn Sie eine IMU mit sehr hoher Messrate anschließen oder besonders rechenintensive Berechnungen oder Algorithmen ausführen, ist es unter Umständen physikalisch nicht möglich, mitzuhalten. Und die Folgen beschränken sich nicht nur darauf, dass „es langsamer läuft“. Stellen Sie sich einen Rennwagen mit starker Dynamik und starken Vibrationen vor, bei dem die Messungen mit hoher Abtastrate genau die Details liefern, die Sie erfassen möchten. Wenn der Prozessor bei dieser Rate nicht mithalten kann, sind Sie möglicherweise gezwungen, eine Messung mit niedrigerer Abtastrate zu verwenden – und genau die wichtigen Details könnten dabei verloren gehen. Oder Sie müssen Funktionen in der Navigations-Engine einschränken oder deaktivieren, auf die Sie sich normalerweise verlassen, was die Leistung beeinträchtigen kann.
Das ist nur eines von vielen Beispielen, aber es verdeutlicht den Sachverhalt. Einige der Techniken, die man benötigt, um ein Höchstmaß an Präzision zu erreichen, lassen sich auf bestimmten Geräten einfach nicht gut umsetzen, da diese Geräte gleichzeitig noch zahlreiche andere Aufgaben bewältigen müssen. Das ist der praktische Unterschied zwischen einer leistungsfähigen Engine, die auf einem Modul läuft, und einer robusteren, die auf einem Host-Prozessor mit ausreichender Rechenleistung läuft. Das ist auch der Grund, warum die richtige Lösung ganz von der jeweiligen Plattform abhängt.
Fragen, die es wert sind, gestellt zu werden
Wenn Sie Ihren eigenen Stack aufbauen oder eine kommerzielle Positionierungs-Engine prüfen:
- Wie gewichtet der Schätzer eine Messung im Verhältnis zu seiner eigenen Konfidenz? Was passiert mit einer zuverlässigen Schätzung, wenn eine einzelne fehlerhafte GNSS-Messung eintrifft?
- Lernt das System Sensorkorrekturen in Echtzeit und passt es diese bei Änderungen der Temperatur und der Umgebungsbedingungen kontinuierlich an?
- Kann es Pseudomessungen wie die stationäre Erkennung nutzen, oder wertet es die Sensordaten lediglich zum Nennwert aus?
- Wie verhält sich das System mit einer IMU im Vergleich zu einer reinen GNSS-Lösung? Was ist die Ausweichlösung, wenn keine Sicht zum Himmel besteht?
- Für welche Hardware ist der Motor ausgelegt? Passt der von Ihnen benötigte Hochgeschwindigkeitspfad tatsächlich neben all den anderen laufenden Prozessen auf Ihren Prozessor?
Wie geht es weiter?
Der Schätzer hat seine Arbeit erledigt. Er liefert mehrmals oder sogar viele Male pro Sekunde einen präzisen Filterzustand. Es bleiben jedoch zwei Probleme bestehen. Erstens: Um Messwerte zu verarbeiten, die in ungeordneter Reihenfolge eintreffen, muss die Engine möglicherweise etwas hinter der Echtzeit zurückbleiben, was bedeutet, dass ihr aktuelles Ergebnis etwas veraltet ist. Zweitens: Dieses Ergebnis besteht nach wie vor lediglich aus Zahlen innerhalb der Engine; kein anderer Teil Ihres Systems kann es bisher nutzen.
Im nächsten Beitrag behandeln wir die letzte Stufe der Pipeline: den Output-Propagator, der Echtzeitdaten wiederherstellt, sowie die Output- und Transport-Dienste, die den Filterzustand in Nachrichten umwandeln, die Ihr Stack tatsächlich verarbeiten kann.
Häufig gestellte Fragen
Was macht der Schätzer in einer Positionierungs-Engine eigentlich?
Es nimmt separate, manchmal kaum miteinander in Zusammenhang stehende Sensormesswerte und fasst sie zu einem einzigen Filterzustand zusammen. Seine Kernaufgabe besteht darin, jeden Messwert anhand seines erwarteten Fehlers im Verhältnis zur bereits vorhandenen Sicherheit des Systems zu gewichten und den Zustand entsprechend zu aktualisieren, anstatt sich blind auf einen einzelnen Sensor zu verlassen.
Was ist ein Zustandsvektor?
Der Zustandsvektor ist die Menge der Werte, die der Schätzer ermittelt. Er umfasst Position, Geschwindigkeit und Ausrichtung sowie weniger offensichtliche Größen wie Korrekturen für Sensoren mit zugrunde liegenden Fehlern und andere Werte, die das System als Nebenprodukte auf dem Weg zu einer korrekten Position schätzt.
Was ist der Unterschied zwischen einem INS-System und einem reinen GNSS-System?
Ein Trägheitsnavigationssystem (INS) umfasst eine IMU, die Beschleunigung und Drehung misst, sodass es die Veränderungen von Position und Geschwindigkeit zwischen den absoluten Positionsbestimmungen verfolgen und auch bei Ausfällen, beispielsweise in Tunneln, die Kurs- und Geschwindigkeitsberechnung aufrechterhalten kann. Ein reines GNSS-System verfügt über keinen solchen Sensor und muss sich bei einem Verlust der Satellitensignale auf allgemeine Annahmen über die Bewegung des Fahrzeugs stützen.
Was sind Pseudomesswerte bei der Sensorfusion?
Pseudomessungen sind Einschränkungen, die sich aus den Informationen des Systems über die Plattform ableiten. Wenn der Motor beispielsweise feststellt, dass ein Auto steht, kann er annehmen, dass die tatsächliche Drehzahl und Geschwindigkeit null sind, diesen Wert zurückmelden und messen, wie stark die Sensoren davon abweichen. Diese Abweichung deckt Sensorfehler auf, die das System anschließend korrigieren kann.
Spielt es eine Rolle, ob die Positionsermittlungs-Engine auf einem Modul oder einem Host-Prozessor läuft?
Ja. Ein Modul verfügt nur über begrenzte Rechenleistung und Energie, und hohe Anforderungen wie eine IMU mit sehr hoher Abtastrate oder rechenintensive Algorithmen können zu niedrigeren Messraten oder zur Deaktivierung bestimmter Funktionen führen. Ein Host-Prozessor verfügt über weitaus mehr Leistungsreserven, was Techniken ermöglicht, die ein Modul nicht unterstützen kann. Die richtige Wahl hängt von der jeweiligen Plattform ab.
Dies ist Teil 5 unserer Reihe zur Architektur von Ortungssystemen. In Teil 1 ging es um die Zeitsynchronisation. In Teil 2 wurden die Vorverarbeitung und die Sensorstrategie behandelt. In Teil 3 ging es um die Navigations-Engine. In Teil 4 wurde die RTK-Positionsbestimmung behandelt.
Testen Sie unser RTK-Netzwerk kostenlos. Erschwingliche, weltweite Präzision ganz ohne Aufwand. Starten Sie Ihre kostenlose Testphase.