EZ-Wifibroadcast, HD FPV in günstig und einfach
- Themenstarter rodizio
- Beginndatum
- Status
Lonestar78:
Kennung haben die Pakete schon durch den wifibroadcast -p parameter. Wenn man Angst hat, dass jemand mit Wifibroadcast auf genau der gleichen Frequenz fliegt und damit die Steuerung übernehmen könnte, kann man "-p 73" oder irgendwas anstatt des defaults nehmen. Sollte man dann aber auch mit dem Video- und Telemetrie Stream machen
Update-Rate, Pakete mehrfach verschicken, Senden und Empfangen über mehr als eine Karte und auf zwei Frequenzen etc. ist alles möglich und frei konfigurierbar. Muss halt noch ein wenig getestet werden was da am "besten" ist bezüglich der Einstellungen.
Das Multiwii Serial Protocol verschickt Pakete mit Checksumme, zusätzlich sind die Wifi-Pakete auch noch mit einer Checksumme gesichert, d.h. es ist völlig unmöglich, dass auf der Luftstrecke oder auch auf der seriellen Strecke vom Pi zur Flightcontrol Daten verfälscht werden. Entweder es kommen gültige Pakete mit genau den Stick-Positionen die an der Funke eingegeben wurden, oder gar nichts.
Failsafe wird der Flightcontrol überlassen weil es allg. mehr Sinn macht das am Ende der Steuerungskette zu machen und weil es die Logik auf dem Air-Pi minimal hält. So leitet der einfach nur auf die serielle Schnittstelle weiter. Das stellt sicher, dass bei einem Software-Absturz oder Bug egal welcher Art auf dem Air-Pi niemals falsche Daten gesendet werden und auch nicht die letzte Stick-Position "einfrieren" kann (was zu einem Fly-Away führen könnte).
Bei der MSP_RC Implementation in Cleanflight werden mindestens 5 Pakete pro Sekunde erwartet, ansonsten greifen die Failsafe-Settings. Habe ich ausgiebig getestest (auch alles "wild aus- und eingeschaltet", Antennen abgeschraubt um den Empfang zu stören etc., Steuerung kam immer wieder).
Was noch nicht ganz optimal ist, ist die Ground-Seite. Die SDL1 Joystick library ist hinsichtlich der Joystick-Erkennung etwas limitiert, es ist nicht möglich festzustellen, wenn der Joystick getrennt wird. In dem Falle wird dann dummerweise einfach immer weiter die letzte Stickposition gesendet. Im Moment ist das mit einer bash funktion in der .profile gelöst, die immer wieder prüft ob der Jostick noch da ist und ggf. den RC TX schnell killt wenn er nicht mehr da ist. Das führt aber dazu, dasss ca. 1-2s die letzte Stick-Position gesendet wird, bevor das Failsafe greifen kann.
Also sicherstellen, dass die USB Verbindung nicht aus versehen getrennt werden kann im Flug.
Zwiebacksäge:
Wifibroadcast auf einem Notebook sollte kein grosser Aufwand sein solange Du nicht 2.3Ghz nutzen willst (dann müsstest Du Kernel- bzw. Treiber-Module patchen und bauen ...).
Kennung haben die Pakete schon durch den wifibroadcast -p parameter. Wenn man Angst hat, dass jemand mit Wifibroadcast auf genau der gleichen Frequenz fliegt und damit die Steuerung übernehmen könnte, kann man "-p 73" oder irgendwas anstatt des defaults nehmen. Sollte man dann aber auch mit dem Video- und Telemetrie Stream machen
Update-Rate, Pakete mehrfach verschicken, Senden und Empfangen über mehr als eine Karte und auf zwei Frequenzen etc. ist alles möglich und frei konfigurierbar. Muss halt noch ein wenig getestet werden was da am "besten" ist bezüglich der Einstellungen.
Das Multiwii Serial Protocol verschickt Pakete mit Checksumme, zusätzlich sind die Wifi-Pakete auch noch mit einer Checksumme gesichert, d.h. es ist völlig unmöglich, dass auf der Luftstrecke oder auch auf der seriellen Strecke vom Pi zur Flightcontrol Daten verfälscht werden. Entweder es kommen gültige Pakete mit genau den Stick-Positionen die an der Funke eingegeben wurden, oder gar nichts.
Failsafe wird der Flightcontrol überlassen weil es allg. mehr Sinn macht das am Ende der Steuerungskette zu machen und weil es die Logik auf dem Air-Pi minimal hält. So leitet der einfach nur auf die serielle Schnittstelle weiter. Das stellt sicher, dass bei einem Software-Absturz oder Bug egal welcher Art auf dem Air-Pi niemals falsche Daten gesendet werden und auch nicht die letzte Stick-Position "einfrieren" kann (was zu einem Fly-Away führen könnte).
Bei der MSP_RC Implementation in Cleanflight werden mindestens 5 Pakete pro Sekunde erwartet, ansonsten greifen die Failsafe-Settings. Habe ich ausgiebig getestest (auch alles "wild aus- und eingeschaltet", Antennen abgeschraubt um den Empfang zu stören etc., Steuerung kam immer wieder).
Was noch nicht ganz optimal ist, ist die Ground-Seite. Die SDL1 Joystick library ist hinsichtlich der Joystick-Erkennung etwas limitiert, es ist nicht möglich festzustellen, wenn der Joystick getrennt wird. In dem Falle wird dann dummerweise einfach immer weiter die letzte Stickposition gesendet. Im Moment ist das mit einer bash funktion in der .profile gelöst, die immer wieder prüft ob der Jostick noch da ist und ggf. den RC TX schnell killt wenn er nicht mehr da ist. Das führt aber dazu, dasss ca. 1-2s die letzte Stick-Position gesendet wird, bevor das Failsafe greifen kann.
Also sicherstellen, dass die USB Verbindung nicht aus versehen getrennt werden kann im Flug.
Zwiebacksäge:
Wifibroadcast auf einem Notebook sollte kein grosser Aufwand sein solange Du nicht 2.3Ghz nutzen willst (dann müsstest Du Kernel- bzw. Treiber-Module patchen und bauen ...).
nein ich wäre wunschlos glücklich wenn ich für mein 10" netbook ein zum pi analoges readonly image hätte was genauso mit dem TPlink stick arbeitet. das wäre effektiv sogar noch billiger als ein pi plus Monitor, Stromversorgung und alles in einer Box unterbringen.
vielleicht kannst du mir da mal ein paar Tips geben was für eine minimal distri da am einfachsten zu adaptieren ist.
Sent from my Wileyfox Swift using Tapatalk
vielleicht kannst du mir da mal ein paar Tips geben was für eine minimal distri da am einfachsten zu adaptieren ist.
Sent from my Wileyfox Swift using Tapatalk
Keine Ahnung, nehme selbst Debian, aber das ist eher nicht Anfängertauglich. Wenn action das mit Lubuntu auf dem Netbook schon am laufen hat, nimm' doch das
@action: Läuft das Lubuntu USB Image problemlos out-of-the-box auf verschiedenen Netbooks? Falls ja, könnte ja jemand ein Lubuntu USB Image welches automatisch wifibroadcast startet machen.
@action: Läuft das Lubuntu USB Image problemlos out-of-the-box auf verschiedenen Netbooks? Falls ja, könnte ja jemand ein Lubuntu USB Image welches automatisch wifibroadcast startet machen.
da wäre ich sehr interessiert dran. hab auch grad lubuntu am Wickel aber ziemliche Probleme weil mein scheiß netbook 32bit efi erwartet...
noch was anderes... wäre ein fallback auf sehr geringe bitrate und Auflösung für Momente mit schlechtem Empfang denkbar und sinnvoll?
Sent from my Wileyfox Swift using Tapatalk
noch was anderes... wäre ein fallback auf sehr geringe bitrate und Auflösung für Momente mit schlechtem Empfang denkbar und sinnvoll?
Sent from my Wileyfox Swift using Tapatalk
Die ganze Telemetrie wäre zu viel. Ich bin nicht sicher, ob im Telemetrie-stream die GPS Daten im nmea format rumschwirren. Externe Geräte erwarten ein sauberes nmea Format, so wie es jedes unserer GPS-Module ausgiebt. Im Grunde soll der Downstream nur die GPS-Daten mit runter schicken und der Groundpi gibt die Daten über einen pin wieder aus. Aber halt nur im nmea-format.
Ne ... genau das finde ich macht das ganze zu kompliziert. Ich denke mehr aus Anwender Sicht. Viele wollen sich nicht mit dem ganzen "Config Kram" beschäftigen. Sie nutzen erstmal das Default was da ist. Also anstecken und geht. Das haben wir ja schon. Umd ei Frequenz zu Ändern musst Du aber dann zumindest schonmal das Notebook auspacken und eine weitere Config Datei anlegen. Dann kann ich aber auch gleich die Frequenz in der Datei ändern. Aus Nutzer Sicht wäre es deutlich einfacher, enfach per Jumper eine Frequenz einzustellen, die dann für alle Configs gilt. So sind Sie es ja auch von analogen Systemen gewohnt.
Viele Grüße
Jens
Viele Grüße
Jens
Naja, einmal Zuhause die Frequenzen einrichten die man zur Auswahl haben möchte müsste man sowieso, sind insgesamt eh zuviele für 8 mögliche Kombinationen. Ausserdem möchte ich alle Einstellungen per Jumper auswählbar haben, nicht nur die Kanäle.
Ich würde das für mich demnächst nutzen um mit verschiedenen FEC settings und Bitraten zu testen, andere wollen vielleicht verschiedene Cam-Settings je nach Lichtverhältnissen oder was auch immer.
Edit: Skydrone:
Hmm, also den vorhandenen Telemetrie Stream noch auf dem Rx Pi Serialport ausgeben bzw. auch noch in reines NMEA umwandeln wäre auf die schnelle nicht möglich. Ich könnte aber einfach einen weiteren seriellen downlink hinzufügen. Die APM Dinger haben doch mehrere Serialports oder? Wenn man da einen weiteren so konfigurieren könnte dass der NMEA ausgibt, würde das so zum Rx Pi übertragen werden und da am seriellen Port ausgegeben.
Wegen Tracker am Pi allgemein: Besteht da eigentlich allgemein Interesse? Ich selbst würde da zwar erstmal nicht dran mitarbeiten wollen, aber habe da schon öfter drüber nachgedacht. Damit liesse sich ein ziemlich cooler Tracker bauen, hab da so ein paar Ideen
Ich würde das für mich demnächst nutzen um mit verschiedenen FEC settings und Bitraten zu testen, andere wollen vielleicht verschiedene Cam-Settings je nach Lichtverhältnissen oder was auch immer.
Edit: Skydrone:
Hmm, also den vorhandenen Telemetrie Stream noch auf dem Rx Pi Serialport ausgeben bzw. auch noch in reines NMEA umwandeln wäre auf die schnelle nicht möglich. Ich könnte aber einfach einen weiteren seriellen downlink hinzufügen. Die APM Dinger haben doch mehrere Serialports oder? Wenn man da einen weiteren so konfigurieren könnte dass der NMEA ausgibt, würde das so zum Rx Pi übertragen werden und da am seriellen Port ausgegeben.
Wegen Tracker am Pi allgemein: Besteht da eigentlich allgemein Interesse? Ich selbst würde da zwar erstmal nicht dran mitarbeiten wollen, aber habe da schon öfter drüber nachgedacht. Damit liesse sich ein ziemlich cooler Tracker bauen, hab da so ein paar Ideen
Zuletzt bearbeitet:
Die Konkurrenz aus Spanien macht das mit der Config über ein Menu im Ground-Pi. Da kann ich sowohl die Kanäle frei klicken wie auch die Cam und den Joystick einstellen. Alles über das GUI, keine Settings von Hand ändern. Da muss ich nur ein paar Freak-Einstellungen vornehmen. Als Anwender aber nur im GUI unterwegs. Dazu hänge ich mir am Ground-Pi eine Maus an und fertig.
wäre jetzt die Frage ob man Konkurrenz kopieren möchte und dann am Ende zwei gleiche Lösungen hat oder eher einen anderen Weg geht und die Leute anspricht die keine Maus mitnehmen möchten oder?
Der Nachteil an GUI Einstellungen ist dass man alle Optionen vorgeben muss. Für Kanalwahl kein Thema für Cam Settings evtl. schon. Sollte man einfach mit bedenken.
Sent from my Wileyfox Swift using Tapatalk
Der Nachteil an GUI Einstellungen ist dass man alle Optionen vorgeben muss. Für Kanalwahl kein Thema für Cam Settings evtl. schon. Sollte man einfach mit bedenken.
Sent from my Wileyfox Swift using Tapatalk
Wie wäre es denn, erst mal TX und RX mit normalem WLAN zu starten? Also als Beispiel: RX macht einen AP auf, TX verbindet sich damit.
Dann kann ich mich mit einem Handy an dem AP anmelden und über eine App, Weboberfläche oder auch einfach per ssh auf die Konfig zugreifen. Wenn ich fertig bin drücke ich Start und beides geht in den WBC Modus über.
Besser noch: ich kann über einen Dipschalter am RX wählen, ob ich Einstellungen vornehmen möchte oder nicht, abhängig davon starten er einen AP oder direkt WBC. Der TX sucht beim Start immer den AP des RX, wenn er keinen findet schaltet er auf WBC um.
Würde halt den Startprozess verlängern, da man sichergehen muss dass der AP auch wirklich gestartet ist. Wobei man das auch wieder an den LEDs der Wlan-Karte sieht.
Gesendet von meinem XT1039 mit Tapatalk
Dann kann ich mich mit einem Handy an dem AP anmelden und über eine App, Weboberfläche oder auch einfach per ssh auf die Konfig zugreifen. Wenn ich fertig bin drücke ich Start und beides geht in den WBC Modus über.
Besser noch: ich kann über einen Dipschalter am RX wählen, ob ich Einstellungen vornehmen möchte oder nicht, abhängig davon starten er einen AP oder direkt WBC. Der TX sucht beim Start immer den AP des RX, wenn er keinen findet schaltet er auf WBC um.
Würde halt den Startprozess verlängern, da man sichergehen muss dass der AP auch wirklich gestartet ist. Wobei man das auch wieder an den LEDs der Wlan-Karte sieht.
Gesendet von meinem XT1039 mit Tapatalk
hab jetzt die RX Seite über ein Netbook zum laufen gebracht. bekomm allerdings merkwürdige Ruckler wobei dann immer bei beiden sticks die led von blinken auf konstant wechselt. Woran kann das liegen? tritt nur auf sobald rx an ist. tx blinkt ansonsten immer brav
Sent from my Wileyfox Swift using Tapatalk
Sent from my Wileyfox Swift using Tapatalk
Ja, grafische Oberfläche (am besten per WLAN über Smartphone zugreifbar) wäre schon nicht schlecht. Aber viel zu viel Arbeit. Die Lösung mit den GPIO Pins erlaubt auf jedenfall maximale Flexibilität auf Anwenderseite und ist nur mit minimalem Aufwand auf meiner Seite verbunden
Mal eine Frage in die Runde:
Wer hat bei sich 18Mbit Wifibitrate eingestellt? Und mit welchen Videobitraten und EXTRAPARAMS seid Ihr dabei unterwegs?
Habe jetzt nochmal getestet, 18Mbit mit 6Mbit Videobitrate und -ex sports und -mm matrix scheint soweit stabil und ohne Latenzschwankungen zu laufen. Einzige Möglichkeit das zu provozieren ist, wenn ich die Linse komplett abdecke und dann plötzlich wieder "Licht" da ist, dann geht die Bitrate kurz so hoch, dass ein Badblock kommt und manchmal auch kurzzeitig etwas mehr Latenz. Sollte aber natürlich bei normalem Fliegen nicht vorkommen.
Wenn das bei Euch mit 18Mbit Wifibitrate läuft (oder auch wenn's nicht lief) wäre es nett wenn Ihr hier kurz Bescheid geben könntet, dann würde ich die Defaults für V1.4 anpassen. Gibt ca. 3db mehr Empfindlichkeit und dadurch theoretische 40% mehr Reichweite ...
Mal eine Frage in die Runde:
Wer hat bei sich 18Mbit Wifibitrate eingestellt? Und mit welchen Videobitraten und EXTRAPARAMS seid Ihr dabei unterwegs?
Habe jetzt nochmal getestet, 18Mbit mit 6Mbit Videobitrate und -ex sports und -mm matrix scheint soweit stabil und ohne Latenzschwankungen zu laufen. Einzige Möglichkeit das zu provozieren ist, wenn ich die Linse komplett abdecke und dann plötzlich wieder "Licht" da ist, dann geht die Bitrate kurz so hoch, dass ein Badblock kommt und manchmal auch kurzzeitig etwas mehr Latenz. Sollte aber natürlich bei normalem Fliegen nicht vorkommen.
Wenn das bei Euch mit 18Mbit Wifibitrate läuft (oder auch wenn's nicht lief) wäre es nett wenn Ihr hier kurz Bescheid geben könntet, dann würde ich die Defaults für V1.4 anpassen. Gibt ca. 3db mehr Empfindlichkeit und dadurch theoretische 40% mehr Reichweite ...
- Status
