FPV Wifi Broadcasting HD Video - Thread zum Raspberry HD Videolink von Befi
- Themenstarter trailblazer
- Beginndatum
- Status
Also therotisch müsste es gehen wenn man zwei Pi's an Board hat. Den Videostream vom zweiten Pi and den ersten über Serial Port schicken und dann über einen zweiten Port von WBC schicken. So bräuchte man nur einen Empfänger. Allerdings leidet darunter die Bildqualität (doppeltes Bild aber gleiche Bandbreite).
Mit zwei USB Webcams an einem Pi dürfte es wohl auch gehen aber auch wieder das Problem mit der Bandbreite.
Edit: Gerade noch was gefunden für zwei Kameras an den Pi
http://www.argondesign.com/case-studies/2014/oct/21/stereo-depth-perception-raspberry-pi/
https://www.raspberrypi.org/blog/raspberry-pi-compute-module-new-product/
http://de.farnell.com/webapp/wcs/st...e module&pageSize=25&showResults=true&aa=true
Mit zwei USB Webcams an einem Pi dürfte es wohl auch gehen aber auch wieder das Problem mit der Bandbreite.
Edit: Gerade noch was gefunden für zwei Kameras an den Pi
http://www.argondesign.com/case-studies/2014/oct/21/stereo-depth-perception-raspberry-pi/
https://www.raspberrypi.org/blog/raspberry-pi-compute-module-new-product/
http://de.farnell.com/webapp/wcs/st...e module&pageSize=25&showResults=true&aa=true
Zuletzt bearbeitet:
2 unterschiedliche Videostreams Side by Side in der Android App wäre kein Problem,wenn die gpu mehrere Video-Decode instances erlaubt. Die meisten gpu's erlauben das. Ich bleibe jedoch bei demselben Stream side by side.
Ich habe mich jetzt hingesetzt und an dem Android OSD gearbeitet. Die ganzen Matritzen für Projection,View usw stehen,d.h man kann jetzt alles zeichnen,was aus Dreiecken besteht xD habe mich schon bisschen gespielt,und einen simplen 3D Kopter entworfen
ich werde mich aber erst einmal auf künstlichen Horizont usw beschränken ( wie Rangarid's OSD ). @Rangarid: wie hast du das mit dem testen gemacht,gibt es vlt. eine Software ,die bspw. Mavlink emuliert ?
Achja: ein 3D-OSD hat auch schon geklappt .
Der einzige nachteil von OpenGl: es gibt keine direkte Funktion für Schrift. Diese muss man in eine Textur zeichnen,und die Textur dann mit OpenGl. Deshalb werde ich wohl bspw. einen Layer für Ampere usw haben,der nur 1mal in der Sekunde aktualisiert wird,und den künstlichen horizont usw mit 60fps aktualisieren
Ich habe mich jetzt hingesetzt und an dem Android OSD gearbeitet. Die ganzen Matritzen für Projection,View usw stehen,d.h man kann jetzt alles zeichnen,was aus Dreiecken besteht xD habe mich schon bisschen gespielt,und einen simplen 3D Kopter entworfen
ich werde mich aber erst einmal auf künstlichen Horizont usw beschränken ( wie Rangarid's OSD ). @Rangarid: wie hast du das mit dem testen gemacht,gibt es vlt. eine Software ,die bspw. Mavlink emuliert ?Achja: ein 3D-OSD hat auch schon geklappt .
Der einzige nachteil von OpenGl: es gibt keine direkte Funktion für Schrift. Diese muss man in eine Textur zeichnen,und die Textur dann mit OpenGl. Deshalb werde ich wohl bspw. einen Layer für Ampere usw haben,der nur 1mal in der Sekunde aktualisiert wird,und den künstlichen horizont usw mit 60fps aktualisieren
Zuletzt bearbeitet:
Hey,
Da das 3D side by side so gut klappt,habe ich beschlossen,das OSD von Anfang an für 3D zu planen. Und das ist richtig cool,wenn der "Kopter" direkt vor der Nase schwebt,und das Video auf einer Leinwand dahinter.
Das Konzept ist jetzt so: Elemente können entweder als Meshes aus Dreiecken (Kopter,Airplane) dargestellt werden,und zusätzlich givt es einen texture atlas, der mit etwa ~10fps geupdatet werden kann,wo man mit "Android Canvas " (das ist das OpenVg equivalent von Android) Schrift usw für mAh oder so zeichnen kann .
Da das 3D side by side so gut klappt,habe ich beschlossen,das OSD von Anfang an für 3D zu planen. Und das ist richtig cool,wenn der "Kopter" direkt vor der Nase schwebt,und das Video auf einer Leinwand dahinter.
Das Konzept ist jetzt so: Elemente können entweder als Meshes aus Dreiecken (Kopter,Airplane) dargestellt werden,und zusätzlich givt es einen texture atlas, der mit etwa ~10fps geupdatet werden kann,wo man mit "Android Canvas " (das ist das OpenVg equivalent von Android) Schrift usw für mAh oder so zeichnen kann .
Hallo zusammen,
ich war längere Zeit nicht mehr im Wifibroadcasting Thread unterwegs, will mich jetzt aber noch einmal dran wagen. Ich habe das selbe Problem wie früher: Wenn ich als TX ein 2,3Ghz Image (TOMM) nutze und z.B. Kanal -7 wähle, bekomme ich bereits nach ein paar Metern ca. 20-35% Error rate auf meiner Fernbedienung angezeigt. Nach 100-200 Metern bin ich bei 100% Error-rate angekommen. Sendet der Stick nicht, sinkt die error-rate auf 1-3%. Es handelt sich um eine TGY-i6 2,4Ghz Funke - wobei ich auch schon eine Graupner Hott getestet habe und die gleichen Probleme erfahre. Kennt jemand diese Problematik? Hat jemand vielleicht sogar eine Lösung?
viele Grüße
Daniel
PS: Die Streamingverbindung scheint dabei stabil zu sein!!
ich war längere Zeit nicht mehr im Wifibroadcasting Thread unterwegs, will mich jetzt aber noch einmal dran wagen. Ich habe das selbe Problem wie früher: Wenn ich als TX ein 2,3Ghz Image (TOMM) nutze und z.B. Kanal -7 wähle, bekomme ich bereits nach ein paar Metern ca. 20-35% Error rate auf meiner Fernbedienung angezeigt. Nach 100-200 Metern bin ich bei 100% Error-rate angekommen. Sendet der Stick nicht, sinkt die error-rate auf 1-3%. Es handelt sich um eine TGY-i6 2,4Ghz Funke - wobei ich auch schon eine Graupner Hott getestet habe und die gleichen Probleme erfahre. Kennt jemand diese Problematik? Hat jemand vielleicht sogar eine Lösung?
viele Grüße
Daniel
PS: Die Streamingverbindung scheint dabei stabil zu sein!!
Das freut mich ! Mit HW oder SW decoder ?
Ich habe den fehler,der für die "pixel fehler" verantwortlich war,gefunden.
Desweilen habe ich ein paar weitere Nachmittage geopfert,und versucht, eine gut anzusehende & informative openGl welt zu entwerfen,gefühlt bestehend aus 3000 dreiecken.
Derzeit: man sieht den "Kopter und die dazugehörige Darstellung der Höhe und den HomePfeil vor sich in der Welt schweben, die Schrift vom OSD auch.
Man braucht nur eine VR brille,die nicht zu sehr "verzerrt",um die Demo zu sehen (wie die Daten geparst werden,muss ich noch implementieren)
Weitere Änderungen:
Benutzung von VBO (Vertex buffer object's),um die performance zu verbessern
Der FOV lässt sich verändern ( settings - view matrix ) ,für VR brillen,die einen zuhohen FOV haben
Lädt gerade hoch.
Ich habe den fehler,der für die "pixel fehler" verantwortlich war,gefunden.
Desweilen habe ich ein paar weitere Nachmittage geopfert,und versucht, eine gut anzusehende & informative openGl welt zu entwerfen,gefühlt bestehend aus 3000 dreiecken.
Derzeit: man sieht den "Kopter und die dazugehörige Darstellung der Höhe und den HomePfeil vor sich in der Welt schweben, die Schrift vom OSD auch.
Man braucht nur eine VR brille,die nicht zu sehr "verzerrt",um die Demo zu sehen (wie die Daten geparst werden,muss ich noch implementieren)
Weitere Änderungen:
Benutzung von VBO (Vertex buffer object's),um die performance zu verbessern
Der FOV lässt sich verändern ( settings - view matrix ) ,für VR brillen,die einen zuhohen FOV haben
Lädt gerade hoch.
Yeah,dann passt doch alles !
Was dann die veränderung war: der Decoder wird jetzt am Anfang mit rpi daten initialiesiert,die ich aus einem Stream gewonnen habe.
Der HW decoder sollte dir viel bessere latenzzeiten geben als der SW !
Das ist auch gut so,der schafft halt 140fps XD und spielt das video deshalb schneller ab
Achja: auf Github ist wieder eine neue Version (von heute),mit dem OSD:
Was dann die veränderung war: der Decoder wird jetzt am Anfang mit rpi daten initialiesiert,die ich aus einem Stream gewonnen habe.
Der HW decoder sollte dir viel bessere latenzzeiten geben als der SW !
Das ist auch gut so,der schafft halt 140fps XD und spielt das video deshalb schneller ab
Achja: auf Github ist wieder eine neue Version (von heute),mit dem OSD:
Ich durchsuche gerade das Internet nach OpenSource- Apps ,die MavLink parsen,und in java geschrieben sind.
Genauso wie der Video Link, per Wifibroadcast durch die luft,und am boden per socat in's Handy.
Das coole: wenn man für die Telemetry eine hoch genuge refresh rate wählt,sollte die latenz "Kopter- OpenGl kopter (künstlicher Horizont usw) " sehr gering sein,und somit der Kopter 1)in hoher entfernung bei schwachem Video-link und 2) bei hoher Latenz noch steuerbar sein.
Aber zurzeit werden die OSD daten noch einfach "generiert",deshalb Demo.
Wenn jemand coole Ideen hat,wie man das OSD noch gestalten kann,dann immer raus damit !
Genauso wie der Video Link, per Wifibroadcast durch die luft,und am boden per socat in's Handy.
Das coole: wenn man für die Telemetry eine hoch genuge refresh rate wählt,sollte die latenz "Kopter- OpenGl kopter (künstlicher Horizont usw) " sehr gering sein,und somit der Kopter 1)in hoher entfernung bei schwachem Video-link und 2) bei hoher Latenz noch steuerbar sein.
Aber zurzeit werden die OSD daten noch einfach "generiert",deshalb Demo.
Wenn jemand coole Ideen hat,wie man das OSD noch gestalten kann,dann immer raus damit !
- Status
