MEKAWIRE
ExpertenarXiv

Echtzeit-Stereo-VO für Eventkameras durch Keytime-GP-Regression

Nikan Nobari, Jonathan D. Gammell
In 30 Sekunden

Das Paper stellt als Preprint eine kontinuierliche Stereo-Visual-Odometry-Pipeline für Eventkameras vor, die mit Keytime-Interpolation und einem WNOA-GP-Prior die asynchronen Messzeitpunkte erhält und dennoch Echtzeit erreicht. Auf MVSEC und DSEC liefert sie Schätzungen mit 22 Hz beziehungsweise 6 Hz und reduziert die relativen RMS-Fehler gegenüber ES-PTAM um Faktor 11 bei Translation und Faktor 15 bei Rotation. Damit zeigt der Ansatz, dass die volle zeitliche Auflösung von Eventkameras nicht mit hohem Rechenaufwand verbunden sein muss.

Forschungsfrage

Kann eine kontinuierliche visuelle Odometrie für Stereo-Eventkameras die nativen asynchronen Messzeitpunkte beibehalten und gleichzeitig in Echtzeit laufen, wenn der Schätzzustand auf wenige Keytimes reduziert wird?

Problem

Eventkameras liefern asynchrone Ereignisse mit Mikrosekunden-Auflösung, aber diskrete VO-Pipelines gruppieren diese zu Frames und verlieren dadurch Zeitinformation; kontinuierliche GP-Ansätze wie GPCT setzen dagegen einen Zustand pro Messzeit und werden bei dichter Ereignisfolge zu groß für Echtzeit.

Bisheriger Ansatz

Bisherige diskrete Systeme, darunter ES-PTAM, akkumulieren Events oder nutzen bewegungskompensierte Frames und verarbeiten im Backend feste Zeitintervalle. Kontinuierliche GPCT verwendet zwar WNOA und MC-RANSAC, platziert aber für jeden Messzeitpunkt einen eigenen Zustand, was die Optimierung stark vergrößert. Andere kontinuierliche Ansätze mit B-Splines benötigen oft Karten, externe Kameras oder erreichen keine Echtzeit.

Neuer Ansatz

Die vorgestellte Pipeline verwendet einen GP mit WNOA-Prior auf SE(3) und definiert den Zustand nur an ausgewählten Keytimes, die jeweils am Ende eines Event-Clusters liegen. Jeder Landmarken-Reprojektionsfehler wird exakt zu seinem eigenen Messzeitpunkt ausgewertet, indem zwischen den beiden benachbarten Keytimes interpoliert wird. MC-RANSAC trennt Ausreißer vor der Schätzung; eine Producer-Consumer-Architektur lässt das Backend Cluster überspringen, vergleichbar mit Keyframing. Implementiert ist das System in C++ mit GTSAM und iSAM2; Event-Cluster umfassen 10.500 Ereignisse auf MVSEC und 150.000 auf DSEC, Feature-Matching nutzt LIBVISO2 über die letzten fünf Cluster.

Ergebnisse

Im Vergleich zu GPCT auf MVSEC indoor_1 und indoor_3 bleiben die Fehler ähnlich: In indoor_1 erreicht Keytime final 4,8 % gegenüber 6,6 % bei GPCT, in indoor_3 final 6,9 % gegenüber 5,5 %, mit relativen RMS-Werten von 4,1×10^{-3} bzw. 3,7×10^{-3} gegenüber 4,7×10^{-3} bzw. 3,8×10^{-3}. Gegenüber ES-PTAM liefert die Pipeline in allen getesteten Sequenzen außer dsec_city_4b bessere globale Fehler; auf MVSEC liegen die Frequenzen bei 22 Hz, auf DSEC bei 6 Hz. Über alle validen Sequenzen betragen die relativen RMS-Fehler 46×10^{-2} cm in der Translation und 3,8×10^{-2} Grad in der Rotation, was 11-mal bzw. 15-mal besser ist als ES-PTAM. In mvsec_indoor_1 sinkt der finale globale Translationsfehler von 40,2 cm auf 34,2 cm und der Rotationsfehler von 29,3 Grad auf 8,4 Grad; in dsec_city_4c sinkt der maximale globale Translationsfehler von 7727,8 cm auf 2608,0 cm.

Grenzen

Das Paper ist ein Preprint ohne Angabe einer Begutachtung. Die Evaluation beschränkt sich auf die Datensätze MVSEC und DSEC, ohne reale Roboter-Experimente; auf der DSEC-Sequenz dsec_city_4b ist ES-PTAM beim globalen Translationsfehler genauer. Die Pipeline ist auf Stereo-Eventkameras und die verwendeten LIBVISO2-Features zugeschnitten, ihr Verhalten mit anderen Eventrepräsentationen und Feature-Extraktoren wird als zukünftige Arbeit genannt. Angaben zu veröffentlichtem Code oder zur Übertragbarkeit auf eingebettete Hardware fehlen im Paper.

Bedeutung für die Branche

Unternehmen aus Robotik, autonomer Navigation und Drohnen könnten die Methode für robuste Echtzeit-Odometrie unter Bewegungsunschärfe und schwierigen Lichtverhältnissen nutzen. Eine Produktintegration ist im Zeitraum von ein bis drei Jahren denkbar, sofern die Pipeline auf Zielhardware portiert, mit robusteren Feature-Extraktoren kombiniert und in industriellen Tests validiert wird; zuerst müssen Rechenlast und Speicherbedarf auf eingebetteten Systemen bestätigt werden.

Der Volltext wird hier nicht wiedergegeben, weil die Lizenz der Studie das nicht erlaubt. Das Original steht auf arXiv.