Wie wir ein Auto mittels WebRTC steuern können

• IoT
• Entwicklung
• React
• WebRTC

Spätes­tens seit die Corona-​Pandemie ange­fangen hat, verwenden wir alle WebRTC. Es wird in Teams, Zoom oder in jitsi verwendet, um Video­kon­fe­renzen im Browser oder in nativen Apps durch­zu­führen. Für ein Projekt haben wir evalu­iert, ob sich diese Tech­no­logie auch für die Steue­rung eines Fahr­zeugs oder einer Drohne eignet.

WebRTC

WebRTC erlaubt die Über­tra­gung von Bild, Ton und Daten, wird von jedem Browser unter­stützt und lässt sich auch in nativen Apps verwenden. Die Proto­kolle auf denen WebRTC basiert, sind bereits seit über 20 Jahren stan­dar­di­siert. Dabei werden moderne Video­for­mate unter­stützt und es funk­tio­niert auch hinter Fire­walls und in komplexen Netz­werk­to­po­lo­gien, wie Mobil­funk­netzen, ausge­zeichnet.

Die Video- und Audio­über­tra­gung findet mittels RTP (Real Time Protocol) statt, welches bereits 1996 in RFC 1889 das erste Mal stan­dar­di­siert wurde. Dabei werden Video Frames mit einem modernen Codec, meist H.264 oder VP8 kodiert, in Pakete zerlegt und über­mit­telt. Ein soge­nannter De-​Jitter-Buffer sorgt auf der Empfangs­seite für ein flüs­siges Bild und flüs­sigen Ton. Damit der Verlust von einzelnen Paketen keinen Einfluss auf die Empfangs­qua­lität hat, wird mit einer gewissen Redun­danz und FEC (forward error correc­tion), wie wir es von DVDs kennen, gear­beitet.

Die Daten­über­tra­gung findet bei WebRTC mittels SCTP (Stream Control Trans­mis­sion Protocol) statt das 2000 in RFC 2960 stan­dar­di­siert wurde. SCTP ermög­licht zuver­läs­sige und unzu­ver­läs­sige Über­tra­gung. Zuver­läs­sige Über­tra­gung braucht man z.B. um Dateien zu über­tragen. Der Nach­teil der zuver­läs­sigen Über­tra­gung ist, dass Daten, die nicht mehr aktuell sind, immer erneut über­tragen werden, was zu Latenz führt. Die unzu­ver­läs­sige Über­tra­gung ist vor allem dann nütz­lich, wenn man nur am letzten Zustand inter­es­siert ist und die bishe­rigen Daten irrele­vant werden. Dies ist z.B. bei Games oder bei Steu­er­si­gnalen der Fall.

Um durch Fire­walls und komplexe Netz­werk­to­po­lo­gien zu kommen, wird ICE (Inter­ac­tive Connec­ti­vity Estab­lish­ment) verwendet. ICE wurde 2010 in RFC 5245 stan­dar­di­siert. Dabei wird im einfachsten Fall eine direkte Verbin­dung verwendet. Befindet sich ein Client hinter einem Fire­wall, wird von dem Client hinter dem Fire­wall versucht eine Verbin­dung aufzu­bauen. Befinden sich, wie im mobile Bereich, beide Clients hinter Fire­walls, wird mittels STUN (Session Traversal Utili­ties for NAT) versucht, Löcher in die Fire­walls zu schlagen. Dabei senden beide Clients hinter den Fire­walls ein UDP Packet an einen STUN-​Server. Der STUN-​Server sendet die IP/Port kombi­na­tion der erhal­tenen Packete, als Antwort zurück. Damit lernen die Clients ihre Public-​IP und ihren Public-​Port, somit den internen Zustand der Zuord­nungs­ta­belle auf der Fire­wall. Da die meisten Fire­walls die Public-​Ports einfach hoch­zählen, können beide Clients ein UDP Packet an die gelernte Public-​IP und den gelernten Public-​Port plus eins des anderen Clients schi­cken. Somit sieht es für beide Fire­walls so aus, als sei die Verbin­dung von ihnen ausge­gangen und sie kommt zustande. Schlägt dies auch fehl, kann immer noch eine Verbin­dung über einen Proxy, einen soge­nannten TURN-​Server (Traversal Using Relays around NAT), aufge­baut werden.

Wenn man noch weiter in die Details von WebRTC eintau­chen möchte, können wir jedem das Buch "High Perfor­mance Browser Networ­king" empfehlen, das auch gratis Online unter hpbn.co verfügbar ist.

Auto

Wir wollten WebRTC nicht für Video­kon­fe­renzen verwenden, sondern ein Auto damit steuern. Deshalb bauten wir ein Auto aus folgenden Kompo­nenten:

Das Motoren-​ und Servo­shield sind dabei über I2C mit dem Raspberry Pi verbunden.

Um das Kame­ra­bild vom Raspberry Pi zu streamen, benutzen wir UV4L (User space Video4Linux), ein Strea­ming Server speziell für IoT Geräte, welcher über ein Plugin auch WebRTC unter­stützt.

Mit dem Stream konnten wir zwar aus der Perspek­tive des Autos schauen, aber um es zu steuern, müssen wir auch Daten senden. Da wir schon WebRTC verwen­deten, konnten wir hierfür die Daten­ka­näle von WebRTC benutzen. Auf dem Raspberry Pi läuft ein Python-​Skript, welches sich mit dem Socket von UV4L verbindet, die Daten ausliest und die Motoren und Servos entspre­chend steuert.

Als Steue­rungs­si­gnale von der App zum Auto werden die gewünschten Geschwin­dig­keiten für die Motoren an den Rädern, die Winkel der Servos im Greifer und ob ein Ton gewünscht wird über­mit­telt. Die Räder sind fix ange­bracht, d.h. um eine Kurve zu fahren, ist es erfor­der­lich die Geschwin­dig­keit der Motoren einzeln zu steuern.

Von dem Auto bekommen wir den Batte­rie­zu­stand, den Strom­ver­brauch und die Tempe­ratur. Bei anderen Tests wurde das Auto mit weiteren Sensoren ausge­stattet, so dass eine Posi­tio­nie­rung möglich war. Einige Sensoren schlossen wir per USB an den Raspberry Pi an und andere verbanden wir über ein WiFi-​Socket. Um die verschie­denen Sockets auszu­lesen, benutzten wir select, welche die entspre­chende Funk­tion aufrief für dieje­nigen Daten, welche gerade bereit sind.

Zur Steue­rung des Autos wurden zwei Apps entwi­ckelt. Eine native App für iOS und eine Web-App mit React. Beide Apps funk­tio­nieren gleich gut. Bei beiden Apps lässt sich das Auto über virtu­elle Joysticks steuern und der Video­stream und die Tele­me­trie­daten werden ange­zeigt. Die Joystick-​Koordinaten werden in der App in Moto­ren­stärken umge­rechnet. Die berech­neten Werte werden dann fort­lau­fend über den Daten­kanal ans Auto gesendet, welches die Motoren entspre­chend steuert.

Bei der React-​App wurde zusätz­lich der Support für einen physi­schen Joystick imple­men­tiert. Dazu konnten wir die Gamepad API vom Browser verwenden.

Für die Kodie­rung der Daten wurde initial CSV verwendet. Da die Daten mit den vielen Erwei­te­rungen unüber­sicht­lich wurden, und neue Daten hinzu­fügen sehr schwierig war, haben wir im Laufe des Projekts auf Protobuf gewech­selt.

Fazit

Mittels WebRTC konnte das Auto für den Proof of Concept gesteuert werden. Die Bild­la­tenz zwischen Kamera und App-​Display lag dabei unter 300 ms, was für unsere Zwecke mehr als ausreicht. Die Tech­no­logie wurde anschlies­send für ein reales Projekt verwendet, bei der sie sich eben­falls bewährt hat. Wir denken, das sich mittels WebRTC noch viele weitere span­nende Bild- und Steu­er­an­wen­dungen im Browser oder in nativen Apps reali­sieren lassen.