Low Cost HD-Video Übertragung + Telemetrie
- Themenstarter Lonestar78
- Beginndatum
- Status
Viele Leute, Viele Anwendungsgebiete, Viele gute Ideen ;_)
Ich fasse nochmal kurz zusammen:
Ich denke für die PPM Ausgabe am Modell brauchst keine weitere Hardware, auf dem Rasp sollte das ppm generieren kaum Last erzeugen.
Am Boden an der App fände ich zumindest zum testen und für Bodengebundene Fahrzeuge kleine Controlls in der App (wie z.B. in der Parrot App) zum steuern sehr schick. So braucht es außer der App eben garnix.
Zum anschließen der Externen Steuerung gäbe es dann eben den Weg übers PPM in per Mic Eingang oder eben per Arduino und BT an die App.
Oder eben ne Arduino/Rasp -> Wifi/LAN Lösung die direkt an den Rasp am Modell schhickt.
Ich fasse nochmal kurz zusammen:
Ich denke für die PPM Ausgabe am Modell brauchst keine weitere Hardware, auf dem Rasp sollte das ppm generieren kaum Last erzeugen.
Am Boden an der App fände ich zumindest zum testen und für Bodengebundene Fahrzeuge kleine Controlls in der App (wie z.B. in der Parrot App) zum steuern sehr schick. So braucht es außer der App eben garnix.
Zum anschließen der Externen Steuerung gäbe es dann eben den Weg übers PPM in per Mic Eingang oder eben per Arduino und BT an die App.
Oder eben ne Arduino/Rasp -> Wifi/LAN Lösung die direkt an den Rasp am Modell schhickt.
Ähm, warum eigentlich das RC-Signal überhaupt nach PPM wandeln? Zumindest für APM/Pixhawk sollte das hier ausreichen: http://dev.ardupilot.com/wiki/raspberry-pi-via-mavlink/
Die Steuerung via GCS (für den APM würde das so aussehen) soll angeblich implementiert sein und komplett ohne RC funktionieren - ausprobiert hab ich es allerdings noch nicht. Das RC-Signal muss also nur noch auf einer Seite "bearbeitet" werden. Der Rest ist relativ triviale Formatkonvertierung nach MAVLink.
Wenn das alles nicht vernüftig gehen sollte: Signal im SBus-Format ausgeben. Das ist eine invertierte serielle Schnittstelle auf 3.3V-Level, die mit 100000 Baud läuft. Damit wären auch diverse andere FCs anschließbar.
Die Steuerung via GCS (für den APM würde das so aussehen) soll angeblich implementiert sein und komplett ohne RC funktionieren - ausprobiert hab ich es allerdings noch nicht. Das RC-Signal muss also nur noch auf einer Seite "bearbeitet" werden. Der Rest ist relativ triviale Formatkonvertierung nach MAVLink.
Wenn das alles nicht vernüftig gehen sollte: Signal im SBus-Format ausgeben. Das ist eine invertierte serielle Schnittstelle auf 3.3V-Level, die mit 100000 Baud läuft. Damit wären auch diverse andere FCs anschließbar.
Zuletzt bearbeitet:
Ich hab es bis jetzt noch nicht geschafft mein Quad mit APM über MAVLink und die entsprechende APP zu Steuern. Entweder klappte gar nichts oder aber der Copter machte was er wollte bis ich wieder mit der RC übernahm.
Zudem fliegt ja bei weitem nicht jeder nen AC. SBUS ist zwar sicher auch eine Lösung aber auch das kann nicht jeder brauchen, für ein Rover müsste man wieder ein Wandler verwenden etc. von daher ist die Lösung mit den GPIOs vom RPi sicher am besten, damit kann jeder etwas anfangen. Man könnte natürlich auch einfach das PPM Signal wieder ausgeben auf dieser Seite.
Man könnte auch ganz einfach das ganze RC zeugs auf 443Mhz betreiben und braucht dann sowas hier sicherlich nicht + ist auf der sichersten Seite was Ausfall betrifft.
Zudem fliegt ja bei weitem nicht jeder nen AC. SBUS ist zwar sicher auch eine Lösung aber auch das kann nicht jeder brauchen, für ein Rover müsste man wieder ein Wandler verwenden etc. von daher ist die Lösung mit den GPIOs vom RPi sicher am besten, damit kann jeder etwas anfangen. Man könnte natürlich auch einfach das PPM Signal wieder ausgeben auf dieser Seite.
Man könnte auch ganz einfach das ganze RC zeugs auf 443Mhz betreiben und braucht dann sowas hier sicherlich nicht + ist auf der sichersten Seite was Ausfall betrifft.
Das ist ja echt Wahnsinn was ihr hier geschafft habe, echt super 
Genau das habe ich gesucht und nun auch gefunden.
Habe mir gestern Abend auch erst mal alle 80 Seiten durchgelesen
Ich habe jetzt aber nochmal ein paar Fragen:
Also ihr benutzt ja diese Wlan Bridges, besonders beliebt und gut soll ja die PicoStation M2 HP 2,4Ghz aber die kostet ja mit knapp 80€ das Stück auch schon ordentlich.
Gibt es da denn auch noch kostengünstigere Wlan Bridges, die auch eine vergleichbare Leistung haben und weniger kosten (vielleicht was aus China?).
Ne Auflistung der kompatiblen Wlan Bridges wäre echt super
Dann habe ich noch eine Frage/Anregung an die Programmierer unter euch.
Was passiert denn eigentlich wenn man außerhalb das Reichweite fliegt? Einfach kein Bild mehr?
( Ich blick da nach den vielen Seiten nicht mehr so ganz durch)
Aber was ich eigentlich sagen wollte, man könnte es ja so lösen, dann man einen "Notmodus" hinzufügt. Sprich wenn die Bandbreite für 720p oder 1080p nicht mehr reicht, wird die Auflösung auf zb. 640x480 runtergebrochen, um die Verbindung weiter halten zu können.
Es gibt auf youtube auch ein Video, wo anscheine jemand schon mal so etwas ähnliches gebaut hat (170ms Verzögerung).
Und dieser Typ hat das mit der reduzierten Auflösung auch so gemacht. Vielleicht kann man das sich bei dem ja abgucken
In der Videobeschreibung ist auch ein link zu einer Seite (Forum), wo er sein System nochmal näher vorstellt. (bin grade am durchlesen)
Er sendet übrigens auch mit 100mw auf 2,4ghz.
Youtube: https://www.youtube.com/watch?v=_1_2fhy3mwY
Forum:http://www.rcgroups.com/forums/showthread.php?t=1507916
Ach ja und was ich auch noch erwähnen wollte, das es ja echt genial wäre wenn man die Steuerung auch mit übertragen könnte
und dies über die Mic-Dose möglich wäre.
So könnte man auch noch ein Programm für nen PC/MAC Programmieren wo die Steuerung dann eingespeist wird.
PS. die Nexus 7 Videobrille, genial (1080p )
LG
Jan (modellflieger9284)
Genau das habe ich gesucht und nun auch gefunden.
Habe mir gestern Abend auch erst mal alle 80 Seiten durchgelesen
Ich habe jetzt aber nochmal ein paar Fragen:
Also ihr benutzt ja diese Wlan Bridges, besonders beliebt und gut soll ja die PicoStation M2 HP 2,4Ghz aber die kostet ja mit knapp 80€ das Stück auch schon ordentlich.
Gibt es da denn auch noch kostengünstigere Wlan Bridges, die auch eine vergleichbare Leistung haben und weniger kosten (vielleicht was aus China?).
Ne Auflistung der kompatiblen Wlan Bridges wäre echt super
Dann habe ich noch eine Frage/Anregung an die Programmierer unter euch.
Was passiert denn eigentlich wenn man außerhalb das Reichweite fliegt? Einfach kein Bild mehr?
( Ich blick da nach den vielen Seiten nicht mehr so ganz durch
)Aber was ich eigentlich sagen wollte, man könnte es ja so lösen, dann man einen "Notmodus" hinzufügt. Sprich wenn die Bandbreite für 720p oder 1080p nicht mehr reicht, wird die Auflösung auf zb. 640x480 runtergebrochen, um die Verbindung weiter halten zu können.
Es gibt auf youtube auch ein Video, wo anscheine jemand schon mal so etwas ähnliches gebaut hat (170ms Verzögerung).
Und dieser Typ hat das mit der reduzierten Auflösung auch so gemacht. Vielleicht kann man das sich bei dem ja abgucken
In der Videobeschreibung ist auch ein link zu einer Seite (Forum), wo er sein System nochmal näher vorstellt. (bin grade am durchlesen
)Er sendet übrigens auch mit 100mw auf 2,4ghz.
Youtube: https://www.youtube.com/watch?v=_1_2fhy3mwY
Forum:http://www.rcgroups.com/forums/showthread.php?t=1507916
Ach ja und was ich auch noch erwähnen wollte, das es ja echt genial wäre wenn man die Steuerung auch mit übertragen könnte
und dies über die Mic-Dose möglich wäre.
So könnte man auch noch ein Programm für nen PC/MAC Programmieren wo die Steuerung dann eingespeist wird.
PS. die Nexus 7 Videobrille, genial (1080p
)LG
Jan (modellflieger9284)
Wow, du hast dir echt die ganzen Seiten angetan ?
Wegen der Bridges: Natürlich kannst du da jede verwenden die ein Clientmode ermöglicht. Die Ubi's bieten halt einige andere Vorteile und sind sicher ziemlich gut was Empfangsstärke (-96dBm) angeht und haben im Gegensatz zu den meisten Homegeräten auch tatsächlich 100mW (und illegal noch mehr). Damit erreichst du natürlich höhere Reichweiten als mit einem 0815 Gerät, welches nur mit 50-60mW sendet und nur bis -85dBm was hört (6dB = Theoretische Reichweitenverdopplung).Auch erreichen die Ubis die angegebenen Geschwindigkeiten was ebenfalls bei günstigeren Geräten nicht der Fall ist.
? Wegen der Bridges: Natürlich kannst du da jede verwenden die ein Clientmode ermöglicht. Die Ubi's bieten halt einige andere Vorteile und sind sicher ziemlich gut was Empfangsstärke (-96dBm) angeht und haben im Gegensatz zu den meisten Homegeräten auch tatsächlich 100mW (und illegal noch mehr). Damit erreichst du natürlich höhere Reichweiten als mit einem 0815 Gerät, welches nur mit 50-60mW sendet und nur bis -85dBm was hört (6dB = Theoretische Reichweitenverdopplung).Auch erreichen die Ubis die angegebenen Geschwindigkeiten was ebenfalls bei günstigeren Geräten nicht der Fall ist.
Ja klar, alles gelesen
Konnte einfach nicht aufhören War ja auch echt super spannend.
Und zu den Bridges, das ist doch so das einfach einer der Client der "Sender" und der andere der "Empfänger" ist, aber man kann sich auch normal per Notebook (Wlan )in diese bestehende Verbindung einklinken?
Wenn einem die Reichweite nicht wichtig wäre könnte man auch als Empfänger quasi eine Fritzbox oder gar das ins Notebook/Tabelt eingebaute Wlan nehmen? Oder geht das doch nicht?
Edit:
Ach ja und warum kann man nicht einfach nen USB Wlan Stick benutzten? (auf Sender Seite)
Ich weiß da war was, aber keine lust nochmal alle Seiten zu lesen
Konnte einfach nicht aufhören
War ja auch echt super spannend.Und zu den Bridges, das ist doch so das einfach einer der Client der "Sender" und der andere der "Empfänger" ist, aber man kann sich auch normal per Notebook (Wlan )in diese bestehende Verbindung einklinken?
Wenn einem die Reichweite nicht wichtig wäre könnte man auch als Empfänger quasi eine Fritzbox oder gar das ins Notebook/Tabelt eingebaute Wlan nehmen? Oder geht das doch nicht?
Edit:
Ach ja und warum kann man nicht einfach nen USB Wlan Stick benutzten? (auf Sender Seite)
Ich weiß da war was, aber keine lust nochmal alle Seiten zu lesen
Wie PPM aus Funke in die App (muss das überhaupt über die App laufen? Nö)?
Ich gehe mal davon aus, dass das Android Phone per OMG-USB-Ethernet kabelgebunden an den WLAN-Accesspoint am Boden verbunden wird (meine Vorliebe, weniger Funkstrecken).
Dann würde ich in die Funke ein Arduino mit LAN Adapter hängen. Sowas hier etwa: ArduinoLAN
Der Arduino kann trivial in ausreichender Auflösung das PPM-Signal auswerten und in irgend einer Art und weise die Daten ins LAN schicken. Und zwar mit dem Ziel: AirPi, also der Pi in der Luft... Braucht keine App und ist Robust.
Dann brauchts nur noch nen billigen mini switch um Funke, AndroidPhone und Accesspoint zu verbinden, vieleicht DEN hier.
Die Folge wäre dann, dass man tatsächlich nur noch die WLAN-Verbindung hätte.
NACHTRAG:
http://arduino.cc/en/Tutorial/UDPSendReceiveString
Also mit den verfügbaren PPM libraries für Arduino hat man den "PPM to LAN" Converter an nem Abend zusammengestöpselt. UDP Pakete noch mit nem Zeitstempel versehen und schon kann man in der Luft ein gutes Failsafe implementieren....
Ich gehe mal davon aus, dass das Android Phone per OMG-USB-Ethernet kabelgebunden an den WLAN-Accesspoint am Boden verbunden wird (meine Vorliebe, weniger Funkstrecken).
Dann würde ich in die Funke ein Arduino mit LAN Adapter hängen. Sowas hier etwa: ArduinoLAN
Der Arduino kann trivial in ausreichender Auflösung das PPM-Signal auswerten und in irgend einer Art und weise die Daten ins LAN schicken. Und zwar mit dem Ziel: AirPi, also der Pi in der Luft...
Braucht keine App und ist Robust.Dann brauchts nur noch nen billigen mini switch um Funke, AndroidPhone und Accesspoint zu verbinden, vieleicht DEN hier.
Die Folge wäre dann, dass man tatsächlich nur noch die WLAN-Verbindung hätte.
NACHTRAG:
http://arduino.cc/en/Tutorial/UDPSendReceiveString
Also mit den verfügbaren PPM libraries für Arduino hat man den "PPM to LAN" Converter an nem Abend zusammengestöpselt. UDP Pakete noch mit nem Zeitstempel versehen und schon kann man in der Luft ein gutes Failsafe implementieren....
Zuletzt bearbeitet:
Ok, interessant. Ich habe es ehlich gesagt noch nicht probiert. Wird mal ein Winterprojekt, in Verbindung mit einem Crash-unempfindlichen Mini-Copter
Ich habe zu Sum-PPM irgendwie ein etwas unterkühltes Verhältnis. Der kleinste Spike auf der Leitung oder auch einfach nur eine unsaubere Flanke am Anfang der Sequenz führt in der Regel sofort zu Kunstflug, weil der Decoder dabei unweigerlich um einen Kanal "verrutscht". Ich versuche daher, dieses Zeug aus Gründen der Betriebssicherheit im Copter unbedingt zu vermeiden.
Für den Boden hätt ich auch noch ne Idee: habe vorhin gerade festgestellt, dass sich meine Taranis an meinem Linux-Rechner einfach so als Joystick anmeldet, wenn man sie im Normalbetrieb per USB anschließt. Das würde sie sicher auch gegenüber einem Raspberry tun. Da fehlt dann nur noch ein kleines Programm, das das Input-Device öffnet und hier die Knüppel- und Schalterpositionen ausliest. Ich wette, das ist mit einem oder zei Dutzend Zeilen Python erledigt...
Ich habe zu Sum-PPM irgendwie ein etwas unterkühltes Verhältnis. Der kleinste Spike auf der Leitung oder auch einfach nur eine unsaubere Flanke am Anfang der Sequenz führt in der Regel sofort zu Kunstflug, weil der Decoder dabei unweigerlich um einen Kanal "verrutscht". Ich versuche daher, dieses Zeug aus Gründen der Betriebssicherheit im Copter unbedingt zu vermeiden.
Für den Boden hätt ich auch noch ne Idee: habe vorhin gerade festgestellt, dass sich meine Taranis an meinem Linux-Rechner einfach so als Joystick anmeldet, wenn man sie im Normalbetrieb per USB anschließt. Das würde sie sicher auch gegenüber einem Raspberry tun. Da fehlt dann nur noch ein kleines Programm, das das Input-Device öffnet und hier die Knüppel- und Schalterpositionen ausliest. Ich wette, das ist mit einem oder zei Dutzend Zeilen Python erledigt...
Zuletzt bearbeitet:
@hornetwl: Zum Thema PPM naja, ich hab sowas noch nie erlebt, dass da etwas schief geloffen ist. Früher wurde das Signal jo so (analog) zum Empfänger übertragen und das ging auch immer ohne grössere Probleme und selbst wenn mal ein Signal zerschossen wird, so ist dies spätestens nach 22ms wieder "korrekt". Da hätte ich eher sorgen, dass es aufgrund UDP oder Wlan Netz gar nicht ankommt.
Die Idee das direkt über USB zu machen ist sicherlich nicht schlecht, aber zum einen verwendet nicht jeder eine Taranis und man müsste wieder ziemlich viel Implementieren, damit wenigstens die "grossen" abgedeckt sind. PPM via Lehrerschüler können praktisch alle, wenn auch einige ein anderen Signalpegel / etc. nutzen, aber dies kann man dann meist mit einfachsten mitteln ausbügeln.
Im Endeffekt wenn man mal definiert hat wie man die Daten zum Pi kommen müssen kann man als Sender auch mehrere Möglichkeiten Bauen, so wäre auch ein normaler Joystick sicherlich nicht unmöglich.
@Lonestar78: Der Timestamp nützt dir so relativ wenig, vor allem bräuchtest du ggf. auf dem Arduino noch ein RTC oder von wo willst du die Daten nehmen? Das gent aber auch einfacher. Auf der Empfänger Seite einfach den Timestamp pro empfangenes Signal aktualisieren und wenn der Grösser als Xms ist -> Failsafe Position anfahren.
Die Idee das direkt über USB zu machen ist sicherlich nicht schlecht, aber zum einen verwendet nicht jeder eine Taranis und man müsste wieder ziemlich viel Implementieren, damit wenigstens die "grossen" abgedeckt sind. PPM via Lehrerschüler können praktisch alle, wenn auch einige ein anderen Signalpegel / etc. nutzen, aber dies kann man dann meist mit einfachsten mitteln ausbügeln.
Im Endeffekt wenn man mal definiert hat wie man die Daten zum Pi kommen müssen kann man als Sender auch mehrere Möglichkeiten Bauen, so wäre auch ein normaler Joystick sicherlich nicht unmöglich.
@Lonestar78: Der Timestamp nützt dir so relativ wenig, vor allem bräuchtest du ggf. auf dem Arduino noch ein RTC oder von wo willst du die Daten nehmen? Das gent aber auch einfacher. Auf der Empfänger Seite einfach den Timestamp pro empfangenes Signal aktualisieren und wenn der Grösser als Xms ist -> Failsafe Position anfahren.
Ja klar, alles gelesen
Konnte einfach nicht aufhören War ja auch echt super spannend.
Und zu den Bridges, das ist doch so das einfach einer der Client der "Sender" und der andere der "Empfänger" ist, aber man kann sich auch normal per Notebook (Wlan )in diese bestehende Verbindung einklinken?
Wenn einem die Reichweite nicht wichtig wäre könnte man auch als Empfänger quasi eine Fritzbox oder gar das ins Notebook/Tabelt eingebaute Wlan nehmen? Oder geht das doch nicht?
Edit:
Ach ja und warum kann man nicht einfach nen USB Wlan Stick benutzten? (auf Sender Seite)
Ich weiß da war was, aber keine lust nochmal alle Seiten zu lesen
Konnte einfach nicht aufhören
War ja auch echt super spannend.Und zu den Bridges, das ist doch so das einfach einer der Client der "Sender" und der andere der "Empfänger" ist, aber man kann sich auch normal per Notebook (Wlan )in diese bestehende Verbindung einklinken?
Wenn einem die Reichweite nicht wichtig wäre könnte man auch als Empfänger quasi eine Fritzbox oder gar das ins Notebook/Tabelt eingebaute Wlan nehmen? Oder geht das doch nicht?
Edit:
Ach ja und warum kann man nicht einfach nen USB Wlan Stick benutzten? (auf Sender Seite)
Ich weiß da war was, aber keine lust nochmal alle Seiten zu lesen
Wenn wirklich der RC Sender genutzt werden woll dann würde ich das wohl auch eher nicht über die App machen.
Eine Option zum steuern über den Touch in der App wäre trotzdem nett zum testen und spielen, da man so eben nur die App braucht und diese ohne weitere Hardware mit dem Air-PI verbinden könnte. Könnte mir z.B. hier auch vorstellen meinen kleinen Rover zuhause ins WLAN zu hängen und ihn per App die im selben LAN hängt zu steuern, für draußen dann eben ne direkte Verbindung App->Air-PI (als AP)
Alternative zum LAN am OTG was wohl nicht bei allen funktioniert könnte man ja auch nen 2. Rasp als Bodenstation und WIFI/LAN Relay zwischenschalten, App per Wifi stick am Rasp über diesen auf den long Range Wifi geroutet der am Rasp LAN post hängt. So Ähnlich scheint es die neue Parrot Bodenstation ja auch zu machen. Da hier nix umkodiert wird sonder nur Pakete geschubst werden sollte das von der Latenz her auch so gut wie nix ausmachen.
Zum PPM und Failsave: Die Ausgabe am Rasp is ja wie gesagt variabel, wenn man einzelkanäle will nimmt man den Servoblaster, ansonsten generiert man am GPIO n PPM oder an der seriellen n SBUS. Wenn keine neuen Pakete mehr per UDP kommen geht man nach nem Timeout auf eingestellte defaults. Timestamp und co ist hier nicht nötig denke ich.
Probleme beim PPM gibts nur wenn die Pause nach dem letzten Kanal zu kurz wird, aber das is ein anderes Thema zu dem es genug Threads gibt.
@aargau, ich werde es erstmal mit nem Stick am PI versuchen, wenn möglich auch auf 5GHz um hier anderen Sachen aus dme weg zu gehen. Die Externen LAN-WLAN Bridges sind mir zum spielen zu teuer.
Odroid-W sollte heute kommen. Gibt es die Streaming pakete/scripte eigentlich auch einzeln, will nicht unbedingt das fertige Image nehmen da ich noch andere Sachen benötigen werde.
Eine Option zum steuern über den Touch in der App wäre trotzdem nett zum testen und spielen, da man so eben nur die App braucht und diese ohne weitere Hardware mit dem Air-PI verbinden könnte. Könnte mir z.B. hier auch vorstellen meinen kleinen Rover zuhause ins WLAN zu hängen und ihn per App die im selben LAN hängt zu steuern, für draußen dann eben ne direkte Verbindung App->Air-PI (als AP)
Alternative zum LAN am OTG was wohl nicht bei allen funktioniert könnte man ja auch nen 2. Rasp als Bodenstation und WIFI/LAN Relay zwischenschalten, App per Wifi stick am Rasp über diesen auf den long Range Wifi geroutet der am Rasp LAN post hängt. So Ähnlich scheint es die neue Parrot Bodenstation ja auch zu machen. Da hier nix umkodiert wird sonder nur Pakete geschubst werden sollte das von der Latenz her auch so gut wie nix ausmachen.
Zum PPM und Failsave: Die Ausgabe am Rasp is ja wie gesagt variabel, wenn man einzelkanäle will nimmt man den Servoblaster, ansonsten generiert man am GPIO n PPM oder an der seriellen n SBUS. Wenn keine neuen Pakete mehr per UDP kommen geht man nach nem Timeout auf eingestellte defaults. Timestamp und co ist hier nicht nötig denke ich.
Probleme beim PPM gibts nur wenn die Pause nach dem letzten Kanal zu kurz wird, aber das is ein anderes Thema zu dem es genug Threads gibt.
@aargau, ich werde es erstmal mit nem Stick am PI versuchen, wenn möglich auch auf 5GHz um hier anderen Sachen aus dme weg zu gehen. Die Externen LAN-WLAN Bridges sind mir zum spielen zu teuer.
Odroid-W sollte heute kommen. Gibt es die Streaming pakete/scripte eigentlich auch einzeln, will nicht unbedingt das fertige Image nehmen da ich noch andere Sachen benötigen werde.
Zuletzt bearbeitet:
In der Regel ist die Ursache, die das Signal gerade eben noch kaputt gemacht hat, aber nach 22ms nicht weg. Habe da mal mit einem Heli ein sehr teueres Loch gegraben...
Das Risiko von Paketverlusten durch UDP/WLAN ist hingegen wesentlich besser beherrschbar - hier werden keine Daten verfälscht, es gehen maximal welche verloren. Wenn die letzten verfügbaren zu alt sind, löst die Failsafe-Logik der FC aus und schaltet auf RTL. Das nervt maximal, aber es geht nix kaputt.
Gegen Null Gas (ein Spike 1ps for der ersten Flanke), Vollausschlag Querruder (statt Vollgas, da ab jetzt um eins verrutscht), voll Höhenruder (aufgrund des vom Piloten gegengesteuerten Querruders) ist hingegen die FC komplett machtlos, das schlägt in wenigen Sekunden unvermeidlich ein. Ich bleibe dabei: SumPPM -> defective by design. Davor habe ich entschieden mehr Angst, als vor ein paar verlorenen UDP-Paketen.
BTW: werde mich in den nächsten Tagen mal an Flugtests mit FASST wagen - das scheint absolut problemlos mit dem WLAN-Link zu koexistieren. Bei der Taranis sieht es hingegen sehr viel schlechter aus. Ein Blick auf den in den UBIs eingebauten Spektrum-Analyser zeigt auch recht eindrücklich, warum.
Das Risiko von Paketverlusten durch UDP/WLAN ist hingegen wesentlich besser beherrschbar - hier werden keine Daten verfälscht, es gehen maximal welche verloren. Wenn die letzten verfügbaren zu alt sind, löst die Failsafe-Logik der FC aus und schaltet auf RTL. Das nervt maximal, aber es geht nix kaputt.
Gegen Null Gas (ein Spike 1ps for der ersten Flanke), Vollausschlag Querruder (statt Vollgas, da ab jetzt um eins verrutscht), voll Höhenruder (aufgrund des vom Piloten gegengesteuerten Querruders) ist hingegen die FC komplett machtlos, das schlägt in wenigen Sekunden unvermeidlich ein. Ich bleibe dabei: SumPPM -> defective by design. Davor habe ich entschieden mehr Angst, als vor ein paar verlorenen UDP-Paketen.
BTW: werde mich in den nächsten Tagen mal an Flugtests mit FASST wagen - das scheint absolut problemlos mit dem WLAN-Link zu koexistieren. Bei der Taranis sieht es hingegen sehr viel schlechter aus. Ein Blick auf den in den UBIs eingebauten Spektrum-Analyser zeigt auch recht eindrücklich, warum.
Zuletzt bearbeitet:
- Status
