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 ;-)
