Wo sollte Ihre Positionierungs-Engine laufen? Entscheiden Sie sich, bevor es teuer wird

Dies ist der vierte Beitrag einer Reihe über die Konzeption von Lokalisierungssystemen für autonome Fahrzeuge und Robotik. In früheren Beiträgen ging es um das V-Modell und die Phasen eines Entwicklungsprogramms, die sechs Fehler, die Projekte am häufigsten zum Scheitern bringen, sowie die drei Anforderungen, die geklärt sein müssen, bevor man die Hardware bewertet. Jeder Beitrag basiert auf einem echten Gespräch zwischen Tom Weeks und mir. Dieser Beitrag knüpft dort an, wo die Erkundungsphase endet.

Die Anforderungsermittlung liefert Ihnen eine Reihe von Anforderungen, die auf Ihr Produkt zugeschnitten sind, und nicht nur eine Zahl aus einem Datenblatt. Außerdem erhalten Sie zwei oder drei mögliche Architekturen, die diese Anforderungen plausibel erfüllen könnten.

An dieser Stelle hört die linke Seite des V-Modells auf, rein theoretisch zu sein. Man muss sich für eine Option entscheiden. Und die Entscheidung trifft man nicht durch weitere Analysen, sondern indem man die Optionen in der Umgebung testet, in der das Produkt tatsächlich zum Einsatz kommen wird.

Das ist der Teil meiner Arbeit, der mir am besten gefällt.

Die zentrale Entscheidung: Wo läuft die Positionierungs-Engine?

Die meisten RTK-Empfänger auf dem Markt sind modular aufgebaut. Die Positionsbestimmungs-Engine läuft auf der eigenen Rechenleistung des Moduls, die begrenzt ist. Für viele Anwendungen ist das die richtige Lösung, und das sollte man auch ganz klar sagen – wir drängen die Teams nicht in Richtung hostbasierter Architekturen. Es geht darum, sicherzustellen, dass die modulinterne Lösung tatsächlich für das funktioniert, was Sie entwickeln.

Probleme treten jedoch auf, wenn die Anwendung mehr benötigt als eine Standardlösung aus RTK und IMU. Dazu gehören nicht standardmäßige Plattformdynamiken, städtische Umgebungen mit schlechten Empfangsbedingungen, in denen ständige Mehrwegausbreitung auftritt, sowie die Fusion mit Kameras, Lidar oder Radodometrie. In diesen Fällen stößt die Rechenleistung des Moduls an ihre Grenzen, und die Lösung ist eine hostbasierte Architektur, bei der die Positionierungs-Engine auf der Hauptrechenplattform läuft.

Der Wandel, den wir derzeit beobachten, besteht darin, dass Teams schon früher fragen, ob sie die auf der Plattform bereits vorhandene Rechenleistung nutzen können. Ein Roboter, auf dem ein Lidar-Stack läuft, verfügt bereits über deutlich mehr Rechenleistung als ein GNSS-Modul. Oft lautet die Antwort „Ja“.

Ein Team, das dies beim Design-Validation-Test (DVT) feststellt, muss eine Neukonzeption vornehmen. Ein Team, das dies bereits bei der Architekturauswahl feststellt, führt ein Gespräch darüber.

Vier Fragen, die den weiteren Aufbau eingrenzen

Die Positionierung der Engine ist der entscheidende Faktor, doch vier Fragen zum Datenfluss bestimmen alles, was danach folgt. Jede Antwort schließt bestimmte Architekturen aus.

1. Nur GNSS oder mit Inertialsensoren gekoppelt? Es gibt Anwendungsfälle, in denen eine reine RTK-Engine die bessere Wahl ist – wenn Sie sich nur dann auf die Position verlassen möchten, wenn Sie eine Trägerphasen-Position haben, und die Kontinuität mit anderen Sensoren in Ihrem eigenen Stack selbst gewährleisten, ist das die klare Antwort. Wenn das System die Position auch bei GNSS-Ausfällen halten muss, benötigen Sie eine Trägheitsfusion, und das verändert die oben gestellte Frage zur Rechenleistung. Es wirft auch die Entscheidung zwischen loser und enger Kopplung auf.

2. Woher stammen die Korrekturdaten? Kann die Anwendung im Gegenzug für eine gleichmäßigere Abdeckung eine geringfügig geringere Genauigkeit in Kauf nehmen? SSR- und VRS-Lösungen bieten andere Kompromisse als RTK mit einer einzigen Basislinie, und die richtige Antwort hängt davon ab, wo das Produkt eingesetzt wird und wie weit es von der nächsten Referenzstation entfernt ist. Die Netzdichte ist die Variable, die bestimmt, in welchem Umfang Sie diesen Kompromiss tatsächlich eingehen müssen.

3. Nur Position oder vollständiges PVT mit Lage? Ein unterirdischer Versorgungsscanner , der die absolute Position ermitteln soll, benötigt lediglich die Position. Das ist alles. Ein Fahrzeug, das seine Gier-, Nick- und Rollwinkel am Rand einer Rennstrecke kennen muss – oder seinen Kurs beim Einparken, damit ein nachgeschaltetes System weiß, in welche Richtung es zeigt –, stellt eine völlig andere Anforderung dar und erfordert einen anderen Datenstrom auf der Backend-Seite. Dies wird oft übersehen, da Kurs und Fluglage in einem GNSS-Datenblatt nicht aufgeführt sind.

   Die Lage muss auch von einer physikalischen Quelle stammen. Zwei Antennen auf einer festen Basislinie liefern direkt die GNSS-Kursangabe, weshalb es Dual-Antennen-Systeme gibt – „Atlas Duo“ ist unser System. Eine einzelne Antenne in Verbindung mit einer IMU kann ebenfalls den Kurs liefern, jedoch erst, wenn sich die Plattform ausreichend bewegt, damit der Kurs beobachtbar wird. Genau diese Einschränkung stellt ein Problem für Fahrzeuge dar, die im Stillstand eine Orientierungsbestimmung benötigen. Neigung und Rollwinkel werden aus der Trägheitslösung ermittelt. Dies sollte frühzeitig geklärt werden, da es sich um eine Entscheidung bezüglich der Anzahl der Antennen und deren Montage handelt und nicht um eine Softwareeinstellung, die man später einfach umschalten kann.

4. Welche Anforderungen bestehen hinsichtlich der Konnektivität? Letztendlich sind für Korrekturen Konnektivitätsverbindungen erforderlich. Zu verstehen, wo das Produkt eingesetzt wird und wie der Netzwerkzugang dort aussieht, ist Teil der Architektur und kein Implementierungsdetail, das später gelöst werden muss.

   In der Praxis gibt es vier Möglichkeiten, und die meisten Systeme nutzen letztendlich einen Primärkanal und einen Ausweichkanal. Mobilfunk ist die Standardlösung für Bodenplattformen – Korrekturdaten werden über NTRIP übertragen, was jedoch mit Lücken in der Netzabdeckung einhergeht. WLAN funktioniert, wenn sich die Plattform innerhalb eines bekannten Bereichs befindet, wie beispielsweise in einem Lagerhaus oder an einem festen Einsatzort. Eine lokale Funkverbindung zu einer eigenen Basisstation beseitigt die Netzabhängigkeit vollständig, weshalb diese Lösung in der Landwirtschaft und Vermessung nach wie vor verbreitet ist – sie lässt sich jedoch nicht über die Gebiete hinaus skalieren, in denen Sie Basisstationen installiert haben. L-Band-Satelliten liefern Korrekturdaten dort, wo es überhaupt kein terrestrisches Netzwerk gibt, allerdings mit geringerer Genauigkeit als terrestrisches RTK.

   Der Ausweichpfad legt fest, was in jenem Bruchteil eines Prozents geschieht, der Ihr gesamtes Verfügbarkeitsbudget aufbraucht. Diese Entscheidung sollte bewusst getroffen werden.

Erstellung eines Proof-of-Concept: repräsentativ, nicht identisch

Sobald wir zwei oder drei Referenzarchitekturen haben, besteht die Aufgabe darin, diese so originalgetreu wie möglich nachzubilden und sie in der Praxis einzusetzen.

Ein konkretes Beispiel dafür, wie das aussehen könnte: Bei einem mittelgroßen mobilen Außenroboter könnten die drei Optionen folgende sein: (1) eine modulbasierte RTK- plus IMU-Lösung mit Korrekturen über mobilfunkbasiertes NTRIP und Positionsausgabe über serielle Schnittstelle – geringste Kosten, geringster Rechenaufwand; (2) dieselbe Empfängerhardware, wobei die Positionierungs-Engine auf dem Host-Rechner des Roboters läuft und Radodometrie zur Fusionsberechnung für Abschnitte mit eingeschränkter GNSS-Empfangsqualität hinzugefügt wird; und (3) ein integrierter Hardware-Beschleuniger, der vollständige PVT-Daten mit Lageangaben über Ethernet liefert – mit den wenigsten Unbekannten bei der Integration und den höchsten Kosten pro Einheit. Alle drei könnten die Genauigkeitsanforderungen auf dem Papier erfüllen. Sie unterscheiden sich jedoch erheblich darin, wie sie sich unter Baumbestand verhalten, und darin, wie die Stückliste (BOM) bei einer Stückzahl von 5.000 Einheiten aussieht.

Der Maßstab ist repräsentative Hardware, nicht identische Hardware. Im Idealfall wird für den Proof of Concept dieselbe Hardware verwendet, die der Kunde ausliefern möchte, doch das hängt vom Zeitplan des Kunden und der Verfügbarkeit ab. Ist dies nicht möglich, kommt es auf die Architektur des Signalwegs an.

Ein Beispiel: Ein Team hat sich für ein Modul entschieden, von dem erst in drei Monaten Muster verfügbar sein werden. Anstatt das Quartal zu verlieren, bauen wir mit einem Empfänger, den wir vorrätig haben, und konfigurieren ihn so, dass er denselben Nachrichtensatz über dieselbe serielle Schnittstelle mit derselben Rate sendet, wie es der Host im Produktivbetrieb tun wird. Die Integrationsarbeit ist echte Arbeit. Die Leistungsdaten sind echte Daten. Die Artikelnummer ändert sich später.

Wenn sich ein Kunde bereits für ein Modul entschieden hat, das serielle Daten an seinen Host ausgibt – das heißt, das Modul berechnet die Position intern und überträgt das Ergebnis über eine serielle Schnittstelle an den Hauptrechner, anstatt Rohdaten zur Verarbeitung an den Host zu übergeben –, baue ich ein System, das serielle Daten an einen Host ausgibt, auch wenn der zugrunde liegende Empfänger ein anderer ist. Wenn der Kunde einen High-End-Empfänger verwendet, kann ich eine baulich ähnliche Lösung mit einem anderen Evaluierungskit (EVK) entwickeln – dem vom Hersteller bereitgestellten Entwicklungsboard, mit dem ein Empfänger getestet wird, bevor man sich für ein Design entscheidet. Was wir validieren, ist die Architektur, nicht die Stückliste.

Genau dieser Unterschied macht das schnelle Prototyping erst möglich. Wenn Sie monatelang auf Ihre ersten Leiterplatten warten müssen, bevor Sie überhaupt sinnvolle Tests durchführen können, haben Sie Ihren Zeitpuffer bereits aufgebraucht, bevor Sie überhaupt etwas gelernt haben. Und wenn Sie in diesem Zeitraum nur einzelne Komponenten statt das gesamte System testen, geht genau dort etwas schief.

Fallstudie: RTK auf einer tragbaren Brille

Tragbare Brillen mit Kameras und Trägheitssensoren sind mittlerweile allgegenwärtig. Ein Kunde, der ein VIO-System entwickelt – also ein visuell-inertiales Odometriesystem, das die Position durch die Fusion von Kamerabildern mit IMU-Daten ermittelt –, wandte sich an uns, weil er das System um GNSS erweitern wollte.

Sie hatten GPS bereits verworfen. Sie hatten es getestet, es hatte nicht funktioniert, und sie hatten sich anderen Dingen zugewandt.

Als wir uns dann mit den tatsächlichen Testbedingungen befassten, stellte sich heraus, dass das Problem in der Platzierung der Antenne lag. Die Signalqualität, die man bei einem Gerät erhält, das auf der Brust getragen oder seitlich am Kopf befestigt wird, reicht einfach nicht aus. Durch die Abschirmung durch den Körper und die unterschiedlichen Ausrichtungsmöglichkeiten entsteht eine Signalumgebung, die sich grundlegend von der einer auf dem Autodach montierten Antenne unterscheidet. Das war kein GPS-Problem. Es war ein Konstruktionsproblem, für das GPS zu Unrecht verantwortlich gemacht wurde.

Also haben wir etwas entwickelt, das sich testen ließ. Sie schickten uns ein Evaluierungskit ihrer eigenen Rechenplattform – denselben Prozessor, mit dem ihr Produkt ausgeliefert werden würde, auf einem Entwicklungsboard, an das wir Anschlüsse vornehmen konnten. Wir schlossen denselben Empfänger an, mit dem sie arbeiteten, und bauten ein kleines modulares System, das von einem echten Menschen in realen Umgebungen getragen werden konnte. Es gibt Bilder von mir, auf denen ich eines trage: den Rechner an der Hüfte, die Antenne in Position und daneben eine am Kopf getragene Antenne, die als Referenzsystem diente.

Diese am Kopf getragene „Ground-Truth“-Vorrichtung ist bewusst einfach gehalten und hat sich schon seit langem bewährt. Sie steht zur Verfügung, falls jemand eine braucht.

Auf dieser Grundlage könnten wir mit ihnen reale Daten erfassen und konkrete Fragen beantworten. Inwieweit verschlechtert die jeweilige Umgebung die Signalqualität? Was kann die Ortungs-Engine mit einem verschlechterten Signal anfangen, um dennoch eine brauchbare Lösung zu liefern? Wie gut kann die IMU die Position halten, wenn das GNSS-Signal ausfällt?

Und damit eröffnete sich eine Möglichkeit, die sie bisher nicht in Betracht gezogen hatten: Sie verfügten bereits über Rechenkapazitäten, auf denen ein VIO-System lief. Die verallgemeinerte Trägheitslösung des Moduls ist zwar nicht auf die Dynamik des menschlichen Körpers abgestimmt – aber es gibt keinen Grund, warum die GNSS-Fusion nicht auf den bereits vorhandenen Rechenkapazitäten laufen könnte.

Das Produkt entwickelte sich von „GPS funktioniert bei uns nicht“ zu einer funktionsfähigen Architektur. Nicht wegen eines besseren Algorithmus. Sondern weil wir das Richtige getestet haben.

Das Prototyping ist ein Werkzeug zur Anforderungserfassung und nicht nur ein Werkzeug zur Validierung.

Das tragbare Gerät ist die Regel, nicht die Ausnahme. Bei Anwendungen, die noch relativ neu im Bereich der Präzisionsortung sind – Wearables für Ersthelfer, Sicherheitsausrüstung, am Körper getragene Sensoren –, tauchen während der Prototypenentwicklung Anforderungen auf, die im ursprünglichen Lastenheft nicht enthalten waren.

Manchmal bedeutet das, dass man wieder zur Erkundungsphase zurückkehren muss. Auf der linken Seite des V-Modells ist dieser Schritt mit geringem Aufwand verbunden. Man ändert ein Dokument und baut eine Anlage neu auf. Auf der rechten Seite bedeutet derselbe Schritt eine Neukonzeption, eine Verzögerung und im schlimmsten Fall eine Stornierung.

Die iterative Variante dieser Phase könnte etwa so lauten: Diese Hardware hat nicht funktioniert, also lassen wir etwas mit leistungsstärkerer Hardware auf die Beine stellen und schauen, ob sich die Zahlen ändern. Oder: Gehen wir noch einmal zurück und prüfen wir noch einmal, was du eigentlich erreichen willst. Beides ist im Moment kostengünstig. Keines von beiden ist jedoch noch kostengünstig, wenn du erst schon Dutzende, Hunderte oder Tausende von Platinen gebaut hast und erst dann einen Fehler entdeckst.

Wo Hardware-Beschleuniger zum Einsatz kommen

Es gibt einen Mittelweg, den man kennen sollte. Ein Teil unseres Vorgehens besteht darin, Hardware in Produktionsqualität einzusetzen, die alles Notwendige – Empfänger, IMU, RTK-Engine und Sensorfusion – in einer einzigen Einheit vereint. Wir bezeichnen diese als Hardware-Beschleuniger. Atlas INS und Atlas Duo sind die aktuelle Generation.

Bei 10 oder 50 Einheiten benötigen Sie möglicherweise gar kein modulbasiertes Design. Sie können mit einem Hardware-Beschleuniger auskommen, der für die von Ihnen validierte Architektur repräsentativ ist. Bei 1.000 Einheiten ist ein eigenes modulbasiertes Design sinnvoll. Bei 10.000 oder 20.000 Stück sollten Sie ein „Chip-Down“-Design in Betracht ziehen – dabei wird der Empfänger-Chipsatz direkt auf Ihre eigene Leiterplatte aufgebracht, anstatt ein vorgefertigtes Modul zu kaufen. Ein „Chip-Down“-Design erfordert zwar zunächst Entwicklungsaufwand, zahlt sich aber bei großen Stückzahlen in Form von Einsparungen bei der Stückliste und der Leiterplattenfläche aus.

Die „Proof-of-Concept“-Methode gilt nach wie vor bei jedem dieser Übergänge. Man baut nicht einfach einen neuen Empfänger in ein serienreifes Produkt ein und betrachtet die Sache damit als erledigt. Jede Generation durchläuft dieselben Phasen – und genau hier findet auch die interessante Arbeit zur Kostensenkung statt. Durch eine Chip-Optimierung bei der nächsten Generation lassen sich mehr Frequenzbänder, mehr Konstellationen und eine geringere Stücklistenkosten (BOM) erzielen, da man die Teile des Moduls weglässt, die man nicht verwendet hat.

Das eigentliche Ergebnis

Das Ergebnis dieser Phase ist eine Architektur, die anhand von Daten ausgewählt wurde.

Das eigentliche Ziel ist jedoch enger gefasst. Bis ein Entwurf in die Fertigung geht, sollte die Wahrscheinlichkeit einer katastrophalen Anforderungslücke – eines Fehlers im Systemdesign, der eine Rückkehr zur linken Seite des V erzwingt oder das Programm zum Scheitern bringt – so nahe wie möglich an Null liegen, soweit es der Prozess zulässt.

Das ist es, was die Tests bringen. Nicht Gewissheit – die hat niemand. Sondern die Zuversicht, dass das, wofür man sich entscheidet, sich bereits unter den Bedingungen bewährt hat, unter denen es tatsächlich zum Einsatz kommen wird.

Im nächsten Beitrag geht es darum, was passiert, wenn man in die Phase der technischen Validierungstests (EVT) übergeht – und wie die rechte Seite des V-Modells aussieht, wenn die linke Seite gut umgesetzt wurde.

Wenn Sie verschiedene Architekturvarianten prüfen und diese vor einer endgültigen Entscheidung anhand realer Daten auf Herz und Nieren testen möchten, vereinbaren Sie einen Discovery-Workshop mit einem Point One-Techniker.

Sehen Sie sich das gesamte Gespräch an – „Catalyst“, Folge 2

Häufige Fragen

Was umfasst die Architektur- und Prototyping-Phase bei der Konzeption eines Lokalisierungssystems?

Dies ist der Schritt zwischen den Anforderungen und der Entscheidung für eine bestimmte Hardware. Man beginnt mit zwei oder drei in der Erkundungsphase identifizierten Architekturkandidaten, baut für jeden davon repräsentative Prototypen, testet diese in der tatsächlichen Betriebsumgebung und nutzt die dabei gewonnenen Daten, um eine davon auszuwählen. Das Ziel besteht darin, Architekturen anhand von Belegen und nicht auf der Grundlage von Analysen auszuschließen.

Soll die Ortungs-Engine auf dem GNSS-Modul oder auf dem Host laufen?

Das hängt von den Rechenanforderungen ab. Bei den meisten modularen RTK-Empfängern läuft die Positionsberechnungs-Engine auf dem Modul, was für Anwendungen mit guter Sicht zum Himmel und Standard-RTK- sowie IMU-Anforderungen ausreichend ist. Anwendungen, die eine komplexe Sensorfusion erfordern – beispielsweise bei nicht standardmäßiger Plattformdynamik, in städtischen Umgebungen mit eingeschränkter Sicht oder bei der Fusion mit Kameras, Lidar oder Odometrie –, überschreiten oft die Rechenkapazitätsgrenze des Moduls und erfordern eine hostbasierte Architektur. Diese Entscheidung bereits in der Anforderungsphase zu treffen, ist kostengünstig; wird dies erst bei der DVT festgestellt, ist eine Neukonzeption erforderlich.

Was bedeutet „repräsentative Hardware“ in einem GNSS-Proof-of-Concept?

Hardware, die den Signalweg und den Datenfluss des beabsichtigten Designs nachbildet, auch wenn sich die genauen Komponenten unterscheiden. Handelt es sich bei dem Seriendesign um ein Modul, das serielle Daten an einen Host ausgibt, sollte der Prototyp ebenfalls ein Modul sein, das serielle Daten an einen Host ausgibt – der konkrete Empfänger kann dabei unterschiedlich sein. Validiert wird die Architektur, nicht die Stückliste.

Wie lassen sich Kurs und Fluglage aus einem GNSS-System ermitteln?

Es gibt zwei Möglichkeiten. Eine Konfiguration mit zwei Antennen auf einer festen Basislinie liefert direkt die GNSS-Kursrichtung und funktioniert auch im Stillstand. Eine einzelne Antenne in Verbindung mit einer IMU kann ebenfalls die Kursrichtung ermitteln, allerdings erst, sobald sich die Plattform ausreichend bewegt, damit die Kursrichtung beobachtbar wird. Nick- und Rollwinkel werden aus der Trägheitslösung abgeleitet. Da dies die Anzahl der Antennen und deren Anbringung bestimmt, muss dies bereits bei der Auswahl der Architektur festgelegt werden und darf nicht als reine Softwarekonfiguration behandelt werden.

Welche Verbindungsmöglichkeiten stehen für die Übertragung von RTK-Korrekturen zur Verfügung?

Mobilfunk über NTRIP ist die Standardeinstellung für die meisten Bodenplattformen, wobei Lücken in der Netzabdeckung als Kompromiss in Kauf genommen werden müssen. WLAN eignet sich für Plattformen, die auf einen bekannten Einsatzbereich beschränkt sind. Eine lokale Funkverbindung zu Ihrer eigenen Basisstation beseitigt die Netzabhängigkeit, lässt sich jedoch nicht über die Gebiete hinaus skalieren, in denen Sie Basisstationen installiert haben. L-Band-Satelliten liefern Korrekturdaten dort, wo kein terrestrisches Netzwerk vorhanden ist, allerdings mit geringerer Genauigkeit als terrestrisches RTK. Die meisten Produktionssysteme nutzen einen primären Pfad sowie einen Ausweichpfad, wobei der Ausweichpfad das Verhalten während des Ausfallzeitfensters bestimmt, das eine Hochverfügbarkeitsanforderung unterbricht.

Warum ist die Platzierung der Antenne bei tragbaren Geräten so wichtig?

Eine auf dem Dach eines Fahrzeugs montierte Antenne profitiert von freier Sicht zum Himmel und einer Bodenfläche als Reflexionsfläche. Eine am Körper oder seitlich angebrachte Antenne wird hingegen durch den Körper abgeschirmt und unterliegt ständigen Ausrichtungsänderungen, was zu einer grundlegend anderen Signalumgebung führt. Oft kommen Teams zu dem Schluss, dass GNSS für ihr Wearable nicht funktioniert, obwohl das eigentliche Problem in der Platzierung liegt. Tests mit einem repräsentativen Testaufbau ermöglichen es, diese beiden Faktoren voneinander zu trennen.

Wie misst man die Referenzdaten für ein am Körper getragenes Ortungssystem?

Mit einem zweiten, qualitativ hochwertigeren Referenzsystem, das auf derselben Plattform getragen wird. Bei Wearables verwenden wir eine am Kopf getragene Antennenvorrichtung als „Ground Truth“ – bewusst einfach und effektiv. Ohne eine „Ground Truth“-Referenz kann man zwar Daten erfassen, aber keine Fehler messen, was die Tests deutlich weniger aussagekräftig macht.

Was ist SSR und wann sollte man es anstelle von RTK mit einer einzigen Basislinie verwenden?

SSR (State Space Representation) berücksichtigt Fehlerquellen über eine gesamte Region hinweg, anstatt nur Beobachtungen von einer einzigen Referenzstation zu übertragen. SSR- und VRS-Lösungen bieten in der Regel eine konsistentere Abdeckung über größere Gebiete hinweg, allerdings auf Kosten einer etwas geringeren Spitzengenauigkeit im Vergleich zu einer RTK-Lösung mit kurzer Basislinie und einer einzigen Station. Die richtige Wahl hängt davon ab, wo das Produkt eingesetzt wird, sowie von der Dichte der Referenzstationen. Die Netzwerkdichte bestimmt, wie ausgeprägt dieser Kompromiss ist.

Was versteht man unter einem Hardware-Beschleuniger bei der Entwicklung von Lokalisierungssystemen?

Ein Gerät in Serienqualität, das Empfänger, IMU, RTK-Engine und Sensorfusion in einem einzigen integrierten System vereint. Es ermöglicht es einem Team, kleine Stückzahlen zu liefern, ohne ein eigenes modulbasiertes Design entwickeln zu müssen, und dient als repräsentative Hardware bei der Architekturvalidierung. Atlas INS und Atlas Duo sind die Hardware-Beschleuniger von Point One.

Was ist ein „Chip-Down“-Design?

Die Integration eines GNSS-Empfänger-Chipsatzes direkt auf Ihrer eigenen Leiterplatte anstelle der Verwendung eines vorgefertigten Moduls. Dies erfordert zwar zunächst einen höheren Entwicklungsaufwand und Kenntnisse im Bereich der HF-Entwicklung, zahlt sich jedoch bei hohen Stückzahlen in Form von Einsparungen bei den Materialkosten und der Leiterplattenfläche aus. Zudem können dadurch zusätzliche Funktionen hinzugewonnen werden, da Sie nicht mehr an die vom Modulhersteller gewählte Band- und Konstellationskonfiguration gebunden sind.

Wie verändert sich eine Lokalisierungsarchitektur, wenn das Volumen von 100 auf 100.000 Einheiten steigt?

Eine Architektur, die bei 100 Einheiten noch richtig ist, ist bei 100.000 Einheiten oft nicht mehr geeignet. Bei geringen Stückzahlen ist ein integrierter Hardware-Beschleuniger in der Regel der schnellste Weg. Mit steigendem Volumen wird ein eigenes modulbasiertes Design wirtschaftlich, und bei hohen Stückzahlen ist ein Chip-Down-Design die richtige Wahl. Jeder Übergang sollte denselben Proof-of-Concept-Prozess durchlaufen – und jeder ist eine Chance, da Chip-Down-Designs weitere Frequenzbänder und Konstellationen hinzufügen können, während gleichzeitig Kosten gesenkt werden, indem nicht genutzte Modulkomponenten wegfallen.

Wie kann ich mehr über den Catalyst-Prozess erfahren?

„Catalyst“ ist die Methodik von Point One für die Konzeption von Lokalisierungssystemen. Der Beitrag zum V-Modell behandelt die einzelnen Phasen und erklärt, warum Entscheidungen auf der linken Seite die Kosten auf der rechten Seite maßgeblich beeinflussen. Der Beitrag zu den sechs häufigsten Fehlern befasst sich mit den konkreten Entscheidungen, die am häufigsten zu Neugestaltungen führen. Der Beitrag zur Erkundungsphase behandelt die drei Anforderungsinputs, die der Auswahl der Architektur vorausgehen. In den kommenden Beiträgen werden EVT, die rechte Seite des V-Modells und die Entwicklung von Positionierungsanforderungen im großen Maßstab näher beleuchtet. Sie können die Positionierungs-Engine auch direkt erkunden oder einen Termin mit einem Außendiensttechniker vereinbaren.