EZ-Wifibroadcast, HD FPV in günstig und einfach

Status
Nicht offen für weitere Antworten.

careyer

DröhnOpaRähta
Hallo zusammen,

wir haben gestern mal mit einer leicht modifizierten EZ 1.5 im wahrsten Sinne des Wortes einen "Feldtest" unternommen und haben die Performance von einem 2,4GHz und 5,8Ghz Testsetup evaluiert und miteinander verglichen.

Testaufbau 2,4Ghz:
AirPi: Pi A+
Air-WiFi : Alfa 036NHA
Air-Antenna: Alfa 036NHA Stock Antena
Gnd Pi: Pi3
Gnd-WiFi: 2x TP-Link 722N
Gnd-Antenna: 2x TP-Link 5dbi Rubber Ducky

Testaufbau 5,8Ghz:
AirPi: Pi A+
Air-WiFi : Alfa 052NH
Air-Antenna: Connex ProSight Antenna
Gnd Pi: Pi3
Gnd-WiFi: 2x CSL-300
Gnd-Antenna: 4x WA5VJB Quad-Patch

Als Terrain haben wir uns eine große ländliche Freifläche in der Nähe von Kircheib/NRW ausgesucht. Hier wurden die beiden Sender jeweils auf einem Strohballen positioniert und im Anschluss ging es mit dem Auto quer durch die Felder. Wir haben also zunächst einen Boden-zu-Boden Test durchgeführt. Dieses Bild hier illustriert die angefahrenen Messpunkte:



Das 5,8Ghz System funktionierte solange gut, wie eine direkte Sichverbindung gegeben war. Das Terrain hatte jedoch einige Herausforderungen in Petto: entweder kleine Wäldchen oder Täler in deren Funkschatten die Sender verschwanden (ergo: direkte Sichtverbindung unterbrochen oder gestört - Obstacles jeweils rot markiert).
Bei 5,8Ghz war in diesen Situationen trotz gerichteter Patch-Antennen das Signal sofort vollständig weg. 2,4Ghz mit den omidirektionalen Antennen hatte zwar auch zu kämpfen... hatte aber sowohl an POS1 und POS2 sobald Pakete empfangen wurden ein glasklares Bild.

POS1 ging nur bei 2,4Ghz, POS2 sowohl mit 2,4 als auch mit 5,8Ghz... letzteres aber deutlich instabiler als der 2,4Ghz Link.

Soweit so gut. Das Ergbnis hatten wir so auch erwartet.

Das bestärkte uns nur darin die RC-Steuerung über WifiBroadcast (hierin lag unsere leichte Modifikation) mit 2,4Ghz zu testen. Als RC-Steuerung setzen wir auf eine Erweiterung der EZ 1.5. Als Steuerprotokoll kam hier MavLink zum Einsatz. Als Fluggerät diente ein pragmatisch zusammengebastelter Testcopter mit Pixhawk Steuerung. Letzteren haben wir gewählt weil die RTH-Fähigkeiten dieser Plattform extrem zuverlässig und gut funktionieren. (hinsichtlich "Precision Landing" kann sich der DJI Mavic noch etwas beim Pixhawk abgucken ;-)

Hier mal ein Bild des genutzen Setups:
(man beachte die fehlende RC-Antenne an der Taranis - diese dient lediglich als besserer USB-Jockstick für den Pi3 im dahinter angebrachten Alu-Gehäuse)


Als Ergebnis konnten wir 700m Entfernung erfliegen - vollkommen ohne Störungen und mit glasklarem Bild und ebenfalls aufgebohrtem Telemetrie-OSD. Hier wäre deutlich(!!) mehr drin gewesen aber leider spielte unser in die Jahre gekommener Akku nicht mit (massiver Voltage Drop unter Last, sodass wir vorzeitig abbrechen mussten).

Dasselbe Setup mit einer jüngeren Version von EZ-Wifibroadcast (ich glaube v1.2) hat aber bereits vor ca. 1 Jahr etwa 1,7km geschaft (Video+RC über 2,4Ghz WBC). Hier gab es zwar im Video noch relativ häufig Bad-Blocks... die Steuerung lief aber super stabil. Hier wäre ebenfalls noch mehr Strecke drin gewesen. Einzig limitierender Faktor war eine parallel betriebene 3DRadio Strecke (433Mhz) die bei Erreichen ihrer Reichweitengrenze ein Telemetry-Failsafe und damit RTH auslöste.

Kleiner Exkurs: Zu etwa dieser Zeit wurde der DJI Mavic vorgestellt und unsere Motivation etwas Eigenes auf die Beine zu stellen war am Boden. Durch die zunehmende Gängelei seitens DJI haben wir die Arbeit am Projekt aber nun wieder aufgenommen


Fazit: Mit der EZ 1.5 hat Rodizio einen super Job gemacht.
Unser Test hat gezeigt, dass sobald eine Sichtverbindung zum Sender möglich ist das Signal stabil wie eine Eins steht und kaum Bildstörungen den Eindruck stören. Wirklich eine tolle Leistung und ein super Engagement was ein dickes THUMBS UP an Rodizio verdient. Ich freue mich, dass wir unsere Modifikationen (RC via MavLink und ein überarbeitetes OSD mit mehreren Screens) Rodizios Projekt heute nach zahlreichen erfolgreichen Tests zur Verfügung stellen können. Wir würden uns freuen wenn diese Features Ihren Weg in EZ-WiFiBroadcast v1.6 fänden und wir damit einen Beitrag zur Weiterentwicklung leisten könnten.

LG
careyer

P.S: anbei noch ein Bild des neuen OSDs (nein das ist kein Gesicht im Hintergrund sondern ein Blumentopf). ;-)


P.S.S: Ich bin nicht der Entwickler (das ist ein guter Freund) sondern lediglich der "Flüsterer" der zusammen bringt was zusammen gehört - liegt wohl an meinem Job ;-)
 
Zuletzt bearbeitet:

rodizio1

Erfahrener Benutzer
Danke für die Blumen. Ja, gerne, immer her mit dem Code :)

Das OSD sieht so pixelig aus, habt Ihr die Goggles One auf 1080p gestellt (die meldet sich nur als 1280x720 per EDID ...)

Falls nein, in der config.txt die drei Sachen einkommentieren:

hdmi_force_hotplug=1
hdmi_group=1
hdmi_mode=16
 
Das bestärkte uns nur darin die RC-Steuerung über WifiBroadcast (hierin lag unsere leichte Modifikation) mit 2,4Ghz zu testen. Als RC-Steuerung setzen wir auf eine Erweiterung der EZ 1.5. Als Steuerprotokoll kam hier MavLink zum Einsatz. Als Fluggerät diente ein pragmatisch zusammengebastelter Testcopter mit Pixhawk Steuerung. Letzteren haben wir gewählt weil die RTH-Fähigkeiten dieser Plattform extrem zuverlässig und gut funktionieren. (hinsichtlich "Precision Landing" kann sich der DJI Mavic noch etwas beim Pixhawk abgucken ;-)
Nachdem ich das gleiche Setup nutze würden mich speziell eure Modifikationen interessieren bzgl. mavlink upstream... ;)
 

careyer

DröhnOpaRähta
Danke für die Blumen. Ja, gerne, immer her mit dem Code :)

Das OSD sieht so pixelig aus, habt Ihr die Goggles One auf 1080p gestellt (die meldet sich nur als 1280x720 per EDID ...)

Falls nein, in der config.txt die drei Sachen einkommentieren:

hdmi_force_hotplug=1
hdmi_group=1
hdmi_mode=16
Den Code solltest du schon haben... Frank hat dich heute per Mail angeschrieben ;-)
OSD sollte soweit scharf sein... Wir haben nur die Schrift vergrößert weil man sie ansonsten z.B. in einer Cinemizer OLED nicht mehr lesen kann weil zu klein (oder die Augen inzwischen zu schlecht sind) ;-)

@r0ck3t: Ich würde dich bitten zu warten bis Rodizio das ggf. in das v1.6 übernommen hat. Ansonsten laufen hier die Fäden schnell auseinander ;-)
 
@All: mein Kumpel careyer ist vielleicht ein wenig zu ungeduldig, möglicherweise hat der arme rodizio für die v1.6 schon andere Pläne, wir sollten ihm ein wenig Zeit lassen. Es wird auch noch eine 1.7 oder 1.8 geben....

@rodizio: das OSD ist knackscharf, ich habe das Foto meines 4k Samsung allerdings nur mit 640 x400 gepostet :)

@r0ck3t: da ich aus Deinen bisherigen Posts ablese, dass Du weisst, wie Du das einbauen kannst, hier der Code im Anhang.


Gruss
Frank
 

Anhänge

Zuletzt bearbeitet:
@r0ck3t: da ich aus Deinen bisherigen Posts ablese, dass Du weisst, wie Du das einbauen kannst, und der Code minimal ist:
Vielen Dank dino, ich bin ja ungeduldig ;)
Bin ich froh das du das File noch angehängt hast, der outputbuffer is in Deinem Post zweimal gesetzt, im File war es richtig. Seh ich das richtig das ihr einzig die RC receive Funktion angepasst habt, sonst an der mavlink Kommunikation nichts geändert habt?
 
in der .profile in der Zeile wo cmavnode (einfach nach "/root/cmavnode/cmavnode" suchen ...) gestartet wird, "--verbose" hinzufügen als option.
Hab ich gemacht allerdings läuft am Air rPi ja gar kein cmavnode :D

Ich hab am Air Pi ja schon alles das aus dem telemetry rx kommt direkt in ein file geschrieben (ansonsten geht das nur direkt gegen den seriellen Port der am FC hängt), da kamen alle messages völlig korrekt an. Jetzt hab ich noch per sniffer am serial port nachgesehen ob die Pakete irgendwie bei der Übertragung zeitlich zerschnitten werden. Nur jedes Mal wenn ich den sniffer aktiviert habe funktionierte die Übertragung also hab ich mir nochmal die stty settings angesehen die wir ja zuletzt auf raw gestellt haben. So wie es aussieht wird damit aber nur etwa jede zehnte message vom FC akzeptiert. Also wieder zurück auf die letzte Einstellung (Korrektur der Parameter weil LF und CR vertauscht wurden) und jetzt geht es relativ zuverlässig. Lag also auf jeden Fall an den stty Parametern...

Jetzt muss ich nur noch den RTP Stream so hinbekommen das er in QGC und Tower korrekt dargestellt wird und ich bin happy [emoji6]
 
Danke r0ck3t, der outputbuffer ist mir bei einer Korrektur durchgerutscht, es war schon spät...
Hab die Codefragmente im Text jetzt entfernt, das File ist ja angehängt.

Es ist richtig, dank Rodizios Vorarbeit braucht der Mavlink-Mod lediglich 13 Zeilen Code in rcrx.c.

Also wieder zurück auf die letzte Einstellung (Korrektur der Parameter weil LF und CR vertauscht wurden) und jetzt geht es relativ zuverlässig. Lag also auf jeden Fall an den stty Parametern...
Schön, dass es klappt!
Bei unserer ersten Mavlink-Implementation vor etwa einem Jahr sind wir exakt mit den gleichen stty-Parametern geflogen wie in der v1.5, bei unserem jetztigen Test mit "raw". In beiden Fällen war die Steuerung problemlos, aber bei 10% von 83 Paketen kommen ja immer noch 8 Pakete / Sekunde an...

Wie überprüfst Du die Validität der Pakete am Pixhawk und wie sind Deine stty-Parameter jetzt genau?
 
Zuletzt bearbeitet:
Wie überprüfst Du die Validität der Pakete am Pixhawk und wie sind Deine stty-Parameter jetzt genau?
Leider hab ich keine (einfache) Möglichkeit gefunden um die Error Rate direkt am Pixhawk zu prüfen, aber nachdem das Umschalten des Flight-Modes in den meisten Fällen nicht klappte habe ich einfach die Message so oft gesendet bis die HEARTBEAT messages mit verändertem Mode vom FC zurück kamen. Alternativ hab ich mir überlegt direkt per "shell" am Pixhawk mitzulauschen und den entstandenen data dump dann auszuwerten, oder die verworfenen Pakete (per Änderung in der Firmware) mitzuzählen.

Als stty-Parameter verwende ich jetzt (.profile):
Code:
FC_TELEMETRY_STTY_OPTIONS="-icrnl -imaxbel -opost -isig -icanon -echo -echoe -ixoff -ixon"
Und falls das auch noch interessiert, die restlichen Parameter (.profile), sind aber eher die letzten Testwerte:
Code:
TELEMETRY_BLOCKS=1
TELEMETRY_FECS=1
TELEMETRY_BLOCKLENGTH=263 #Mavlink Max
TELEMETRY_MIN_BLOCKLENGTH=8 #Mavlink Min
 
Das ist seltsam, "raw" schaltet schon die meisten Optionen aus:

Code:
:~# stty -F /dev/serial0 raw 57600
:~# stty -F /dev/serial0 -a
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iucl
-ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoct
echoke
Probier doch mal:
Code:
stty -F /dev/serial0 raw -onlcr -echoe -echok -echoctl -echoke 57600
 
Kleine Zwischenfrage:
Gehe ich recht in der Annahme, dass die zwei Antennen des ALFA AWUS052NH als tx so recht keinen Sinn machen? Besser als rx für diversity und den 51NH als tx?
 

stxShadow

Erfahrener Benutzer
Bei mir funktioniert der 52NH prima als Sender. Insbesondere, weil ich so keine Abschattung beim drehen durch den Copter habe.

Copter.jpg

Man sieht ggf die Antennen an den beiden Auslegern.

Gruß

Jens
 
Bei mir funktioniert der 52NH prima als Sender. Insbesondere, weil ich so keine Abschattung beim drehen durch den Copter habe.

Anhang anzeigen 167503

Man sieht ggf die Antennen an den beiden Auslegern.

Gruß

Jens
Bei mir gibts keine Abschattung, der Alfa soll in einen Segler rein, wo die Antenne(n) oben rausschaut mit freier Sicht rundrum. Deshalb meine Frage, ob da zwei Antennen überhaupt was bringen.
 

DangerDave

Erfahrener Benutzer
Hi, eventuell passt es ja auch gerade zur Mavlink Diskussion. Ich hatte vor ein paar Wochen im Thread der VR-App, wegen der Implementierung des Headtrackings mal den Stand angefragt, bis jetzt ohne Antwort. Eventuell seid ihr da schon an der Umsetzung. Mich würde interessieren, ob es hierzu irgendwelche Neuerungen gibt, oder ob das ganze erstmal auf Eis gelegt wurde.

Beste Grüße!
 
Das ist seltsam, "raw" schaltet schon die meisten Optionen aus:

Code:
:~# stty -F /dev/serial0 raw 57600
:~# stty -F /dev/serial0 -a
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iucl
-ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoct
echoke
Probier doch mal:
Code:
stty -F /dev/serial0 raw -onlcr -echoe -echok -echoctl -echoke 57600
Hab ich so probiert (bis auf höhere Baudrate), allerdings kaum eine Änderung des Verhaltens bemerkt. Allerdings geht beides eigentlich ausreichend zuverlässig für mich, nur der Mission-Upload macht noch Probleme. Bin aber nicht sicher ob da die GC Software spinnt, das teste ich noch gegen das Radio Dongle...

Btw: Neben der telemetry_blocksize gibt es ein paar Zeilen darunter noch einen zweiten Parameter zur Einstellung der UDP Blockgröße... der ist bei mir kleiner als die blocksize eingestellt, sollte die nicht auf jeden Fall größer sein?
 

jewa

Neuer Benutzer
Hallo Zusammen

ich versuche mich gerade mit EZ-Wifibroadcast und bekomme den Video Ausgang nicht hin. HDMI geht ohne Probleme aber Video nicht.
Ist das Normal?
Hier der Auszug aus meiner config.txt:


hdmi_force_hotplug=1
config_hdmi_boost=4
overscan_left=24
overscan_right=24
overscan_top=16
overscan_bottom=16
disable_overscan=0
overscan_scale=1
hdmi_cvt=480 272 60 3
# uncomment for composite PAL
sdtv_mode=2

ich freue mich über jede Antwort!
 

rodizio1

Erfahrener Benutzer
Careyer/dino_de:

Habe bis jetzt alles erst 'überflogen', aber wie ich schon sagte: Sehr geil, das wird wirklich ein Schritt nach vorne. Muss noch schauen ob ich zur 1.6 alles mit rein nehme (oder eine Beta mache?), und wieviel Aufwand das wird. R/C mit Mavlink sieht auf jedenfall schnell machbar aus.


rocket schrieb:
da kamen alle messages völlig korrekt an. Jetzt hab ich noch per sniffer am serial port nachgesehen ob die Pakete irgendwie bei der Übertragung zeitlich zerschnitten werden. Nur jedes Mal wenn ich den sniffer aktiviert habe funktionierte die Übertragung also hab ich mir nochmal die stty settings angesehen die wir ja zuletzt auf raw gestellt haben. So wie es aussieht wird damit aber nur etwa jede zehnte message vom FC akzeptiert. Also wieder zurück auf die letzte Einstellung (Korrektur der Parameter weil LF und CR vertauscht wurden) und jetzt geht es relativ zuverlässig. Lag also auf jeden Fall an den stty Parametern...
Habe die Infos jetzt hier aufgeschrieben:
https://github.com/bortek/EZ-WifiBroadcast/issues/31

Erstmal nur -crnl und -ocrnl (für Output) um nicht zuviel zu verändern ...

Kamen die Pakete denn korrekt heraus? Also _nicht_ zeitlich zerschnitten? So rein theoretisch müsste cmavnode immer genau eine Mavlink message an den wbc telemetry tx liefern. Werde mal schauen, dass ich da ein debug-logging einbaue ...

Btw: Neben der telemetry_blocksize gibt es ein paar Zeilen darunter noch einen zweiten Parameter zur Einstellung der UDP Blockgröße... der ist bei mir kleiner als die blocksize eingestellt, sollte die nicht auf jeden Fall größer sein?
Du meinst die für socat für die FPV_VR app auf port 500x? Ich glaube die FPV_VR stellt sich nicht so an wie das Mavlink GCS Zeugs und funktioniert einfach, von daher egal.


jpfeifer schrieb:
Kleine Zwischenfrage:
Gehe ich recht in der Annahme, dass die zwei Antennen des ALFA AWUS052NH als tx so recht keinen Sinn machen? Besser als rx für diversity und den 51NH als tx?
Mehr Antennen sind grundsätzlich immer besser, würde den 052NH als TX und mindestens zwei diversity-sticks (also 4 RX-Antennen) als RX empfehlen. Theoretisch hat der 052NH auch als RX Vorteile wegen des LNA in den Amps, wieviel das in der Praxis bringt hat aber glaube noch niemand verglichen. Ich würde einfach 2-3 günstige diversity low-power Ralink sticks wie die CSL-300 für den RX nehmen.


jewa:
ich glaube das HDMI Zeugs darf nicht gleichzeitig an sein, probier' mal:

#hdmi_force_hotplug=1
#config_hdmi_boost=4
overscan_left=24
overscan_right=24
overscan_top=16
overscan_bottom=16
disable_overscan=0
overscan_scale=1
#hdmi_cvt=480 272 60 3
# uncomment for composite PAL
sdtv_mode=2
 
Habe die Infos jetzt hier aufgeschrieben:
https://github.com/bortek/EZ-WifiBroadcast/issues/31

Erstmal nur -crnl und -ocrnl (für Output) um nicht zuviel zu verändern ...

Kamen die Pakete denn korrekt heraus? Also _nicht_ zeitlich zerschnitten? So rein theoretisch müsste cmavnode immer genau eine Mavlink message an den wbc telemetry tx liefern. Werde mal schauen, dass ich da ein debug-logging einbaue ...
Bestens, danke, das Issue hätte ich wohl auch selber erstellen können ;)

Wie gesagt, die Pakete kommen am AirPi, bevor sie an den FC gehen, komplett richtig an (Sequenz hab ich noch nicht kontrolliert). Ich gehe aber schwer davon aus das entweder die Sequenz nicht korrekt ist oder eben manche Pakete zerschnitten und deswegen vom FC nicht akzeptiert werden. Das fällt speziell beim Up- oder Download von Missions auf. Je nach GC Software wird damit dann korrekt umgegangen oder nicht, Tower (Android) oder APM (MacOS) kommen damit irgendwie zurecht, per QGC gibt das massive Probleme. Das trifft allerdings nicht nur wbc sondern auch Übertragung per 3DR Radio, wenn da die Verbindung nicht gerade 100% sauber ist sehe ich genau das selbe Verhalten.

Du meinst die für socat für die FPV_VR app auf port 500x? Ich glaube die FPV_VR stellt sich nicht so an wie das Mavlink GCS Zeugs und funktioniert einfach, von daher egal.
Ich meinte die TELEMETRY_UDP_BLOCKSIZE, die wird für socat von /root/telemetryfifo2 auf den target UDP Port verwendet. Wenn ich das richtig verstehe kann da potentiell schon ein mavlink Paket (im downlink) zerschnitten werden, oder?

Edit: Nochmal das dumpfile am AirPi angesehen, da sind die messages doch nicht ganz OK, ich hab bis jetzt nur geschaut ob alle angekommenen OK sind, allerdings erkennt man an der Sequenznummer das erstens 1-2 von 10 Messages nicht ankommen und auch teilweise die Sequenz durcheinander ist. Das führt natürlich zu Problemen (z.B. Invalid Sequence) bei Missions. Wer ist da jetzt schuld, cmavnode oder der wbc link?
 
Zuletzt bearbeitet:

jewa

Neuer Benutzer
Vielen Dank für die schnelle antwort rodizio1

hat aber leider nicht Funktioniert. Verschwommene Schrift mit 3 Synchronisation Zeilen und einem "wackligen"
weisen rechten Rand. Der Video Eingang Funktioniert normaler weise richtig.
Benutzt Ihr alle HDMI oder verwendet jemand auch den Video Ausgang?
Vielen Dank für jede Antwort!

Jens
 

Anhänge

Hallo zusammen,

nach gründlichem Studium vieler Webseiten und den Beiträgen hier im Forum habe ich ein FPV-System für meinen Hexacopter gebaut.
Mit EZ-Wifibroadcast-1.5, Sender: Pi_Cam-1.3, Raspi-Zero-W, AWUS051NH, Empfänger: 2x CSL300, Raspi3, Raspi-Screen. Funktionert prima!
Ich würde gerne mein kleines leichtes Linux-Tablet als Empfänger nutzen.
Bisher klappt nur eine Videoübertragung mit dem image0.4 von befinitv im Sender auf das Linux-Tablet,
das aber auch nur auf Kanal 149 (5.745 Ghz), wähle ich einen anderen Kanal in settings.sh (z.B. 140 5,700 Ghz) und auch
im Script auf dem Tablet geht gar nichts.
Frage1: Wie kann ich in den Dateien von image0.4 einen anderen Kanal im 5Ghz-Bereich wählen?
Frage2: Gibt es einen Weg die Video-Daten von EZ-Wifibroadcast-1.5 auf einem Linux-Rechner zu empfangen?
Über Antworten oder Lösungsvorschläge würde ich mich freuen.

Giovanni
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten