Low Cost HD-Video Übertragung + Telemetrie

Status
Nicht offen für weitere Antworten.
Ohne euch direkt die Hoffnungen nehmen zu wollen, stellt ihr euch das glaube ich ein bisschen einfach vor...

Noch ein paar Anforderungen:
- Das Kabel zur Cam darf kein so steifes Flachband sein. Eher wie die Verlängerung bei der Mobius mit Einzellizen. Und es muss die in verschiedenen Längen geben, damit man mit dem Sensor alleine ein Gimbal bestücken kann.
Klar sind diese dämlichen Flachbandkabel total nervig, aber es hat schon so seinen Sinn, warum die verwendet werden. Die Datenrate für so einen Full HD Video Stream ist nicht ohne. Genau aus diesem Grund ist ja auch mit MIPI CSI eine differentielle Übertragung gewählt worden. Wenn die Äderchen meilenweit auseinander in der Weltgeschichte rumfliegen, dann hätte man sich das differentielle auch sparen können. Und die Masse zwischen jeder Datenleitung hat auch ihre Berechtigung. Vielleicht geht es trotzdem, aber dann sicherlich nur auf sehr kurzen Stücken. Ich kenne diese Mobius nicht, und auch deren Kabel nicht, und auch nicht, was da an Datenrate durch muss.

Das weis ich erlich gesagt auch nicht kann aber gut sein

Hier kann man etwas zur Spannung finden

Wichtig ist dieser Absatz

Die Frage ist: Was Passiert wenn ein Regler ausfällt??

Im Original ist dieses Problem mit einer Ein-Chip-Lösung entschärft
Datenblatt
Ich selbst hab mich zwar schon mit Eagle gespielt aber noch keine eigene Platine geätzt.


Dimmsockel selbst verlöten wäre bestimmt machbar
Aber da muss man schon gut sein
Ich glaube mittlerweile beherrscht auch Eagle die Impedanz- und Längenanpassung, aber wenn hier noch niemand diesen Kram gemacht hat, ist schon das alleine sportlich, wenn man es sauber hinbekommen will.

Und diese Einchip-Lösung ist ja schön und gut, aber das sieht mir auf den ersten Blick schon wieder ziemlich unlötbar aus. Man könnte es natürlich in einem SMD Ofen versuchen, aber meine Versuche im umgebauten Pizza-Ofen waren bisher nicht so super, wie ich es mir erhofft hatte.

Außerdem hänge ich als Beweis mal noch einen Screenshot von meinem Testaufbau an ;)
 

Anhänge

Sledge

lonesome Cowboy
@Sledge: das mit dem Webserver schaut auch schonmal super aus. Ich hoffe ich kann es bald mal bei mir ausprobieren. Und wenn du Unterstützung brauchst, um nginx zu kompilieren, sag Bescheid. Ich habs erst letztens für Baikal (Cal-/CardDAV) kompiliert, weil mir ein Modul beim Binärpaket gefehlt hatte. Allerdings war das unter Arch. Ich weiß ja nicht worauf du unterwegs bist. Aber an sich ists ganz hübsch unter Arch, weil man mit makepkg direkt ein Paket für den Paketverwalter pacman erzeugt, sodass dieser sich auch um Dependencies und so kümmern kann, halt die üblichen Vorteile von Paketmanagern. Und neuer sind die Binärpakete unter Arch auch durchweg. Aber genug der Werbung jetzt ;)
Danke für die Unterstützung, ich komme da sicher noch drauf zurück. Im Moment möchte ich erst mal bei raspbian als Grundlage für das Image bleiben. Die Software die für das Projekt relevant ist kompiliere ich in aktuellster Version aus dem Quellcode, alles andere frisst eigentlich kein Brot. Die Prozessorlast ist absolut im grünen Bereich und auf dem Laptop habe ich eine Latenz von 101 ms. Auf dem Android sind es 140 ms, also ebenfalls völlig akzeptabel. Wenn es irgendwann eng wird würde ich es aber auch mit archlinux versuchen.

Ob sich die Kosten für eine Apple App Entwicklung tragen, kann ich nicht beantworten. Aber ich denke die HD Geschichte hat Potential und Zukunft und ob man letztendlich einen analogen Empfänger kauft oder eine App die den Empfang übernimmt spielt auch keine Rolle. Und wenn jetzt sogar Apoc, den ich bisher als entschiedensten Gegner von HD FPV erlebt habe, ein solches System aufbauen will, dann glaube ich ist das Projekt auf dem richtigen Weg :)

Also hau rein so lange Apple noch 15% Marktanteil hat *nur Spaß nur Spaß*
 
Ich wusste es. ;)

Nee, geht nicht um mich, sondern um euch, was ihr tolles auf die Beine stellt.

Und jeder Tester machts besser.

Ich brauch immernoch kein HD FPV, btw. ;)
 

Lonestar78

Erfahrener Benutzer
Ne "Brauchen" tut das niemand....
Aber nachdem man das erstemal mit 720p geflogen ist und dann mal kurz den Spasscopter mit analog Video ausgepackt hat, dann "braucht" mans plötzlich doch :D

Spass beiseite: es macht zunehmend Spass, hier weiter zu kommen und mehr Tester braucht das Land...
 

Constantin

Erfahrener Benutzer
Constantin. Die raspberry pi Android Kombi schafft schon 1080p. Nur die Latenz ist nicht ganz so gut. Fullhd über raspi geht nur mit 30fps, 720p bis 49fps. Mehr fps -> geringere Latenz. So erklärt sich das also. Ich dachte die fps werden bloss von der Kamera limitiert. Auch wenn ich persönlich die taktik die fps zu erhöhen für eine geringere latenz erst einmal aufgrund der größeren datenmenge suboptimal finde,aber mit der direkten integration des H.264- codes geht's wohl nicht anders.

Ansonsten steht ja die verwendete Pipeline im ersten Post:

rtspServerairPi "(rpicamsrc bitrate=6500000 hflip=true vflip=true preview=false ! video/x-h264,width=1280,height=720,framerate=49/1,profile=high ! h264parse ! rtph264pay name=pay0 pt=96 )" genau,das meinte ich(fett)

Du liegst mit Deiner Vermutung also richtig bezüglich des Encoder-Profils.
Ich habe mit Baseline keine guten Ehrfahrungen gemacht. Viele Artefakte.
schade.ich muss dann mal schauen ob's dass mir wert ist weil ich das ganze auch gerne aufn Flieger packen will.

Lg
Constantin
 

nique

Legal-LongRanger
Kann mir jeman sagen, wie ich mit dem gstreamer am Boden die Aufnahme mache? Die Beispiele im Netz die ich gefunden habe, habe ich nicht verstanden :(
 

Lonestar78

Erfahrener Benutzer

nique

Legal-LongRanger
Schade, wie sollen dann Beweise hier hoch bezüglich Reichweite? Ich film doch nicht meinen Monitor...

Noch eine Herausforderung. Bis zu welcher Auflösung kann man maximal gehen? Liegt ein Bild mit 2560x1920 drin? Wenn ja, würde mir eine FPS von 10 für die eine Anwendung vollauf genügen. Ich brauche Pixel, Pixel und nochmals Pixel... Wenn es nicht geht, wo klemmts? Schon am Sensor oder erst am GStreamer?

Die tollen Progis mit GUI die hier vorgestellt werden. Versehe ich das richtig, dass ich damit von der Groundstation aus den PI umkonfiguriere, damit der einen anderen Stream sendet? z.B hd bei 30fps oder dann fullhd bei 20fps (nur Beispiele)? Und ist dan solange Blindflug, bis der PI wieder da ist (muss doch neu booten, oder? Also irgendwo 30Sekunden? Oder verstehe ich da was völlig falsch?

Und wenn ich schon am fragen bin....

Zu den Canon Fotoapparaten gibt es einen "Wireless File Transmitter" (z.B. WFT-E4). Da kann man so wie ich das verstehe mit einem LAN (oder auch WLAN) auf die Kamera los, Bilder knipsen und die über FTP/HTTP runterziehen. Wenn ich jetzt in den Flieger einen Switch einpacke und neben dem PI auch noch so eine Kamera mit dem WFT. Dann könnte ich doch via Pixhawk die CAM auslösen lassen (alle 10 Sekunden z.B.) und die Bilder mehr oder weniger gleich vom Boden aus abgreifen? Wenn da eine Verzögerung von 5-10 Sekunden ist, alles kein Problem. Keine Fragen wegen dem Platz oder Gewicht. Wenn man den Flieger noch etwas hochskalliert, passt das alles rein. ;-) Mir geht es ums Prinzip, ob das mit den UBIs im Grundsatz möglich sein könnte.

So, mal schauen, ob ich mein Sandwich auf den Teksumo bekomme. Mit dem Auto rumkurven ist vorbei, jetzt muss die Cam in die Luft.
 

Lonestar78

Erfahrener Benutzer
Hi nique,

Diverse Antworten:
- Modes der CAM, die oberste hab ich nie probiert, sollte aber gehen.

  • 2592×1944 1-15fps, video or stills mode, Full sensor full FOV, default stills capture
  • 1920×1080 1-30fps, video mode, 1080p30 cropped
  • 1296×972 1-42fps, video mode, 4:3 aspect binned full FOV. Used for stills preview in raspistill.
  • 1296×730 1-49fps, video mode, 16:9 aspect , binned, full FOV (width), used for 720p
  • 640×480 42.1-60fps, video mode, up to VGAp60 binned
  • 640×480 60.1-90fps, video mode, up to VGAp90 binned
- Genau, die Android APP kann auf Knopfdruck derzeit per SSH Kommandos an den Pi absetzen. Demnächst wird sie voll kompatibel mit dem Webinterface sein, das Sledge gerade bastelt.
- zu WFT: Vieleicht den Ubi am Copter als Accespoint konfigurieren und die Groundstation und Fotodingens als Client? Dann sparst Du dir den Switch. Keine Ahnung, ob das sinnvoll ist.
 

hornetwl

Erfahrener Benutzer
Habe hier leider etwas Aerger mit der App: Installation laeuft kommentarlos und ohne Fehler, beim Starten erscheint ein schwarzer Bildschirm. Dann passiert oft nichts mehr, manchmal kommt eine Meldung " wurde beendet".

Hardware ist ein auf CM11 (Android 4.4.2) umgehacktes Amazon Kindle Fire HD.

Irgendwelche Ideen, um den Fehler einzugrenzen?
 
Habt ihr das schon gesehen?
http://www.wirelessdv.com/en/index
Arbeiten die auch mit dem Pi?
Wenn ja wäre es ja interessant zu wissen wie es Receiver seitig mit der Rechenleistung aussieht.
Jap da hat sich einer gedacht das ganze kommerziell anzubieten. Der nutzt auf beiden Seiten den Pi. Naja aus der HP wird nicht ersichtlich welche WLAN module er benutzt. Aber wen er reichweiten von bis zu 20Km angibt wohl auch die Ubis. Naja wie es halt immer so ist wird bei den daten übertrieben.
 

nique

Legal-LongRanger
Hmm, die UBIs könnens doch fast nicht sein, dann wäre das Gehäuse länger und dicker. Insbesondere wenn er den LAN-Stecker dran lässt...
Das Menu für die Programmsteuerung ist aber schon noch ne gelungene Idee - zumal wenn man kein PC hat. Das wäre die Variante Brille. Leider nur bis 720px. Mehr kann wohl die GroundStation nicht dekodieren [grins]. Da seid Ihr Jungs schon noch nen Zacken weiter! Auch wenn es noch keiner ein Gehäuse gemacht hat. Im Flieger brauch ich das eh nicht ;)
 

Lonestar78

Erfahrener Benutzer
Jap da hat sich einer gedacht das ganze kommerziell anzubieten. Der nutzt auf beiden Seiten den Pi. Naja aus der HP wird nicht ersichtlich welche WLAN module er benutzt. Aber wen er reichweiten von bis zu 20Km angibt wohl auch die Ubis. Naja wie es halt immer so ist wird bei den daten übertrieben.
Ich glaube die Kollegen nutzen vieleicht die Alpha Hardware. Sieht aus, als wäre der WLAN Kram per USB angeschlossen.
720p ist auch naheliegend, wegen der geringeren Latenz. Nichts Aufregendes ;-)
Aufgenommen wird auf dem Sender Pi, das sieht man im netten OSD. Ist auch sinnvoll.
Vieleicht haben die Kollegen hier ja mitgelesen;-) Aber wir sind ja nicht alleine in der gleichen Richtung unterwegs
 

hornetwl

Erfahrener Benutzer
Habe jetzt meinen Testcopter zusammen - ein erster Bodentest zeigt jedoch noch Schwierigkeiten: Obwohl bei einem Ping-Test nur 0...1% der Pakete verloren gehen (Copter strategisch hinter Wand eine Etage tiefer versteckt), bricht der Stream (RTSP) komplett zusammen und zeigt nur hin und wieder mal ein Bild. Ein kurzer Blick mit Wireshark zeigt, dass der Client mit dem Raspi offenbar RTP over UDP als Transport aushandelt.

Als Client habe ich zwei verschiedene Linux-Laptops mit gstreamer 1.2 und 1.4 ausprobiert - keine Unterschiede.

Was ist aktuell die am besten funktionierende Streaming-Methode?
 

Lonestar78

Erfahrener Benutzer
@hornetwl, habs mir kurz angeschaut. Passt, das hab ich gebraucht.
Sieht so aus, als ob es ein Problem mit der GStreamer integration im Zusammenspiel mit dem omx Video decoder gäbe...
Lösung? Keine Ahnung.
Ich mach mal ein update in der App von Gstreamer 1.3.91 auf 1.4.1
Vieleicht hilfts...
 

hornetwl

Erfahrener Benutzer
Bin der Problematik mit dem stehenden Stream auf die Spur gekommen: offensichlich stört die Taranis (zwischen den beiden Ubis positioniert) doch erheblich. Sobald die Anlage aus ist, läuft alles einwandfrei, Anlange ein - Stream steht. Der Effekt lässt sich nur beobachten, wenn man für ein etwas abgeschächtes Signal sorgt (-76dBm laut Ubi). Eine genaue Beobachtung des Ping-Tests zeigt auch hier Ausfälle von etwa einem Prouzent, die genau durch die eingeschaltete Taranis verursacht werden.

Ein Gegentest mit FASST zeigt diesen Effekt nicht. Nun könnte man vermuten, dass das am Telemetriesender im Empfänger liegt - das ist aber nicht der Fall: Ein Abziehen des Empfängers ändert genau gar nichts - sobald die Taranis sendet, ist der Stream kaputt.

Mal schauen ob sich der Problematik mit etwas (Kanal-)Tuning bekommen lässt.

Noch eine Feststellung: der RTSP-Stream ist mitnichten ein TCP-Stream. Lediglich die Aushandlung der Verbindung passiert per TCP, das Streaming selbst wie gehabt per RTP/UDP. Insofern hat die Streamingmethode keinerlei Einfluss auf die Störungen.
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten