Unbemanntes Fahrzeug: Animationsalgorithmen. Yandex-Bericht

Eine detaillierte Abschrift eines weiteren Berichts des Yandex.Zhelezo-Treffens - über die Entwicklung von Geräten für UAVs.



- Hallo allerseits, mein Name ist Vitaly Podkolzin, ich bin der Leiter der Entwicklung eingebetteter Systeme für das unbemannte Fahrzeugprojekt. Und heute möchte ich mit Ihnen darüber sprechen, was ein unbemanntes Auto ist, welche Komponenten in seiner Zusammensetzung enthalten sind, wie das Auto bewegt wird und wie der Autopilot und seine Komponenten von den verwendeten Geräten abhängen.

Um zu verstehen, wohin es als nächstes gehen soll, muss eine Person zuerst herausfinden, wo sie sich befindet. Auch ein unbemanntes Auto. Dafür ist das Lokalisierungssubsystem für uns verantwortlich. Dann müssen Sie verstehen, was um uns herum passiert. Das Wahrnehmungs- oder Wahrnehmungssystem ist verantwortlich für unsere Vision, die Wahrnehmung der Welt. Basierend auf Standortdaten über Objekte um uns herum können wir Vorhersagen über die Straßensituation, ihre Entwicklung und das Verhalten der Verkehrsteilnehmer treffen. Und wählen Sie die optimale Bewegungsroute und Flugbahn, um daraus eine Kontrollaktion zu machen.

Alle oben genannten sind jedoch im allgemeinen Fall Algorithmen. Und Sie könnten diese Algorithmen auf Ihrem Computer ausführen, wenn sie leistungsfähig genug wären. Natürlich würde dies kein unbemanntes Auto aus einem Computer machen. Zwei wichtige Dinge fehlen.



Der erste ist ein ziemlich umfangreicher Satz von Sensoren, von denen die wichtigsten auf der Folie aufgeführt sind. Und natürlich brauchen wir eine Plattform, die unsere Befehle ausführt. Sie müssen mit ihr interagieren.

Lassen Sie uns auf die Frage der Interaktion mit dem Auto eingehen. Der Autopilot muss wie eine Person einfache Dinge tun, um ein Auto zu fahren: das Rad drehen, beschleunigen, verlangsamen. Eine logische Lösung könnte darin bestehen, Aktuatoren zur Steuerung dieser Körper zu verwenden.


Link von der Folie

Dieser Ansatz weist jedoch eine Reihe erheblicher Schwierigkeiten auf. Die Entwicklung eines unbemannten Fahrzeugs setzt in bestimmten Phasen immer noch die Anwesenheit eines Fahrers voraus. Sie müssen das Auto zu einem Service bringen oder den Autopiloten überwachen, wenn wir verschiedene Funktionen testen, insbesondere in den frühen Phasen. Diese Geräte verkürzen die Lebensdauer des Fahrers erheblich.

Natürlich ist das gesamte System komplex, und im Allgemeinen können solche Mechaniken unangenehme Verzögerungen bei den Steuerungen verursachen. Dies wirkt sich negativ auf den Fahrzeugsteuerkreis aus.

Ja, wir brauchten zu Beginn des Projekts noch eine einfache Plattform, aber wir brauchten einen anderen Ansatz, um mit dieser Plattform zu interagieren. Und wir fingen an, tief ins Auto zu graben.



Nachdem wir die Eigenschaften verschiedener Plattformen untersucht hatten, stellten wir fest, dass viele moderne Autos die Möglichkeit haben, ihre eigenen Organe des Autos zu steuern. Zum Beispiel steuert ein Assistent das Lenkrad während des Parkens. Die Geschwindigkeitsregelung beeinflusst die Beschleunigung des Fahrzeugs, die adaptive Geschwindigkeitsregelung oder ein Geschwindigkeitsbegrenzungssystem können das Bremssystem beeinflussen.

Alle diese Systeme sind in der Regel in Autos geschlossen. Um mit ihnen zu interagieren, mussten eine Reihe spezialisierter Geräte entwickelt werden. Zusätzlich zur Interaktion mit dem Auto musste das System eine bequeme, benutzerfreundliche Oberfläche für das Fahren des Autos bereitstellen. Und natürlich sollte das System einfach, unkompliziert und sehr flexibel sein.



Wir kamen zu einer Plattform, auf der je nach Fahrzeug kleine Steuerplatinen entwickelt werden, die mit einem bestimmten Knoten interagieren. Die Zusammensetzung und Funktionalität dieser Boards unterscheiden sich von Plattform zu Plattform, aber sie kommen alle in einem Netzwerk zusammen, in dem sich eine Headunit befindet, die wir üblicherweise als Gateway bezeichnen. Es überwacht diese Geräte. Darüber hinaus bietet das Gateway eine Schnittstelle für den Autopiloten auf praktischen Geräten. Hier sehen wir Ethernet, das für unsere Infrastruktur praktisch ist, und CAN, die beliebteste Automobilschnittstelle. Darüber hinaus interagiert unsere Headunit ständig mit dem Auto und überwacht den Status von Komponenten und Baugruppen. Wenn Abweichungen festgestellt werden, wird je nach Art zusammen mit dem Autopiloten eine Entscheidung über weitere Schritte getroffen.

Wir haben uns entschlossen, das Board auf ziemlich beliebten und bewährten Mikrocontrollern zu implementieren. Wir haben sie mit einem gewissen Leistungsspielraum ausgewählt und diejenigen ausgewählt, die die für die Arbeit erforderlichen Schnittstellen unterstützen: CAN, Ethernet und analoge digitale Ein- / Ausgänge.

Wir haben eine Lösung gefunden, die sich für uns als sehr flexibel erwiesen hat und die es uns ermöglichte, mit weniger Problemen von Plattform zu Plattform zu wechseln.

Sprechen wir über Sensoren. Jedes unbemannte Fahrzeug verfügt über zahlreiche Sensoren. Jedes unbemannte Yandex-Fahrzeug verfügt über vier Lidars auf dem Dach und drei vorne, sechs Kameras auf dem Dach und sechs Radare: zwei hinten und vier vorne, von denen sich zwei seitlich befinden.



Wir nehmen Radar, Lidars, Kameras, verbinden, fahren in den Computer. Aber nicht so einfach. Es ist sehr wichtig sicherzustellen, dass die Sensordaten angemessen und von hoher Qualität sind. Wir haben eine große Anzahl von Experimenten durchgeführt, um zu verstehen, wo die Sensoren platziert werden müssen, damit wir die Welt besser und klarer sehen können.

Darüber hinaus mussten unsere Designer hart arbeiten, um sicherzustellen, dass alle Änderungen am Fahrzeug in Bezug auf Sensoren den Anforderungen der Zertifizierungsstellen entsprechen.



Folgendes ist passiert. Sechs Kameras auf dem Dach bieten eine gute 360-Grad-Ansicht mit deutlicher Überlappung - dunkle Bereiche sind auf der Folie markiert. Diese Kameras bieten auch eine gute vertikale Sicht. Die Kamera ist der einzige Sensor, der Ampeln sieht, da sie sich je nach Kreuzung und anderen Dingen an verschiedenen Stellen befinden können.



Radargeräte sind ein weiterer wichtiger Sensor für jedes Auto. Sie sind insofern interessant, als sie einen nicht sehr weiten Betrachtungswinkel, aber eine gute Reichweite haben. Zwei Frontalradare haben die Funktion, zu überwachen, was vor uns liegt. Die Heckradare in unseren Algorithmen werden in der Regel beim Wiederaufbau, Überholen und ähnlichen Manövern verwendet. Radare, die seitwärts schauen, sind erforderlich, um durch ziemlich komplexe Kreuzungen zu fahren, an denen Informationen von den Sensoren möglicherweise nicht ausreichen.



Der wahrscheinlich interessanteste Sensor ist Lidar. Er interessiert sich für die Informationen, die von ihm kommen. Hier ist eine Punktwolke, Punktwolke, dies sind Daten von Lidars. Sie zeigen Fußgänger, Autos, die Straße, sogar die Straßenränder und andere Objekte. Boxen sind bereits das Ergebnis der Arbeit unserer Erkennungsalgorithmen.



Insgesamt liefern alle Sensoren ungefähr das gleiche Bild. Wie Sie sehen können, ist es mit einem solchen Satz von Sensoren unmöglich, nichts um das Auto herum zu bemerken.

Ich möchte auf zwei Beispiele eingehen, die uns bei der Entwicklung von Hardware begegnet sind. Ich werde mit dem Lokalisierungsfall beginnen.

Die Hauptquelle sind hochauflösende Karten. Zu jedem Zeitpunkt vergleicht ein unbemanntes Fahrzeug Daten von Lidars mit diesen Karten. Basierend auf einem solchen Vergleich erhält er seinen Standort mit Zentimetergenauigkeit. GPS, Glonass oder eine andere Satellitennavigation sind aufgrund ihrer geringen Stabilität, hohen Abhängigkeit von äußeren Bedingungen, Wetter, Lärm und Störungen einfach nicht für die Arbeit mit unbemannten Fahrzeugen geeignet. In der Stadt wird dies alles durch Signalüberlappungen, Reflexionen von Gebäuden usw. erheblich erschwert. Aber woher bekommen wir diese Karten? Wir bauen selbst Karten mit unseren unbemannten Fahrzeugen mit einer Reihe von Sensoren.

Um diese Karten zu erstellen, benötigen wir Lidars und eine Art Referenz vor Ort. Sie müssen irgendwie Ihre Koordinate bekommen. GPS könnte anfänglich eine Koordinate geben, aber seine Genauigkeit ist nicht sehr hoch. Wie gesagt, die Genauigkeit von GPS wird durch atmosphärische Bedingungen, Störungen und in der Stadt auch durch Reflexionen beeinflusst.



Die kinematische Echtzeittechnologie hilft dabei. Das Fazit lautet: Irgendwo am Boden wird eine feste Basisstation mit demselben Empfangsgerät wie bei einem Auto installiert. Wenn der Abstand zwischen dem Auto und der Basisstation 30 km (in einigen Fällen 50 km) nicht überschreitet, sind die vom Auto und der Basisstation empfangenen Satellitendaten ungefähr gleich. Die Basisstation, die ihre genaue Koordinate kennt (sie ist stationär) und die Koordinate anhand von Satellitendaten berechnet, erhält jedoch bedingt einen Berechnungsfehler. Basierend auf diesem Fehler werden Änderungen entwickelt, die per Auto über das Internet an das Auto gesendet werden. Das Auto erhält unter Berücksichtigung der erhaltenen Korrekturen bei der Berechnung der Koordinaten durch Satelliten seine Koordinate mit Zentimetergenauigkeit. Um mit diesem System arbeiten zu können, benötigen Sie natürlich einen guten Internetkanal und gutes Wetter, damit das GPS-Signal stabil ist.

Um ein funktionierendes Gerät mit RTK-Unterstützung für ein Auto oder eine Basisstation zu erhalten, benötigen Sie Software. Bibliotheken mit RTK RTKLib-Funktionen sind öffentlich verfügbar. Es gibt verschiedene Variationen mit unterschiedlichen Merkmalen. Bibliotheken erfordern normalerweise eine Linux-Umgebung und Satellitennavigationsmodule, die Rohdaten bereitstellen.

Nachdem wir einige Experimente durchgeführt und einige Dinge prototypisiert hatten, erhielten wir ein Blockdiagramm des Lokalisierungsblocks, den wir GeoHub nannten.

Neben dem angegebenen Satellitennavigationsmodul gibt es auch ein Modul für Trägheitsmessungen, das wir im Lokalisierungssystem verwenden. Das Internet kommt jetzt über die Ethernet-Schnittstelle, die für unsere Infrastruktur praktisch ist.





Hier ist das zweite Gerät, seine zweite Generation und die wichtigsten technischen Eigenschaften.

Wir haben das Trägheitsmessmodul und das Satellitensignalmodul ausgetauscht. Infolgedessen konnten wir eine Reihe von Experimenten an einem Auto durchführen und das Trägheitsmessmodul auswählen, das unter dem Gesichtspunkt verschiedener Parameter optimal ist. Beim Satellitensignalmodul konnten wir auf einen Dualband-Empfänger umsteigen, wodurch die Qualität der Standortbestimmung erheblich verbessert wurde.

Warum Ihr Gerät entwickeln, wenn Sie sicher auf den Markt gehen und etwas Ähnliches kaufen können? Die Antwort ist, dass für uns einer der wichtigsten Parameter die Flexibilität des Geräts ist. Aufgrund der sich schnell ändernden Anforderungen im Projekt und der sich abzeichnenden neuen Funktionen müssen wir in der Lage sein, sehr schnell darauf zu reagieren. Nur wenn wir die Entwicklung von Hardware und Software innerhalb des Projekts intern durchführen, erhalten wir eine wirklich hohe Entwicklungsgeschwindigkeit für diese Änderungen.

Ein weiterer interessanter Sensor aus Sicht eines unbemannten Fahrzeugs ist die Kamera. Okay, in jedem Telefon und Laptop ist eine Kamera. Was könnte hier kompliziert sein? Aber lassen Sie uns sehen, auf welche Probleme Sie möglicherweise stoßen, wenn Sie die Kamera in einer Drohne verwenden.



Das erste Problem ist das Flackern von LED-Lichtquellen. Die meisten Ampeln sind nur solche Quellen. Das Video wurde in dem Moment gestoppt, als das rote Signal aufgrund von Flackern fast verschwand.

Für dieses Problem sind Hardwarelösungen in den Sensor eingebettet. Um jedoch gut und mit hoher Qualität zu arbeiten, müssen Sie in der Lage sein, aktiv mit dem Sensor zu interagieren.

Die zweite Voraussetzung für Kameras ist ein hoher Dynamikbereich, dh die Fähigkeit, bei allen Lichtverhältnissen sowohl nachts als auch bei strahlendem Sonnenschein zu arbeiten. Das Vorhandensein von HDR ist ebenfalls wichtig, dh die Möglichkeit, Bilder mit unterschiedlicher Beleuchtung zu einem zu kombinieren, um ein besseres Bild zu erhalten.



Links ist ein Beispiel für ein Bild, in dem die HDR-Funktion verwendet wird, und rechts - wo sie deaktiviert ist.



Außerdem müssen wir natürlich ein Bild mit einer ausreichenden Auflösung und einer ausreichenden Bildrate erhalten. Auf der Folie werden einige weitere Punkte hervorgehoben, die unbemannten Fahrzeugen inhärent sind, einschließlich. Die Kamera sollte einen unkomprimierten Videostream erzeugen, vorzugsweise im RGB888-Format, da unsere Netzwerke und Algorithmen mit diesem Format arbeiten und Frames in diesem Format empfangen möchten.

Die meisten Kameras, vorgefertigte Lösungen auf dem Markt, liefern komprimierte Daten - H264, MPEG. Die Probleme hier sind einfach: Wir verlieren während der Komprimierung an Qualität und führen zu einer Verzögerung bei der Komprimierung und Dekomprimierung. Die Verzögerung kann insbesondere bei hohen Systemlasten nicht deterministisch sein. Eine Kamera mit Full HD-Auflösung und einer Frequenz von 30 Bildern pro Sekunde mit einer Bitrate von 16 Bit pro Pixel erzeugt einen Strom von etwa Gigabit pro Sekunde reiner Videodaten.

Außerdem befinden sich Kameras normalerweise in einem Abstand von der Empfangsvorrichtung, und im Auto, insbesondere während einiger Experimente, können sie sich im Allgemeinen am anderen Ende des Autos befinden. Wir brauchten Kameras, mit denen der gesamte unkomprimierte Videostream unter Berücksichtigung der Verkabelung in einer Entfernung von 6 bis 8 Metern übertragen werden kann. Bei einer Full-HD-Kamera mit 16 Bit pro Pixel beträgt der Videostream 1 Gigabit, wodurch die Verwendung von Gigabit-Ethernet nicht mehr möglich ist, da verschiedene Servicedaten usw. an der Übertragung beteiligt sind. Zehn-Gigabit-Ethernet ist nicht ganz angemessen. Es ist teuer, hoher Stromverbrauch, hohe Wärmeableitung, erhöhte Komplexität der Netzwerkinfrastruktur.

Ja, es gibt andere interessante Schnittstellen. Ich möchte über zwei von ihnen sprechen, mit denen wir gearbeitet haben. Sie werden von Maxim Integrated und Texas Instruments bereitgestellt. Die Besonderheit ist, dass der Videostream in Daten serialisiert wird, die auf einer einfachen physischen Ebene, in diesem Fall über ein Koaxialkabel, mit einer Geschwindigkeit von 3-4, manchmal 6 Gigabit pro Sekunde, übertragen werden. Darüber hinaus können Sie über diese Schnittstelle den Rückkanal verwenden, um die Kamera über dasselbe Koaxialkabel zu steuern. Und darauf kann die Kameraleistung gehen. All dies macht diese Schnittstelle sehr attraktiv.



Als wir anfingen, fanden wir eine Lösung auf dem Markt, die im Grunde die meisten Anforderungen erfüllte. Wir haben es zu Beginn des Projekts einige Zeit benutzt.



Das Blockdiagramm der Lösung liegt vor Ihnen. Dies ist ein Sensor, von dem Daten an die GMSL / FPD-Link-Schnittstelle serialisiert werden. Am empfangenden Teil, der bis zu 15 Meter entfernt werden kann, werden die Daten deserialisiert und an den Empfänger übertragen. In unserer Lösung lieferte dieser Empfänger dann Daten über die USB 3.0-Schnittstelle.

Bei der Verwendung dieser Lösung stießen wir jedoch auf eine Reihe unangenehmer Probleme. Das Hauptproblem - die Lösung funktionierte extrem instabil, fiel dabei ab, die Kameras starteten nicht gut, als der Autopilot startete. Darüber hinaus erlaubte die Lösung nicht, die Parameter der Sensoren selbst anzupassen, um die Bildqualität zu verbessern. Es gab auch eine Reihe von Problemen. Zum Beispiel war es schwierig, den genauen Zeitstempel der Kamera, die Aufnahmezeit, zu erhalten, was sehr wichtig ist, da das Auto bei einer Geschwindigkeit von 15 m / s mit einer Verzögerung von 100 ms bereits eineinhalb Meter fährt und dies die Wahrnehmungsalgorithmen sehr negativ beeinflussen kann.

Es gab noch einen anderen interessanten Punkt. Die Ausgabeschnittstelle der ausgewählten Lösung war USB 3.0, und wir stellten fest, dass es extrem laut war. Wie verstehen wir das? Wir hatten zwei Autos, die mit nichts verbunden waren. Zum einen starteten sie die Kamera, zum anderen sank das Satellitennavigationssignal sehr stark. Dann begannen wir zu studieren, was los war.

Nachdem wir all diese Mängel im Allgemeinen analysiert, das vor Ihnen liegende Strukturdiagramm usw. studiert hatten, kamen wir zu dem Schluss, dass das Problem im empfangenden Teil liegt. Dann begannen sie zu überlegen, was sie damit anfangen sollten. Wir haben uns die Produkte auf dem Markt und die Lösungen anderer Teams angesehen und sind zu dem Schluss gekommen, dass wir unser eigenes Empfangsgerät entwickeln müssen, das über die GMSL- oder FPD-Link-Schnittstelle mit der Kamera funktioniert.



Wir haben Deserialisierer verwendet, die in der Regel über eine MIPI CSI2-Schnittstellenausgabe verfügen, und nach einem Modul oder Prozessor gesucht, der diese Schnittstelle unterstützen könnte. Und wir haben eine interessante Lösung mit sechs MIPI CSI2-Schnittstellen sowie leistungsstarken und umfangreichen Peripheriegeräten gefunden. Dadurch konnten wir schließlich die für unsere Netzwerkinfrastruktur geeignete 10-Gigabit-Ethernet-Schnittstelle als Ausgabeschnittstelle für dieses Gerät verwenden. Nachdem das Gerät GMSL / FPD-Link-Daten von 6 Kameras (oder in einigen Fällen von 12 Kameras) empfangen und verarbeitet hat, überträgt es den bereits verarbeiteten Videostream über 10-Gigabit-Ethernet weiter an den Computer.



Hier ist die Lösung selbst und ihre Hauptmerkmale. Nachdem wir so etwas entwickelt hatten, lernten wir nicht nur, wie man zuverlässig mit 6 oder 12 Kameras arbeitet, sondern hatten auch die Möglichkeit, die Kameras zu optimieren. Dies ermöglichte es, die Bildqualität zu verbessern, was sich positiv auf den Betrieb von Wahrnehmungsalgorithmen auswirkte. Wir haben auch ein klares Verständnis für die Zeit bekommen, die für die Aufnahme des Rahmens benötigt wird, und haben gelernt, wie man mit dieser Zeit umgeht. Dank der Rechenleistung des Moduls konnten wir die anfängliche Videoverarbeitung mit minimalen Verzögerungen direkt am Modul durchführen.

Der Hardware-Codec dieses Moduls erlaubte auch das Komprimieren von Videodaten für die nachfolgende Speicherung in den Protokollen.

Wir mussten nicht nur mit Lokalisierungssensoren und Kameras arbeiten. Wir mussten Hardwarelösungen für fast alle von uns verwendeten Sensoren entwickeln. All dies wurde getan, um die Erhöhung der Zuverlässigkeit und Qualität der Daten zu lösen, von denen die Erkennungs- und Wahrnehmungsalgorithmen abhängen. Und es hängt von ihnen ab, wie optimal die vom Autopiloten ausgegebene Lösung sein wird.

Okay, wir haben gelernt, wie man ein Auto fährt, haben an Sensoren gearbeitet, sie gut positioniert und ihnen beigebracht, uns ein qualitativ hochwertiges Bild zu geben. Welche andere Arbeit leisten die Ingenieure für eingebettete Systeme und Hardware-Mitarbeiter in unserem Projekt? Wir überwachen nicht nur die Entwicklung von Sensoren, die bereits alltäglich geworden sind, sondern auch alternative Informationsquellen. Wir erforschen ständig alternative Beschleuniger von neuronalen Netzen und anderen Algorithmen, einschließlich solcher, die FPGAs verwenden. Und die Entwicklung des Projekts ist ohne Interaktion mit einem erfahrenen Autohersteller kaum vorstellbar.


— , , .

. , . , , , . , .

Source: https://habr.com/ru/post/de471636/


All Articles