xNH Software
Um dem Micro Hexacopter xNH Leben einzuhauchen habe ich neben der Standard MultiWii auch BradWii bemüht und eine Version erstellt, die die vorhandene Quadro-Version von BradWii um zwei zusätzliche Motoren erweitert.
Der Code in seiner momentanen Version steht hier zur freien Verwendung zum Download bereit:
In der nachfolgenden Version ist zusätzlich der Kompass des MPU9150 eingebunden:
Bitte beachten, dass die Entwicklung dieser Software noch nicht abgeschlossen ist!
Bei der Entwicklung des xNH bin ich davon ausgegangen, dass ich neben MultiWii auch BradWii und andere MultiCopter-Software zur Steuerung des Copters verwenden werde . Unter diesem Gesichtspunkt wurde also die Pinbelegung der µController soweit möglich an vorhandene FlightController angelehnt, die mit dieser Software laufen.
BradWii hatte es mir angetan, da ich bei meinen früheren Versuchen mit den Varianten des sNQ und xNQ immer Probleme mit der Bestimmung der PID Parameter hatte und BradWii diese Parameter automatisch findet.
Nachdem ich also zuerst MultiWii auf dem xNH am Laufen hatte - wir erinnern uns: MultiWii unterstützt HexaCopter von Hause aus - und nachgewiesen war, dass die Hardware soweit funktioniert, habe ich mich auf BradWii gestürzt und im ersten Ansatz den xNH als QuadX ans Fliegen gebracht. Die beiden mittleren Motoren wurden einfach nicht angesteuert, was recht gut funktionierte - dass der Hexa sich in dieser Konstellation wie ein nasser Schwamm flog, soll aber ebenfalls Erwähnung finden. Bei diesen ersten Versuchen musste sich der xNH mit den zwei vorgesehenen Akkus herumquälen, was die Agilität des Konstrukts sicher ebenfalls nicht gesteigert hat.
Ok, BradWii muss Hexa lernen, also frisch ans Werk :-)
Ich habe zu diesem Behufe eigentlich nur die Teile in MultiWii V2.4 ausfindig gemacht, die sich mit den zwei Mittelmotoren eines Hexa in H-Bauweise beschäftigen und in BradWii implantiert. Das schreibt sich im Nachhinein einfacher als es war, aber Brad hat das mit seiner strukturiert aufgebauten Software wesentlich erleichtert.
Im Zuge der Umstellung von BradWii auf meine Hardware sind mir noch ein paar Ungereimtheiten im Code aufgefallen, die die Vermutung nahe legen, dass noch nie
jemand BradWii tatsächlich mit Bürstenmotoren eingesetzt hat. Wahrscheinlicher ist aber, dass nach Einbau und Verifikation der Programmteile für brushed Motoren diese
im Zuge der Weiterentwicklung in Vergessenheit gerieten und nicht weiter gepflegt wurden.
Auf jeden Fall fehlte ein #define und die generierten Werte ließen die Motoren direkt
nach dem PowerOn - noch disarmed - anlaufen. Das war einfach zu finden und zu beheben und schließlich liefen auch die beiden Mittelmotoren gesteuert mit. Soll heißen:
Die mittleren Motoren werden ausschließlich über Gas vom Sender beeinflusst, die Regelung nimmt hier keinen Einfluss.
Da zur Ansteuerung der Motoren 5 und 6 (die beiden Mittelmotoren) eine per Software generierte PWM verwendet wird, musste ein Timer für die Pulserzeugung heran gezogen werden. Da Timer1 und Timer2 bereits für die vier Eckmotoren belegt sind kommt nur Timer0 in Frage, der allerdings auch für den Takt der Software allgemein verwendet wird.
So dürfte sich das sporadische Zucken der Drehzahlen erklären - hier kommen sich möglicher Weise die verschiedene Timer-Interrupts in die Quere. Das muss noch geklärt und natürlich behoben werden.
Soweit gediehen durfte sich der xNH aber schon mal mit sechs Motoren befeuert in die Luft erheben, diesmal nur mit einem Akku beladen, denn es hat sich bei der Softwareentwicklung heraus gestellt, dass der xNH auch mit nur einem 600 mAh-Akku schon ein paar Minuten in Betrieb bleibt.
Momentan habe ich eine Version von BradWii und eine Version von MultiWii V2.4 die beide mit der Hardware des xNH zusammen arbeiten, aber beide noch nicht fertig und vor Allem nicht fehlerfrei sind.
Die aktuelle BradWii-Version ist oben verlinkt.
Der momentane Stand meiner MultiWii-Version ist hier zu finden:
In dieser Version der MultiWii sind die acht Positions-LEDs des xNH aktiviert und blinken in unterschiedlichen Mustern, je nach Flugzustand. Auch die Akkuspannung wird über
diese LEDs mit unterschiedlichen Mustern angezeigt. Da mir das “Blitzen” der LED_FLASHER Implementierung zu lange dauerte, habe ich eine Variante mit 16 Bit
langem Datenfeld für die Blinkmuster eingebaut. Das einfache Aufblitzen ist jetzt wirklich eher ein Blitzen als ein Blinken.
Prinzipiell können die vorderen und die hinteren LEDs getrennt angesteuert werden, z.B.
vorne (Blau) für Ja, OK, eingeschaltet, hinten (Rot) für Nein, NoK, ausgeschaltet.
Der MPU9150 ist originär unterstützt, die Kompasswerte werden in ca. 300 µs ausgelesen.
Wir erinnern uns, dass vorgesehen ist, den xNH auch mit einem MPU9150 zu betreiben, der neben den vom MPU6050 bekannten ACC- und Gyro-Sensoren noch einen Kompass enthält. Der Kompass wird über ein eigenes Register angesprochen, aber vorher muss dazu der I²C-Multiplexer des MPU6050-Teils auf Durchgang geschaltet werden. Das klingt soweit überzeugend und ist schnell implementiert, aber holt man sich die Werte des Kompass, wie man es von den anderen Sensoren des Chip gewohnt ist - grob gesagt also immer wenn man an der Codestelle vorbei kommt, einfach die Register auslesen und die Werte verwenden - liest man nur Datenmüll.
Nach vielen Stunden Recherche im Internet auf der Suche nach funktionierenden Beispielen für den Kompass des MPU9150 bin ich dann auf die Implementierung von Kris
Winer gestoßen, die zumindest den Anstoß in die richtige Richtung gab - mein Dank an dieser Stelle an Kris!
Der Trick ist, dem Kompass, nach Anstoßen des Sampling, Zeit zu geben, die gefundenen
Werte in den Ausgaberegistern abzulegen. Kris hat das mit einer if-Abfrage erledigt und ich gehe davon aus, dass das bei ihm auch funktioniert hat (genauso übrigens, wie bei
allen anderen im Netz zu findenden Beispielen), aber auf meiner Hardware war es dennoch Zufall und von Programmlaufzeiten und sonstigen Widrigkeiten abhängig, ob ich sinnvolle Kompasswerte erhalten habe oder nicht.
Ein Blick ins Datenblatt hat dann Klarheit gebracht und ich habe die if-Abfrage durch eine while-Schleife ersetzt, die den Programmlauf so lange verzögert, bis die Werte tatsächlich zur Verfügung stehen. Der Kompass benötigt ca. 2,8 ms je Sample, um diese Zeit wird der Schleifendurchlauf verzögert, sobald der Kompass abgefragt wird.
Um diese Zeit zu verkürzen, habe ich getestet, ob der Ansatz trägt, das nächste Sampling sofort nach dem Auslesen der letzten Werte zu starten und dann, nach z.B. 100 ms, diese abzuholen. Offenbar funkt da aber irgendwer dazwischen, auf diese Weise klappt es leider nicht.
Um trotzdem nicht alle 70 ms (das ist die Kompass-Auslese-Zykluszeit in BradWii) 2,8 ms durch Warten zu verbraten, habe ich zu einem Trick gegriffen und den Trigger für das Sampling der Kompasswerte 3 ms vor dem eigentlichen Lesezugriff ausgelöst. Auf diese Weise liegt die Wartezeit auf die Kompasswerte im Durchschnitt bei erträglichen 410 µs, die Bandbreite ist 370 µs bis 3 ms, je nachdem, was die Software noch alles zu tun hat (Kommunikation zur GUI beispielsweise - hier passieren die größten Ausreißer). Ohne GUI-Kommunikation, also im reinen “Flugbetrieb” habe ich ein Maximum von 1,9 ms beobachtet.
Um die Prozedur des Einlernens des Kompass etwas zu erleichtern, habe ich dem xNH ein Bluetooth-Modul spendiert.
Besucher seit
25.11.2000