Baubericht: HD-FPV für 250EUR - nach Lonestar et al
- Themenstarter nachbrenner
- Beginndatum
Wo hast du die gesteigerte Latenz gemessen, am Fernseher? Ich hatte es früher immer wenn ich am Fernseher gezockt habe, dass ich einen Inputlag hatte. Das war zurückzuführen auf einige Bildverbesserungsprozesse vom Fernseher, die das Bild aufbereiten sollten. Vll. läuft sowas auch bei dir.
Du benutzt bloß ein Notebook mit kleinem Prozessor (Lenovo IdeaPad?). Vll. sind Lags auch auf schwachbrüstige Hardware zurückzuführen, oder auf Prozesse die im Hintergrund dir die Ressourhen abzwacken. Evt. probierst du es mal mit einem sehr schlanken Linuximage, welches du von USB booten kannst. Wurde im Ursprungsthread auch bereits von einem User behandelt.
OT: Wie zufrieden bist du mit dem Crawler? Ich bin auch schon lange am Überlegen mir einen zuzulegen. Was machte der so an Spitzengeschwindigkeiten?
Du benutzt bloß ein Notebook mit kleinem Prozessor (Lenovo IdeaPad?). Vll. sind Lags auch auf schwachbrüstige Hardware zurückzuführen, oder auf Prozesse die im Hintergrund dir die Ressourhen abzwacken. Evt. probierst du es mal mit einem sehr schlanken Linuximage, welches du von USB booten kannst. Wurde im Ursprungsthread auch bereits von einem User behandelt.
OT: Wie zufrieden bist du mit dem Crawler? Ich bin auch schon lange am Überlegen mir einen zuzulegen. Was machte der so an Spitzengeschwindigkeiten?
+1, bin sehr gespannt was hier rauskommt. Endlich mal jemand der nicht nur groß im Chat rumredet sondern tatsächlich tut, das habe ich bei dem ganzen HD-FPV-Thema bisher noch nicht gesehen
Da du damit wohl mich meinst, ich hab im Chat nicht nur herumgeredet sondern auch an meiner "Lösung" weitergebastelt
Und ich weiß noch dass mir im Chat oft genug von fast jedem gesagt wurde wie dämlich es sei FPV über WLAN machen zu wollen Finde es aber gut dass der Thread hier von nachbrenner mit einer recht ähnlichen Herangehensweise wie meiner auf positive Resonanz stößt.
Ich denke trotzdem dass man für ne optimale HD-FPV Lösung über WLAN das ganze unidirektional und in Einzelbildern machen sollte um die Latenz gering zu halten. Und hey, mein Code dafür ist quasi fertig, so weit bin ich gar nich mehr davon entfernt das ganze zum laufen zu bekommen
Danke für den Tipp, werde ich probieren!
Das ist ein Lenovo x210 mit einer Corei5 CPyu. Sollte genug Dampf haben. Ich nutze bereits ein abgestecktes Linux-Image (LUbuntu), habe sogar dem GStreamer mittels nice mehr Prio gegeben.
Der Crawler funktioniert als Testplattform gut. Allerdings würde ich ihn eher Indie Kategorie Spielzeug einordnen. Max Geschwindigkeit ist ca Schrittgeschw. also geschätzte 4-6kmh. (Er ist ja untersetzt und auf langsames drehmomentstarkes Fahren spezialisiert)
Das ist ein Lenovo x210 mit einer Corei5 CPyu. Sollte genug Dampf haben. Ich nutze bereits ein abgestecktes Linux-Image (LUbuntu), habe sogar dem GStreamer mittels nice mehr Prio gegeben.
OT: Wie zufrieden bist du mit dem Crawler? Ich bin auch schon lange am Überlegen mir einen zuzulegen. Was machte der so an Spitzengeschwindigkeiten?
So, habs jetzt endlich auch hinbekommen.
aktuelles Setup: PiCam->Raspi->Gstreamer->LAN->Router->WLAN->Gstreamer->Laptop
Mit dem GStreamer: 108 ms sind doch ok, oder? (Zum Vergleich: VLC hat über 1 Sek Latenz!)
Benutze zZ noch das hauseigene LAN/WLAN, die Bridge wird aber demnächst angeschafft.
Wenn ich allerdings die lauchGstreamer_HD.sh etc verwende, bekomme ich folgenden Fehler:
[Update1: 14.09.14 15:02]
Bei VLC kann man das Caching einstellen ("Mehr Optionen") und es beträgt standardmässig 1000ms. Stellt man es auf 0, wird nur ein Bild angezeigt. Ab 120ms hats geklappt, was natürlich realistischer ist. Allerdings werden dann dennoch Latenzzeiten von über 1Sek gemssen.
Es wird vermutlich aber am Uni-LAN liegen, da GStreamer auch nicht viel besser abschneidet.
aktuelles Setup: PiCam->Raspi->Gstreamer->LAN->Router->WLAN->Gstreamer->Laptop
Mit dem GStreamer: 108 ms sind doch ok, oder?
(Zum Vergleich: VLC hat über 1 Sek Latenz!)Benutze zZ noch das hauseigene LAN/WLAN, die Bridge wird aber demnächst angeschafft.
Wenn ich allerdings die lauchGstreamer_HD.sh etc verwende, bekomme ich folgenden Fehler:
Code:
-bash: raspivid: command not found
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstH264Parse:h264parse0: No valid frames found before end of stream
Additional debug info:
gstbaseparse.c(1155): gst_base_parse_sink_event_default (): /GstPipeline:pipeline0/GstH264Parse:h264parse0
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...Bei VLC kann man das Caching einstellen ("Mehr Optionen") und es beträgt standardmässig 1000ms. Stellt man es auf 0, wird nur ein Bild angezeigt. Ab 120ms hats geklappt, was natürlich realistischer ist. Allerdings werden dann dennoch Latenzzeiten von über 1Sek gemssen.
Es wird vermutlich aber am Uni-LAN liegen, da GStreamer auch nicht viel besser abschneidet.
Anhänge
Zuletzt bearbeitet:
@Nachbrenner nur mal so als kleiner Hinweis.
Da du auch in 2G4 unterwegs bist musst du die Ubis so einstellen das dir nicht zu arg von den Funken gestört werden.
Habe in deinem Berricht gelesen das du ausetzer und latenz anstiege hattest ... jetzt weist du auch warum.
Habe zwar bis zu 400 mit TCP geschaft. Aber nach meinem heutigem wissen würde ich dan doch die 5G8 ubis verwenden. Da dieser Berreich generell "sauberer" ist. Wenn du wissen willst wie man die 2G4 Ubis einstellt kannst ne PN an mich senden und das dan hier veröffentlichen fals es besser ist
Da du auch in 2G4 unterwegs bist musst du die Ubis so einstellen das dir nicht zu arg von den Funken gestört werden.
Habe in deinem Berricht gelesen das du ausetzer und latenz anstiege hattest ... jetzt weist du auch warum.
Habe zwar bis zu 400 mit TCP geschaft. Aber nach meinem heutigem wissen würde ich dan doch die 5G8 ubis verwenden. Da dieser Berreich generell "sauberer" ist. Wenn du wissen willst wie man die 2G4 Ubis einstellt kannst ne PN an mich senden und das dan hier veröffentlichen fals es besser ist
So, die Ubiquities sind da und dank der guten Anleitung hats auch gleich geklappt (habs erstmal länger ohne versucht ).
Die Latenz beträgt 170ms. Allerdings waren die beiden Geräte sehr nah beieinander. Heute wird gebastelt und dann später ein Reichweitentest durchgeführt.
Update: Reichweitentest
Wir haben die Ubiquities an einen 3S Lipo angeschlossen und dann folgende Messwerte gehabt:
210ms (gemittelt) bei 0m (Start)
310ms (min) bei 550m [dazwischen wegen vorbeifahrenden Autos und Bewegung der Cam zum Laptopbildschirm über 3Sek]
160ms (gemittelt) bei 0m (Ende, 33 min später)
Setup zum Latenzmessen: wir haben Windows auf 2 Laptops mit ntp1.lrz.de (die direkt auf GPS und GLONASS Atomuhren zugreifen) die Zeit synchronisiert und anschließend per cmd-Skript
die Systemzeit von Windows anzeigen lassen. Natürlicch driften diese wieder auseinander, je nach Laptop. Um diesen Drift zu kompensieren haben wir anfangs und am Ende der Zeit nebeneinander Werte gemessen. Wenn wir von einem linearen Drift ausgehen, beträgt die minimale Latenz bei 550m : 310ms - 12,4ms = 297,6ms.
Das Ganze mit Win7 System und TCP, im Prinzip war "schönes Fliegen" nur bis ca 100m möglich.
Die Umstellung auf UDP folgt das nächste Mal. Vielleicht kriegen wir auch eine elegantere Methode hin, um die Latenz zu messen.
Irgendwelche Tipps?
).Die Latenz beträgt 170ms. Allerdings waren die beiden Geräte sehr nah beieinander. Heute wird gebastelt und dann später ein Reichweitentest durchgeführt.
Update: Reichweitentest
Wir haben die Ubiquities an einen 3S Lipo angeschlossen und dann folgende Messwerte gehabt:
210ms (gemittelt) bei 0m (Start)
310ms (min) bei 550m [dazwischen wegen vorbeifahrenden Autos und Bewegung der Cam zum Laptopbildschirm über 3Sek]
160ms (gemittelt) bei 0m (Ende, 33 min später)
Setup zum Latenzmessen: wir haben Windows auf 2 Laptops mit ntp1.lrz.de (die direkt auf GPS und GLONASS Atomuhren zugreifen) die Zeit synchronisiert und anschließend per cmd-Skript
Code:
@echo off
:ENDLOS
cls
echo %time%
ping -n 1 -w 1 127.0.0.1 1>nul
goto ENDLOSDas Ganze mit Win7 System und TCP, im Prinzip war "schönes Fliegen" nur bis ca 100m möglich.
Die Umstellung auf UDP folgt das nächste Mal. Vielleicht kriegen wir auch eine elegantere Methode hin, um die Latenz zu messen.
Irgendwelche Tipps?
Zuletzt bearbeitet:
Also ich habe gestern erst eine Entfernung von 500m mit dem Setup und original Antennen erreicht, bei max Latenz von 170ms. Ich denke wir sind auf dem richtigen Weg
@nachbrenner: Wann können wir mit der Fortsetzung des Bauberichts rechnen?
Zuletzt bearbeitet:
Da haben sich gleich zwei Fehler eingeschlichen. Hast du deinem Rechner wirklich die IP 192.168.20.1 gegeben? Damit dürfte es nicht funktionieren, jedenfalls tat es das bei mir nicht Außerdem lauten Benutzer und Kennwort für das airOS ubnt / ubnt
Außerdem lauten Benutzer und Kennwort für das airOS ubnt / ubnt
Hier jetzt mal ein realistisches Bild vom aktuellen Zustand:
https://www.youtube.com/watch?v=3LWMlGtinE8
Links oben im Bild ist die abgefilmte Groundstation (Notebook an Fernseher, Latenz bei Tests ca. 150ms). Rechts unten das Bild einer Gopro die auf dem Rover mit fuhr.
Am Anfang des Videos sieht man sehr hohe Latenz. Ab Sekunde 22 wird es dann besser und ist zwischendurch gut fahrbar, da sollten es die 150ms sein. Allerdings machen die großen Schwankungen einen Einsatz im Flächenflieger nahezu unmöglich. Die Frage ist: Wo kommt das her? Basisstation und Rover sind nur wenige Meter voneinander entfernt und haben Sichtverbindung. Das Ground-Notebook ist ein minimales Ubuntu auf dem keine Background-Jobs laufen.
Läuft es bei euch besser? Wenn ja: Habt ihr Aufnahmen davon?
Ideen was ich verbessern kann?
Danke.
p.s.
Übrigens habe ich meine Pi-Cam für den Einsatz normaler Objektive umgebaut. Ich habe ein paar Bilder geschossen, Ergänzung im Baubericht folgt.
https://www.youtube.com/watch?v=3LWMlGtinE8
Links oben im Bild ist die abgefilmte Groundstation (Notebook an Fernseher, Latenz bei Tests ca. 150ms). Rechts unten das Bild einer Gopro die auf dem Rover mit fuhr.
Am Anfang des Videos sieht man sehr hohe Latenz. Ab Sekunde 22 wird es dann besser und ist zwischendurch gut fahrbar, da sollten es die 150ms sein. Allerdings machen die großen Schwankungen einen Einsatz im Flächenflieger nahezu unmöglich. Die Frage ist: Wo kommt das her? Basisstation und Rover sind nur wenige Meter voneinander entfernt und haben Sichtverbindung. Das Ground-Notebook ist ein minimales Ubuntu auf dem keine Background-Jobs laufen.
Läuft es bei euch besser? Wenn ja: Habt ihr Aufnahmen davon?
Ideen was ich verbessern kann?
Danke.
p.s.
Übrigens habe ich meine Pi-Cam für den Einsatz normaler Objektive umgebaut. Ich habe ein paar Bilder geschossen, Ergänzung im Baubericht folgt.
Hey. Ich habe zwar keine Lösung für dein Problem, aber Erfahrung. Ich war heute auch am Boden mit dem HD-FPV-Geraffel unterwegs. Nachdem ich gestern bereits schon die ersten Erfahrungen gemacht habe dass in Mitten von Wohnsiedlungen mit Stabantennen nicht gut WLAN-FPV zu fahren ist, bin ich heute rauf aufs Feld, weit ab von irgendwelchen Störquellen. Auf dem Spielplatz in der Sielung habe ich zwar nicht auf die Latenz geachtet, aber ich kann sagen, dass das Bild nach vll. gerade mal 30m Entfernung weg war! Nicht zu gebrauchen!
Heute auf dem Feld sah es schon anders aus. Hatte aber auch andere Testvoraussetzungen als gestern. So habe ich mir heute ein Stativ geschnappt und den Empfänger in 1,60m Höhe montiert. Außerdem habe ich mir heute fix ein Paar Cloverleaf-Antennen zusammengeschustert und die mit genutzt.
Heute kam ich bei freier Strecke bis an die Grenze des Sportplatzes, was min. schonmal doppelt so weit war wie gestern. Leider konnte ich da nicht weiter testen, weil halt das Ende des Platzes erreicht war. Was diese Verbesserung nun zuzuschreiben ist, weiß ich nicht genau. Den Antennen, keine WLAN-Netze in der Nähe, Höhere Position des Empfängers?
Wir waren heute zu 3. aufm Feld fliegen, und ich fahren. Was mir auch noch aufgefallen ist, dass die Funke (Irgendeine Taranis?) meines Kumpels das WLAN-Signal ziemlich krass gestört hat, sodass ich keine 20m weit fahren konnte?! Als er sie wieder ausgemacht hat, war alle wieder in Ordnung!
Ich bin übrigens in niedriger Auflösung gefahren, da ich nur ein altes Notebook mit hatte. In der horizontalen waren es 940Pixel. In der Senkrechten bin ich mir gerade nicht ganz sicher. Irgendwie um die 5xx oderso.
Hier übrigens meine Platform (da noch mit Stabantenne).
Edit: Achja. Ich hatte gestern für Fahrzeug und FPV-Sachen denselben LiPo genommen. Heute hatte ich alles an zwei voneinander getrennten LiPos.
Heute auf dem Feld sah es schon anders aus. Hatte aber auch andere Testvoraussetzungen als gestern. So habe ich mir heute ein Stativ geschnappt und den Empfänger in 1,60m Höhe montiert. Außerdem habe ich mir heute fix ein Paar Cloverleaf-Antennen zusammengeschustert und die mit genutzt.
Heute kam ich bei freier Strecke bis an die Grenze des Sportplatzes, was min. schonmal doppelt so weit war wie gestern. Leider konnte ich da nicht weiter testen, weil halt das Ende des Platzes erreicht war. Was diese Verbesserung nun zuzuschreiben ist, weiß ich nicht genau. Den Antennen, keine WLAN-Netze in der Nähe, Höhere Position des Empfängers?
Wir waren heute zu 3. aufm Feld fliegen, und ich fahren. Was mir auch noch aufgefallen ist, dass die Funke (Irgendeine Taranis?) meines Kumpels das WLAN-Signal ziemlich krass gestört hat, sodass ich keine 20m weit fahren konnte?! Als er sie wieder ausgemacht hat, war alle wieder in Ordnung!
Ich bin übrigens in niedriger Auflösung gefahren, da ich nur ein altes Notebook mit hatte. In der horizontalen waren es 940Pixel. In der Senkrechten bin ich mir gerade nicht ganz sicher. Irgendwie um die 5xx oderso.
Hier übrigens meine Platform (da noch mit Stabantenne).
Edit: Achja. Ich hatte gestern für Fahrzeug und FPV-Sachen denselben LiPo genommen. Heute hatte ich alles an zwei voneinander getrennten LiPos.
Danke für die Tipps!
Das Problem scheint gelöst: In meiner Pipeline auf dem Boden hatte ich das Bild gedreht (videoflip in der Kommandozeile). Das mache ich jetzt direkt am Pi in der Luft.
So sieht es es jetzt aus:
https://www.youtube.com/watch?v=5WE1vlJEnvA
Ich halte das für fliegbar. Next up: Flugtest auf dem Skywalker eines Freundes. Ich werde versuchen auch da einen Vergleich Boden/Luft zu filmen. Sobald ich Zeit habe gibt es euch kleine Doku zum Umbau der Raspberry-Cam auf Weitwinkel:
Das Problem scheint gelöst: In meiner Pipeline auf dem Boden hatte ich das Bild gedreht (videoflip in der Kommandozeile). Das mache ich jetzt direkt am Pi in der Luft.
So sieht es es jetzt aus:
https://www.youtube.com/watch?v=5WE1vlJEnvA
Ich halte das für fliegbar. Next up: Flugtest auf dem Skywalker eines Freundes. Ich werde versuchen auch da einen Vergleich Boden/Luft zu filmen. Sobald ich Zeit habe gibt es euch kleine Doku zum Umbau der Raspberry-Cam auf Weitwinkel:
