OpenHD

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Ich habe die notwendige Hardware (2 x Raspberry Pi + WLAN-Devices) schon vor Monaten beschafft und angetestet. Mit einem 7’‘-LCD-Screen als Anzeige. Da ich jetzt eine HDO2 mit HDMI-Eingang habe, will ich es noch einmal angehen. Die Bild-Übertragung auf die Brille ist schon ziemlich geil. Muss nur noch die Telemetrie-Übertragung von meinem FC einrichten. Dann kann ich die Eigenbau-Air-Unit auf meinen Copter setzen und los geht‘s...
    • Also die "technischen Daten" klingen schonmal ganz ordentlich:

      Auflösung: 1080p 30/60fps
      Latenz: 100ms
      Reichweite: 40km ;)

      Was mich echt verblüfft, wie gut 4mbit aussehen können, wenn bei DJI 50mbit teilweise nur Pixel Brei sind... Aber das wird ua. der niedrigen Latenz bei Dji geschuldet sein...

      Ich hätte aber bei 100ms Bauchschmerzen, das auf einen Copter zu setzen. Für Fläche klingt es aber erstmal nicht so schlecht... Bräuchte das ganze jetzt in kleinerer und in evtl integrierterer Form, also passender WLAN Chipsatz auf einem RaspiZeriZero, dazu eine gute Cam im Minigehäuse mit Weitwinkel... Oder gibt es da auch schon was?
    • Das Problem an den Zeros ist m.E. erst mal der Mangel an Sendeleistung und das Band. Beim BCM43438 ist bei 17dBm Schluss und es gehen nur 2.4G. Bei 2.4G habe ich schlechter Erfahrung mit einem parallelen 2.4G Control Link.
      Einen Asus AC56 strippen und direkt mit einem Pi 3 oder4 Compute Board verlöten? - Das Compute Modul 4 ist 55mmx40mm. Der gestrippte USB sollte Huckepack drauf passen. Ist viel Arbeit - wird dann grob ähnlich zur DJI Air Unit (44mm×38mm×15mm).
      Die Latenz wird man bei dem Ansatz nicht so leicht auf ein DJI/SB Niveau bekommen. Da glaube ich - falls die Community das packt - eher an den DIY HD Ansatz (s.o.) mit einem dedizierten FPGA.
    • Ich habe OpenHD sowie Ruby (eine andere Alternative auf der selben Hardware) im Testbetrieb auf einem Flächenflieger. Damit da etwas vernünftiges rumkommt, wird aber schon etwas Equipment benötigt. In meinem Fall:

      Flieger:
      Pi3b+
      Hawkeye Split 4K (HDMI-Ausgang auf CSI-Adapter auf Pi3b+)
      AC56 WiFi-Adapter
      Maple Leaf Antenne

      Boden:
      Pi3b+
      Touch-Screen
      2x AC56 Wifi-Adapter
      Antennen nach Anwendungszweck

      Das soll dann mal so aussehen, aber mit der Reichweite komme ich noch nicht hin ...





      (Kamera ist beim 2. Video 'ne andere).
    • Echt ein spannendes Thema! Da muss ich mich mal informieren.

      tomstoms schrieb:

      Latenz: 100ms
      Das ist allerdings dermaßen übel :D Werden die Frames erst entwickelt und dann via Deutsche Post verschickt?

      Ich denke, dass es durchaus möglich sein könnte, dass jeder seinen eigenen kompromiss zwischen ErrorCorrection, Bandbreite und Latenz einstellt. Wer halt nur max. 100m weit direkt vor der Nase fliegt und dann auch noch bereit ist in Auflösung etwas zu reduzieren, sollte dafür auch mit ner brauchbaren Latenz versorgt werden.
      Ausschließlich in der Mitte von Nix zu schweben macht mich depressiv!
      ...meine Rechtschreibprüfung funktioniert zum Glück nur bei kurzen Wörtern. Korrekte Wörter werden da immer durch unsinnige andere ersetzt.
    • Ein paar Gedanken zum Thema Latenz:
      Im openHD Wiki unter den FAQ steht, von den 100-120ms Latenz bei einem Pi + Pi Kamera Setup. Bei einem Jetson sind sie wohl schon auf 40-60ms gekommen - und eine geeignete Kamera scheint auch ein Thema. Jetzt fehlt noch grob ein Faktor 2. Die Frage ist, wieviel davon auf den ganzen TCP/IP Stack zurück fällt.

      Ein zweites Thema ist die Kompression. Das ist nach meinem Verständnis ist das ein MP4 Stream, der mit UDP übertragen wird. Da werden viele Keyframes konfiguriert, damit ein Übertragungsproblem maximal 100ms Bildausfall verursacht. M.E. ist MP4 ex factory denkbar ungeeignet, weil einzelne umgefallene Bytes mehrere Bilder in Folge komplett vernichten können. Weder DJI noch Sharkbyte lösen das so. DJI hat ein eigenes Protokoll das vermutlich mit einem Mix aus adaptiver Kompression, Redundanz und Paketnachforderungen arbeitet. Sharkbyte hat sich für eine fixe, relativ simple und weniger effiziente Kompression entschieden. Diese verzeiht aber Übertragungsfehler - es fällt immer nur ein 12x8er Pixelblock aus. Ich würde mich zutrauen eine Spec für die Sharkbyte Kompression zu schreiben. Evtl. würde ich noch langsamen & lausigen C-Code hinbekommen. Ich bin aber nicht kompetent, das in einen FPGA Code zu übersetzen. Das dürfte aber nötig sein, um die Übertragung in der Latenz hinzubekommen und die Robustheit die wir für FPV Racing brauchen.
      Last but not least: Die OpenHD Übertragungen scheinen alle von Wings in größerer Höhe gemacht zu sein. Das sind einfacherer Randbedingungen als wir sie haben.
    • @Stefan73
      Alle Jahre wieder :D

      Brummer schrieb:

      Nur noch ein Paar Zeilen über Raspberry Pi

      Wenn man jetzt die RasPi nimmt, ist die Pi Kamera die schnellste Lösung die ich da sehe um an RAW Bild zu kommen.
      Irgendetwas über usb anzuschließen wäre lächerlich langsam.

      Die Pi Kamera ist eine rolling shutter Cam (CMOS).
      Bedeutet (getestet), das diese insgesamt 30-35ms braucht umein RAW Bild auszulesen.
      Das ist die Zeit die vergehet, bis das ganze belichtet wird und alle Linien ausgelesen werden.

      AmEnde der Belichtungszeit wird die erste Linie ausgelesen und an SoC gesendet. WeitereLinien werden dann je nach dem in welche sensormode gelesen wird, weiter gelesenund an SoC gesendet
      Ab ca. 200 Linien wird der ISP mit der Verarbeitung derDaten beginnen.
      Im 1296x972 2x2 binned sensor Modus (42fps) sind es ca. 24ms
      Nach letzte Linie wird dann der Frame komplett gemacht waswieder ca. 10ms kostet.

      Das wäre dann RAW Bild in 30-35ms je nach Belichtungszeit.
      Und da hat der ganze Spaß nicht mal begonnen.

      Wenn du das ganze jetzt in sowas wie H264 haben möchtest,dann dauert es nochmal 30ms
      Dann währen wir schon bei 60ms bis 70ms.
      Dann muss das ganze durch die frische Luft zu dir.
      Und dann noch auf die Brille dargestellt werden.
      Das ganze Thema hatten wir im 2019 gekaut.
    • Ich kann mir eine gute Lösung nur durch geniale Softwareentwicklung vorstellen. Zunächst braucht es nen cameratreiber, der es schaft den sensor so hardwarenah wie möglich auszulesen. Wir brauchen nichtmal vollbilder, wenige Zeilen früher zu bekommen wäre besser.
      Dann der codec, mp4 ist Unsinn... unbrauchbar für Realtime. Ich würde jetzt eigentlich sagen, auch TCP IP ist nicht brauchbar. Also bräuchte es eine Art Video-Protokoll, welches transport, error correction sowie bilddatenkompression vereint.
      Ausschließlich in der Mitte von Nix zu schweben macht mich depressiv!
      ...meine Rechtschreibprüfung funktioniert zum Glück nur bei kurzen Wörtern. Korrekte Wörter werden da immer durch unsinnige andere ersetzt.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von simon.bethke ()

    • Stefan73 schrieb:

      Last but not least: Die OpenHD Übertragungen scheinen alle von Wings in größerer Höhe gemacht zu sein. Das sind einfacherer Randbedingungen als wir sie haben.
      Es gibt auch ein paar Beispiele für Copter, aber das interessiert mich eher nicht. Das interessante bei OpenHD/Ruby ist für mich, dass das mit normal käuflicher Wifi-Hardware funktioniert und ich neben dem Plug & Play DJI FPV auch ein System habe, das man selbst ein wenig tunen kann oder auch muss. Die Latenz ist für meine Zwecke völlig ausreichend, die Flüge entspannen, LR ist aber keineswegs out of the Box zu haben, dafür müssen einfach zu viele Parameter stimmig sein.
    • 100ms finde ich für die Hardware, die benutzt wird, gar nicht verkehrt.
      Für LongRange oder Waypoint-Missions reicht das ja schon.
      Wahnsinnig geringere Latenzen erfordern mMn eigentlich recht schnell spezielle Hardware.
      Die NVidia Jetsons könnten eine Option sein, aber klein und leicht ist auch anders.


      Es ist aber auch vielleicht etwas naiv zu erwarten, dass man mit ein bisschen Software das Niveau von kommerziellen Lösungen erreicht, in die ordentlich Entwicklungsbudget reingeflossen ist.
    • Mal ne kleine Frage, ist nicht bös gemeint sondern echte Interesse.

      Wenn das System nicht besser ist als das von DJI und FS und man es mit moderatem technischen Aufwand auch nicht besser hinbekommt als die beiden bereits bestehenden Systeme, warum dann das Ganze?
      Ich meine bringt es einen Vorteil mit, der sich mir gerade nicht erschließt, oder gehts hier eigentlich nur um den Basteltrieb zu befriedigen?
      Goblin Helis bis 800er Speedmod
      Racequads, AR-Wing Pro, Funjet Ultra 2 FPV Mod
      Div. Flächenflieger
      Horus X10S Express, Taranis X-Lite S
    • @catdog79
      Weil das ganze in Gegensatz zu dji und FS so gut wie garnicht kostet und man viele Teile vieleicht in der Schublade hat.
      Dazu alle Vorteile einen offenen System.
      Mich hat das vor Jahren gereizt weil es garnicht auf den Markt gab was HD übertragen könnte.

      Ich flog damals auch ein Tarot 17 Zoller mit pixhawk. Latenz war weniger interessant.
    • Ich glaube es ist eher die Hoffnung nach einem offenen HD FPV Standard. DJI ist propritär und SB auch.

      Die Kosten Stand heute sind nicht mal so toll. Ein geeigneter Pi + Pi Kamera + Asus AC56 und man ist bei grob 100€. Das ist in der Region der kleinsten Caddx Vista Variante (mit Nebula gerade 112€ bei BG). Und wenn man einen Jetson nimmt, steigt die Rechnung um gute 100€.
    • Ich hab ja mein Setup oben angegeben. Mit passenden Antennen am Boden und Pi4 anstatt Pi3 plus ein bisschen Zubehör, wie z.B. HDMI-Rekorder, BECs etc. kommt da fast der Preis vom DJI FPV raus ... In meinem Fall will ich ja mindestens auch die Reichweite vom DJI haben und die Videoaufzeichnung bzw. Live-Bild soll auch annehmbar sein.

      Also billig ist es (dann) nicht (mehr), es ist aber ein offenes System wo man selbst dran drehen kann. Und genau das macht für mich den Reiz aus.