Digital FPV - Diskussion

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

    • Digital FPV - Diskussion

      Ich würde gern mal das ganz grundsätzliche Thema digitales FPV so diskutieren. Unabhängig von HD oder anderem.

      Mich interessiert ob wir zunächst theoretisch einen Weg finden das Video signal bei sehr niedriger Latenz digital zu übertragen.

      Ich denke dabei vor allem daran, vorhandene cams, vtx, und vrx zu nutzen und das Signal vor dem vtx a/d zu wandeln. Nach dem receiver bedarf es dann natürlich auch eines decoders.
      Dazu interessiert mich erstmal, ob ein vtx ein beliebiges analoges Signal übertragen kann oder irgendwie speziell auf analoges Video getrimmt ist.
      Auch stellt sich die Frage, ob sich ein raspberry pi zero nutzen lässt oder man ein dsp wie die typischen stm32f4 nutzen muss.
      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.
    • Klar ist das möglich, nur halt nicht so klein und kompakt wie wir es gerne für 5" hätten, wäre X-Class der Mainstream hätten wir das schon lange.
      Geringere Latenzen sind durch Bündelung mehrerer sendener Kanäle technisch auch kein Problem.

      Für mich stellt sich primär die Frage ob der Spassfaktor durch bessere Bildqualität tatsächlich nennenswert steigt... ich flieg ja nicht um die tolle Landschaft zu beobachten sondern wegen der Action. (Für ersteres hat DJI ja schon mehr als genug auf dem Markt)
    • Mir geht es zunächst nicht um Bildqualität sondern um das digitale Signal. Im Zweifel kann man da auch andere Daten reinmischen.
      Bündelung von Kanälen finde ich auch kontraproduktiv. Es soll gern ein einzelner Kanal genutzt werden. Vielleicht schaffen wir ja 100p unkomprimiert. Dann kann man ab da weiter machen und einen geeigneten codec (open source) entwickeln.

      Und ein raspberry pi zero passt auch in nen normalen 5'' freestyle copter
      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 ()

    • hier ein paar links von dem was ich 2016 probiert habe.

      der-frickler.net/modellbau/fpv/hdwifi

      Am Ende sind einige Links die das ganze beschreiben.

      Wifibroadcast ist das Zauberwort.

      Ganz viel Fummelei bis das ganze funktioniert hat.
      Latenz war aber auch ordentlich vorhanden.
      Um das zu verbessern musste man dann Abstriche machen in Paketgröße oder an anderen Stellen.

      Zumindest mit Pi1 und Pi Zero und (720p, 4.5Mbit Bitrate, 8/4/1024) war CPU nach eine Minute voll ausgelastet.
      Danach stieg die Latenz und Bild fing an zu stottern.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Brummer ()

    • ja di pi cam war nicht die beste aber die hatte den Vorteil dass sie ein dedicated port hat am Raspbery, direkter geht ja nicht.

      Und das ganze hat mit der Standard Wifi dann nichts zu tun.
      Zitat:
      Wifibroadcast puts the wifi cards into monitor mode. This mode allows to send and receive arbitrary packets without association. Additionally, it is also possible to receive erroneous frames (where the checksum does not match). This way a true unidirectional connection is established which mimics the advantageous properties of analog Link.

      d.h. mann hat beide sticks umkonfiguriert und sich auf eine Frequenz geeinigt.
      Ein stick sendete stumpf die Pakete an diese Frequenz ohne was zu überlegen undirektional und der andere empfing die Pakette nur ebenso ohne etwas zu prüfen.
    • Was wäre deiner Meinung nach ein möglicher Weg? Genial wäre es sonst auch, wenn man die internals einer HS1177 hijacken kann. Wenn man zB. ein digitales Signal heraus bekommt.
      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.
    • Das größte Problem von wifibroadcast etc entsteht durch die Nutzung von TCP als Protokoll. Das Protokoll versucht die Übertragung von Paketen abzusichern. Dadurch kommt es zu erheblichen Latenzen, wenn der Empfang schlecht wird und man kann auf dem Applikationslayer nichts dagegen tun.
      Das zweite Problem kommt durch MPEG4/H.264. Da werden Keyframes eingesetzt. Verpasst man einen Keyframes, ist das Bild je nach Konfiguration sekundenlang gestört (die bunten Sequenzen bei Signalstörung).
      Idealer wäre die Nutzung von UDP oder eines noch einfacheren Protokolls, das Pakete nicht absichern will. Dazu muss ein Videokompressor, der mit Paketverlusten gut umgehen kann. HEVC kann man wohl so konfigurieren, dass es gegen Paketverluste recht stabil ist. Last but not least sollte man die Übertragung so modifizieren, dass die niedrigen Ortsfrequenzen häufiger übertragen werden, um eine Störungssicherheit einzubauen.
      M. E. klappt digitales FPV nicht, wenn man fertige Protokolle verdrahtet. Da muss man tiefer rein.
    • Man müsste noch an den Codec ran. Bei Bildverarbeitung kann ich halbwegs mitreden, aber Video Codecs sind definitiv nicht meine Expertise. Eine radiale Cosinus Basis scheint mir für unsere Zwecke deutlich besser geeignet. Das würde für ein scharfes zentrales FoV sorgen und man könnte die entsprechenden Koeffizienten mit hoher Redundanz übertragen.
      link.springer.com/chapter/10.1007/978-3-662-46742-8_10
    • An sowas wie ein polarkoordinaten-system hab ich auch schon gedacht. Wäre vor allem in Zusammenhang mit nem größeren fov und head tracking interessant.
      Bei der digitalen Übertragung würde ich am liebsten von irgendwelchen Verfahren wie udp oderso komplett absehen und quasi einfach binärdaten streamen. Byte für Byte. Ich glaube, dass unser Anwendungsbereich so speziell ist, dass er auch sehr spezielle Codecs braucht.
      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.
    • 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.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Brummer ()

    • simon.bethke schrieb:


      ...Bei der digitalen Übertragung würde ich am liebsten von irgendwelchen Verfahren wie udp oderso komplett absehen und quasi einfach binärdaten streamen. Byte für Byte....
      Das habe ich jetzt auch für dich kurz versucht zu rechnen.

      Ohne Modulation ist ein Hertz ein Bit.
      Jetz haben wir 20MHz zu Verfügung in unseren Racebandkanal.
      20MHz = 20Mbit
      20Mbit / 8 = 2,5MByte
      Wenn wir jetzt nur 30fps senden wollen sind das nur noch 2,5MB / 30fps = 0,083MByte
      Das sind 83,3KByte die du für einen Bild hast.

      Jetzt rechnen wir unser bedarf bei 1280×720 mit nur 30fps
      (Pixel Breite * Pixel Höhe) * Datentiefe * Frames
      Ein Bild mit eine Auflösung von 1280×720 hat 921600 Punkte
      Jetzt bei nur 30fps sind das 27648000 Punkte/Sekunde, jetzt noch etwas Farbtiefe von 8Bit dazu sind wir schon bei 221184000 Bit / Sekunde
      In Bytes sind es dann 27648000 Bytes oder 27648KByte pro Sekunde oder ca. 28 MegaByte.

      Ich bin mir aber jetzt nicht ganz genau sicher ob die ganze Berechnungen stimmen.
    • Deine Rechnung stimmt im Prinzip, wenn man keine digitalen Modulationsverfahren verwendet wie QPSK etc. Wenn man mal auf Sat TV schaut, dann hat ein Transponder so um die 30-40 MHz und da sind dann 4 HD Sender drauf mit so um die 10Mbit.
      Die Bandbreite unsere Kanäle passt an sich. Man bekommt durchaus Respekt vor der Leistung der Codecs. Aber zieh bei deinem Dvb-s oder C Receiver mal kurz das Kabel raus und schau, wie lange der braucht, bis das Signal zurück kommt. Das ist unser Kernproblem. Die hohen Kompressionsraten sind möglich, weil sich typischerweise zwischen den einzelnen Frames nicht viel ändert. Also wird recht selten ein Keyframe (komplettes Bild) gesendet und dann nur Änderungen dazu. Das klappt super, solange man keine Störungen einfängt bzw Pakete verloren gehen. Deshalb geht es auch nicht mit Standard Codecs. Und für einen speziellen Codec ist sowas wie ein PI viel zu lahm. Da muss imho ein DSP oder FPGA ran. Oder jemand bekommt eine GPU in die Luft.
    • Ich glaube was hier nicht berücksichtigt wird, ist dass wir einen gestörten Übertragungskanal haben. Im Endeffekt heißt das, die Bandbreite ist nicht konstant. Oder wir haben mehr oder weniger viele Bit Fehler. Je nach Redundanz und/oder Fehlerkorrektur.
      Bit Fehler führen sofort zum Ausfall von größeren Bildteilen oder ganzen Frames je nachdem wie groß die Blöcke im Codec sind. Ganz schlecht.
      Dagegen hilft nur mehr Redundanz oder eine adaptive Anpassung der Bitrate. Das wird beim DJI System gemacht. Dafür braucht es aber einen Rückkanal. Das haben wir beim bisherigen Analog-System aber nicht. IMO wird ein Digitales System ohne Rückkanal nie vernünftig funktionieren.
    • Es macht absolut Sinn, die Übertragung an die aktuelle Empfangssitutation anzupassen, d.h. einen Rückkanal zu nutzen. Aber es löst nicht das Problem an sich. Wenn die Brille über den Rückkanal meldet, dass ein Frame oder wesentliche Bestandteile fehlen, dann muss das empfangen werden, es muss neu kodiert werden, es muss neu gesendet werden, es muss neu empfangen werden, es muss neu dekodiert werden und erst dann kommt es zur Anzeige. Das dauert zu lange, um sich darauf generell verlassen zu können. Unsere Empfangsbedingungen ändern sich rasend schnell. Es ist aus den Reviews mittlerweile klar, dass DJI einfach Frames fallen läßt, wenn etwas nicht passt und vermutlich läuft dann der genannte Prozess. Ich halte das aber für wenig optimal.
      Die Lösung sind Codecs mit mehr Toleranz bei Datenverlust.