Low Cost HD-Video Übertragung + Telemetrie
- Themenstarter Lonestar78
- Beginndatum
- Status
Danke für die App. Nur was bei mir der fall ist das ich ne super latenz habe wen die aufösung bei 360p liegt alles darüber geht über 200ms. Anonsten funzt alles rtsp und udp. Naja da ich eher schnell unterwegs bin ist das noch ein bisschen zu viel.
Gibt zwar noch ein paar kleinere und größere bugs. Aber anonsten super Sache
Gibt zwar noch ein paar kleinere und größere bugs. Aber anonsten super Sache
Bei mir liegt die Latenz bei 211 ms @720p bei einem udp Stream. Damit kann ich gut leben.
Der Test lief mit dem selbst kompilierten 1.41 gstreamer.
Einzig die Verbindung zum rtsp klappte bei mir nicht. @Lonestar ist die Pipe so richtig oder erwartet der Androide andere Parameter?
Ebenfalls cool wäre die Möglichkeit mit der App eine ssh Verbindung aufzubauen und benutzerdefinierte Befehle abzusenden. z.B.: Stream starten/stoppen, sudo reboot, sudo -h shutdown now...
Der Test lief mit dem selbst kompilierten 1.41 gstreamer.
Einzig die Verbindung zum rtsp klappte bei mir nicht. @Lonestar ist die Pipe so richtig oder erwartet der Androide andere Parameter?
Ebenfalls cool wäre die Möglichkeit mit der App eine ssh Verbindung aufzubauen und benutzerdefinierte Befehle abzusenden. z.B.: Stream starten/stoppen, sudo reboot, sudo -h shutdown now...
Ein Tipp zur Koexistenz mit 2.4GHz-RC: einige RC-Systeme haben einen speziellen "Frankreich"-Modus, wo der obere 2.4GHz-Bereich ausgeblendet wird. In Verbindung mit einer Einstellung auf CH13 könnte damit eine relativ gute Trennung zu bewerkstelligen sein.
Habe noch nicht in der Praxis getestet, aber laut UBNT-Airview sieht die Sache vielversprechend aus...
Habe noch nicht in der Praxis getestet, aber laut UBNT-Airview sieht die Sache vielversprechend aus...
Abend Zusammen, gesammelte Antworten:
@digital_wadik: "Gibt zwar noch ein paar kleinere und größere bugs. Aber anonsten super Sache"
Danke, aber das reicht leider nicht, etwas mehr Schreibarbeit wäre hilfreich. Also bitte Bugs nennen, sonst kann ich sie nicht beheben. Btw.: Gibts von Dir auch irgendwelchen Code? Wird doch langsam Zeit ;-)
Für alle mit Android >=4.1 hab ich den App level runter gesetzt. Könnt Ihr mal testen, ob das klappt? Also Installation und Funktion? File: Anhang anzeigen GroundPiRelease_V15_API16.zip
Zum Thema Latenz: Hier wirds für diverse Android Mobiles halt völlig unterschiedliche Ergebnisse geben. Leider nicht zu ändern. Erfahrungswerte bitte posten.
@Sledge: Das mit dem RTSP dingens, hab ich auch gelegentlich. Muss ich mir anschauen, nach neustart App klappts meist. Deine Pipeline wird wohl so eher im Software Decoder Mode laufen. Ich empfehle das hier:
rtspsrc location=rtsp://192.168.137.240:8554/test latency=0 drop-on-latency=true ! application/x-rtp, payload=96 ! rtph264depay ! decodebin ! glimagesink sync=false
decodebin sollte den optimalen decoder raussuchen, glimagesink das passende Display.
@digaus: RSSI ist jetzt über SNMP realisiert. Einfach SNMP einschalten und als Community "public" angeben.
Grüße, The Dark Knight (Eingeweihte wissen warum. Danke für die Blumen ;-))
@digital_wadik: "Gibt zwar noch ein paar kleinere und größere bugs. Aber anonsten super Sache"
Danke, aber das reicht leider nicht, etwas mehr Schreibarbeit wäre hilfreich. Also bitte Bugs nennen, sonst kann ich sie nicht beheben. Btw.: Gibts von Dir auch irgendwelchen Code? Wird doch langsam Zeit ;-)
Für alle mit Android >=4.1 hab ich den App level runter gesetzt. Könnt Ihr mal testen, ob das klappt? Also Installation und Funktion? File: Anhang anzeigen GroundPiRelease_V15_API16.zip
Zum Thema Latenz: Hier wirds für diverse Android Mobiles halt völlig unterschiedliche Ergebnisse geben. Leider nicht zu ändern. Erfahrungswerte bitte posten.
@Sledge: Das mit dem RTSP dingens, hab ich auch gelegentlich. Muss ich mir anschauen, nach neustart App klappts meist. Deine Pipeline wird wohl so eher im Software Decoder Mode laufen. Ich empfehle das hier:
rtspsrc location=rtsp://192.168.137.240:8554/test latency=0 drop-on-latency=true ! application/x-rtp, payload=96 ! rtph264depay ! decodebin ! glimagesink sync=false
decodebin sollte den optimalen decoder raussuchen, glimagesink das passende Display.
@digaus: RSSI ist jetzt über SNMP realisiert. Einfach SNMP einschalten und als Community "public" angeben.
Grüße, The Dark Knight (Eingeweihte wissen warum. Danke für die Blumen ;-))
Zuletzt bearbeitet:
Hallo,
wie sehr lässt sich denn der Videocodec verändern ?
http://www.axis.com/de/products/video/about_networkvideo/compression.htm
Der Text ist ziemlich einfach und verständlich.
Wir haben zuerst einen I-Frame,welcher zwar auch codiert wird,jedoch die bitrate wenig verändert. Mehr kompression erreicht man durch die folgenden P-frames,welche die bildinhalte(pixelblöcke) des ersten I-frames die sich nicht verändert haben nicht nochmal erneut übertragen.
Unser fpv-videobild sollte sich hier am besten reduzieren lassen,da die bildinhalte zb beim überfliegen einer wiese ziemlich gleich bleiben.
Es gibt dann auch noch B-frames,diese sind für uns jedoch unpraktikabel,da sie sich auf vorausgehende und nachfolgende bilder beziehen,und man beim codieren als auch beim decodieren auf noch mehr frames warten muss.
Ich glaube das latency-Problem liegt an dem nicht ganz passendem codec,nicht an der Hardware. Wenn bei 30fps auf ein I-Frame (pauschal) erstmal 1p dann 2b frames folgen haben wir beim codieren 5frames "latency und beim decodieren wieder 5frames. Das sind von 30frames 10frames latency,also 1/3secunde latency,~333ms latency. Nur eine Idee,ich kann mich auch irren.
Lg
Constantin
wie sehr lässt sich denn der Videocodec verändern ?
http://www.axis.com/de/products/video/about_networkvideo/compression.htm
Der Text ist ziemlich einfach und verständlich.
Wir haben zuerst einen I-Frame,welcher zwar auch codiert wird,jedoch die bitrate wenig verändert. Mehr kompression erreicht man durch die folgenden P-frames,welche die bildinhalte(pixelblöcke) des ersten I-frames die sich nicht verändert haben nicht nochmal erneut übertragen.
Unser fpv-videobild sollte sich hier am besten reduzieren lassen,da die bildinhalte zb beim überfliegen einer wiese ziemlich gleich bleiben.
Es gibt dann auch noch B-frames,diese sind für uns jedoch unpraktikabel,da sie sich auf vorausgehende und nachfolgende bilder beziehen,und man beim codieren als auch beim decodieren auf noch mehr frames warten muss.
Ich glaube das latency-Problem liegt an dem nicht ganz passendem codec,nicht an der Hardware. Wenn bei 30fps auf ein I-Frame (pauschal) erstmal 1p dann 2b frames folgen haben wir beim codieren 5frames "latency und beim decodieren wieder 5frames. Das sind von 30frames 10frames latency,also 1/3secunde latency,~333ms latency. Nur eine Idee,ich kann mich auch irren.
Lg
Constantin
Sehr interessante Ueberlegung!
Die Codierungsstratgie sollte sich mit gstreamer wohl recht einfach anpassen lassen:
http://gstreamer.freedesktop.org/da...ugly-plugins-x264enc.html#GstX264Enc--bframes
Die Codierungsstratgie sollte sich mit gstreamer wohl recht einfach anpassen lassen:
http://gstreamer.freedesktop.org/da...ugly-plugins-x264enc.html#GstX264Enc--bframes
@sledge: Update für Dich.
Changelog V16:
- App level 16 (Android >= 4.1) Bin aber nicht sicher, ob das klappt.
- App jetzt mit SSH:
- Vier vorkonfigurierte Befehle an den Pi, ein Custom Befehl.
- Einstellung Custom Befehl, username und password über das Settingsmenü der App.
- Die ersten beiden Befehle erwarten diese ausführbaren Skripte auf dem airPi (reinpacken könnt Ihr da, was Ihr wollt):
/root/stopFromAndroid.sh
/root/startFromAndroid.sh
App:
Update im 1. Post.
Changelog V16:
- App level 16 (Android >= 4.1) Bin aber nicht sicher, ob das klappt.
- App jetzt mit SSH:
- Vier vorkonfigurierte Befehle an den Pi, ein Custom Befehl.
- Einstellung Custom Befehl, username und password über das Settingsmenü der App.
- Die ersten beiden Befehle erwarten diese ausführbaren Skripte auf dem airPi (reinpacken könnt Ihr da, was Ihr wollt):
/root/stopFromAndroid.sh
/root/startFromAndroid.sh
App:
Update im 1. Post.
Zuletzt bearbeitet:
Das Problem ist dass ich selber leider noch kein raspberrypi habe,sonst könnte ich besser mitreden.
http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=70095
Hier habe ich den Eindruck,dass er zwischen baseline und high wählen kann.
Welche H.264 ?art? Läuft denn zurzeit ? Schon die baseline oder eine andere ?
MotionJPEG bräuchte man xD
Constantin
http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=70095
Hier habe ich den Eindruck,dass er zwischen baseline und high wählen kann.
Welche H.264 ?art? Läuft denn zurzeit ? Schon die baseline oder eine andere ?
MotionJPEG bräuchte man xD
Constantin
Danke Lonestar, RSSI funktioniert jetzt Kann es sein, dass dabei immer die schlechteste Verbindung angezeigt wird? Ich habe ja auch mein Smartphone über wifi verbunden. Wenn ich damit den Raum verlasse wird der RSSI Wert schlechter... Auf dem Feld bin ich ja eh immer in der Nähe des Groundmoduls, von daher müsste dann der RSSI Wert zum Airmodul angezeigt werden.
Das einzige was noch nicht klappt, ist die Kommunikation mit mavproxy zur apm. Da ich ein Tablet als Groundstation verwende möchte ich die Telemetrieverbindung per UDP realisieren. Die APP Droidplanner ist auch in der Lage Telemetrie über UDP zu empfangen. Naja, allerdings scheitert es schon an der Kommunikation mit der apm. Hat schon jemand mavproxy erfolgreich eingesetzt?
Habe mich an diese Anleitung gehalten(allerdings mit Levelshifter): http://dev.ardupilot.com/wiki/raspberry-pi-via-mavlink/
Gruß
Daniel
Kann es sein, dass dabei immer die schlechteste Verbindung angezeigt wird? Ich habe ja auch mein Smartphone über wifi verbunden. Wenn ich damit den Raum verlasse wird der RSSI Wert schlechter... Auf dem Feld bin ich ja eh immer in der Nähe des Groundmoduls, von daher müsste dann der RSSI Wert zum Airmodul angezeigt werden.Das einzige was noch nicht klappt, ist die Kommunikation mit mavproxy zur apm. Da ich ein Tablet als Groundstation verwende möchte ich die Telemetrieverbindung per UDP realisieren. Die APP Droidplanner ist auch in der Lage Telemetrie über UDP zu empfangen. Naja, allerdings scheitert es schon an der Kommunikation mit der apm. Hat schon jemand mavproxy erfolgreich eingesetzt?
Habe mich an diese Anleitung gehalten(allerdings mit Levelshifter): http://dev.ardupilot.com/wiki/raspberry-pi-via-mavlink/
Gruß
Daniel
Bin auch bei 141ms!
So, nun bin ich auch "bei den Leut". Zwar jeweils nur als Nachahmer. Wenn es aber bei mir geht, können es viele andere auch
Latenz: 141ms
So sieht die Cam aus:
Ok, nicht hübsch, aber funktional. Kommt nun auf alles Mögliche und Unmögliche rauf um die Reichweite zu testen.
Und so siehts am Boden aus:
Da ist toll, dass ich halt ein 5m LAN-Kabel nehmen kann. So kann ich die Antenne dann schön hoch positionieren.
Hey, die Dinger werden aber ordentlich warm...
Sind übrigens die 5.8er Dev-Boards drin. Für die Tests werde ich dann CL/SPW-Antennen nehmen.
So, nun bin ich auch "bei den Leut". Zwar jeweils nur als Nachahmer. Wenn es aber bei mir geht, können es viele andere auch
Latenz: 141ms
So sieht die Cam aus:
Ok, nicht hübsch, aber funktional. Kommt nun auf alles Mögliche und Unmögliche rauf um die Reichweite zu testen.
Und so siehts am Boden aus:
Da ist toll, dass ich halt ein 5m LAN-Kabel nehmen kann. So kann ich die Antenne dann schön hoch positionieren.
Hey, die Dinger werden aber ordentlich warm...
Sind übrigens die 5.8er Dev-Boards drin. Für die Tests werde ich dann CL/SPW-Antennen nehmen.
- Status
