Low Cost HD-Video Übertragung + Telemetrie

Status
Nicht offen für weitere Antworten.
Habe bereits ne kleine Java Anwendung programmiert mit der ich einfach durch Regler den Stream bequem starten kan. Ist ähnlich wie ein RTSP Server. Läuft zurzeit unter Windows und Linux. Bin auch langsam dabei die Telemetrie Daten von Mavproxy aufzuarbeiten. Zieht sich jetzt alles weil ich am studieren bin. Wird aber noch nicht veröffentlicht. Vlt nächstes Jahr ;)
 

JR63

Erfahrener Benutzer
Schau Dir mal die Intel NUC Geräte an, die sind ganz putzig und sollten von der Leistung absolut ausreichend sein. Unter Windows und Linux kannst Du den Gstreamer installieren um das Video zu sehen. Viel mehr neues gibt es an dieser Front nicht. Ansonsten gibt es ja noch Tablets in Hülle und Fülle. Ich hab jetzt günstig ein Nexus 7 geschossen. Mal sehen wie sich das Teil schlägt. Ansonsten habe ich mir das Galaxy Note 4 bestellt. Ab Dezember soll es dafür ja auch die Galaxy Gear VR Brille geben. Das schöne an der Gear VR ist, dass es ein Touchpad an der Seite hat. Mehr Immersion bekommt man sicher nur noch unter Zuhilfenahme von Halluzinogenen :)
Ok Danke, die NUCs werde ich mal checken.

Ansonsten läuft das bei mir aktuell auf einem Win-Laptop (core i5) mit gstreamer mit ca. 170-180ms, allerdings hat der Laptop kein HDMI out :-(

Das Galaxy Note 4 widerspricht in meinem Fall etwas gegen den LowCost Gedanken dieses Threads, da ich es sonst für nix gebrauchen kann.

Also scheinen die meisten hier eher auf der Smartphone Schiene zu sein, weil heutzutage der normale Mensch ein solches einfach hat?

Tschö
JR
 

Constantin

Erfahrener Benutzer
Ok Danke, die NUCs werde ich mal checken.

Ansonsten läuft das bei mir aktuell auf einem Win-Laptop (core i5) mit gstreamer mit ca. 170-180ms, allerdings hat der Laptop kein HDMI out :-(

Das Galaxy Note 4 widerspricht in meinem Fall etwas gegen den LowCost Gedanken dieses Threads, da ich es sonst für nix gebrauchen kann.

Also scheinen die meisten hier eher auf der Smartphone Schiene zu sein, weil heutzutage der normale Mensch ein solches einfach hat?

Tschö
JR

Solange du bei dem Laptop bleibst würde ich einen bootfähigen usb mit linux erstellen und dann gstreamer von dem starten. Windows scheint einfach zu viel im Hintergrund laufen zu haben.
Wenn er wenigstens vga hat kannst du fast alle 5" 72OP bildschirme anschließen. Diese kosten aber auch 1OO€ in fernost mit einem lvds Controller . Ein motorola moto g mit 4.5" 72OP kostet ~189€ das ist verflickst. Bin aber der Meinung dass die Latenz aufm Handy mit Android immer höher bleiben wird als mit (roh)Linux. Eine "echte" Videobrille mit 72OP kostet einfach noch zu viel/gibt es da berhaupt welche ausser der zeiss ?
 

hornetwl

Erfahrener Benutzer
Sledge;710689 hat gesagt.:
Zum Thema Debian Pakete. Mein Ursprünglicher Plan war ja ein Installationsskript zu schreiben. Dann könnte man einfach wget installationsskript ; sh installationsskript ausführen und alle Pakete werden installiert, Einstellungen werden geschrieben und fertig. Das Problem war in erster Linie, dass es vom Gstreamer nur veraltete Pakete gibt und ich keine Lust habe ein eigenes Repo aufzubauen. Es ist auch nicht gesagt ob das Skript nach einem dist upgrade noch läuft bzw ob es sich mit anderen Einstellungen zankt, die der Benutzer bereits getroffen hat.
Mit einem Installationsskript kann das in der Tat schnell passieren - mit Paketen eher nicht! Genau darum kümmert sich dpkg, sollten sich z.B. verschiedene Pakete das gleiche File zanken, gibts unmissverständliche Fehlermeldungen. Auch Abhängigkeiten zu anderen notwendigen Paketen sind mit einer Zeile oder weniger definiert und werden automatisch mitinstalliert.

Auch der veraltete GStreamer schreit m.E. nach Paketen in einem eigenen Debian-Repo.

Das Image ist die sauberste Lösung um allen Leuten den Einstieg in das Projekt zu ermöglichen die mit Linux nichts am Hut haben. Profis oder neugierige können sich ja ihr eigenes Image aufbauen wenn Sie das lieber möchten.
Genau das funktioniert eben nicht besonders gut. Ich habe mir z.B. auch eine MAVProxy-Integration gebaut und diese von Hand ins Image gefrickelt, zusammen mit vielen kleinen Konfigurationsänderungen. Jetzt kommt ihr mit nem komplett neuen Image um die Ecke und der Krampf geht wieder los ;) . Meine Änderungen kann ich auch nicht so einfach teilen, wie sollte ich die denn aus dem Image herausdestillieren? Das Image ist für eine schnelle Quick-and-Dirty-Operation sicher ausreichend, aber für ein sich beständig weiterentwickelndes Projekt halte ich das als für zu kurz geschossen.

Es wäre aber schön wenn weiterhin das Wissen geteilt wird damit ich das Image weiter und erweitern kann. Mavproxi steht auch schon auf der Roadmap und wird wahrscheinlich in der nächsten Iteration verfügbar sein. Ein weiterer Punkt wäre die Übertragung der Steuersignale über Wlan. Hier wäre ich für jede Hilfe dankbar. Da ich mich mit Senseless und Lonestar immer eng abstimme werden kommende Erweiterungen wahrscheinlich auch irgendwann in den Apps Einzug finden. Auf diese Weise haben wir irgendwann die digitale Wollmilchsau in ein Image gepresst.
Bitte, bitte nicht in einen monolithischen Block pressen, sondern sauber strukturiert in Form kleinen atomaren Bausteinen (einzelne Skripte, einer per Feature) in ein Github-Repo packen - dann ist genau diese Art von Hilfe viel, viel einfacher.

Ich will aber hier nicht nur rummeckern - wenn ihr mal die Rohbestandteile (= alle Abweichungen vom Standard-Raspi) mal in einem Thread oder sonstigen Dokument strukturiert und sämtliche Skripte in eine Dropbox o.ä. packt, mache ich gern mal einen Versuch, das zu paketieren.

PS.: vielleicht gibts die struktuierte Doku schon - find ich aber im monolithischen 1166 Beiträge langen Monstertrhead gerad nicht :D :D :D

PPS: das einsteigerfreundliche Fertig-Image ist bei Vorhandensein ordentlicher Pakete natürlich trotzdem erstellbar, und zwar jederzeit und (fast) auf Knopfdruck!
 
Zuletzt bearbeitet:

Lonestar78

Erfahrener Benutzer
Das mit den Fehlern auf verschiedenen 4.4.4er Versionen blicke ich nicht.
Vieleicht komm ich aber noch drauf.
Ist ja zumindest kein Verlust wenns noch nicht funktioniert....

Ansonsten ein Teaser:
Teaser.jpg
 

Lonestar78

Erfahrener Benutzer
Ok...Noch zwei weitere Teaser.
Google Cardboard, wir kommen ....:)
Meins kommt Donnerstag, dann stelle ich die Verzerrungen so ein, dass das Maximum an Auflösung genutzt wird.
Der Google Cardboard Modus wird dann einfach in der App zuschaltbar sein.
Screenshot_2014-11-10-21-31-04.png

Screenshot_2014-11-10-21-32-00.png
 
Zuletzt bearbeitet:

Lonestar78

Erfahrener Benutzer
Naja, das ist dann ertmal nur Side by Side, um auch mit Handyhalterungen mit zwei Linsen klarzukommen.
Ist ausserdem entspannender für die Augen.
Nachteil: Man verliert mehr als Faktor 2 auf FullHD an Auflösung pro Auge (1920/2 und dann auch noch der Verlust durch die Verzerrung).
Vorteil: Na dann muss ich auch kein 1920x1080 Video mehr übertragen..960x1080 reicht ;-)

Mal gespannt, was der GLShader mit der Latenz macht...
 

digaus

Erfahrener Benutzer
Also dafür wäre das iPad perfekt. Das hat ne Auflösung von 2048x1536 Pixeln. Dann zwei Streams mit je 720p nebeneinander.
Bei den Streams sehe ich auf dem Handy zumindest keinen Unterschied zwischen 720p und 1080p.
 

Sledge

lonesome Cowboy
Mit einem Installationsskript kann das in der Tat schnell passieren - mit Paketen eher nicht! Genau darum kümmert sich dpkg, sollten sich z.B. verschiedene Pakete das gleiche File zanken, gibts unmissverständliche Fehlermeldungen. Auch Abhängigkeiten zu anderen notwendigen Paketen sind mit einer Zeile oder weniger definiert und werden automatisch mitinstalliert.

Auch der veraltete GStreamer schreit m.E. nach Paketen in einem eigenen Debian-Repo.


Genau das funktioniert eben nicht besonders gut. Ich habe mir z.B. auch eine MAVProxy-Integration gebaut und diese von Hand ins Image gefrickelt, zusammen mit vielen kleinen Konfigurationsänderungen. Jetzt kommt ihr mit nem komplett neuen Image um die Ecke und der Krampf geht wieder los ;) . Meine Änderungen kann ich auch nicht so einfach teilen, wie sollte ich die denn aus dem Image herausdestillieren? Das Image ist für eine schnelle Quick-and-Dirty-Operation sicher ausreichend, aber für ein sich beständig weiterentwickelndes Projekt halte ich das als für zu kurz geschossen.


Bitte, bitte nicht in einen monolithischen Block pressen, sondern sauber strukturiert in Form kleinen atomaren Bausteinen (einzelne Skripte, einer per Feature) in ein Github-Repo packen - dann ist genau diese Art von Hilfe viel, viel einfacher.

Ich will aber hier nicht nur rummeckern - wenn ihr mal die Rohbestandteile (= alle Abweichungen vom Standard-Raspi) mal in einem Thread oder sonstigen Dokument strukturiert und sämtliche Skripte in eine Dropbox o.ä. packt, mache ich gern mal einen Versuch, das zu paketieren.

PS.: vielleicht gibts die struktuierte Doku schon - find ich aber im monolithischen 1166 Beiträge langen Monstertrhead gerad nicht :D :D :D

PPS: das einsteigerfreundliche Fertig-Image ist bei Vorhandensein ordentlicher Pakete natürlich trotzdem erstellbar, und zwar jederzeit und (fast) auf Knopfdruck!
Du hast natürlich Recht, dass die Vorgehensweise mit den Images nicht dem Linux Grundgedanken entspricht. Natürlich sind Pakete eine feine Sache. Ob es die Entwicklung vorantreibt wage ich aber noch zu bezweifeln. Der Aufwand mit den Paketen ist erheblich größer. Ich denke das ist für unseren Zweck zu aufwändig da der Raspberry ja tatsächlich nur eine Sache machen muss und nicht wie normale Rechner in der Lage sein muss jede ihm zugedachter Aufgabe übernehmen zu müssen.

Ich verstehe natürlich den Frust wenn man Änderungen am Image vorgenommen hat und dann gehen Sie mit dem nächsten Release flöten. Dem kann man entgegen wirken in dem man die Änderungen sauber und ausführlich dokumentiert, so dass jeder diese nachvollziehen kann und bei Bedarf am eigenen Image durchführen kann.

Auf der anderen Seite habe ich aber auch eher die Leute im Blick die noch nie eine Konsole gesehen haben und selbst mit einem apt-get install nächstes-geiles-feature überfordert sind.

Wenn Du Dich der Herausforderung ein Repo zu erstellen annimmst unterstütze ich Dich dabei natürlich gerne so weit es mir möglich ist. Ich würde aber dennoch von Zeit zu Zeit ein fertiges Image bauen damit Endbenutzer es einfach haben ein PlugNPlay System ans laufen zu bekommen.

Den Quellcode des Webservers kann ich tatsächlich bei Git Hub einstellen. Aber mit der Installation von Nginx und befüllen des Webroot ist es nicht getan. Der Webserver muss z.B. in der Lage sein einige Kommandos per sudo auszuführen. Ich lasse Ihn daher als Benutzer Pi laufen, da der in der sudoers list steht. Wenn Du das mit Paketen hin bekommst sollte es eigentlich kein Problem sein. Für den Anfang wären gstreamer, nginx und mavproxy wichtig.
Eine Anleitung zum kompilieren des Gstreamer habe ich hier gepostet: http://fpv-community.de/showthread....ung-Telemetrie&p=672743&viewfull=1#post672743
 

Sledge

lonesome Cowboy
Habe bereits ne kleine Java Anwendung programmiert mit der ich einfach durch Regler den Stream bequem starten kan. Ist ähnlich wie ein RTSP Server. Läuft zurzeit unter Windows und Linux. Bin auch langsam dabei die Telemetrie Daten von Mavproxy aufzuarbeiten. Zieht sich jetzt alles weil ich am studieren bin. Wird aber noch nicht veröffentlicht. Vlt nächstes Jahr ;)
Coole Sache. Ein Programm für Windows/Linux PCs fehlt noch. Falls Du tatsächlich eins schreibst wäre es cool wenn Du auch die Webapi nutzt damit alles schön miteinander harmoniert. Der Webserver nimmt an http://airpi/api.php XML Dokumente mit Kommandos entgegen mit denen er dann die Pipes manipuliert, Streams startet usw. Im Gegenzug quittiert er mit einer XML den aktuellen Status des airpi und sendet alle Informationen in welchem Zustand sich der Airpi derzeit befindet. Ich werde die Api in den nächsten Tagen dokumentieren und ein paar Codeschnipsel zur Handhabung beifügen.
 

digaus

Erfahrener Benutzer
Sensless hat mir heute mal die iOS App zum Testen geschickt. Sie ist noch nicht ganz auf dem neusten Stand mit dem Image, aber den UDP Stream konnte ich schon anzeigen. Das ganze lief dann noch über WLAN und nicht über Ethernet, das heißt:
Raspberry Pi->Picostation->Picostation->Router(WLAN)->iPad
Das liegt daran, dass ich keinen aktiven USB Hub für den Ethernet Adapter habe.
Trotzdem habe ich eine Latenz von 110ms gemessen und die Verzögerung war spürbar geringer als mit der Android App.
IMG-20141110-WA0020.jpg
Wirklich super Arbeit, danke! Auch wenn ich hier wohl der einzige mit iOS bin...

Gruß
Daniel
 

Lonestar78

Erfahrener Benutzer
Ja auf die Latenz bin ich neidisch. Senseless hat nen super job gemacht und sich von gstreamer in seiner App verabschiedet. Ich schau mir irgendwann mal an, ob das gleiche auch mit Android umsetzbar ist.
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten