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:
Um mir das Gefummel mit Leitungen bei einseitigem Layout zu ersparen, bin ich diesmal auf doppelseitiges Platinenmaterial ausgewichen. Die Unterseite stellt sich so dar:
Die gestrichelte Linie im nachfolgenden Bild markiert die maximale Platinengröße 10 x 8 cm für die Freeware-Variante von Eagle:
(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:
(Click auf das Bild für volle Auflösung)
Die Platinen sehen hervorragend aus:
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.
Der Empfänger, ein Deltang Rx31c sitzt senkrecht in der Mitte, der MPU6050 auf abgesetzter Platine in Flugrichtung davor, hier ebenfalls auf einem Stecker:
IMU-Platinen im Größenvergleich mit einem Reißnagel. Links der MPU9150 mit integriertem Kompass AK8975C, in der Mitte der MPU6050:
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:
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)...
...sowie zwei neue Verbindungen:
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.
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).
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:
Wie man sieht, hat die Maßnahme zum Erfolg geführt - 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:
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.
(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:
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:)
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...