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

Status
Nicht offen für weitere Antworten.

rodizio1

Erfahrener Benutzer
Careyer: 3 Gründe ;) Bei Ralink geht keine CTS protection, die Medium Access Parameter sind nicht passend und es lassen sich keine 'kurzen' Pakete senden. Lässt sich alles lösen, aber aufwendig. Habe da nie Zeit reingesteckt weil Ralink eher auf 5GHz genutzt wird und da hat man das 2.4GHz Band ja eh frei.


Murdok1980: Wifibroadcast config sieht richtig aus. Das mit EZ GUI was kommt wird wohl daran liegen, dass das MSP spricht schätze ich mal (wäre mir jedenfalls neu dass ezgui mavlink versteht). Bist Du ganz sicher, dass uart1 auch bzw. immer MSP eingeschaltet haben muss? Das ist bei meinen (älteren) Sp Racing F3 und Flip32 so, aber die haben auch kein USB VCP, sondern da ist der USB anschluss eben uart1 und ohne einen MSP port sperrt man sich aus. Das jetzt zusätzlich zum usb vcp noch uart1 auf msp stehen muss klingt für mich erstmal unlogisch. Aber ich bin mir nicht sicher, hab' keine FC mit usb vcp. Ich würde mal einen anderen uart versuchen und den nur auf mavlink stellen. Oder beim uart1 msp ausmachen (und vorher config dump speichern falls du dich aussperrst und neu flashen musst).

Edit: Noch was: Bei meinen FCs (bei denen uart1 und usb 'shared' ist) ist es so, dass ich zwar Telemetrie auf uart1 legen kann, die wird aber erst ausgegeben, wenn armed ist (damit man un-armed noch den Konfigurator nutzen kann).
 
Zuletzt bearbeitet:
@rodizio1 deine Vermutung war goldrichtig
Wichtig!
Das sollte unbedingt ins Wiki oder so aufgenommen werden.
Also bei einem Omnibus F3 AIO und ich vermute bei allen anderen ähnlichen Modellen auch, ist es zwingend erforderlich bei dem
UART (UART1 oder UART2) wo die Telemetrie angeschlossen ist und an den Air Pi übergeben wird das MSP auszuschalten. Dann bei der Telemetrie Mavlink anschalten mit 57600 baud und es funktioniert. LTM kann man auch einstellen, allerdings muss dann in der OSD config das Protokoll geändert werden.
Grüße André
 

careyer

DröhnOpaRähta
Danke rodizio, jetzt verstehe ich das :).
Ich werde versuchen heute Abend oder morgen mal mit einem 036NHA (TX) und 2x 722N (RX) zu testen und dir Bescheid zu geben ob es funktioniert. Bin momentan nur leider gesundheitlich etwas angeschlagen und falle nach der Arbeit regelmäßig direkt komatös ins Bett.

Da ich langfristig (Mavlink Telemetrie Up+Downlink) sowie IBUS nutzen möchte werde ich tatsächlich versuchen müssen ob man den Pixracer direkt via USB mit dem Raspi verbinden und darüber einen zweiten seriellen Port schaffen kann. Zumindest lässt sich beim Pixrracer via USB eine Serielle Verbindung zum PC aufbauen - sollte damit auch vom Raspi aus möglich sein. Spannend wird nur sein, ob der Serial-Port am PixRacer zwischen Pfostenleiste und USB-Port irgendwie geshared ist (war zumindest damals beim 16bit APM so. Falls ja, dann ergibt sich das gleiche Problem wieder - nur diesmal auf der anderen Seite der Peripherie ;-).

P.S: Auf GitHub hatte ich die Diskussion über das Einbetten der OSD Informationen in die Daten die auf den USB-Stick geschrieben werden mitverfolgt. Klar kannst du nicht das Video komplett neu rendern um die Informationen dort einzubetten.... eine mögliche Lösung wäre allerding die OSD-Daten separat in einen eignen Videostream (vor z.B. schwarzem oder grünen Hintergrund) zu speichern. Man könnte Video und OSD dann später am Rechner in Form von Videoschnitt ganz einfach wieder übereinander legen. E'Viola. Ginge das?

P.S.S: Mir ist übrigens aufgefallen, dass die "Undervoltage or Overtemperature" Meldung (bekomme ich einfach nicht weg) in das aufgezeichnete Video mit einfließt. Ist das intendiert und ließe sich so ggf. auch der Rest des OSDs einbetten?
 
Zuletzt bearbeitet:

careyer

DröhnOpaRähta
Okay, habe heute die iBUS Geschichte mit Atheros Karten versucht (TX=Alfa 036NHA, RX=2x 722N), leider gleiches Ergebnis... aus dem iBUS Adapter kommt rein gar nix raus :-/

Anbei mal das Log. Habe ich etwas falsch gemacht?

TELEMETRY_UPLINK=disabled/mavlink (keines der Settings macht einen Unterschied)
RC=ibus
FC_TELEMETRY_BAUDRATE=115200 (beides vorsichthalber auf 115200 baud gesetzt)
FC_RC_BAUDRATE=115200
 

Anhänge

rodizio1

Erfahrener Benutzer
Hmm, config sieht richtig aus und der rctx prozess läuft auch. Zeigt die dbm Anzeige für RC was an? Hast Du eine Möglichkeit mit was anderem zu testen um erstmal zu sehen, ob was aus dem Air Pi uart herauskommt? Usb2serial adapter am PC mit Putty z.B.
 

careyer

DröhnOpaRähta
Hmm, config sieht richtig aus und der rctx prozess läuft auch. Zeigt die dbm Anzeige für RC was an? Hast Du eine Möglichkeit mit was anderem zu testen um erstmal zu sehen, ob was aus dem Air Pi uart herauskommt? Usb2serial adapter am PC mit Putty z.B.
Danke für deine schnelle Nachricht und Unterstützung.
Die dbm Anzeige für RC zeigt in der Tat nichts an. Einen Serial2USB habe ich leider keinen zur Hand (oder ist das ein einfacher 3,3V FTDI?)

Liebe Grüße
Thomas



Gesendet von iPhone mit Tapatalk
 

Schlonz

Erfahrener Benutzer
Ich habe mal eine (vielleicht total dumme )Frage an die Netzwerk-Profis hier:
Das Grundprinzip von Wifibroadcast ist ja, die Wifi-Adapter in den Monitor Mode zu schalten und damit dann Datenblöcke ohne Ack/Retry einfach zu senden. Damit wird ja erreicht, dass bei schlechter werdender Verbindungsqualität die Latenz nicht steigt.

Warum betreiben wir eigentlich den Aufwand mit dem Monitor Mode usw. (mit den daraus sich ergebenden Konsequenzen wie dass nur ganz wenige Adapter gehen), und senden die Streams nicht einfach nur ordinär über 802.11 als Broadcast- oder Multicast-Frames?

Wahrscheinlich übersehe ich gerade etwas, aber Danke wenn es mir mal schnell jemand in Stichworten erklärt :)

Viele Grüße,
Stefan
 

rodizio1

Erfahrener Benutzer
Careyer:
OSD: Bei Deiner Idee würde das "auspacken" des Videostreams entfallen und weniger Last erzeugen. Könnte klappen, aber trotzdem müsste das noch jemand programmieren ;)

Undervoltage: Ja, die Meldung fliesst ins aufgezeichnete Video mit ein liegt daran, dass ich beim Starten prüfe ob Unterspannung/Übertemperatur aufgetreten ist, wenn ja, dann startet raspivid nicht mit den "normalen" Parametern sondern mit der Undervoltage Warnung als Annotation Text. Und mit auf 3Mbit festgesetzter Bitrate (falls Du Dich über schlechte Qualität wundern solltest).

Du kannst die Checks in der .profile in der tx_function herausnehmen ("check if over-temp or undervoltage occured" oder so, müsste da irgendwo kommentiert sein), aber das ist halt ein wenig so wie Motorkontrolleuchte mit Isolierband überkleben ;)

Wegen der R/C Funktion: Konfig sieht richtig aus, kann es sein dass der Joystick irgendwie nicht erkannt wurde? Muss da glaube noch irgendwie eine Meldung einbauen wenn der Joystick angesteckt wurde. Wenn Du mit alt-F3 auf tty3 schaltest, kannst Du sehen was der R/C TX macht bzw. ob er den Joystick erkannt hat und sendet (TX abschalten damit das Video nicht darüber liegt).


Schlonz:
Ginge theoretisch auch, aber ist auch nicht unbedingt einfacher. Ack/Retry wird man mit broadcasts zwar los, aber man hat immer noch eine Verbindung die abbrechen kann, mehrere Empfängerkarten geht auch nicht ohne weiteres, man muss hostapd laufen lassen der wieder Probleme mit sich bringt. Kriegt man wahrscheinlich auch alles gefixt, aber ist dann teilweise auch wieder je nach Chipsatz und Treiber etc. anders.
 

careyer

DröhnOpaRähta
Hallo rodizio,

Ja Joystick wird erkannt. Kann ich sagen weil es mit RC=mavlink klappt. Zumindest bewegen sich die Balken bei der RC Kaibrierung im Mission Planner wenn man an den Knüppeln rumrūhrt ;-)

Bei RC=ibus kommt aber wie gesagt irgenwie nix raus. dBm Anzeige steht wie gesagt auch auf 0.

Was könnte ich da noch testen?


Gesendet von iPhone mit Tapatalk
 

careyer

DröhnOpaRähta
Hallo Rodizio,

habe jetzt ein paar Tage in die Fehlersuche gesteckt und den Übeltäter wieso das mit dem ibus nicht klappte identifizieren können. Deshalb bin ich hier einen kurzen Status schuldig (vorab: es liegt nicht an deiner Implementierung - die funktioniert prima ;-):

Zunächst eine kurze Beschreibung meines Setups:
Code:
AirPi (serial0:ibus) --> iBus-2-SBUS+PPM Adapter* --> Pixracer(RCin:SBUS)
                           | | | | | | | | | | |
                            Channel 1-10 (PPM)
                            Servos/Peripherie
Fehleranalyse:
Zunächst haben wir an den serial0 des AirPi einen FTDI angeschlossen und via Putty geschaut ob aus dem Port etwas rauskommt wenn ibus konfiguriert ist (Danke für den Tipp mit Putty - manchmal sieht man die naheliegendste Lösung einfach nicht). Hier liegt nach vollständigem Bootvorgang des AirPi ein Datenstrom an TX an. Ergo: Sieht gut aus - Wir gehen also erstmal davon aus, dass am serial0 tatsächlich ibus anliegt. (da hatte ich auch nicht dran gezweifelt, du sagtest ja dass du das getestet hast).

Als nächstes haben wir uns dem iBus-2-SBUS+PPM Adapter genähert. Zunächst mal mit einem Osziloskop geschaut, ob hier ein Signal anliegt. Ergebnis: Ja, auch hier liegt ein wie auch immer geartetes Signal an. Das ist schon einmal gut. Weitere Analyse ergibt: Ja hier liegt tatsächlich ein sauberes SBUS Signal mit allen Kanälen an.
Der nächste Blick fiel dann auf die PPM Outputs Ch1 ... Ch10 des Adapters. Hier wollen wir ja noch vor(!) der FC einige PPM Kanäle abgreifen da wir diese aufgrund von Hardwarebeschränkungen des PixRacers (zu wenige AUX Outs) von dort nicht mehr ausgekoppelt bekommen.

JETZT kommts: An Ch1-Ch10 liegt vollständiger Müll an... Entweder gar keine Signale, wilde Pegel und einige Ports haben vollständigen Durchgang zueinander. Also vollständiges Kuddelmuddel. Wir Fragen uns natürlich: "Was soll der Mist? Wie zum Teufel kann man aus diesem Chaos ein sauberes SBUS zusammen bauen?

Bei genauerer Betrachtung der Platine fällt uns auf: Wieso steht dort wo das ibus Signal eingespeist wird: "SBUSIN" und nicht "IBUSIN"???? To cut a long story short: Das Teil war ursprünglich ein SBUS->PPM Auskoppler, dessen Mikrokontroller man kurzum mit anderer Firmware umgeflashed hat um daraus einen IBUS->SBUS+PPM(und hier ist Summensignal, nicht Einzelkanäle gemeint) zu machen. Dabei sind allerdings die Ch1...Ch10 Ausgänge auf der Strecke geblieben und werden nicht mehr bedient. BOAAAHHH!!!!! Da muss man erstmal drauf kommen. ARGH!#@°^ Tagelange Fehlersuche wegen so einem Scheiß! Fazit: Der Adapter ist für uns nicht brauchbar. Erhofte Lösung des Problems damit gestorben :-(

Folgeüberlegungen:
Nach längerer Überlegung kommen wir zu dem Schluss, dass IBUS uns unserem Ziel nicht näher bringen wird. Das liegt primär daran, dass wir MavLink und IBUS nicht gleichzeitig nutzen können, da der Pi nur einen Serialport bereithält. Der Anschluss eines zusätzlichen USB Hubs und FTDI an den USB des Pi (um einen weiteren Serialport zu erzeugen) scheidet aufgrund von Platz- und Gewichtsbeschränkungen in unserem Projekt leider auch aus. Es ist schlichtweg keine Luft mehr im Gehäuse. Folge: Setzen wir auf ibus haben wir zwar die gewünschte Anzahl von Kanälen, aber dafür keine MavLink Telemetrie mehr (die wird aber zwingend benötigt). Setzen wir auf MavLink haben wir die Telemetrie aber nicht die Anzahl benötigter Kanäle. Also Pest oder Cholera.

Eine Bitte:
Da wir zwingend MavLink einsetzen müssen jedoch mehr als 8 Kanäle benötigen: Kannst du bitte nochmal in die Richtung "Mavlink mit mehr als 8Ch" forschen? Du hattest erwähnt, dass du hier wohl was gehört/gelesen hättest.
...es soll wohl auch noch eine Möglichkeit geben mit Mavlink irgendwie mehr als 8 Channels zu übertragen, aber ich habe keine Ahnung wie, wenn sich hier jemand damit auskennt, immer her mit den Infos ;)
Soweit ich es als Laie verstehe kannst du für die Kanäle 88bit zum AirPi hochschicken und baust auf dem AiPi dann erst das MavLink Protokoll zusammen, richtig? Wäre es ggf. möglich die ersten 8 Kanäle in das MavLink Protokoll zu verpacken und weitere Kanäle (9-...) entweder als PWM Signal direkt auf freien GPIO Pins des AirPi auszugeben (oder wenn alle Stricke reißen: zumindest GPIO Pins am AirPi als Schaltkanäle zu nutzen? Das würde uns auch schon aus der Zwickmühle helfen.

Vorab besten Dank für deine tolle Arbeit - die wir (ich denke ich spreche für alle hier) sehr zu schätzen wissen!
P.S: Und sorry für den länglichen Beitrag... ich wollte nur vermeiden dass jemand in das selbe Fettnäpfchen tritt wie wir.

*https://www.banggood.com/de/IBus-To...-Channels-PPM-And-S-Bus-Output-p-1099337.html

P.S: Eine weitere Idee
Ist es möglich aus zwei freien GPIO Pins des AirPi eine zusätzliche Serielle Schnittstelle zu schaffen? Den USB Port des Pi0 als zusätzliche serielle Schnittstelle zu "mißbrauchen" hat nämlich einen gravierenden Nachteil: Hier hängt ja schon der WLAN Adapter dran... d.h. man benötigt neben einem FTDI noch zusätzlich einen USB-Hub - ergo neben dem kleinen Pi0 noch zwei zusätzliche Platinen und jede Menge Kabelsalat :-(
Hätte man eine 2. Serielle über die GPIO Pins könnte man dort das RC-Signal (ibus, SUMD...) ausgeben .... ODER ABER AUCH... (Achtung: IDEE!!!!) ein zweites MavLink Signal welches dann statt den Kanälen 1-8 die Kanäle 9-16 Transportiert. Dazu müsste das "Verpacken in MavLink" lediglich zweimal durchlaufen und eben an unterschiedliche Serielle Schnittstellen geroutet werden. (Ich weiß nicht wie ich das besser beschreiben soll... ich kann leider so überhaupt nicht programmieren).
MavLink-2-PWM Konverter gibt es ja (z.B: https://github.com/gregd72002/mav2ppm) Ergo: Nur eine zusätzliche Platine und viele tolle Möglichkeiten (wenn man die Idee bis zu Ende spinnt sogar bis hin zur vollständigen Redundanz durch z.B. zwei FCs ;-)
 
Zuletzt bearbeitet:

rodizio1

Erfahrener Benutzer
EZ-Wifibroadcast 1.6RC3

Sorry, hatte wenig Zeit, werde noch antworten. Hier aber schonmal Version 1.6RC3


Changelog:
- New feature: RSSI/packetloss graphing and logging
- New feature: integrated airodump-ng wifi scanner
- Increased wifibroadcast-1.txt GPIO config combinations from 8 to 16
- Reverted back to stty serialport initialisation to fix issue with heartbeats getting lost
- Rewritten telemetry rx: Should fix out-of-order delivery and packetloss for telemetry
- Changed manual bitrate setting to kbit/s instead of bit/s
- Measured bitrate display in video stream can be disabled in wifibroadcast-1.txt
- Added debug option to wifibroadcast-1.txt
- Removed confusing bitrate display during startup on RX
- Changed txpower for Atheros back to 58 (was 56 accidentally in 1.6RC1 and RC2)
- Changed Atheros Thresh62 parameter to 26
- Added configurable mavlink forwarder: cmavnode or mavlink-routerd
- cmavnode.conf moved to boot partition for easier access
- Display error message in case of syntax errors in osdconfig.txt
- Added various USB webcam drivers to the kernel (for experimenting)
- raspivid default intrarefresh changed to "-if both"

https://www.file-upload.net/en/download-12889765/EZ-Wifibroadcast-1.6RC3.zip.html (Adblocker empfohlen)
 

careyer

DröhnOpaRähta
Junge Junge! Der Changelog erklärt allerdings wieso du plötzlich "abgetaucht" warst! Respekt! *ThumbsUP* ...wird gleich getestet ;-) MEGA! Du überrascht uns immer wieder! DANKE MAN!!!!!

Update:
Erstes Feedback: Der Verbindungsaufbau zum Pixhawk/PixRacer via Missionplanner funktioniert jetzt viel zügiger und die Telemetrieverbindung bleibt stabil (brach in 1.6RC2 öfters mal ab und man musste die Verbidnung neu Aufbauen). Scheint als täten

rodizio1 hat gesagt.:
- Reverted back to stty serialport initialisation to fix issue with heartbeats getting lost
- Rewritten telemetry rx: Should fix out-of-order delivery and packetloss for telemetry
ihre Wirkung! :)
 
Zuletzt bearbeitet:

rodizio1

Erfahrener Benutzer
Careyer: Sehr schön, danke für die Rückmeldung. Auf RCGroups hat auch jemand zurückgemeldet, dass es mit einer FC mit der es vorher nicht ging jetzt geht, von daher bin ich guter Dinge, dass das jetzt mal langsam richtig funktioniert mit dem Telemetrie-Uplink :). Falls nicht, habe ich in der Zwischenzeit noch ein paar kleinere Verbesserungen und mehr debug-logging am Telemetrie RX eingebaut.

Wegen der Steuerung bzw. der ganzen Kanäle die Du brauchst. Alles irgendwie blöd :D Ich glaube auch am besten (oder sagen wir "weniger schlecht") ist es irgendwie eine 2. serielle Schnittstelle am Pi zu in Software basteln. Gibt irgendwo auf Github (hatte ich glaube hier schonmal gepostet) sowas wie eine "Softserial" Implementation. Problem ist wohl genau wie beim Softserial bei Flightcontrols, das die baudrate begrenzt ist und zusätzlich das ganze auf einem nicht-Realtime Multitasking OS immer so eine Sache ist.

Oder halt die Implementation von dino_de. Du schriebst, die soll keine CPU-Last verursachen und keine Timing-Probleme haben weil sie irgendwie mit Interrupts oder "halb" in Hardware arbeitet wenn ich mich recht entsinne. Klingt grundsätzlich super, wenn man eine 2. serielle Schnittstelle hätte die man frei belegen kann. Aber da gab es noch das Problem, dass es noch manchmal einfriert (?). Da wäre ich strikt dagegen bis bekannt ist warum das passiert und wie das so gefixt werden kann, dass es definitiv nicht mehr auftreten kann. Müsste sich dino_de wahrscheinlich anschauen, meine Ahnung reicht da nicht um das zu debuggen.



Ansonsten gibt's in 1.6RC4 bald live CPU-Last und Temperatur-Anzeige (inclusive logging und Graphing) für TX und RX, ca. 10-15% höhere mögliche Bitraten und hoffentlich weniger Probleme mit verzögertem Bild bei belegten 2.4Ghz Kanälen in Wohngebieten z.B.
 

cesco1

Erfahrener Benutzer
OT *** ich hätte da ein paar fragen und da die xperten hier sizen frag ich mal hier *** OT

Braucht ihr jpeg kompression für die bilder oder ein videoformat?
Ist der kompressor in software oder in der webcam?

Gibts eine "anleitung für blöde" zum projekt? Ein raspberry liegt hier irgendwo rum.

Um latenz durch ACK's und resends zu vermeiden, braucht ihr broadcast?

ESP-NOW, das neue protokoll von expressif ist ack frei?
 

stxShadow

Erfahrener Benutzer
Bevor hier niemand antwortet mache ich das doch mal:

Braucht ihr jpeg kompression für die bilder oder ein videoformat?
Ist der kompressor in software oder in der webcam?
H.264 -> kann der Raspi in Hardware. Die Cam an sich ist "doof".

Gibts eine "anleitung für blöde" zum projekt? Ein raspberry liegt hier irgendwo rum.
Lade Dir das ISO runter, spiel es auf 2 MircoSD Karten und dann kann es schon losgehen (ein paar Wlan Sticks und einen HDMI Monitor o.ä. solltest Du auch noch haben). In der Default Config funktioniert das schon einwandfrei.

Um latenz durch ACK's und resends zu vermeiden, braucht ihr broadcast?
Für ein ACK brauchst Du erstmal ein Protokoll. Das gibt es hier allerdings nicht. Im Endeffekt werden per Paket Injection im Netzwerktreiber direkt Daten an die WLAN Karte übergeben. Diese pustet sie raus. Auf der Empfänger seite wird per WLAN Monitoring einfach alles angenommen was da kommt und an den Hardware Decoder weitergeben. Dieser pflückt die Bilder dann wieder auseinander.

Viele Grüße

Jens
 
Esp-now: Broadcast is not supported. ACK sind Pflicht.
Allerdings gibts es auf github Projekte zur ACKlosen Video Übertragung mit dem esp8266 (kompatibel?)

Gesendet von meinem LG-H815 mit Tapatalk
 
Zuletzt bearbeitet:

cesco1

Erfahrener Benutzer
@stxShadow

Danke. Gute erklärung.

@markus1234

Nein, EspNow ist connectionless, das nennt sich "vendor frames" und dürfte "packet injection" ähnlich sein. Keine ack's, keine IP, gar nix. Das mit "no broadcast" stimmt, man muss aber nur die MAC des controllers (server) kennen, mehr nicht.

>gibts es auf github Projekte zur ACKlosen Video Übertragung mit dem esp8266

Hast du eine link? Genau sowas such ich.
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten