LiDARFlow: Echtzeit-Panel-Guidance für MAVs in unbekannten Umgebungen
Das Preprint LiDARFlow stellt ein vollständig onboard integriertes Führungssystem für Mikro-Luftfahrzeuge vor, das mit einem Livox MID-360 LiDAR Hindernisse erkennt und über die Panel-Methode PGFlow kollisionsfreie Geschwindigkeitskommandos erzeugt. In zwei realen Indoor-Flugszenarien, Wegpunktnavigation und Richtungsvorgabe, erreichte das Fahrzeug bei maximal 0,5 m/s alle Ziele und wich allen Hindernissen aus. Die Implementierung auf einem Raspberry Pi 5 zeigt die Machbarkeit einer leichtgewichtigen Echtzeitführung, auch wenn die Punktwolkenverarbeitung als Hauptlimitierung identifiziert wird.
Kann ein MAV in unbekannten, unstrukturierten Umgebungen allein mit onboard LiDAR und einem leichtgewichtigen, reaktiven Panel-Verfahren in Echtzeit kollisionsfrei zu Wegpunkten oder entlang einer vorgegebenen Richtung fliegen?
MAVs müssen in Such- und Rettungseinsätzen ohne vorherige Karte fliegen; bisherige optimierungsbasierte Verfahren benötigen oft Karten und sind rechenintensiv, während reaktive Verfahren zu lokalen Minima oder Oszillation neigen. Zudem fehlt eine experimentelle Validierung eines vollständig onboard integrierten LiDAR-basierten Panel-Guidance-Systems für reale Flüge.
Optimierungsbasierte Verfahren wie FASTER, MADER, HDSM, DYNUS oder SANDO garantieren kollisionsfreie Trajektorien, sind aber rechenintensiv und kartenabhängig. Soft-Constraint-Verfahren wie EGO-Planner, EGO-Swarm oder SUPER sind schneller, verzichten aber auf formale Sicherheitsgarantien. Reaktive Methoden wie CBF-Sicherheitsfilter, Velocity-Obstacle-Ansätze und klassische Potenzialfelder arbeiten kartenfrei und mit geringer Latenz, leiden jedoch unter lokalen Minima und Oszillationen. Die Panel-Methode PGFlow selbst setzt bislang vollständige Hinderniskenntnis voraus oder wurde nur in Simulation beziehungsweise am Bodenroboter validiert.
Der Ansatz koppelt ein konvergentes Führungsvektorfeld für die Nominalbewegung mit dem harmonischen Potenzialfeld PGFlow zur Hindernisvermeidung. Hindernisse werden aus Livox MID-360 Punktwolken per Voxel-Downsampling, ROI-Filterung, Clustering, RANSAC-Liniensegmentierung und temporärer Segmentkarte extrahiert; die Panels werden inflatiert, um die Fahrzeuggröße zu berücksichtigen. Die gesamte Pipeline läuft onboard auf einem Raspberry Pi 5 und sendet Geschwindigkeitskommandos an einen Paparazzi-Autopiloten. Eine vorherige Karte ist nicht erforderlich.
Im Wegpunktszenario flog das Fahrzeug von A=(-2,-4) m zu B=(2,4) m und zurück bei vd=0,5 m/s, kc=1 und Maximalgeschwindigkeit 0,5 m/s; zwei Hindernisse bei (-1,5,-1,75) m und (-0,5,2) m wurden umflogen. Im Richtungsszenario folgte es zunächst Richtung (0,1), später (1,0) bei gleichen Parametern und wich drei Hindernissen bei (-2,1) m, (1,5,0,5) m und (-1,-2) m aus. In beiden Fällen wurden alle Wegpunkte erreicht beziehungsweise Richtungen eingehalten und alle Hindernisse vermieden. Die PGFlow-Berechnung lief mit 100 Hz; die maximal erlaubte Panelanzahl beträgt laut Tabelle bei 1 Hz 2025, bei 5 Hz 1100, bei 10 Hz 725 und bei 20 Hz 506. Die Arena war 10 × 10 m groß, die Zustandsschätzung erfolgte über ein externes OptiTrack-System mit 16 Kameras. Die Trajektorien wiesen sichtbare Oszillationen auf, die auf instabile Hindernisschätzung zurückgeführt werden. Quantitative Vergleiche mit anderen Verfahren oder Baselines sind im Paper nicht berichtet.
Die Autoren nennen als Grenzen: nur konvexe, statische Hindernisse; keine schnellen bewegten Hindernisse; externe OptiTrack-Zustandsschätzung statt onboard Schätzung; Führung nur in der horizontalen Ebene; Validierung mit nur einem einzigen MAV. Die Punktwolkenverarbeitung ist instabil und wird über TCP vom C++-Treiber an das Python-Modul übertragen, was Overhead erzeugt. Die Matrixinversion in PGFlow hat O(n^3) Komplexität. Es wurde keine formale Nutzerstudie durchgeführt, und die Verfügbarkeit von Code wird im Paper nicht berichtet.
Such- und Rettungsdienste, Inspektionsdrohnen und Anbieter von Paparazzi-basierten Autopiloten könnten die Methode nutzen, sobald eine robuste onboard Zustandsschätzung, eine effizientere C++-Integration der Punktwolkenverarbeitung und eine Validierung bei höheren Geschwindigkeiten vorliegen. Kurzfristig, innerhalb von 1 bis 3 Jahren, ist ein Einsatz als Assistenzsystem für langsame Indoor-Inspektionsflüge denkbar; für dynamische Hindernisse und Multi-Vehicle-Betrieb sind mehr als 3 Jahre erforderlich.
Der Volltext wird hier nicht wiedergegeben, weil die Lizenz der Studie das nicht erlaubt. Das Original steht auf arXiv.