Low Cost HD-Video Übertragung + Telemetrie

Status
Nicht offen für weitere Antworten.

Constantin

Erfahrener Benutzer
Ich hatte den Herrn Stabernack zuletzt in 2012 in dieser Angelegenheit kontaktiert. Wir haben ein paar e-Mails gewechselt und aus der Sache ist damals nichts geworden. Mir ist noch in Erinnerung geblieben, dass die Lizensierungskosten SEHR hoch sind. Ansonsten hier noch ein paar technische Hinweise von ihm in Bezug auf den Codec:

Für PAL-Auflösung braucht er ca. 10 MBit/s Datenrate. Der Videostream darf nicht interlaced sein sondern muss progressive sein. Der Encoder/Decoder (ULLVC) selbst hat eine eigene Latenz von 5-10ms. Er hat auch noch einen anderen in petto (ELLVC) der ca. 40ms bei 1-2MBit/s hat. Das alles wie gesagt ist der Stand von 2012. vielleicht gibt es jetzt schon etwas Neues, aber irgendwie sieht die Website noch so aus wie damals.

Natuerlich ich bin froh wenn er mir antwortet...bei solchen Sachen habe ich die Erfahrung gemacht das trotz gut geschriebener e-mail am Anfang nix kommt ...nach der 2. Dann schon(auch wenn dies an steffan's lipo shop war-er ist jedoch sicher auch eine vielbeschäftigte person )
Fuer mich kommt bei so etwas nur open source infrage(also lizensgebühren usw kann ich mit meinem taschengeld nicht berappen :p mich wuerde interessieren wie dji dies bei ihrer lightbridge macht-wenn man die 300ms von denen sieht leisten sie's sich auch nicht) und dann interessiert mich natürlich auch einfach wie die's im Institut so ungefaehr machen. Fragen kostet nix ;)
 
Habe die Tage noch das Projekt hier gefunden:

AvrMiniCopter - Linux based controller project

Raspberry/Odroid-W + Arduino basierter Kopter mit Raspberry live Übertragung und Android App zum Steuern und Gucken.

https://github.com/rpicopter/AvrMiniCopter/wiki
http://www.rcgroups.com/forums/showthread.php?t=2302054

Jemand das schon probiert? Klingt für mich sehr interessant, da ich eben was kleines mit dem Odroid bauen wollte das dann auch die Flugsteuerung per WLAN übernimmt.

Ist wohl noch in den Kinderschuhen und wird wohl auch die selben Probleme mit Latenz etc.. haben, trotzdem sehr interessant wie ich finde.
 

hkubota

Neuer Benutzer
Hallo,

Wollte mich hier kurz melden. Bei meinen Nachforschungen wie man HD mit niedriger Latenz (<100ms) hinbekommen kann, bin ich mittlerweile zu dem Schluss gekommen dass das besondere Hardware-Fähigkeiten braucht: namentlich einen Frame-Grabber der das Bild sofort weiterleitet, also nicht erst ein Bild empfängt, und dann weitergibt. Ein FPGA wäre hier das Mittel zur Wahl. Steht mir nicht zur Verfügung. Ich sehe langsam dass Trevor mit der Transporter3D gute Arbeit geleistet hat.

Fertig kaufen geht, geht aber schnell in Richtung 4000 Euro. Für 1000 Euro gibt's 30m mit den integrierten Antennen.

Deshalb schliess ich mich hier an, aber weil ich schon immer etwas anders drauf war, wird's ein Banana Pi. Sollte in 2 Wochen hier sein. Mehr CPU Leistung bringt (hoffentlich) weniger Latenz. 1Gb/s Netzwerk anstelle von 100 Mb/s via USB auch. So die Theorie. Die Kamera ist ebenfalls via speziellem Interface. In jedem Fall mal interessant zu sehen wie das Teil gegen das Raspberry Pi macht. Weil ich immernoch mit Rift fahren/fliegen will, muss ich erstmal sehen wie ich das HD Bild in den Computer und speziell LiveViewRift bekomme. Habe bisher nichts besseres gefunden.

Das Low-Latency-HD (<1ms Latenz) muss wohl noch ein oder zwei Jahre brauchen bis die Preise in Hobby-freundlichen Regionen kommt.

Was ist hier die momentan beste Lösung fuer den Wifi Link? 802.11ac sieht gut aus. Mikrotik hat kleine Platinchen dafür. Benutzt die jemand? Taugen die für FPV?
 
Hallo,

Wollte mich hier kurz melden. Bei meinen Nachforschungen wie man HD mit niedriger Latenz (<100ms) hinbekommen kann, bin ich mittlerweile zu dem Schluss gekommen dass das besondere Hardware-Fähigkeiten braucht: namentlich einen Frame-Grabber der das Bild sofort weiterleitet, also nicht erst ein Bild empfängt, und dann weitergibt. Ein FPGA wäre hier das Mittel zur Wahl. Steht mir nicht zur Verfügung. Ich sehe langsam dass Trevor mit der Transporter3D gute Arbeit geleistet hat.

Fertig kaufen geht, geht aber schnell in Richtung 4000 Euro. Für 1000 Euro gibt's 30m mit den integrierten Antennen.

Deshalb schliess ich mich hier an, aber weil ich schon immer etwas anders drauf war, wird's ein Banana Pi. Sollte in 2 Wochen hier sein. Mehr CPU Leistung bringt (hoffentlich) weniger Latenz. 1Gb/s Netzwerk anstelle von 100 Mb/s via USB auch. So die Theorie. Die Kamera ist ebenfalls via speziellem Interface. In jedem Fall mal interessant zu sehen wie das Teil gegen das Raspberry Pi macht. Weil ich immernoch mit Rift fahren/fliegen will, muss ich erstmal sehen wie ich das HD Bild in den Computer und speziell LiveViewRift bekomme. Habe bisher nichts besseres gefunden.

Das Low-Latency-HD (<1ms Latenz) muss wohl noch ein oder zwei Jahre brauchen bis die Preise in Hobby-freundlichen Regionen kommt.

Was ist hier die momentan beste Lösung fuer den Wifi Link? 802.11ac sieht gut aus. Mikrotik hat kleine Platinchen dafür. Benutzt die jemand? Taugen die für FPV?
Zu deiner Umsetzung mit dem BananaPi: bist du dir sicher, dass einerseits die Kamera mittlerweile über CSI angesprochen werden kann und viel entscheidender, ob es einen Treiber für Hardware-h264-Encoding gibt?! Bei meiner letzten Recherche war das nicht der Fall. Ist das immer noch nicht so, kannst du ihn zumindest für diesen Zweck gleich wieder zurückschicken.

Latenz von < 1 ms halte ich für absolut utopisch (WLAN in jedem Fall). Außerdem solltest du dir dann jetzt schonmal anfangen Gedanken zu machen, wie du deine Kamera inklusive Encoder so baust, dass du schneller bist, als ein einzelnes Frame.
Abgesehen davon braucht kein Mensch ne Latenz von unter einigen 10 ms.

Bezüglich ac: ich würds nicht empfehlen. Durchsatz gibts auf kurzer Entfernung, aber auf langer wird das arg einbrechen. Schau dir nur einmal den Unterschied zwischen 256 QAM bei ac und 8 PSK bei gemächlicherem WLAN an.
 

hkubota

Neuer Benutzer
Zu deiner Umsetzung mit dem BananaPi: bist du dir sicher, dass einerseits die Kamera mittlerweile über CSI angesprochen werden kann und viel entscheidender, ob es einen Treiber für Hardware-h264-Encoding gibt?! Bei meiner letzten Recherche war das nicht der Fall. Ist das immer noch nicht so, kannst du ihn zumindest für diesen Zweck gleich wieder zurückschicken.
Sicher wie in "Ich weiss es weil ich hab's selber schon gemacht": Nein.
Aber http://wiki.lemaker.org/Camera_Module#Setting_up_the_B-Pi sagt dass es funktioniert.

Dekodieren von H.264: http://forum.lemaker.org/1822-1-1-1.html
und http://forum.lemaker.org/forum.php?mod=viewthread&tid=1707&page=

Und in der Tat konnte ich keinen H.264 Encoder finden ausser dieses: http://linux-sunxi.org/CedarX/Encoder. Damit ist das vielleicht ein Griff in's Klo, aber dekodieren geht wenigstens, und damit kann ich Plan B ausführen: Einen gesendeten H.264 Stream zu dekodieren, warpen und auf der Rift darstellen. Mal sehen ob ich gstreamer zum laufen bekomme auf dem Banana Pi...

Latenz von < 1 ms halte ich für absolut utopisch (WLAN in jedem Fall). Außerdem solltest du dir dann jetzt schonmal anfangen Gedanken zu machen, wie du deine Kamera inklusive Encoder so baust, dass du schneller bist, als ein einzelnes Frame.
Abgesehen davon braucht kein Mensch ne Latenz von unter einigen 10 ms.
Ich weiss nicht genau wie sie's machen, aber das wird angegeben als Latenz. Und ich kann mir schon vorstellen wie das funktioniert: 10 Zeilen einscannen, dann encoden, eine Zeile rausschicken, eine Zeile einscannen, encoden, eine Zeile rausschicken. Latenz: 10 Zeilen. 0.2ms Latenz hier (bei 45kHz horiz. Ablenkfrequenz). Plus Encoder- und WLAN-Overhead.

Das funktioniert nicht mit Hausmitteln, daher auch die Hobby-unfreundlichen Preise. Wer's braucht (Profis die Geld damit verdienen), zahlt's.

Bezüglich ac: ich würds nicht empfehlen. Durchsatz gibts auf kurzer Entfernung, aber auf langer wird das arg einbrechen. Schau dir nur einmal den Unterschied zwischen 256 QAM bei ac und 8 PSK bei gemächlicherem WLAN an.
Ist das Erfahrungswert? Ich dachte ac macht Multipath nützlich und man kann damit linear-polarisations Antennen benutzen (man hat ja mindestens 2 für das einfachste MIMO). Aus einem schlauen Buch:

In the past, data corruption of 802.11a/b/g transmission caused by multipath had to be dealt with, and using unidirectional antennas to cut down on reflections was commonplace in high-multipath indoor environments. Now that MIMO technology used by 802.11n and 802.11ac radios is commonplace, multipath is now our friend..."

Naja, wie so oft: das ist Theorie und es wird sich zeigen ob das funktioniert. Draussen ist ja nicht drinnen, und wenn ich Richtantennen (oder Sektorantennen) Empfängerseitig benutzen kann, ist das eh wahrscheinlich "unchartered territories". Ich jedenfalls werde mir ein Paar Mikrotik Routersn besorgen und testen. Plan B ist die Zuhause zu benutzen in meinem "high-multipath indoor environment" :)

Harald
 
Sicher wie in "Ich weiss es weil ich hab's selber schon gemacht": Nein.
Aber http://wiki.lemaker.org/Camera_Module#Setting_up_the_B-Pi sagt dass es funktioniert.

Dekodieren von H.264: http://forum.lemaker.org/1822-1-1-1.html
und http://forum.lemaker.org/forum.php?mod=viewthread&tid=1707&page=

Und in der Tat konnte ich keinen H.264 Encoder finden ausser dieses: http://linux-sunxi.org/CedarX/Encoder. Damit ist das vielleicht ein Griff in's Klo, aber dekodieren geht wenigstens, und damit kann ich Plan B ausführen: Einen gesendeten H.264 Stream zu dekodieren, warpen und auf der Rift darstellen. Mal sehen ob ich gstreamer zum laufen bekomme auf dem Banana Pi...
Okay, das klingt schonmal ganz gut. Dann nichts für ungut, hab schon länger nicht mehr geguckt, ob es da mittlerweile was gibt. Bin ich ja mal gespannt, ob du es ans laufen bekommst.

Ich weiss nicht genau wie sie's machen, aber das wird angegeben als Latenz. Und ich kann mir schon vorstellen wie das funktioniert: 10 Zeilen einscannen, dann encoden, eine Zeile rausschicken, eine Zeile einscannen, encoden, eine Zeile rausschicken. Latenz: 10 Zeilen. 0.2ms Latenz hier (bei 45kHz horiz. Ablenkfrequenz). Plus Encoder- und WLAN-Overhead.

Das funktioniert nicht mit Hausmitteln, daher auch die Hobby-unfreundlichen Preise. Wer's braucht (Profis die Geld damit verdienen), zahlt's.
Na dann kann man sich das auch gleich schenken zu codieren. Es sei dann man übertreibt den Aufwand vollends, und implementiert trotzdem Interframe-Codierung.
Wenn ich mir aber mal so einen Ping von meiner aktuellen WLAN-Strecke ansehe, dann kam ich WIMRE auf irgendwas mit 3 ms. Also damit dürfte das nichts geben denke ich, es sei den Ping macht irgendnen Quark, der während des Streamens nicht passiert, keine Ahnung. Müsste man wenn was selber basteln, in dem möglichst wenig FIFOs drin sind und nichts gebuffert wird...

Nebenbei braucht aber auch kein Profi dieser Welt Latenzen von weniger als 1 ms. Wenn du deinen Kram ans Laufen bekommst, wirst du merken, was ich meine: Mach deine Hand vor der Kamera, die neben dem Bildschirm steht, auf und zu und du wirst bei einer Latenz von ~90 ms (zumindest bei mir) nicht sehen, dass deine echte Hand schneller auf oder zu ist, als auf dem Bildschirm.

Ist das Erfahrungswert? Ich dachte ac macht Multipath nützlich und man kann damit linear-polarisations Antennen benutzen (man hat ja mindestens 2 für das einfachste MIMO). Aus einem schlauen Buch:

In the past, data corruption of 802.11a/b/g transmission caused by multipath had to be dealt with, and using unidirectional antennas to cut down on reflections was commonplace in high-multipath indoor environments. Now that MIMO technology used by 802.11n and 802.11ac radios is commonplace, multipath is now our friend..."

Naja, wie so oft: das ist Theorie und es wird sich zeigen ob das funktioniert. Draussen ist ja nicht drinnen, und wenn ich Richtantennen (oder Sektorantennen) Empfängerseitig benutzen kann, ist das eh wahrscheinlich "unchartered territories". Ich jedenfalls werde mir ein Paar Mikrotik Routersn besorgen und testen. Plan B ist die Zuhause zu benutzen in meinem "high-multipath indoor environment" :)

Harald
Nein, ist kein Erfahrungswert, auch nur Theorie, hätte ich vielleicht dabei sagen sollen. Aber wie du schon richtig sagst, ist Mehrwegeausbreitung auf dem Feld glaube ich weniger ein Problem, als eben indoor. Daher glaube ich nicht, dass einem das große Vorteile bringt. Außerdem passt die Robustheit und Durchsatz in meinem Kopf einfach nicht zusammen, aber ich lasse mich gerne eines besseren belehren. Beschwer dich nachher nur nicht, dich hätte keiner gewarnt, wenn es nichts gibt ;)
 
Schaut sehr gut aus, bin auf das Projekt echt gespannt!
Die Platine könnte für auf den Odroid-W was groß sein, aber es ist ja auch "nur" ein Breakout/Shield wenn ich das richtig sehe oder?

Ist die Ausgabe über einen extra Arduino besser/genauer als direkt über die IOs des Raspberrys?
PPM sollte der doch auch schaffen oder?

Gruß
Johannes
 
Zuletzt bearbeitet:

JR63

Erfahrener Benutzer
Schaut sehr gut aus, bin auf das Projekt echt gespannt!
Vielen Dank.


Die Platine könnte für auf den Odroid-W was groß sein, aber es ist ja auch "nur" ein Breakout/Shield wenn ich das richtig sehe oder?
Ja, für diese Platine hatte ich definitiv erstmal den Raspberry Pi B+ und A+ angedacht.

Nach meinen Infos soll der Odroid-W ja abgekündigt sein.
Falls doch nicht, könnte ich ja die Platine mal auf den Odroid-W Formfaktor umdesignen.


Ist die Ausgabe über einen extra Arduino besser/genauer als direkt über die IOs des Raspberrys?
PPM sollte der doch auch schaffen oder?

Kurz: Ja.

Bei meinem ersten Video hier im Thread, mit der Demo des Systems auf einem RC-Car, habe ich die Servos tatsächlich vom RasPi direkt angesteuert.
Allerdings gab es da immer mal wieder ein kurzes Zucken der Servos weil die PWM Erzeugung nicht absolut sauber lief.


Ein Arduino hat mehrere Vorteile:

PPM/PWM per Interrupt mit einer Auflösung von 1 micro Sekunde mit 8 PWM und bis zu 12 Kanälen über PPM

unabhängiges, 2 stufiges, frei konfigurierbares Failsafe

6 ADC


Aktuell ist neben den 8 PWM und der 12 Kanal PPM auch schon ein Telemetrie Rückkanal implementiert.


Übertragen werden:
GPS Daten (folgende Protokolle werden unerstützt: NMEA, UBX, DJI proprietär)
6 ADC Roh Werte


Darüberhinaus kann man konfiurieren ob und in welchen Intervallen diese Daten auf per USB verbundene Speichermedien geschrieben werden sollen.


Tschö
JR
 
Ja, sicher, mit dem Arduino hast mehr Möglichkeiten, schön was ihr da alles implementiert, nur sind es dann eben schon Raspberry, Arduino und Flightcontrol auf dem Kopter.

Normal kein Problem, nur wollte ich mit dem Odroid-W eigentlich nen kleinen, leichten Kopter bauen. So in der 300 max 400g Klasse., 5" und 2S mit HD Übertragung. Denke ich versuche dann erstmal den AVRMiniKopter. Wenn das nicht klappt dann kann ich immer noch eure Lösung nehmen mit nem pro-mini als Adapter und AfroMini als FC oder so.

Das Odroid-W is abgekündigt, ja, hardkernel bekommt keine Chips mehr von Broadcom, ich hab aber 2 hier liegen. Die 26 Pin IO Leiste is ja eh kompatibel mit den Rasps.


Verfolgt jemand das OpenFPV Projekt? Er scheint ja mit den 20€ Ralink Dongles ganz gute Erfahrung gemacht zu haben:
http://diydrones.com/profiles/blogs/openfpv-update-2-roadmap-for-2015-oculus-rift-support-5ghz
 
Zuletzt bearbeitet:

Sledge

lonesome Cowboy
Schöne Platine JR. So lange im Quellcode keine typos sind ist alles halb so wild :) Mir persönlich sind die paar extra Gramm für den Arduino lieber. Bei einem Stubenkopter braucht man wahrscheinlich kein Failsafe aber für anspruchsvollere Anwendungen kommt man da nicht drum herum. Sobald ich wieder etwas Luft habe baue ich den PiInMotion nach und mache ein paar Tests. Wenn alles klappt wird die PiInMotion Config in die AirPiControl (Webfrontend) integriert.

Wie ist das ganze denn auf der Steuerseite gelöst? Raspberry + PiInMotion an der Funke und ein Lan Kabel zum Ubiquity?
Ein Träumchen wäre es nur den PiInMotion mit BT Modul im Modulschacht der Funke zu verstauen und dann am GroundPi/ GroundPhone/Groundirgendwas das BT ins Netzwerk zu speißen.
 
Ein Träumchen wäre es nur den PiInMotion mit BT Modul im Modulschacht der Funke zu verstauen und dann am GroundPi/ GroundPhone/Groundirgendwas das BT ins Netzwerk zu speißen.
Brrr BT für die Steuerung...dann doch lieber n kleinen PPM Empfänger zum Speisen der PiInMotion am Boden und so drahtlos an die Funke - so brauchst an der auch nix zu ändern.
 

Sledge

lonesome Cowboy
Dann hast Du aber wieder ein 2,4 ghz TX im Spiel und genau das galt es ja zu vermeiden. BT läuft zwar auch über 2.4 ghz, stört sich aber nicht am Wlan. Alternativ könnte man auch eines der vielen Telemetrie Module zweckentfremden aber BT sollte das eigentlich auch hinbekommen.
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten