TLDR: Bevor Sie GNSS/RTK-Hardware bewerten, benötigen Sie drei Eingaben: Designvorgaben (Leistung, Kosten, Formfaktor und Rechenleistung – wobei die Rechenleistung am häufigsten unterschätzt wird), Betriebsumgebung (Himmelsfreisicht, Antennenmontage und Plattformdynamik) sowie Anwendungsfall (was das System in seinen schlechtesten Momenten leisten muss, nicht in seinen besten). Eine gezielte Stunde der Analyse dieser drei Faktoren liefert zwei oder drei Architekturkandidaten, die für Tests unter realen Bedingungen bereit sind – und vermeidet Neudesigns, die Projekte bereits in der DVT-Phase zum Scheitern bringen.
Das Höre ich am häufigsten, wenn ein neuer Kunde hereinkommt: „Ich muss mit GPS eine Genauigkeit von einem Zentimeter erreichen.“
Diese Angabe stammte in der Regel aus dem Datenblatt eines Empfängers. Man hatte ein Modul gefunden, das RTK unterstützt, die Spezifikation gelesen – „ein Zentimeter plus ein Teil pro Million mal Baseline“ – und sie in die Anforderungen aufgenommen. Die nächste Frage lautete: Wie kann dieser Empfänger tatsächlich in jeder Umgebung, in der das Produkt zum Einsatz kommt, eine Genauigkeit von einem Zentimeter gewährleisten?
Das ist der Beginn des Erkundungsprozesses.
Die Angaben im Datenblatt sind zwar korrekt, wurden jedoch unter idealen Bedingungen gemessen: uneingeschränkte Sicht zum Himmel, eine Antenne ohne jegliche Störquellen und eine kurze Entfernung zur Basisstation. Die meisten Produkte werden jedoch bei weitem nicht unter solchen Bedingungen eingesetzt. Das Datenblatt enthält keine Genauigkeitsangaben für sechs verschiedene Umgebungen, da diese Umgebungen nicht das Problem des Herstellers sind – es ist Ihre Aufgabe, die entsprechenden Lösungen zu entwickeln.
Unter „Discovery“ versteht man den Prozess, bei dem ein Wert aus dem Datenblatt durch eine Reihe von Anforderungen ersetzt wird, die auf Ihr Produkt zugeschnitten sind.
Der Instinkt, schnell zur Hardware zu gelangen, ist richtig – die Reihenfolge ist entscheidend
Ingenieure wollen entwickeln und testen. Das Interesse an der Hardware ist verständlich. Doch wenn man diesem Interesse nachgeht, bevor man die richtigen Informationen eingeholt hat, verlieren Programme an Zeit.
Die Teams, die den Zeitplan auf der linken Seite des V-Modells straffen, sind diejenigen, die die Discovery-Phase gut umsetzen. Ein zielgerichtetes Discovery-Gespräch deckt die wichtigsten Inputs in etwa einer Stunde ab. Architekturoptionen nehmen bereits während dieses Gesprächs Gestalt an, nicht erst danach – und das Ergebnis ist ein Team, das schneller zu repräsentativer Hardware gelangt und dabei mehr Vertrauen in die Architektur hat, die es testet.
Das System, das derzeit entwickelt wird, umfasst den gesamten Lokalisierungs-Stack: Antennen, Empfänger, IMU, Software für die Positionsbestimmung sowie die Konnektivität für Korrekturdaten. Es geht also nicht nur um das GNSS-Modul. Jedes Element wird durch die Ergebnisse der Erkundungsphase geprägt.
Die drei Faktoren sind Konstruktionsbeschränkungen, Betriebsumgebung und Anwendungsfall.
Eingabe 1: Entwurfsbeschränkungen – die vier physikalischen Grenzen, die jede Hardware-Entscheidung bestimmen
Bevor Sie Hardware bewerten, müssen Sie die Einschränkungen kennen, denen jede Hardwareauswahl standhalten muss. Diese definieren die äußeren Grenzen des Entwurfsraums.
Leistungsbudget. Ein tragbares Gerät verfügt über einen kleinen Akku. Diese Einschränkung schränkt die Auswahl an verfügbaren Empfängern sofort ein. Leistungsfähigere Empfänger verbrauchen in der Regel mehr Strom, sodass ein knapperes Leistungsbudget Kompromisse an anderer Stelle im System erfordert.
Kostenziel. Ein High-End-Vermessungsempfänger auf jeder Drohne einer Flotte liefert zwar hervorragende Positionsdaten – ist aber bei großem Umfang nicht rentabel. Das Kostenziel legt die Obergrenze für die Hardware bei großen Stückzahlen fest. RTK-Korrekturen verändern diese Rechnung erheblich: Ein kostengünstigerer Empfänger mit Zugang zu einem Korrekturnetzwerk kann eine Genauigkeit erreichen, die er im Alleingang nicht erreichen könnte, was einen Kosten-Leistungs-Kompromiss eröffnet, den die meisten Teams zunächst nicht berücksichtigen.
Größe, Formfaktor und Platz auf der Leiterplatte. Die Antenne muss an einer Stelle auf der Plattform angebracht werden, an der sie einen freien Blick zum Himmel hat. Der Empfänger und die Recheneinheit müssen in den mechanischen Rahmen passen. Der Platz auf der Leiterplatte ist begrenzt, und jede Komponente, die sich diesen teilt, birgt das Risiko von HF-Störungen. Der Formfaktor bestimmt die Platzierung der Antenne, was wiederum die Signalqualität beeinflusst und damit den gesamten Positionierungsstack.
Rechenkapazität – wählen Sie nicht die falsche aus. Dies ist die am häufigsten unterschätzte Einschränkung und diejenige, die zu den schmerzhaftesten Umgestaltungen in der späten Projektphase führt.
Die meisten RTK-Empfänger sind modular aufgebaut – die Positionsbestimmungs-Engine läuft auf der eigenen Rechenleistung des Moduls, die jedoch begrenzt ist. Für Anwendungen mit guter Sicht zum Himmel ist das kein Problem. Wenn jedoch zusätzliche Sensoren einbezogen werden müssen, die Plattformdynamik komplex ist oder mehr als eine Standardlösung aus RTK und IMU erforderlich ist, wird die Rechenleistungsgrenze zu einer unüberwindbaren Hürde.
Teams, die ihr System um einen modularen Empfänger herum aufgebaut hatten und bei DVT feststellten, dass die für ihre Umgebung erforderliche Sensorfusion die Möglichkeiten des Moduls überstieg, standen vor zwei Optionen: das System zu vereinfachen oder es auf eine hostbasierte Architektur umzugestalten, bei der die Positionierungs-Engine auf dem Hauptrechner der Plattform läuft. Beide Optionen sind in dieser Phase mit hohen Kosten verbunden.
Der Wandel, den wir derzeit beobachten, besteht darin, dass Teams schon frühzeitig fragen: Können wir die bereits auf der Plattform vorhandenen Rechenressourcen nutzen? Oft lautet die Antwort „Ja“ – und wenn man dies frühzeitig erkennt, bleiben die Kosten für die Architekturentscheidung gering.
Eingabe 2: Betriebsumgebung – drei Ebenen, die bestimmen, welchen Belastungen die Hardware standhalten muss
Designvorgaben legen fest, wie die Hardware beschaffen sein muss. Die Betriebsumgebung legt fest, welchen Belastungen sie standhalten muss.
Wo GNSS zum Einsatz kommt. Der freie Himmel ist der einfachste Fall. Wenn ein Produkt stets unter freiem Himmel und mit verfügbarer Internetverbindung betrieben wird, kann eine reine RTK-Engine die richtige Lösung sein – und das sollte man direkt sagen. Doch der freie Himmel ist selten die gesamte Realität. Städtische Umgebungen, Baustellen, Übergänge zwischen Innen- und Außenbereichen sowie alles, was in der Nähe von Gebäuden betrieben wird, verursachen Mehrwegausbreitung und Signalverschlechterung, was die Architektur völlig verändert. Ein unterirdischer Versorgungsscanner, der auf einem Parkplatz funktioniert, ist nicht dasselbe Produkt wie einer, der direkt an einer Gebäudewand scannt.
Worauf das Gerät montiert ist. Eine auf dem Autodach montierte Antenne profitiert von einer hervorragenden Sicht zum Himmel und einer als Erdungsfläche fungierenden Unterlage. Ein am Brustkorb oder an der Schulter getragenes Gerät unterliegt anderen Signalbedingungen – Körperabschirmung, variierende Ausrichtung und eine schwerer zu steuernde Signalqualität. Die Art der Montage bestimmt die anfängliche Signalqualität, die wiederum bestimmt, wie stark die Ortungsengine arbeiten muss, was wiederum bestimmt, welche Sensoren für die Fusionsverarbeitung benötigt werden.
Plattformdynamik, Schwingungen und Bewegungsmodelle. Eine Drohne weist andere Bewegungseigenschaften auf als ein Auto. Ein Fahrzeug mit Allradlenkung verhält sich anders als eine Plattform mit Zweiradlenkung – und zwar in einer Weise, die für die Modellierung der Bewegung durch einen Sensorfusionsalgorithmus von Bedeutung ist. Ein landwirtschaftlicher Traktor weist spezifische Schwingungs- und Schlupfprofile auf. Eine gehende Person erzeugt ein völlig anderes dynamisches Muster.
Im Bewegungsmodell wird dies konkret. Die Sensor-Fusions-Software modelliert, wie sich die jeweilige Plattform bewegt – was sie tut, wenn sie beschleunigt, abbiegt, vibriert oder vorübergehend den GNSS-Empfang verliert. Ein verallgemeinertes Modell deckt ein breites Spektrum an Plattformen angemessen ab. Im Leistungsgrenzbereich wird eine Lösung, die auf die tatsächliche Dynamik der Plattform abgestimmt ist, jedoch bessere Ergebnisse liefern. Die meisten modularen Empfänger werden mit einer verallgemeinerten Trägheitslösung ausgeliefert – das ist ein bekannter Kompromiss, aber es muss der richtige Kompromiss für die jeweilige Anwendung sein.
Die Signalqualität verbindet alle drei Ebenen miteinander. Sie ist der entscheidende Faktor dafür, ob in einer bestimmten Betriebsumgebung eine RTK-Genauigkeit im Zentimeterbereich erreicht werden kann.
Eingabe 3: Anwendungsfall – was das System in seinen schwierigsten Momenten ausgeben muss
Was muss das System in seinen schwierigsten Momenten leisten – nicht in den einfachsten? Ein Produkt, das unter freiem Himmel eine Genauigkeit im Zentimeterbereich erreicht, aber überall sonst versagt, ist kein Produkt – es ist ein Prototyp, der den falschen Test bestanden hat. Das Ziel ist ein System, das in 99,9 % der Fälle funktioniert, und zwar in allen Umgebungen, denen die Anwendung ausgesetzt sein wird.
Das bedeutet, dass die Genauigkeit auf einem Niveau angegeben werden muss, das konstruktiv realisierbar ist. Ein Zentimeter ist ein Zielwert. Entscheidend sind der 1-Sigma-Fehler, der 2-Sigma-Fehler, das Sicherheitsniveau und das Verhalten des Systems, wenn es diese Grenzen nicht einhalten kann. Nur die Position oder auch die Lage – Kurs, Nick- und Rollwinkel? Ein Fahrzeug, das seine Ausrichtung in einer Kurve mit Schräglage kennen muss, stellt ein anderes Problem dar als ein Scanner, der lediglich die absolute Position benötigt.
Im Rahmen des Anwendungsgesprächs kommen auch Einschränkungen zum Vorschein, die zunächst nicht offensichtlich waren. Ein Team, das sein Produkt als tragbares Gerät für den Außenbereich beschreibt, betrachtet es möglicherweise zunächst nicht als Problem im städtischen Umfeld – bis der Anwendungsfall verstanden wird. Sobald dies klar ist, ergeben sich die Konsequenzen für das Design unmittelbar daraus.
Geschäftsergebnisse und Skalierbarkeit. Wie lässt sich die Anwendung skalieren? Das Zielvolumen bestimmt die Korrekturstrategie, die Anforderungen an die Konnektivität und die Architekturentscheidungen – auch wenn diese in der Anforderungsphase noch in weiter Ferne liegen. Die Erkundungsphase ist an sich schon eine Investition in die Produktivität: Eine Stunde gezielter Informationserfassung verkürzt wochenlange Iterationen, die andernfalls erst in der DVT-Phase stattfinden würden.
Was eine gute Entdeckung bewirkt
Das Ergebnis eines gut geführten Erstgesprächs ist kein fertiger Entwurf. Es sind zwei oder drei Referenzarchitekturen, die die Anforderungen plausibel erfüllen und bereit sind, unter realen Bedingungen mit echter Hardware gegeneinander bewertet zu werden.
In dieser Phase geht es darum, sich mehrere Optionen offen zu halten. Die Erkundungsphase liefert genügend Informationen, um zu vermeiden, dass die falsche Architektur zu früh ausgeschlossen wird. Der nächste Schritt – Architekturoptionen und Prototypenbau unter realen Bedingungen – besteht darin, repräsentative Versionen jedes Kandidaten zu erstellen und diese in der tatsächlichen Betriebsumgebung zu testen, bevor eine Platine in die Fertigung geht.
Darum geht es im nächsten Beitrag.
Wenn Sie sich noch in einer frühen Phase der Konzeption eines Lokalisierungssystems befinden und die Anforderungen im Rahmen der Bedarfsanalyse durchgehen möchten, bevor Sie sich für eine Hardware entscheiden, vereinbaren Sie einen Termin für einen Discovery-Workshop mit einem Point One-Ingenieur.
Sehen Sie sich das gesamte Gespräch an – „Catalyst“, Folge 2
Häufige Fragen
Was ist der „Catalyst“-Entdeckungsprozess?
„Catalyst“ ist die Methodik von Point One für die Konzeption von Lokalisierungssystemen. Die Analysephase ist der erste Schritt: ein strukturiertes Gespräch, um Designbeschränkungen, die Betriebsumgebung und die Anwendungsanforderungen zu ermitteln, bevor überhaupt Hardware bewertet wird. Dies dauert in der Regel etwa eine Stunde und führt zu zwei oder drei Architekturvorschlägen, die für die Validierung unter realen Bedingungen bereit sind.
Was sind die drei grundlegenden Komponenten bei der Konzeption eines GNSS-Ortungssystems?
Die drei Eingangsgrößen sind Entwurfsbeschränkungen (Leistungsbudget, Kostenziel, Größe und Formfaktor sowie Rechenkapazität), die Betriebsumgebung (GNSS-Sichtbarkeit am Himmel, physische Montage und Plattformdynamik) sowie der Anwendungsfall (erforderliche Ausgabewerte, Genauigkeitsgrenzen und geschäftliche Ergebnisse im großen Maßstab).
Warum reicht die Angabe in einem Datenblatt eines Empfängers nicht als Systemanforderung aus?
Angaben in Datenblättern wie „1 cm + 1 ppm“ werden unter idealen Bedingungen gemessen – unter freiem Himmel, mit kurzer Basislinie und ohne Störungen. In der Praxis werden Produkte jedoch in Umgebungen eingesetzt, die diesen Bedingungen nicht entsprechen, und das Datenblatt gibt keinen Aufschluss darüber, wie die Leistung unter solchen Bedingungen aussieht. Die Verwendung einer Angabe aus dem Datenblatt als Anforderung bedeutet, dass man für den besten Fall plant, den man jemals erleben wird, und nicht für die Bedingungen, unter denen das Produkt tatsächlich zum Einsatz kommt.
Was versteht man unter Rechenkapazität und warum ist sie für die Auslegung von GNSS-Systemen von Bedeutung?
Die meisten modularen GNSS-Empfänger verfügen über begrenzte integrierte Rechenleistung. Bei Anwendungen, die eine komplexe Sensorfusion erfordern – also die Zusammenführung von GNSS-Daten mit IMU, Kameras, Lidar oder nicht standardmäßigen Plattformdynamiken –, wird diese Rechenleistungsgrenze zu einer erheblichen Einschränkung. Teams, die dies erst bei der Designvalidierung und nicht bereits bei der Anforderungsdefinition feststellen, stehen vor einer kostspieligen Neugestaltung der Architektur. Eine frühzeitige Erkennung hält die Kosten für die Entscheidung gering.
Was ist ein Bewegungsmodell und warum beeinflusst es die Lokalisierungsleistung?
Ein Bewegungsmodell ist die Gesamtheit der Annahmen in einer Sensor-Fusions-Software darüber, wie sich eine Plattform bewegt – ihre Dynamik, ihr Drehverhalten, ihr Schwingungsprofil und ihr Ansprechverhalten auf Beschleunigung. Ein verallgemeinertes Modell eignet sich für eine breite Palette von Plattformen. Anwendungen am Leistungsgrenzbereich mit ungewöhnlicher Dynamik oder hohen Genauigkeitsanforderungen profitieren von einem Modell, das auf ihre spezifische Plattform abgestimmt ist.
Inwiefern beeinflusst die Betriebsumgebung die Auswahl der GNSS-Hardware?
Die Umgebung bestimmt, welche Signalqualität das System erwarten kann, was wiederum die Fusionsarchitektur und damit die Hardwareauswahl beeinflusst. Im Freien ist ein einfacherer, rein auf RTK basierender Ansatz möglich. In städtischen Umgebungen, bei am Körper getragenen Anwendungen und auf Plattformen mit komplexer Dynamik sind zusätzliche Sensoren, hochwertigere IMUs und eine auf die jeweilige Plattform abgestimmte Positionierungssoftware erforderlich.
Wie lange dauert die Erkundungsphase?
Bei den meisten Projekten dauert das zentrale Erstgespräch etwa eine Stunde. Dabei zeichnen sich bereits erste Architekturoptionen ab. Bei größeren Projekten oder komplexeren Umgebungen kann es vor der Erstellung eines formellen Angebots zu internen Folgegesprächen kommen, doch der Großteil der Informationsbeschaffung lässt sich zügig erledigen, wenn die richtigen Fragen in der richtigen Reihenfolge gestellt werden.
Wie kann ich mehr über Sensorfusion bei GNSS-Ortungssystemen erfahren?
Die Sensorfusion – die Kombination von GNSS-, IMU- und anderen Sensordaten zu einer einzigen Positionsangabe – zieht sich wie ein roter Faden durch alle Phasen des Entwurfs von Lokalisierungssystemen. Die Catalyst-Reihe behandelt dieses Thema ausführlich in mehreren Beiträgen. Der Beitrag zum V-Modell erläutert, warum Fusionsentscheidungen, die früh im Entwurfsprozess getroffen werden, später zu den am schwersten zu ändernden Einschränkungen werden. Der Beitrag zu den sechs häufigsten Fehlern befasst sich mit den spezifischen fusionsbezogenen Entscheidungen – IMU-Klasse, Rechenarchitektur, Bewegungsmodell –, die am häufigsten zu Neugestaltungen in der DVT-Phase führen. Kommende Beiträge der Reihe gehen näher auf Architekturoptionen, Proof-of-Concept-Prototyping und die Frage ein, wie sich die Fusionsanforderungen ändern, wenn ein Design von 10 Einheiten auf 100.000 skaliert wird. Sie können auch die Positionierungs-Engine von Point One direkt erkunden oder ein Gespräch mit einem Außendiensttechniker vereinbaren.