Low Cost HD-Video Übertragung + Telemetrie
- Themenstarter Lonestar78
- Beginndatum
- Status
Moin zusammen,
ich dachte mir, ich melde mich auch mal wieder, nachdem ich aus privaten Gründen in den letzten Wochen verhindert war.
Danke für dein Feedback und es freut mich zu hören, dass auch auf deinem Device die Latenz in einem sehr guten Bereich liegt. Damit bin ich mir jetzt ziemlich sicher, dass die Latenz auf allen iOS-Devices, für die iOS 8 verfügbar ist (wegen direktem Zugriff auf den HW-Decoder), ziemlich ähnlich gut sein wird.
Für die Kritiker von damals ist das ja dann jetzt der Beweis, dass es nicht nur bei mir so gut funktioniert.
Was willst du denn genau wissen? Die eine Verbesserungen, die ich vorgenommen habe, ist eben den HW-Decoder zu verwenden, was die CPU natürlich erheblich entlastet. HEAD im GStreamer-SDK kann es nun auch schon seit ein paar Wochen, den HW-Decoder zu verwenden. Allerdings steigt die Latenz damit auf über 300 ms. Die bei mir aktuelle Latenz ist ja nun hinreichend bekannt. Des Weiteren empfange ich den UDP-RTP-Stream selber, entpacke ihn und massiere die Bits so, dass der HW-Decoder was mit anfangen kann. Damit konnte ich mich also ganz von GStreamer verabschieden. Das hat dann auch noch einmal die CPU-Auslastung mindestens halbiert.
Ansonsten frag gerne nach, wenn irgendwas noch nicht klar sein sollte.
Hier muss ich hornetwl meine Zustimmung aussprechen. Es wäre wirklich wesentlich eleganter, wenn man dies so handhaben würde. Allerdings würde ich mich an der Stelle auch gleich von dem blöden Raspbian verabschieden, und auf Arch umsteigen. Es ist wesentlich sauberer (denn X braucht man in der Luft zB einfach nicht) und man bekommt sehr viel aktuellere Pakete. Zum Beispiel ist GStreamer bei Arch mit der aktuellen Version drin.
Dabei werde ich auch direkt noch einmal meine Idee los, den ganzen aktuellen Murks mit den IP-Adressen mit einer Zeroconf-Implementierung (Avahi/Bonjour) zu erschlagen. Das sprach ich schon einmal intern an, aber es blieb leider ohne Resonanz. Vielleicht spricht sich hier ja auch noch jemand dafür aus, sodass man mal einen Gedanken daran 'verschwendet'.
Denn leider habe ich aktuell nicht die Zeit, mich auch noch um die air-Seite zu kümmern; die App kostet mich bisher genug Zeit und Nerven. Außerdem finde ich es auch blöd, wenn man hier ein zweites Lager aufmachen würde, das sich dann nur mit dem ersten bekriegen wird.. Andererseits, Konkurrenz belebt das Geschäft
Und ansonsten, Glückwunsch Lonestar zu deinem Start im Play Store. Bitte im Übrigen für die Idee mit dem Einstellen der Parameter für raspivid in der App
ich dachte mir, ich melde mich auch mal wieder, nachdem ich aus privaten Gründen in den letzten Wochen verhindert war.
Danke für dein Feedback und es freut mich zu hören, dass auch auf deinem Device die Latenz in einem sehr guten Bereich liegt. Damit bin ich mir jetzt ziemlich sicher, dass die Latenz auf allen iOS-Devices, für die iOS 8 verfügbar ist (wegen direktem Zugriff auf den HW-Decoder), ziemlich ähnlich gut sein wird.
Für die Kritiker von damals ist das ja dann jetzt der Beweis, dass es nicht nur bei mir so gut funktioniert.
Was willst du denn genau wissen? Die eine Verbesserungen, die ich vorgenommen habe, ist eben den HW-Decoder zu verwenden, was die CPU natürlich erheblich entlastet. HEAD im GStreamer-SDK kann es nun auch schon seit ein paar Wochen, den HW-Decoder zu verwenden. Allerdings steigt die Latenz damit auf über 300 ms. Die bei mir aktuelle Latenz ist ja nun hinreichend bekannt. Des Weiteren empfange ich den UDP-RTP-Stream selber, entpacke ihn und massiere die Bits so, dass der HW-Decoder was mit anfangen kann. Damit konnte ich mich also ganz von GStreamer verabschieden. Das hat dann auch noch einmal die CPU-Auslastung mindestens halbiert.
Ansonsten frag gerne nach, wenn irgendwas noch nicht klar sein sollte.
Hier muss ich hornetwl meine Zustimmung aussprechen. Es wäre wirklich wesentlich eleganter, wenn man dies so handhaben würde. Allerdings würde ich mich an der Stelle auch gleich von dem blöden Raspbian verabschieden, und auf Arch umsteigen. Es ist wesentlich sauberer (denn X braucht man in der Luft zB einfach nicht) und man bekommt sehr viel aktuellere Pakete. Zum Beispiel ist GStreamer bei Arch mit der aktuellen Version drin.
Dabei werde ich auch direkt noch einmal meine Idee los, den ganzen aktuellen Murks mit den IP-Adressen mit einer Zeroconf-Implementierung (Avahi/Bonjour) zu erschlagen. Das sprach ich schon einmal intern an, aber es blieb leider ohne Resonanz. Vielleicht spricht sich hier ja auch noch jemand dafür aus, sodass man mal einen Gedanken daran 'verschwendet'.
Denn leider habe ich aktuell nicht die Zeit, mich auch noch um die air-Seite zu kümmern; die App kostet mich bisher genug Zeit und Nerven. Außerdem finde ich es auch blöd, wenn man hier ein zweites Lager aufmachen würde, das sich dann nur mit dem ersten bekriegen wird.. Andererseits, Konkurrenz belebt das Geschäft
Und ansonsten, Glückwunsch Lonestar zu deinem Start im Play Store. Bitte im Übrigen für die Idee mit dem Einstellen der Parameter für raspivid in der App
Zuletzt bearbeitet:
Achso, okay. Ich weiß zwar nicht, was BCM ist, aber ich kann dir sagen, was ich mache.
Das hängt aber natürlich auch massiv davon ab, in welchem Format der HW-Decoder die NALUs haben möchte.
Einmal muss man natürlich schauen, was für ein NALU-Type man hat. Wichtig für den Decoder sind natürlich erstmaldie Formatinformationen. Die kommen bekanntlichermaßen ja als SPS und PPS an. Ansonsten werden die reinen Slice-Daten in dem Fall hier normalerweise fragmentiert angeliefert. Im Standard heißen die Teile FUs und sind hier vom Typ A. Darin kannst du dir Start- und Stop-Bits angucken und daraus dann einen ganzen Frame zusammenbasteln. Ich muss dann noch das eigentliche Startbyte 0x00 0x00 0x00 0x01 ersetzen durch die Länge der eigentlichen Payload (siehe dazu auch hier meine Frage auf Stackoverflow; allerdings habe ich hier noch GStreamer verwendet, was ja für das oben geschriebene nicht mehr stimmt), damit mein HW-Decoder damit was anfangen kann. Wie gesagt kommt das jetzt natürlich stark darauf an, in welchen HW-Decoder du das schieben willst.
Das hängt aber natürlich auch massiv davon ab, in welchem Format der HW-Decoder die NALUs haben möchte.
Einmal muss man natürlich schauen, was für ein NALU-Type man hat. Wichtig für den Decoder sind natürlich erstmaldie Formatinformationen. Die kommen bekanntlichermaßen ja als SPS und PPS an. Ansonsten werden die reinen Slice-Daten in dem Fall hier normalerweise fragmentiert angeliefert. Im Standard heißen die Teile FUs und sind hier vom Typ A. Darin kannst du dir Start- und Stop-Bits angucken und daraus dann einen ganzen Frame zusammenbasteln. Ich muss dann noch das eigentliche Startbyte 0x00 0x00 0x00 0x01 ersetzen durch die Länge der eigentlichen Payload (siehe dazu auch hier meine Frage auf Stackoverflow; allerdings habe ich hier noch GStreamer verwendet, was ja für das oben geschriebene nicht mehr stimmt), damit mein HW-Decoder damit was anfangen kann. Wie gesagt kommt das jetzt natürlich stark darauf an, in welchen HW-Decoder du das schieben willst.
Ok, danke für die Info.
BCM steht für Broadcom, das ist die Company, welche den SoC des RasPi entwickelt hat:
http://www.broadcom.com/products/BCM2835
Tschö
JR
BCM steht für Broadcom, das ist die Company, welche den SoC des RasPi entwickelt hat:
http://www.broadcom.com/products/BCM2835
Tschö
JR
Ach...So viel zu tun und sowenig Zeit.
Also grundsätzlich sind wir glaube ich gedanklich so unterwegs gewesen: Erstmal eine funktionsfähige Variante haben, die im großen und ganzen stabil läuft. Stabil heisst in diesem Kontext: Während des Streamings keine unerwarteten Überraschungen. Eine nicht startende App ist blöd, aber keine unerwartete Überraschung im Flug.
Ich bin auch dabei:
-Pakete wären sicher super. Wie immer: freundliche Unterstützer gesucht.
-Zeroconf schau ich mir auch an. Wäre mittelfristig sicher ne gute Sache.
-Latenzverringerung durch Abschaffung GStreamer steht auf der Liste der Wünsche für die Android App
- Cardboard-Unterstützung (Kein großer Akt, zumindest nicht mit GStreamer)
- Debuggung
- Headtracker (Läuft grundsätzlich auch schon)
- ....
Ist halt ein Hobby-Projekt. Insofern: Wir kriegen das schon hin Kollegen.
Also grundsätzlich sind wir glaube ich gedanklich so unterwegs gewesen: Erstmal eine funktionsfähige Variante haben, die im großen und ganzen stabil läuft. Stabil heisst in diesem Kontext: Während des Streamings keine unerwarteten Überraschungen. Eine nicht startende App ist blöd, aber keine unerwartete Überraschung im Flug.
Ich bin auch dabei:
-Pakete wären sicher super. Wie immer: freundliche Unterstützer gesucht.
-Zeroconf schau ich mir auch an. Wäre mittelfristig sicher ne gute Sache.
-Latenzverringerung durch Abschaffung GStreamer steht auf der Liste der Wünsche für die Android App
- Cardboard-Unterstützung (Kein großer Akt, zumindest nicht mit GStreamer)
- Debuggung
- Headtracker (Läuft grundsätzlich auch schon)
- ....
Ist halt ein Hobby-Projekt. Insofern: Wir kriegen das schon hin Kollegen.
Hi Sledge,
da bin ich schon dran und hatte heute früh meine ersten Probefahrten mit meinem HobbyKing 1/10 Test-SCT.
Momentan sieht es so aus:
RC-Sender - PPM - Arduino - I2C - RasPi - UDP - Ubi ---- Air ---- Ubi - UDP - RasPi - GPIO - PWM
Soll aber künftig so aussehen, wenn der zweite Arduino eingetroffen ist:
RC-Sender - PPM - Arduino - I2C - RasPi - UDP - Ubi ---- Air ---- Ubi - UDP - RasPi - I2C - Arduino - PPM und/oder PWM
Das Ganze natürlich schon mit Failsafe.
Das GroundRecording ist per SD-Recorder am Analog-Out der Ground-Station entstanden, HD GroundRecording kann ich noch nicht aufzeichnen.
Ab 1:35 geht es los
http://youtu.be/riZqJue6dfk
Tschö
JR
Hä, warum willst du das denn machen?
Ich meine der HW-Dec des VC4 ist doch mit gst-omx schon länger in GStreamer verwendbar. Hat es da auch so hohe Latenzen wie beim frisch eingebauten HW-Dec in iOS? Als ich das mal probiert hatte, meine ich war das nicht der Fall. Und das Senken der CPU-Last ist bei der GroundStation mit Pi doch auch vollkommen wurst.
Ich meine der HW-Dec des VC4 ist doch mit gst-omx schon länger in GStreamer verwendbar. Hat es da auch so hohe Latenzen wie beim frisch eingebauten HW-Dec in iOS? Als ich das mal probiert hatte, meine ich war das nicht der Fall. Und das Senken der CPU-Last ist bei der GroundStation mit Pi doch auch vollkommen wurst.
Danke Sledge.
Tja, da bin ich aktuell aus folgendem Grund etwas unentschlossen:
Die Chinesen benutzen seit Kurzem meinen OpenSource minNAZAOSD Code und kommerzialisieren diesen Code was eindeutig gegen die GNU GPL v3 verstößt.
Wer mein hier in der FPV-C und auf RCG veröffentlichtes minNAZAOSD Projekt kennt und auch den RCG Thread etwas mitverfolgt, hat vielleicht mitbekommen, dass die Chinesen meinen minNAZAOSD Code bzw. das hex-File einfach genommen haben und in eine Hardware flashen.
Dabei besteht diese Hardware genau aus meinen Ideen, dass z.B. EIN Atmega 328p + MAX7345 genügt um ein NAZA OSD zu realisieren, im Gegensatz zu den anderen Lösungen mit ZWEI Atmega 328p.
Auch meine (kleine aber bei genauer Betrachtung gerade darum so feine) Idee der Abfrage der NAZA LED per 3fach Spannungsteiler und nur EINEM ADC wurde dort kopiert.
Des weiteren Radar, AF etc....
Und das alles ohne Nachfrage bei mir oder einer Namensnennung, sogar noch schlimmer: Die nennen das Teil fälschlicher Weise '... iOSD Remzibi OSD ...' wenn die wenigstens bei minNAZAOSD geblieben wären...
http://www.rcgroups.com/forums/showpost.php?p=29788036&postcount=950
http://www.rcgroups.com/forums/showpost.php?p=29796246&postcount=962
Das hat mich sehr demotiviert meinen Code weiterhin OpenSource zu deklarieren; man hat Ideen, programmiert sich 'nen Wolf und 'die' nehmen es einfach her und verdienen Geld und man selber wird noch nicht einmal erwähnt!
Vielleicht hat ja jemand eine Idee wie man sich dagegen schützen kann?
Irgend etwas in der Art wie hier aktuell ja leider auch der Code der Android App und wohl auch der iOS App nicht (mehr) OpenSource ist, sondern die Apps per Shop verteilt werden.
Dabei muss ich ganz klar sagen, dass ich kein Problem mit den 1,99€ für die App habe.
Im Gegenteil, ich denke die ist eher > 10€ wert.
Software wird total unterbewertet weil nur wenige wirklich wissen wieviel Wissen, Ideen und Zeit da drin stecken und wenn man bedenkt wieviel sonst so für den ganzen Hardware Kram ausgegeben wird.
Tschö
JR
Tja, da bin ich aktuell aus folgendem Grund etwas unentschlossen:
Die Chinesen benutzen seit Kurzem meinen OpenSource minNAZAOSD Code und kommerzialisieren diesen Code was eindeutig gegen die GNU GPL v3 verstößt.
Wer mein hier in der FPV-C und auf RCG veröffentlichtes minNAZAOSD Projekt kennt und auch den RCG Thread etwas mitverfolgt, hat vielleicht mitbekommen, dass die Chinesen meinen minNAZAOSD Code bzw. das hex-File einfach genommen haben und in eine Hardware flashen.
Dabei besteht diese Hardware genau aus meinen Ideen, dass z.B. EIN Atmega 328p + MAX7345 genügt um ein NAZA OSD zu realisieren, im Gegensatz zu den anderen Lösungen mit ZWEI Atmega 328p.
Auch meine (kleine aber bei genauer Betrachtung gerade darum so feine) Idee der Abfrage der NAZA LED per 3fach Spannungsteiler und nur EINEM ADC wurde dort kopiert.
Des weiteren Radar, AF etc....
Und das alles ohne Nachfrage bei mir oder einer Namensnennung, sogar noch schlimmer: Die nennen das Teil fälschlicher Weise '... iOSD Remzibi OSD ...' wenn die wenigstens bei minNAZAOSD geblieben wären...
http://www.rcgroups.com/forums/showpost.php?p=29788036&postcount=950
http://www.rcgroups.com/forums/showpost.php?p=29796246&postcount=962
Das hat mich sehr demotiviert meinen Code weiterhin OpenSource zu deklarieren; man hat Ideen, programmiert sich 'nen Wolf und 'die' nehmen es einfach her und verdienen Geld und man selber wird noch nicht einmal erwähnt!
Vielleicht hat ja jemand eine Idee wie man sich dagegen schützen kann?
Irgend etwas in der Art wie hier aktuell ja leider auch der Code der Android App und wohl auch der iOS App nicht (mehr) OpenSource ist, sondern die Apps per Shop verteilt werden.
Dabei muss ich ganz klar sagen, dass ich kein Problem mit den 1,99€ für die App habe.
Im Gegenteil, ich denke die ist eher > 10€ wert.
Software wird total unterbewertet weil nur wenige wirklich wissen wieviel Wissen, Ideen und Zeit da drin stecken und wenn man bedenkt wieviel sonst so für den ganzen Hardware Kram ausgegeben wird.
Tschö
JR
Wenn Du möchtest dass sich ggf. Leute beteiligen können, es aber unter Kontrolle bleiben soll, hat sich bei uns ein "private" github repository bewährt. Alle die mitmachen wollen sind dann namentlich bekannt und ansonsten bleibt es closed. Wie Du schon sagst, die Leute wissen um den Wert der Software meist nicht.
Ich zahle auch gerne für Apps, oder spende wenn es keine Kaufoption gibt. Als Java-Entwickler weiß ich ja was da manchmal für ne Arbeit drin steckt. Wenn ich bedenke was mein Chef abrechnet für ne mobile App, von nativ mal garnicht geredet
Ich zahle auch gerne für Apps, oder spende wenn es keine Kaufoption gibt. Als Java-Entwickler weiß ich ja was da manchmal für ne Arbeit drin steckt. Wenn ich bedenke was mein Chef abrechnet für ne mobile App, von nativ mal garnicht geredet
Wie kommst Du darauf, dass das gegen die GPLv3 verstoesst?
Das ist definitiv erlaubt, sofern die Nebenbedinungenen eingehalten werden (Aenderungen offenlegen, auf Lizenz hinweisen, Patentbestimmungen, etc.). Wenn Du das ausschliessen willst, musst Du eine andere Lizenz verwenden (z.B. CC-BY-NC) oder irgendwelche Kernbestandteile patentieren (viel Spass...)
Das ist definitiv erlaubt, sofern die Nebenbedinungenen eingehalten werden (Aenderungen offenlegen, auf Lizenz hinweisen, Patentbestimmungen, etc.). Wenn Du das ausschliessen willst, musst Du eine andere Lizenz verwenden (z.B. CC-BY-NC) oder irgendwelche Kernbestandteile patentieren (viel Spass...)
Sledge, spricht eigentlich irgendwas dagegen, mit den Paketen von vornherein auf Jessie statt Wheezy zu setzen? Wird eh demnächst die neue Stable werden. Dann ist nämlich der erste nervige Teil bereits erledigt - gstreamer 1.4.3 befindet sich im Lieferumfang.
Sofern eurerseits da noch keine (negativen) Erfahrungen damit vorliegen, schau ich mal ob der mitgelieferte GStreamer taugt.
Sofern eurerseits da noch keine (negativen) Erfahrungen damit vorliegen, schau ich mal ob der mitgelieferte GStreamer taugt.
Zuletzt bearbeitet:
Im Grunde spricht da nichts dagegen. Die Hauptarbeit liegt auch nicht bei den Paketen. Bisher sind im Endeffekt nur Gstreamer und Nginx installiert. Die Hauptarbeit lag und liegt beim Airpi am Webserver, der die Dienste steuert und eine Api bietet um mit den Clients zu kommunizieren. Letztendlich ist es eigentlich egal auf welchem Betriebssystem das ganze läuft oder welche Gstreamer Version installiert ist. Das macht dann höchstens was an der Latenz aus. Es muss nur alles richtig konfiguriert werden damit auch alles sauber ineinander greift. Der Webserver braucht z.B. sudo Rechte damit er Prozesse killen kann. Man könnte natürlich einfach den user http zur sudoers List hinzufügen, ich lasse den Webserver aber als user pi laufen welcher sudoer ist. Spielt beides eigentlich keine Rolle so lange der Pi in einem abgeschotteten Netzwerk läuft.
Mein Hauptaugenmerk liegt auf dem Webserver und künftigen Erweiterungen. Das Image ist nur Beiwerk um es jedem einfach zugänglich zu machen. Momentan kann man 5 Pipes speichern/auswählen/starten/stoppen, Den Raspberry herunterfahren/booten und das ganze ist über die Api via xml Kommandos auch für externe Programme möglich.
Geplante Erweiterungen sind:
- Steuerung über Wlan (Ich habe gerade mit JR telefoniert und ich denke wir finden da eine Lösung)
- Telemetriedaten (Mavproxi ist easy, Naza & Co eine Herausforderung aber auch da hat JR evtl. etwas parat)
- Antennentracking anhand der Telemetriedaten
- Headtracking (Da ist Lonestar schon dran)
- Joystick support
und was uns mit der Zeit sonst noch so einfällt.
Ein Github für den PHP Quellcode macht sicher Sinn. Ich werde das ganze auch sauber dokumentieren damit sicher jeder sein Lieblingssystem zurecht biegen kann. Mit Paketen für Gstreamer usw. möchte ich mich aber nicht wirklich rumschlagen. Zeit ist knapp und irgendwann soll es ja auch mal fertig werden Da ich hier ohnehin mit einem Produktiv System arbeite ist es sehr simpel von Zeit zu Zeit ein Image zu posten auf dem alle Dienste laufen. Damit ist den Linux Anfängern auch am ehesten geholfen.
Es wäre halt schön, wenn jemand der das ganze auf Arch, Jessie oder was auch immer portet eine Doku zum Lösungsweg schreibt. Ich kann das dann auch gerne auf die Homepage packen damit es zentral abrufbar ist.
Mein Hauptaugenmerk liegt auf dem Webserver und künftigen Erweiterungen. Das Image ist nur Beiwerk um es jedem einfach zugänglich zu machen. Momentan kann man 5 Pipes speichern/auswählen/starten/stoppen, Den Raspberry herunterfahren/booten und das ganze ist über die Api via xml Kommandos auch für externe Programme möglich.
Geplante Erweiterungen sind:
- Steuerung über Wlan (Ich habe gerade mit JR telefoniert und ich denke wir finden da eine Lösung)
- Telemetriedaten (Mavproxi ist easy, Naza & Co eine Herausforderung aber auch da hat JR evtl. etwas parat)
- Antennentracking anhand der Telemetriedaten
- Headtracking (Da ist Lonestar schon dran)
- Joystick support
und was uns mit der Zeit sonst noch so einfällt.
Ein Github für den PHP Quellcode macht sicher Sinn. Ich werde das ganze auch sauber dokumentieren damit sicher jeder sein Lieblingssystem zurecht biegen kann. Mit Paketen für Gstreamer usw. möchte ich mich aber nicht wirklich rumschlagen. Zeit ist knapp und irgendwann soll es ja auch mal fertig werden
Da ich hier ohnehin mit einem Produktiv System arbeite ist es sehr simpel von Zeit zu Zeit ein Image zu posten auf dem alle Dienste laufen. Damit ist den Linux Anfängern auch am ehesten geholfen.Es wäre halt schön, wenn jemand der das ganze auf Arch, Jessie oder was auch immer portet eine Doku zum Lösungsweg schreibt. Ich kann das dann auch gerne auf die Homepage packen damit es zentral abrufbar ist.
digaus: made my day!
Edit: Digaus: Sag mal, ab welchem RSSI Wert wird die Fliegerei denn schlecht?
Edit: Digaus: Sag mal, ab welchem RSSI Wert wird die Fliegerei denn schlecht?
Edit:
So, hier das Video. Da ich es mit dem Xperia Z2 über die GPU aufnehmen konnte, hat es jetzt auch höhere FPS:
https://www.youtube.com/watch?v=3xBZrEmoGCE
Im Video sieht man, dass ich auch mit nem RSSI von 26 keinerlei Artefakte habe. Aber wenn ich z.B hinter einem Baum herfliege, bleibt RSSI gleich aber ich bekomme starke Artefakte(bei 5:35).
Hier war der AirPi dann auch kurzzeitig offline.
Zuletzt bearbeitet:
- Status
