Low Cost HD-Video Übertragung + Telemetrie

UPDATE 8.11.2014:
neue App, neues Image, siehe b)

Post geteilt in a) Motivation + b) Tutorial

a) Motivation

Hallo Zusammen,

ich starte hier mal ein Projekt zum Thema "Low Cost Full HD FPV mit Telemetrie und OSD".
Die Idee wäre ja, damit genauso einen Gamechanger zu erzeugen, wie mit dem Thema Brushlessgimbal vor 1,5Jahren...Achja, gibts noch Servo Gimbals?
Auch hier: Ziel Open Source....

Motviert durch die Lightbridge von DJI habe ich angefangen, zu suchen, was es da im Moment so gibt.
Gestossen bin ich auf das hier, Raspberry Pi basiert:
http://diydrones.com/profiles/blogs/fpv-setup-with-raspberry-pi
Zusammengefasst:
- Raspberry Pi mir Pi Cam als Streaming Server. Kosten um die 60€. Das spannende hieran ist, das die Cam nicht über USB, sondern direkt an den Prozessor angebunden ist. Damit ist Hardware Encoding in der GPU des Pi in H264 mit extrem geringer Latenz möglich.
- Raspberry Pi als Streaming Client am Boden mit Full HD out über HDMI, 30€
- Übertragung über spezielle Outdoor WLAN bridges im 5GHz Band, kosten so um die 70-200€ je nach Reichweite-Wunsch ( Schaut mal nach Ubiquiti Rocket, Bullet, Wispstation, oder Mikrotek Metal, Groove,...).
- Antennen, hier sollten sich durchaus die Mad Mushrooms, Cloverleaves usw nutzen lassen, wenn man die WLAN bridge nahe an 5.8GHz betreibt. Kosten 30- 60€
- Drumherum...Gehäuse, BEC, Kabel... 50€
Mit den Komponenten, die ich gerade im Auge habe, komme ich in Summe auf ~300€.
- Software: der Schlüssel GStreamer über UDP (!)
Full HD 30 FPS. Latenz, die derzeit erreichbar scheint (Gals zu Glas): ~180-200ms, ich glaube, das ist noch nicht das Ende der Fahnenstange. Gewicht onboard? nicht superleicht, aber so um die 100-150g sollten machbar sein für Cam, Pi und WLAN

Proof of Concept (Nicht von mir):
http://www.youtube.com/watch?v=fLQZq7pc6SQ&list=UUXjXxKM6YHByS5gOSd9I5rQ


Jetzt geht natürlich sofort das "Unfliegbar ....!!!!"-Geschrei los. Ich sag dazu: mal sehen. Ich denke für meinen langsamen Copter reichts.

Die Lightbridge liegt angeblich bei 80ms.
Das Video hier sagt allerdings etwas anderes:
http://www.youtube.com/watch?v=aMxfh7ckGG0
Da wären es eher um die 300ms.
Ist aber alles neu, insofern war das vieleicht auch ne Beta-Firmware.

Wie gehts weiter?
Ich hab jedenfalls erstmal einen 2. Pi bestellt mit Pi Cam.
Den werde ich mit dem Vorhandenen Pi direkt per Ethernet-Kabel verbinden und sehen, was sich da machen lässt. Danach gehts an die geeignete WLAN Bridge.

Wenn das funzt: GPS-Daten vom Naza per Serial in den Pi im Copter, genauso Spannung, Stromverbrauch, vielicht MAVlink.... und ab damit über die Bridge zum Boden-Pi.
Auf dem Boden-Pi dann Einbindung der Daten per Overlay ins decodierte Video.
Und das ist sicher nur der Anfang....
Tja, muss mal wieder eine neue Programmiersprache lernen... Python.
Oder es findet sich hier jemand, der Lust hat, softwareseitig zu helfen?
Grundsätzlich geht das wohl, siehe hier.

Edit:
Mittlerweile gibts auch den aktuellen Stand der Software hierr:
https://github.com/monsieurpod/raspifpv

So, und auch hier gibts seit vorgestern was Neues:
http://diydrones.com/xn/detail/705844:BlogPost:1646128

Ich werde jedenfalls berichten....

Interesse geweckt?



b) Tutorial

Tutorial-Überarbeitung am 10.11.2014:

Wichtigster Link für die Zukunft: www.swat-drones.de
Hier wird nach und nach Info zusammengetragen und es gibt Download-Quellen.

Nötige Hardware:

• Raspberry Pi mit zugehöriger CAM über CSI (Kosten in Summe etwa 70€)
• Eine gute WLAN Bridge (Ich empfehle hier mal die Ubiquiti Bullets, PicoStations oder Rockets. Bitte jeweils die 2,4GHz Variante zum legalen Senden aus der Luft an den Boden. Bitte auf 100mW Sendeleistung einstellen.) Ergänzung: 5,8GHz WLAN ist nicht ohne weiteres als fliegender Sender zulässig, steht irgendwo in diesem Thread mit Quellangabe. Beispiel: Picostation bei Interprojekt. (Kosten für das Paar 80-180€, je nach Wahl)
• Passende Antennen für 2.4GHz: Ich empfehle Skew Planar Wheel oder Cloverleaf (etwa 20€, wenn man China-Modelle nimmt. Ich hab welche und die sind gut)
• Ein Abspielgerät: Laptop oder Android Phone mit Android ab 4.1 (ich teste auf nem Nexus 5 und einem Samsung Galaxy S5 mit 4.4.2. Muss nicht zwingend gerootet sein! Root ist nötig, wenn man ein Ethernet-Kabel über einen USB to Ethernet und ein OTG Usb-Adapter anschließen möchte. Dann brauchts wohl auch ne möglichst neue Android Version)
• OTG Kabel und USB to Ethernet Adapter für gerootetes Android: Beispiel: OTG-Kabel, Beispiel: USB-To-Ethernet-Adapter (Kosten etwa 12-15€ in Summe)
• Etwas Lötarbeit, um die Power-Over-Ethernet-Versorgung für die beiden WLAN-Hotspots zu realisieren.

Gesamtkosten ohne Abspielhardware am Boden: ~180-300€

Nötige Software:
- siehe unten

Nötige Kenntnisse:
- Löten (für Power over Ethernet Adapter)
- Netzwerk- und Linux-Kenntnisse doch sehr von Vorteil

Raspberry Pi und Abspielgerät müssen im gleichen Netzwerk liegen.



Raspberry Pi Installation -> airPi = Raspberry mit Cam über CSI für die Luft:

Das Image für den Pi kommt jetzt von Sledge. Er hat ein schönes Webinterface reingebastelt.
1) das Image: Ankündigungspost von Sledge
Das neue Raspberry Image findet Ihr hier: http://www.swat-drones.de/downloads/airpi_v0.2.zip
Die Installation ist hier beschrieben: http://swat-drones.de/index.php/hd-fpv/installation

2) Image auf SD packen mit den üblichen Tools (Unter Windows z.B. Win32DiskImager)

3) Raspberry Pi mit angeschlossener CAM anschalten. Fertisch...


Abspielgeräte:

• Pipeline für Windows:

• App für Android:

Super Idee

Als alternative evtl. Den banana pi, der ist etwas leistungsstärkere. Top Projekt mehr als staunen kann ich nicht beitragen....

Hm, gute Idee das mit dem Banana Pi...gleich mal anschauen.

Der Haupt-Knackpunkt ist ja immer Latenz. Encoding ist problemlos in der GPU, aber das Stream Handling kann man mit mehr CPU-Power vielicht beschleunigen.

Update mit Link zur Software auf GIT im ersten Post.
Lesenswert...

Für ein Projekt habe ich einen Gumstix mit DSP (DaVinci) und Cam-Interface her genommen.
Das maximale was ich raus bekommen habe ist ~100ms Latency und 720p und max. fps ~30.
1080 kann der Chipsatz (in meiner Configuration) nicht.

- Problem HW anschluss, HDMI In ?? Etwas schwierieg.
- WLAN treiber in der HW :-( Ist nicht gerade ein Highlight im Gumstix
- RTSP server (Gstreamer), war Ordentlich und funktionierte ganz gut
- Problem client. Hier ist es manchmal ein "Glücksgriff" welche SW, und welche Version einigermassen wenig Latenz benötigt.
z.B. Damals aktuelle Version von VLC erzeugte ca. 300ms Latenz = insgesamt 400ms.
VLC version 1.1.6 bekam ich ca. gesamt 150ms Latenz.

Grundsätzlich wird man mit Latenz leben müssen, so bald man den Stream encoden und decoden muss.

Alternativ, wäre noch in Richtung DVB-T.
Was ich mir momentan anschaue, modulatoren gibt's z.Zt. ~100€, allerdings muss man hier einen Video-TS bereitstellen.
Das muss dann eben auch "encodet" werden, benötigt aber weniger Performance.
Zudem wäre hier Client HW für viele Geräte Verfügbar.

Mit Raspi, habe ich keinerlei Erfahrung, bin etwas skeptisch, wegen der Performance.
Mir persönlich gefällt der Odroid mit Exynos etwas besser. Aber halt auch etwas teurer, und bin mir nicht so sicher
das hier die Treiber Entwicklung schnell voran geht.

Interessantes Projekt!

Evtl ist der neue Raspberry im SODIMM Formfaktor auch ne interessante Alternative:
http://www.element14.com/community/...ry-pi-compute-module?CMP=SOM-RASPI-COMPUTE-TW

Das Dev-Kit Board bietet 2 Camera Schnittstellen -> 3D und mit nem eigenen, angepassten Board sollte das ganze noch deutlich kleiner und leicther zu machen sein.

Dann noch n GPS an die Serielle und dann sollte das OSD sollte auch realisierbar sein.

Und warum immer 30fps? Klar, wenn man live eine Übertragung streamen will.

Aber warum nicht zum fliegen lieber höhere Auflösung, dafür "nur" 20fps? Oder noch tiefer. Ich denke mir, lieber ein mit 20fps zuckelndes Bild als 200ms Latenz. Die Aufnahme auf der Cam, kann ja dann schon mit 30 und mehr sein. Das wäre meine Richtung in welcher ich die Latenz drücken würde... Hat das schon einer ausprobiert? Lässt sich an den fps was machen?

Also im Moment glaube ich, dass ein RPi als Sender ausreichend ist wegen der Hardware-Codierung in H264.
Am Boden denke ich über eine Android-App nach, die GStreamer nutzt. Hab ein Nexus 5, das hat defakto mehr als genug Power. Eingebaut mit lLinse in ein Brillengestell wäre doch nett. Anbindung über Ethernet an eine long range WLAN Lösung...

Kleines Update:
1) Sender Airborne
Mein Raspberry Pi mit Cam ist da. Auf dem RPi habe ich das letzte Raspbian installiert und die GUI deaktiviert.
GStreamer 1.0 installiert
("deb http://vontaene.de/raspbian-updates/ . main" hinzufügen zu /etc/apt/sources,
sudo apt-get install gstreamer1.0-tools gstreamer1.0-omx gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad).

Dann einfach die Senderzeile starten (erst nachdem der Empfänger, siehe unten, läuft):

raspivid -n -w 1920 -h 1080 -b 8000000 -fps 30 -vf -hf -t 0 -pf high -o - | gst-launch-1.0 -v fdsrc ! h264parse ! rtph264pay ! udpsink host=192.168.100.111 port=9000



2) Empfänger Ground
Derzeit nur mein Windows 8 Laptop.
Gstreamer SDK installiert (http://gstreamer.freedesktop.org/data/pkg/windows/1.2.4.1/gstreamer-1.0-x86_64-1.2.4.1.msi).
Empfangszeile:
gst-launch-1.0 -e -v udpsrc port=9000 ! application/x-rtp, payload=96 ! rtpjitterbuffer ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false

Beim ersten Start der Netz-Nutzung zustimmen, falls sich die Firewall meldet.

Netzwerkkonfig:
Einfach statische Adressen verwendet. Verbindung derzeit nicht über WLAN (Habe gerade Ubiquiti Rockets bestellt 2x), sondern direkt über LAN-Kabel.

Ergebnis:
Latency ~170 - 200 ms (je nach Power-Setting meines Laptops. Interessant...)

Gefühlt ist das ganz ordentlich.

Bild (muss noch die Schärfe der Camera einstellen):

Hi Lonestar,

ein sehr geiles Projekt hast du da angestoßen.

Allerdings solltest du nur ein minimales Raspbian installieren anstatt bei der fetten Voll-Image nur die GUI zu deaktivieren ...
Das sollte dir deutlich bessere Latenzen bringen ...

Allerdings wirst du dann einige benötigte Pakete per Hand nachinstallieren müssen ....

Das Minimal-Image nur mit GUI kriegst du hier (ARMHF-Version): http://www.linuxsystems.it/raspbian-wheezy-armhf-raspberry-pi-minimal-image/

Du kannst auf der gleichen Seite auch eine ARMEL-Version ziehen, die dann normale Debian-Pakete akzeptiert, allerdings gibst du dann ja bekanntermaßen die hardcodierte Fließkommaberechnung auf. Aber der Video-Codec müsste trotzdem laufen, wenn du den Key hinterlegst ....

Hier ist die ARMEL-Version: http://www.linuxsystems.it/2012/06/debian-wheezy-raspberry-pi-minimal-image/

Könntest du das mal mit einer anderen SD-Karte ausprobieren? Die sind ja schnell gewechselt, so dass du nicht erst wieder nen Image zurückspielen müsstest.

Hattest du auf dem rPi schon den Turbo-Mode aktiviert, oder läuft der noch auf den regulären 700MHz?

-ghost-

Also das Projekt empfinde ich auch als äußerst überzeugend. Normalen Rundflug sollte man aufjedenfall mit 100-150ms hibekommen. Schade, dass man nicht wie bei Computerspielen einfach das geschen zusätzlich verzögern kann. Ein Reality-Delayer wäre zu entwickeln

Grundkenntnisse in Python habe ich. Außerdem habe ich ein Raspberry Pi was gerade in meine GroundStation transplantiert wird.
Alternativ könnte man ja auch einen oder zwei CubieTruck nehmen. Dieser ist bedeutend leistungsfähiger. Ich würde ihn wohl für die Bodenstation empfehlen.


Ich bin mal gespannt wie es weiter geht.

Hey Ghost, danke für den Tip mit der armhf version, werd ich testen
Gstreamer gibts auf jeden fall mal dafür...

So, hab mal das minimal-Linux installiert und mit unterschiedlichen Overcklock-Einstellungen getestet...
170ms, weniger ist nicht.


~30% CPU wird genutzt auf dem Raspberry

Das liest sich doch schon mal ganz gut.

Was jetzt noch mal interessant wäre, um den Falschenhals zu finden:
Mach doch bitte nochmals den gleichen Test und reduziere mal nur die Auflösung der Kamera auf 1280 x 720 bei gleicher FPS.
Oder aber die FPS mal reduzieren - so wüsste man dann, ob der Decoderchip vielleicht nicht hinterher kommt und so die Latenz negativ beeinflusst.

Falls das bei den 170ms bleibt, dann weißt du aber, dass du so vermutlich nichts mehr am System optimieren kannst, um die Latenz zu drücken ...

Es ist und bleibt spannend - obwohl ich das jetzt schon mehr als annehmbar finde ...
Die hochpreisigen Profilösungen sind wahrscheinlich auch nicht großartig besser.


Noch eine Frage zur Kamera, da ich keine für den rPi habe, kann man da nen anderes Objektiv draufmachen?
Wenn ja, welches Gewinde? Standart 12mm wie bei dem FPV-Kameras?

-ghost-

Hey,
Ich möchte mich hier kurz mit einer Frage einklinken: Weiss jemand, wie viel Verzögerung das Live-out der Mobius etwa hat? Rein als Vergleichwert.

MfG

Ca. 100ms soweit ich weiß...

jupp alles durch...bleibt bei 170ms. Insofern denke ich, die Latenz kommt durch das Hardwareencoding. Weniger FPS führt zu leicht höherer Latenz, was auch Sinn macht.

Cam hab ich die hier, mit 12mm Gewinde:
http://www.watterott.com/de/Raspberry-Pi-Camera-Board-/w-M12x05-mount-Lens

Also, das ein minimal Linux schneller läuft als das normale hätte mich stark gewundert. Es verbraucht zwar weniger platz aber im idle hat mein RPi auch fast 0,0% Auslastung. Booten sollte aber schneller sein.
Im ganzen ist es natürlich schön wenn keine unnötige software mitgeschleppt wird.

Hast du mal versucht eine geringere Auflösung zu übertragen. Wird dann die verzögerung geringer? Normal sollte die Bandbreite ja mehr als ausreichen.
/Edit/ Da war ich zu lange beim schreiben. Ok dann wäre das geklärt.
Alternative Hardware wäre halt noch eine möglichkeit.
Mich interessiert vorallem, wie lange das RPi wirklich benötigt um den Videostream bereit zustellen. Der Empfänger erzeugt ja auch immer eine gewisse latency. Was für Spezifikationen jat den das verwendete Notebook.

Man wenn ich doch mehr von der Netzwerk-Technik verstehen würde.

Den Video Weg verstehe ich so
Kamera -> RPi (schnell da Rohdaten)
RPi -> H256 (Hardware Encoder: geschwindigkeit?)
H256 -> Netzwerk-Adapter (Ich glaube auf dem RPi als USB 2.0 gelöst | USB läuft ja auch nur mit Datenpaketen und Overhead)
Netzwerk -> Netzwerk (UDP Datenpakete. Sollte recht schnell sein. WLAN dürfte aber langsamer sein)
Netzwerk -> Decoder (Abhängig vom System sehr schnell zb. PCIe)
Decoder -> Grafikkarte (Abhängig vom System sehr schnell | Hardwaredecoder auf Grafikkarte)
Anzeige -> Person (sehr schnell ca 5ms)

Wenn man das jetzt noch über WLAN macht kommt noch mal eine verzögerung dazu.

Was ist eigentlich mit dem OpenSource Grafiktreiber? Bringt der eventuell geschwindigkeit?
http://www.golem.de/news/raspberry-pi-open-source-grafiktreiber-ist-fertig-1403-105497.html

Ich wollte auch vorschlagen auf UDP anstelle von TCP umzustellen, falls du das noch nicht nutzt.

-ghost-