Diese Maßnahme wird mitfinanziert mit Steuermitteln auf Grundlage des vom Sächsischen Landtag beschlossenen Haushaltes.
3D-Karten Meißen
Eine mögliche Pipeline zur Erstellung einer Referenzkarte für die autonome Fahrzeuglokalisierung
Öffentliche Informationsfassung. Erläuternde Grafiken wurden mit KI-Unterstützung erstellt und sind entsprechend gekennzeichnet.
Von lokalen LiDAR-Messdaten zur georeferenzierten Referenzkarte für die autonome Fahrzeuglokalisierung – am Beispiel von Meißen.
Quelle: GeoSN – Digitale 3D-Stadtmodelle
Quelle: Mechlab
Eine beispielhafte Route in Meißen, auf der später ein autonomes Fahrzeug selbstständig navigieren soll.
Warum ein einzelner LiDAR?
Der Ouster OS1-64 rev7 erfasst die Zielumgebung schnell als 3D-Punktwolken.
Das Ouster-SDK bietet einen unkompliziert nutzbaren SLAM-Algorithmus zum Aufbau einer zusammenhängenden Karte.
Was liefert dieser Messaufbau?
LiDAR-Messdaten im lokalen Koordinatensystem.
Keine synchronisierten Kamerabilder und keine direkt zugeordneten Geokoordinaten.
Scanner und verwendeter Messmodus
Ouster OS1-64 Rev7
| Eigenschaft | Herstellerangabe laut Datenblatt |
|---|---|
| Wellenlänge | 865nm |
| Reichweite bei 80% lambertsche Reflexion | 170 m bei >90 % Detektionswahrscheinlichkeit und 100 klx Sonnenlicht; Modus 1024 × 10 Hz |
| Reichweite bei 10% lambertsche Reflexion | 90 m unter denselben Bedingungen |
| Mindestreichweite | 0,0 m; (optional 0,3 m, Standardeinstellung 0,5 m) |
| Vertikale Auflösung | 64 Kanäle |
| Horizontale Auflösung | 512, 1024 oder 2048 Spalten, konfigurierbar |
| Rotationsrate | 10 oder 20 Hz, konfigurierbar |
| Punkte/s | ~2.6 Mio |
| Sichtfeld | Horizontal 360°; vertikal 42,4° ± 1,0° (nominal −21,2° bis +21,2°) |
| Winkelabtastgenauigkeit | Vertikal ±0,01°; horizontal ±0,01° |
| Entfernungsauflösung | 0,1 cm; im Low-Data-Rate-Profil 0,8 cm |
| Rückläufe pro Messung | Bis zu 2 |
| Reihenfolge der Rückläufe | Stärkster bis schwächster; fernster bis nächster; nächster bis fernster |
Quelle: Ouster OS1 Rev7 – Datenblatt, Stand 02/2025, „Optical Performance“.
Verwendeter Messmodus: mechanisch rotierender OS1-64 Rev7 mit 64 Kanälen, 2048 Spalten, 10 Hz und Single Return (2048x10). Das entspricht 131.072 Messplätzen pro Scan beziehungsweise ca. 1,31 Mio./s. Der horizontale Winkelabstand beträgt ca. 0,176°. Die Reichweitenangaben der Tabelle gelten für den spezifizierten 10-Hz-Testmodus.
Winkelabtastgenauigkeit und Entfernungsauflösung beschreiben nicht den Strahlabstand oder die absolute Messgenauigkeit. Die konkreten Strahlabstände ergeben sich aus der Sensorkalibrierung und dem Betriebsmodus.
Ergänzende Orientierung: Eine separat mit dem iPhone 17 Pro aufgezeichnete GPX-Spur dient als grobe räumliche Referenz.
Einordnung: Eine gezielte Optimierung des SDK-SLAM auf Ouster-Sensoren wird vermutet; sie ist hier nicht nachgewiesen.
Einblick in den PCAP-Datensatz · Fahrt B
Das Ouster-SDK schätzt die Sensorbewegung und fügt die LiDAR-Scans zu einer lokalen Punktwolkenkarte zusammen.
Wichtige SLAM- und Exportparameter
Basis: export_slam_map_meissen.yaml und der abschnittsweise Exportaufruf. Die Filter des Exportskripts sind von den Parametern der SLAM-Engine zu unterscheiden.
| Parameter | Wert | Funktion | Wirkung / Abwägung |
|---|---|---|---|
--split-chunks + --chunk-duration |
aktiviert + 1m |
Berechnet aufeinanderfolgende 1-Minuten-Abschnitte jeweils mit neuer SLAM-Engine. | Begrenzt den über eine ganze Fahrt auflaufenden Drift; die Abschnitte müssen anschließend räumlich zusammengeführt werden. |
voxel_size |
1.0 m |
Voxelgröße der internen SLAM-Karte. | Steuert Detailgrad und Rechenaufwand des Trackings; legt nicht die endgültige Exportpunktdichte fest. |
deskew_method |
imu_deskew |
IMU-basierte Bewegungskompensation innerhalb eines Scans. | Reduziert Bewegungsverzerrungen, beispielsweise an Fassaden während der Fahrt. |
deadzone_radius |
2.3 m |
Exportfilter für Punkte im Nahbereich um den Sensor. | Entfernt etwa Fahrzeug- oder Dachpunkte; nahe Umgebungsstrukturen gehen ebenfalls verloren. |
min_z |
−1.5 m |
Untere Höhenschwelle im lokalen SLAM-Kartenkoordinatensystem. | Schneidet tiefere Punkte aus dem Export; ist keine Bodenklassifikation und keine globale Höhenangabe. |
static_voxel_size |
0.4 m |
Rastergröße der Persistenzfilter beim Export. | Größere Zellen sammeln leichter genug Beobachtungen, können aber benachbarte Strukturen vermischen. |
min_observations |
40 |
Mindestens 40 Kartenpunkte je Persistenzvoxel. | Entfernt schwach belegte Bereiche; kann auch dünne feste Strukturen ausdünnen. Gemeint sind Punkte, nicht Scans. |
min_scan_observations |
3 |
Ein Persistenzvoxel muss in mindestens drei unterschiedlichen Scans vorkommen. | Unterdrückt einmalige Beobachtungen; eine vollständige Entfernung bewegter Objekte ist damit nicht garantiert. |
Ergebnis: erste zwei Teilabschnitte (0–2 Minuten)
Punktwolke manuell bereinigt um:
- Ausreißer
- stehende und fahrende Fahrzeuge
- Passanten
Quellen: lokale Exportkonfiguration und export_slam_map.py; Ouster-SDK – Mapping-API.
Als globale Referenz verwenden wir die georeferenzierten ALS-Punktwolken des GeoSN aus dem sächsischen Geodatenportal. ALS steht für Airborne Laser Scanning: Die Umgebung wurde aus der Luft mit einem Laserscanner erfasst.
Die lokal berechneten Ouster-SLAM-Abschnitte werden in CloudCompare an gemeinsamen Gelände- und Gebäudestrukturen der ALS-Referenz ausgerichtet. Dadurch erhalten die Sensorpunktwolken einen globalen Lage- und Höhenbezug.
Ausgangspunkt: georeferenzierte ALS-Referenz
Ergebnis: registrierte Ouster-Punktwolke
Wie genau ist die ALS-Referenz?
| Eigenschaft | Angabe / Einordnung |
|---|---|
| Lagegenauigkeit der ALS-Punkte | Laut GeoSN bis zu ±0,30 m |
| Höhengenauigkeit der ALS-Punkte | Laut GeoSN bis zu ±0,15 m |
| Statistische Einordnung | Beide Genauigkeitsangaben bei 95 % Sicherheitswahrscheinlichkeit (2 σ) |
| Lagebezug | ETRS89 / UTM Zone 33N · EPSG:25833 |
| Höhenbezug | DHHN2016 · Normalhöhen · EPSG:7837 |
| Aktualität der lokalen ALS-Kacheln | 27.11.2024 laut mitgelieferten Aktualitätsdateien |
Damit liegt die amtliche Referenz im Dezimeterbereich. Die Genauigkeit der registrierten Ouster-Karte muss zusätzlich geprüft werden: Registrierungsfehler und verbleibender SLAM-Drift kommen hinzu.
Quellen: GeoSN – Fachliche Details zu Laserscandaten, Offene Geodaten Sachsen – Downloadbereich und lokale Kachelmetadaten unter ALS_maps.
Quelle
ETRS89 / UTM 33N · EPSG:25833
DHHN2016-Höhen · EPSG:7837
Ziel
MGRS 33UUS · lokale XY-Werte
Absolute ellipsoidische Höhen (WGS84)
Normalhöhe und ellipsoidische Höhe
Die Normalhöhe H bezieht sich auf DHHN2016. Die ellipsoidische Höhe h verwendet das Referenzellipsoid. GCG2016 liefert die ortsabhängige Höhenanomalie ζ für die Umrechnung: h = H + ζ.
Was bringt die Umrechnung?
- X und Y werden kleiner: Ein fester Kartenursprung wird abgezogen. Das verringert Rundungsfehler bei der Verarbeitung mit Float32.
- Der globale Bezug bleibt erhalten: Über den bekannten Ursprung können die ursprünglichen UTM-Koordinaten zurückgerechnet werden.
- Z bekommt den passenden Höhenbezug: DHHN2016-Normalhöhen werden mithilfe von GCG2016 in ellipsoidische Höhen umgerechnet, damit Karte und GNSS vergleichbar sind.
Datensatzbezogen; kein pauschaler Korrekturoffset.
Horizontaler Ursprung: E 300000 m / N 5600000 m. Von Z wird kein lokaler Ursprung abgezogen.
Die aufgezeichneten LiDAR-Scans werden gegen die Referenzkarte lokalisiert.
Wie funktioniert NDT?
NDT = Normal Distributions Transform. Das Verfahren sucht die Position und Orientierung, bei der ein LiDAR-Scan zur Referenzkarte passt:
- Die Karte wird in räumliche Zellen (Voxel) unterteilt.
- In ausreichend besetzten Zellen beschreiben Mittelwert und Kovarianz die lokale Punktverteilung.
- Der gesamte Scan wird gemeinsam verschoben und gedreht, bis seine Punkte möglichst gut zu diesen Verteilungen passen.
Unterschied zu ICP und Vorteile
| Klassischer Punkt-zu-Punkt-ICP | Hier verwendetes NDT | |
|---|---|---|
| Kartenrepräsentation | Einzelne Punkte | Lokale Gauß-Verteilungen in Voxeln |
| Optimierung | Abstände zu zugeordneten Nachbarpunkten verkleinern | Scanpunkte anhand der lokalen Verteilungen bewerten und Pose verbessern |
| Maßgeblicher Parameter | Auswahl und Filterung der Punktpaare | Unter anderem Größe der NDT-Voxel |
Vorteile von NDT: vorberechenbare Kartenstatistik, Berücksichtigung lokaler Streuung und Flächenorientierung sowie analytische Ableitungen für die numerische Optimierung. NDT_OMP parallelisiert die Berechnung auf der CPU.
Für beide wichtig: Eine passende Startpose, genügend gemeinsame Struktur und geeignete Parameter. NDT ist nicht grundsätzlich schneller oder genauer als jedes ICP-Verfahren; beispielsweise verwendet Punkt-zu-Ebene-ICP ein anderes Fehlermaß als der hier gezeigte Punkt-zu-Punkt-ICP.
Grundlagen: PCL – NDT, PCL – ICP. Die Grafiken verwenden synthetische Daten und veranschaulichen das Prinzip; sie zeigen keinen gemessenen Vergleich.
Anwendung: Lokalisierung in Meißen
- Verfahren: 3D-NDT in der Variante NDT_OMP, CPU / OpenMP; im aktuellen Parametersatz mit vier Threads und 2 m NDT-Voxelgröße.
- Beobachtung: Laufende Positionsschätzung über einen längeren Fahrtabschnitt.
- Nächste Auswertung: Positionsabweichungen, Ausfälle und Rechenzeiten quantifizieren.
Softwarequellen: ROS2-Lokalisierungsknoten · verwendete ROS2-NDT-Portierung · ursprüngliche Implementierung von Koide.
NDT → WGS84 → GPX
Eine exportierte NDT-Trajektorie vom 10.11.2026 liegt vor.
Vergleichsbasis
Die iPhone-Spur enthält beide Messfahrten vom 28.08.2026 und liegt gepunktet über der durchgezogenen NDT-Spur.
Für die Auswertung erforderlich
Passende Zeitbasis, Sensorposition und Höhenbezug.
Interaktiver Vergleich der Ergebnisse
Kartenvergleich in einem eigenen Fenster öffnen
Die Spuren werden räumlich überlagert. Eine zeitliche Synchronisation oder quantitative Genauigkeitsbewertung erfolgt hier nicht.