Low Cost HD-Video Übertragung + Telemetrie

Status
Nicht offen für weitere Antworten.

digital_wadik

Well-known member
Sicher kann man es schon nutzen auch "bequem". Autostart funktioniert wunderbar. Und unter Windows einfach eine Batch datei erstellen damit man nicht immer das Commandofenster öffnen muss.

Eig. kann man schon lange ein Tutorial dazu machen. Das würde den meisten eine menge Zeit ersparren. Habe aber keine Zeit für sowas. Baue grade an meinem Copter meiner Groundstation und programmiere das HUD und nebenbei arbeite ich noch :/
 

aargau

Erfahrener Benutzer
Kann es sein, dass bei Dunkelheit die hohe Framezahl sehr negativ wird? Ich habe wieder zum Teil mehrere Sekunden Verspätung. Hingegen wenn ich die FPS auf 20-25 setze erreiche ich 150-200ms. Ev will die Software dann unbedingt mehr FPS, muss aber einige Frames verwerfen, weil das andere noch nicht fertig belichtet wurde?

Edit: Hab beim raspivid sowohl bitrate als auch fps rausgeworfen, dann nimmt er das Maximalmögliche... Bitrate müsste man in der udpsink wohl noch irgend wie regeln, habe aber noch nicht herausgekriegt wir das genau geht. Auf die vom raspivid reagiert er nicht wirklich.

Multicast: Auf dem RPi: udpsink host=224.1.2.3 port=5000
PC:
gst-launch-1.0 -e -v udpsrc multicast-group=224.1.2.3 port=5000 ! application/x-rtp, payload=96 ! rtpjitterbuffer ! rtph264depay ! a
vdec_h264 ! fpsdisplaysink sync=false text-overlay=false

Läuft wunderbar :D

Edit2:
Stream braucht so zwischen 5 und 8Mbit/s. im Schnitt ca. 8Mbit/s.

Edit3: Sorry, für die vielen Edits, aber wenn ich es nicht aufschreib geht es bei mir wieder vergessen ^^
Mit akzeptablen 230ms Verzögerung habe ich mit 720x480 und 10fps <1Mbit/s. erreicht. Ist schon krass, wenn man bedenkt was für eine Bandbreite analoges Video verbraucht. Mit einer Dynamischen Pipeline lässt sich da also bis fast ans Limit vom Wlan Link gehen
 
Zuletzt bearbeitet:

digital_wadik

Well-known member
@aargau du musst aber bedenke das die ergebnisse die du da für die herausbekommen hast nur für dein system gelten.

Habe diesen stream schon mit den verschiedensten paltformen/HW ausprobiert. Und JEDES mal musste ich andere parameter verwenden.
 
Zuletzt bearbeitet:

aargau

Erfahrener Benutzer
Hmm okay, das ist aber schon etwas komisch. Mit meinem Ultrabook habe ich bis jetzt auch noch keine brauchbaren resulatate erreicht, obwohl das ding ein i7 hat und ich damit schon ganz andere dinge gemacht habe. Wobei ich da nicht sicher bin ob es nicht mein Heimrouter ist, der Link mit 130Mbit/s. und ca. 50Mbit/s. "wirklichem" Durchsatz müsste zwar locker reichen.
 

digital_wadik

Well-known member
Bei mir hats bis jetzt immer funktioniert. Auch mit einer ganz alten fritzbox. Lass das mal bei dir mit dem multicast. Hat schon sein grund warum ein "unicast" stream eine höhere performance aufweist.
 
Zuletzt bearbeitet:

aargau

Erfahrener Benutzer
Die Tests waren noch mit unicast, bei Multicast kommt nur noch Datenmüll an, liegt wohl daran, dass der AP/Router IGMP nicht wirklich unterstützt, müsste es mal per LAN testen, aber dazu muss ich erst mal mein USB Lan Adapter vom Ultrabook wieder finden ^^ Werde mal noch testen wie es auf einem Atom Tablet aussieht.
Ich Stressteste den Pi gerade, bis jetzt läuft der Stream noch fehlerfrei seit gestern Abend.

Edit:
Reagiert doch auf das -b (bitrate). bei 720p sind 5-7Mbit/s. ganz okay, man kann aber auch gut auf 1Mbit/s. gehen, man erkennt das Bild noch mehr als gut, bin sogar mit 500kBit/s. noch ganz zu frieden für den Notfall :p

So, nun würde ich gerne mal beginnen eine Dynamische Pipeline zu realisieren, so dass man wenigstens relativ einfach die Einstellungen onAir changen kann, ideal über ein tcp SocketServer.
Weis jemand von euch wo ich da am besten Anfange und in welcher Sprache man sowas am besten Proggt? Bin halt ein "Windows Kind" und kenn mich dafür zu wenig mit Linux aus.
Gibt es irgend wo gute Tutorials für den gStreamer mit einer dyn Pipeline?

Im übrigen scheint es HDMI zu CSI ICs zu geben, sowas wäre dann ev. der nächste schritt, wenn das ganze mal sauber läuft, dann könnte man auch direkt die Gimbalkamera verwenden, da würde die Verzögerung zwar wohl höher ausfallen, aber als Bildkontrolle wären >720p dann schon was ganz tolles.
 
Zuletzt bearbeitet:

aargau

Erfahrener Benutzer
Habe gerade mein ersten FPVoverWifi test in der Tiefgarage meines Arbeitgebers gemacht. Läuft schon super und die Bildqualität ist schon toll. Reichweite war nicht so viel drinn, selbst nach 50m hatte ich extremes delay, allerdings habe ich das ganze auch nur mit einem TPLink TL-MR3040 auf dem Auto und meinem Ultrabook getestet. Windows selber zeigte mir noch vollen Empfang an, Bitrate war bei 72Mbit/. Hoffe, dann mit etwas besserer Wlan hardware auch etwas weiter zu kommen :)
 

digital_wadik

Well-known member
TCP verbindungen kann man sehr leicht mit Java programmieren. Jedoch weis ich nicht in wie weit man gstreamer in java implementieren kann. Wenn es dafür ne schöne Dokumentation gibt wäre das aber auch nicht unmöglich. Habe aber grade andere Ziele. Min dem HUD bin ich schon ganz schön beschäftig.

Achja und Java ist ja Platformübergreifend. Also auch Windows menschen werden da kein problem haben xD
 
Zuletzt bearbeitet:

aargau

Erfahrener Benutzer
Ich frag mich einfach ob java der richtige Weg wäre, Java läuft ja quasi Virtuell, was sicher einiges an Performance schluckt, ob man von Java direkt auf die CSI Schnittstelle zugreifen kann?
Naja, ich werde mich in einer ruhigen Minute mal etwas umsehen und dann sonst mal versuchen was zu basteln
 

digital_wadik

Well-known member
So es geht weiter :D

Zuerst wollte ich mal kurz meine Groundstation präsentieren.
Hier erstmal ein Bild
https://drive.google.com/file/d/0Bz-hsySloAOXc1cybXJlcUdsU0k/edit?usp=sharing

Habe mir gedacht solange ich noch kein Notebook habe nehme ich das Low Cost mal wörtlich xD
Also FPV Konzept Pi to pi :rolleyes:

[video=youtube;hMmZ4Jx6ddA]https://www.youtube.com/watch?v=hMmZ4Jx6ddA[/video]
PHP:


Und nun zum Stream.
Habe zwei Ubiquiti Bullet M2 im 2.4Ghz an jedem Pi einen.
Der Ground Ubi ist als Router konfiguriert dadurch habe ich auch die möglichkeit die Pi's durch mein Smartphone zu steuern etc.

Das beispiel Video habe ich leider noch mit schlechten Einstellungen gemacht wodurch eine Verzögerung von ~200 ms ensteht. Jedoch habe ich auch schöne ~120 ms hinbekommen zwischen den Raspberry Pi's !!!!
Auflösung war jedoch nur 800x600 was auch daran liegt das der Display nicht mehr schaft.
Hier das Video

[video=youtube;Rga99KyxGOU]https://www.youtube.com/watch?v=Rga99KyxGOU[/video]



Also wie gehts weiter ?

Baue mein Copter im moment auf tri um da ein Motor leider hin ist un muss mir noch meine Motorhalterungen fräsen. Mein Kumpel baut seinen auch grade um also mit richtigen Luftbildern und einem Rangetest ist erst in 1 - 2 Wochen zu rechnen. Bis dahin müssten auch meine Cloverleaf Antennen da sein. Für den Test werde ich mir dann aber ein Notebook besorgen.

Auf jeden Fall läuft die Sache. Bin auch bisschen in meiner Gegend rumgelaufen. Also MIMO durchschlägt wirklich jegliche Wände xD also Bild war immer Flüssig. Ne Quatsch so funzt MIMO nicht. Aber es ist in Urban Gebiete vom Vorteil es zu haben.
http://www.lte-anbieter.info/technik/mimo.php
bisschen Hintergrundwissen wen jemand mag.

Ich bin auf jeden Fall sehr begeistert von der ganzen Sache. Das HUD musste bis jetzt leider warten aber hoffe demnächst ein paar Ergebnisse vorlegen zu können.

Bis dahin viel Spaß bei Fliegen :)
 
Zuletzt bearbeitet:

YaNnIk

Erfahrener Benutzer
Sieht gut aus und interessanter Artikel über die MIMO Technik! Aber ähhm, du schreibst MIMO funktioniert so toll - die Bullet M2 haben doch nur eine Antenne und sind damit nicht MIMO fähig, oder?! Ich dachte, dass wäre eben der entscheidende Vorteil den die Rocket Teile haben?!

Und nochmal zur MIMO Technik.. Würden man nicht einen Vorteil beziehen, wenn die Datenströme besser getrennt werden.. Dort bei der LTE Technik steht ja, dass die nur separiert werden können, wenn 15dB Unterschied herscht, was wohl bei uns kaum der Fall sein wird... Also schalten die nur in pseudo MIMO (Diversity), wenn ich das richtig verstanden habe. Wäre es dann nicht sinnvoll z.B. eine RH und eine LH polarisierte Antenne zu nehmen ? Da dürfte doch genug dB Abfall zwischen den falschen Kombinationen produziert werden?!
 

digital_wadik

Well-known member
Die Bullet M2 haben MIMO.
Keine ahnung wie die das machen. Wird wahrscheinlich durch Software gelösst. Auf jeden fall habe ich mit den M2 gute ergebnisse auch bei Hindernissen. Nutze noch stabantennen. Mal sehen wie es wird wen ich meine Cloverleaf habe.

Normaler weise bräuchte man es auch gar nicht. Weil man ja keine 100 Mbps braucht.

Aber naja bin in dem Gebiet kein Fachmann.
 
Zuletzt bearbeitet:

digital_wadik

Well-known member
Bei den Rockets würde RH und LH sogar sinn machen. Denke dadurch würde man die besten ergebnisse erzielen. Denn egal wie die Wellen umpolarisiert werden. Sie können immer ausgewertet werden.

Ich mag die Bullets aber mehr. Die verbrauchen viel weniger Platz und sind voll ausrreichend.
 

Lonestar78

Erfahrener Benutzer
Mal ein kurzer Zwischenstand:
Ich habe mittlerweile meine erste Android App, die per GStreamer von einem Raspberry Pi RTSP Server abspielt.
Haken: noch nur per Software Codec, an der Nutzen des Hardware Codecs arbeite ich noch...

In kleinen schritten....
 

Lonestar78

Erfahrener Benutzer
So wie es aussieht, liegt das an der GStreamer Version 1.2.4-1, die kann den Farbcode des HW-Decoders nicht...
Aber 1.3.9 müsste das können. Mal schaun, ob ich das heute hinbekomme...:)
 

Lonestar78

Erfahrener Benutzer
Jupp, lag an der Gstreamer Version.
Habe jetzt etwa 180ms glas to glas bei 720p mit einer Pipeline, die den GStreamer rtsp-server auf dem Pi nutzt.
AndroidGroundPi.jpg

Pipeline auf dem Pi:
rtspServerairPi "(rpicamsrc bitrate=8500000 hflip=true vflip=true preview=false ! video/x-h264,width=1280,height=720,framerate=45/1,profile=high ! h264parse ! rtph264pay name=pay0 pt=96 )"

rtspServerairPi ist die umbenannte test-Applikation, die im rtsp-server Paket dabei ist.
Installiert auf dem Pi ist Gstreamer 1.2.4-1

Die App für Android nutzt root tools um ein etwaig verfügbares eth0 statisch auf 192.168.137.1 zu konfigurieren. Wenns nicht geht: Kein Problem.
Die Pipeline für Android (zu finden in pipeline.h):
rtspsrc location=rtsp://192.168.137.240:8554/test latency=30 ! application/x-rtp, payload=96 ! rtph264depay ! decodebin ! glimagesink sync=false

Achja: Nur auf Nexus 5 mit Android 4.4.2 getestet. benötigt mindestens Android 4.4
Source als Eclipse Projekt anbei, genauso die app selbst.
Wenn jemand spielen möchte:
Anhang anzeigen RootTools.zip
Anhang anzeigen GroundPiProject_000Alpha.zip
Anhang anzeigen GroundPiDebug.zip
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten