Micro HexaCopter xNH

Den aus dem xNQ V2 abgeleiteten Ansatz eines HexaCopters habe ich nicht weiter verfolgt, sondern habe das Layout noch etwas vergrößert und für den Einsatz von 55 mm Propellern ausgelegt, die wir vom Hubsan X4 kennen.

Hier musste ich ein bisschen tricksen, da meine Freeware-Version von Eagle lediglich die Platzierung von Bauteilen auf einer Fläche von 10 x 8 cm erlaubt. Die Platine selbst darf dieses Maß allerdings überschreiten, ich musste also nur die Positions-LEDs von den Auslegern auf den Grundkörper verlegen.

Die Positions-LEDs sitzen auf der Ober- und der Unterseite, sind also immer sichtbar und sind zur Signalisierung von Zuständen (z.B. “Akku schwach”) oder zur Rückmeldung vom µC schaltbar ausgelegt.

Mit der durch die Vergrößerung zur Verfügung stehenden Fläche konnte ich mich nicht bremsen und habe das Layout als “universellen” Versuchsträger entworfen. Soll heißen, der Hexa kann wahlweise mit einem AtMega328p oder einem XMega32 bestückt werden. Weiterhin können Glockenanker-Motoren per PWM oder Brushless-Motoren über ESCs angesteuert werden.

Mit dem alternativ zum MPU6050 bestückbaren MPU9150 kann die Sensorik um einen Kompass erweitert werden, ebenso habe ich einen Luftdrucksensor vorgesehen. Der Footprint passt für den BMP085 sowie den moderneren BMP180.
Die abgesetzte Sensor-Platine für den MPU6050 kann direkt gesteckt oder über Kabel flexibel platzierbar angeschlossen werden.

Die ESCs sind steckbar oberhalb der Platine angeordnet, die zugehörigen Stecker werden natürlich nur bestückt wenn auch die Brushless-Motoren eingesetzt werden.

Für den Betrieb mit dem AtMega328 ist ein StepUp-Converter notwendig, damit der µC mit 16 MHz betrieben werden kann. Ebenso ist hier dann wieder ein Levelshifter einzusetzen, der den I²C-Bus des AtMega328 von 5 V auf die 3,3 V der Sensoren umsetzt.
Für den Schutz der ESCs vor zu hoher Spannung am Signaleingang setze ich blaue LEDs mit Vorwiderstand ein.

Selbstverständlich ist auch ein Steckplatz für die Montage des FPV-Moduls sowie der Einsatz des Deltang Rx31c mit Downlink-Option vorgesehen.

Mit den beiden µC-Optionen steht dem Einsatz von MultiWii oder der eigenen Software, abgeleitet von Willas Bolt bzw. Matthias’ XMega-Implementierung, nichts im Wege.

Die Ansteuerung der sechs Motoren ist in der MultiWii Standard-Pinbelegung ausgeführt.
Beim XMega32A4 sind alle Ausgänge auf HW-PWM-Pins gelegt.

Für die wahlweise Realisierung der Downlink-Option mit dem Deltang Rx31c muss ein Portpin für RxD frei gemacht werden (per Lötbrücke selektierbar), der bei MultiWii standardmäßig für die Ansteuerung des Motors Links hinten vorgesehen ist. Diese Option ist nur mit dem XMega realisierbar, da der AtMega328 nur einen echten Seriellport hat.

Um der höheren Motorleistung Rechnung zu tragen, sind zwei Akku-Stecker vorgesehen (parallel geschaltet).


Das Layout dieser größeren Version habe ich bezeichnender Weise xNH “big” genannt, man verzeihe mir die Übertreibung ;-)

Hier die Ansicht der Oberseite:

xNH V3.0 - Oberseite

Um mir das Gefummel mit Leitungen bei einseitigem Layout zu ersparen, bin ich diesmal auf doppelseitiges Platinenmaterial ausgewichen. Die Unterseite stellt sich so dar:

xNH V3.0 - Unterseite

 

Die gestrichelte Linie im nachfolgenden Bild markiert die maximale Platinengröße 10 x 8 cm für die Freeware-Variante von Eagle:

xNH V3.0 Layout
             (Click auf das Bild für volle Auflösung)

Die Rotorkreise haben einen Durchmesser von 55 mm, die weißen Flecke markieren die Einbaupositionen der ESCs. In der großen Auflösung kann man im rechten Teil der Platine zwischen den drei grünen Steckern und den beiden ESCs die angedeuteten Umrisse des T-förmigen FPV-Moduls erkennen (weiße Linie).

Die Abmessungen des Layouts sind im folgenden Bild angegeben:

xNH V3.0 - Abmessungen
             (Click auf das Bild für volle Auflösung)

 


Nach den theoretischen Vorarbeiten, musste jetzt MME mal wieder ran und die Platinen für mich fertigen.

Die Platinen sehen hervorragend aus:

xNH V3.0 - Oberseite
xNH V3.0 - Unterseite

 

Schaltplan und Layout des xNH V3.0 liegen als EAGLE-Dateien vor.


Wie gehabt wurde zuerst der Stromversorgungsteil in Betrieb genommen, anschließend der µController bestückt (die erste Version des xNH mit dem AtMega328p), danach die Sensoren (BM180 und MPU6050).

Der erste Hexa ist ein HexaCopter mit Glockenanker-Motoren, der zweite ist ein HexaCopter mit Brushless Motoren.


 

Hier die Variante mit Glockenanker-Motoren

Die Motoren sitzen geklemmt in den Aussparungen der Ausleger, ich habe die 7 mm Typen von Hubsan verwendet, die Propeller sind ebenfalls vom Hubsan.

xNH mit Glockenanker-Motoren

Der Empfänger, ein Deltang Rx31c sitzt senkrecht in der Mitte, der MPU6050 auf abgesetzter Platine in Flugrichtung davor, hier ebenfalls auf einem Stecker:

xNH - Empfänger und Lagesensor

IMU-Platinen im Größenvergleich mit einem Reißnagel. Links der MPU9150 mit integriertem Kompass AK8975C, in der Mitte der MPU6050:

MPU6050 und MPU9150 neben einem Reißnagel

Die starre Befestigung mittels Platinenstecker hat sich als zu instabil erwiesen, die Lage des Sensors zum Grundboard konnte sich verändern und musste einer Ausführung mit Litzen und Doppelklebeband weichen:

IMU-Sensor auf Doppelklebeband

Um unkompliziert die GUI der MultiWii verwenden zu können, musste ich den Kommunikationsanschluss GUI-Comm (siehe Schaltplan) für den AtMega328p umverdrahten. Das bedingte drei Leiterbahnauftrennungen (siehe rote Kästen im nachfolgenden Bild)...

Trennstellen

...sowie zwei neue Verbindungen:

Kommunikationschnittstelle neu verdrahtet


Im weiteren Verlauf der Inbetriebnahme hat sich heraus gestellt, dass mir beim Layout ein typischer Anfängerfehler unterlaufen ist...

Nachdem die Funktionen der Software nach und nach in Betrieb genommen waren, habe ich die Motoren eingebaut und anlaufen lassen. Mit dem ersten Motor hat das auch noch funktioniert, doch als alle Motoren angeschlossen waren und der erste Probelauf stattfinden sollte, hat sich der µC wiederholbar nach einem ersten Zucker sang- und klanglos verabschiedet und musste durch den Reset-Knopf erst wieder zum Leben erweckt werden.

Analyse: Die Massezuführung für den AtMega trägt zusätzlich den Motorstrom der beiden vorderen Motoren. Werden diese angesteuert, ändert sich das Potential entlang der Leiterbahn auf Grund des durch den Leiterwiderstand implizierten Spannungsabfalls. Da die Motoren pulsweitenmoduliert angesteuert werden, haben diese Potentialsprünge sehr steile Flanken und bringenden damit den µC aus dem Takt. Dieses Problem nennt man “Ground bouncing” und muss durch entsprechende Maßnahmen unterbunden werden.

Im folgenden Bild ist der Treiber für den linken vorderen Motor (gelber Kreis) und die Abzweigung der Masse für den µC (gelber Pfeil) visualisiert. Die Leitung vom Akku kommt von links, der kritische Teil ist die blaue Leiterbahn links vom Pfeil.

Masseführung für µC und Motoren

Ich hatte insofern Glück, dass das Via (Durchkontaktierung), das die Masseanbindung des µC an die auf der Unterseite geführte Leiterbahn bewerkstelligt, die einzige Stelle ist, an der eine elektrische Verbindung zwischen der Masseleitung der Motoren und der Masse des µC besteht. Dadurch konnte ich die obere Lage des Via mit dem Bohrer vorsichtig entfernen und so von der Unterseite trennen (im Bild unten das große Via rechts des Steckers).

Via angebohrt

Dabei war es wichtig, das Via nicht komplett auszubohren um den Querschnitt der Leiterbahn auf der Unterseite der Platine nicht zu schwächen, hier fließt ja der Strom der vorderen Motoren.

Die jetzt fehlende Massezuführung für den µC habe ich mit einem Draht direkt vom Akkuanschluss zu einem dem alternativ bestückbaren XMega zugehörigen Blockkondensator-Pad realisiert:

Masse für den µController

Wie man sieht, hat die Maßnahme zum Erfolg geführt - alle Motoren laufen:

xNH - alle Motoren laufen

Die sechs blauen LEDs sind bei der Version des xNH mit Bürstenmotoren unnötig, zeigen aber schön über die subjektiv empfundene Helligkeit die PWM für die Motoren an.

Mit den bis hier beschriebenen Maßnahmen ist der xNH flugfertig, jetzt musste die Software angepasst werden.

 


Die Software für den xNH ist im ersten Ansatz zum Einen MultiWii, zum Anderen die von Bradley Quick aus MultiWii abgeleitete Spezialfirmware BradWii, die nette Features wie Autotune für die PID-Werte und - in Verbindung mit einem Luftdrucksensor - den Uncrashability Mode bietet ;-)

Zuerst habe ich den xNH V3.0 mit BradWii in die Luft gebracht:

Video des xNH V3.0 im Freien
         vimeo.com/132645879

Anschließend ging es an den Aufbau der Brushless-Version xNH V3.0 BL.


Sensibilisert durch das Groundbouncing-Problem mit dem AtMega habe ich gleich noch die Leiterbahnführung des alternativ bestückbaren XMega analysiert. Auch hier findet sich Potential für ein gleich geartetes Problem, weshalb ich direkt eine Version V3.1 des Layout erstellt habe, das die beschriebenen Probleme umgeht. Natürlich sind alle anderen oben beschriebenen Änderungen ebenfalls eingeflossen.

Im folgenden Bild sind die Maßnahmen zur Vermeidung des Groundbouncing markiert. Kräftig Rot und Blau sind alle Masseleitungen hervorgehoben. Der gelbe Kreis kennzeichnet die Stelle dicht bei den Akkuanschlüssen, an der die Masseleitung für die beiden alternativ bestückbaren µController von der übrigen Masseführung abzweigt. Die gelben Rechtecke umreißen die Bauelemente, die von dieser quasi getrennten Masse versorgt werden. Neben den beiden µControllern sind das der Empfänger und der I²C Level shifter.

CPU Masse beim xNH V3.1
             (Click auf das Bild für volle Auflösung)

Hier die EAGLE-Dateien des xNH V3.1. In dem Archiv sind weitere Änderungen gegenüber der Abbildung oben enthalten.

In dem Design des xNH V3.1 ist zusätzlich eine IMU-Platine enthalten, die dem geänderten Chip-Layout des MPU9150 Rechnung trägt. Die Unterschiede im Bild:

IMU-Layout MPU9150 vs MPU6050

Bei der Version für den MPU9150 habe ich die Defaulteinstellung für A0 auf GND geändert, der Chip wird hier also über die I²C-Adresse 0x68 angesprochen. Das Layout für den MPU9150 ist ohne Änderung auch für die Bestückung mit einem MPU6050 geeignet.

Verwendung der MPU6050-Version für den MPU9150

Prekärer Weise sind Pins, die beim MPU6050 als “NC, frei zur Verwendung als Routing-Option” bezeichnet sind, beim MPU9150 in Verwendung. So muss z.B. beim MPU9150 auf Pin 3 die Versorgungsspannung zugeführt werden. Schlimmer ist, dass Pin 15 beim MPU9150 GND führt. Im Layout für den MPU6050 habe ich hier VDD geroutet, so dass der Pin falsch gepolt angeschlossen ist.

Die Platine kann also nicht unverändert für den MPU9150 verwendet werden.

Ich habe die überflüssigen Verbindungen auf der Platine mit dem Skalpell getrennt und zwei zusätzliche Anschlüsse direkt an die “Pins” des MPU9150 angelötet. Hier hat mir noch nicht mal meine gute alte 3-fach vergrößernde Leuchtlupe geholfen, ich musste auf eine 10-fach vergrößernde Uhrmacherlupe zum ins Auge klemmen ausweichen, mit der ich schon gefährlich nahe an die Lötkolbenspitze gekommen bin, damit die Abbildung scharf wurde.

Die Trennstellen sind nicht zu sehen, aber die beiden zusätzlichen Verbindungen von GND und 3V3 (die beiden silbernen Freiluft-Drähte:)

Geänderte GND- und VDD-Anschlüsse am MPU9150
Geänderte GND- und VDD-Anschlüsse am MPU9150

Zu dem im MPU9150 gegenüber dem MPU6050 zusätzlich enthaltenen Kompass AK8975C habe ich auch noch die eine oder andere Geschichte auf Lager, dazu später mehr...


 

Über eine Suchmaschine hier gelandet? Dann bitte mit Click Navigations Schaltflächen anzeigen

[Home] [Modelle] [Eisenbahn TT] [Was ist neu ?] [Elektronik] [Kontakt] [Links] [Tipps+Tricks]