xNQ
Am Anfang stand Svens Idee, einen sehr kleinen Quadrocopter zu bauen.
Der Weg dahin ging über verschiedene Versionen des sNQ, deren Layouts und Eigenheiten auf der verlinkten Seite kurz umrissen sind.
Der bereits mit dem sNQ V2 BL eingeleitete Schwenk auf alternative Motoren mündet im nächsten Schritt in die Entwicklung des Nachfolgers, der zusätzlich zum Antrieb per Brushlessmotoren ein reines 3,3 V Design und damit einhergehend einen neuen Prozessortyp einführt. Der verwendete XMega32A ist namengebend für den xNQ V1.
Getrieben durch die schlechten Erfahrungen beim Einsatz der Brushlessmotoren zusammen mit dem fest auf der Hauptplatine montierten Bewegungssensor MPU60x0 (wahlweise MPU6050 oder MPU 6000), sitzt der Sensor beim xNQ auf einer eigenen, kleinen Platine und kann somit mechanisch entkoppelt am Copter befestigt werden. Diese Idee hat Bernd in die Entwicklung eingebracht und er hat auch gleich ein passendes Platinenset entflochten.
Die Schaltung ist durch die hohe Integration des XMega32 erstaunlich übersichtlich:
(Cllick für größere Darstellung)
An aktiven Bauteilen ist nur noch der Microcontroller XMega32A, der Bewegungssensor MPU60x0 sowie der LowDrop-Spannungsregler LT1761 vorhanden, der Rest sind
Steckverbinder, Hühnerfutter (SMD-Widerstände und -Kondensatoren) und ein paar LEDs.
Ok, es kommen noch vier ESCs dazu, die senkrecht unter die Motorenausleger montiert werden. Die sind im Schaltbild nicht berücksichtigt.
Achtung! Schaltbildänderung: R3 von 10k auf 12k geändert.
Das Layout ist recht zierlich geworden, nicht zuletzt durch Auslagerung des Sensors auf eine eigene Platine:
Gegenüber dem Layout für den sNQ V2 BL habe ich die Konturen der Basisplatine an den Propellerkreis angeschmiegt, so dass der volle Luftstrom nach unten an der Platine vorbei geht und dennoch die Achsabstände und damit die Gesamtabmessungen nochmals um einige Millimeter kleiner wurden.
- größte Spannweite diagonal (inklusive Propeller) - 118 mm
- größte Breite - 97 mm
- Achsabstand diagonal - 73 mm
- Achsabstand horizontal und vertikal - 52 mm
Einige Angaben habe ich bildlich dargestellt.
Durch Verwendung des XMega32 im QFN-Gehäuse lässt sich hier noch etwas optimieren, aber zuerst soll das Design zeigen, dass es flugfähig ist :-)
Die Platinen habe ich wieder bei MME fertigen lassen, die Qualität ist wie immer prima:
Zwei Größenvergleiche mit dem Layout des sNQ V2:
Die hier gezeigte sNQ-Platine ist die nicht umgesetzte Version für 7mm Didel-Motoren, daher die vergleichsweise großen Ösen an den Auslegerenden.
Die nur ca. 9 x 9 mm große Sensorplatine in Großaufnahme:
Für das Routen von GND und VCC habe ich nicht belegte Pins des MPU60x0 (NC) verwendet.
Hier zwei Besonderheiten im Detail:
Zum Größenvergleich: Die Sensorplatine liegt hier auf einer Schieblehre, die kurzen Striche sind die Millimeter-Marken.
Der runde Anschluss rechts ist der INT-Ausgang des MPU60x0. Falls der benötigt wird, kann er über eine zusätzliche Leitung an den µC geführt werden, der korrespondierende Anschluss am µC ist ebenfalls auf ein Pad geführt.
Links unterhalb des MPU60x0 sind zwei Lötbrücken aus Leiterbahnen gezeichnet, die die Festlegung des A0-Anschlusses erlauben. Defaulteinstellung ist A0=1. Die rechte Brücke nach VCC ist bereits im Layout vorgesehen und muss aufgetrennt werden, falls A0=0 sein soll. In diesem Fall sind dann die beiden linken Leiterbahnen mit einem Klecks Lötzinn zu verbinden.
Das ist bei den verwendeten Leiterbahnstrukturen nicht ganz einfach, aber wer es geschafft hat, den MPU zerstörungsfrei auf die Platine zu bannen, der sollte auch damit zurechtkommen :-)
Falls nicht, kann ja immer noch der Code passend zur Hardware geändert werden.
Alle Bauteile sind bestückt, der Einbau des MPU6000 steht kurz bevor:
Die Sensorplatine wird mit 4 kurzen Drähten mit dem Grundboard verbunden. Die Interrupt-Option wird vorerst nicht aktiviert.
Der Sensor ist verdrahtet, zusätzlich sind die Positions-LEDs an den Auslegerenden angeschlossen:
Es fehlen hier noch die ESCs und die Motoren. Der Empfänger Deltang Rx31 sitzt an seinem Platz und tut was er soll. Das Binding mit einem DX6i Sender von Spektrum hat problemlos funktioniert:
Damit aus diesem zur Zeit nur nett aussehenden Stück Hardware ein Quadrocopter wird, muss der XMega32 Futter in Form einer Firmware bekommen, die die Sensoren und den Empfänger abfragt und diese Informationen zu Sollwerten verarbeitet, die die Motoren über noch einzubauende ESCs ansteuert.
Der erste Wurf (Williams Originalsoftware vom Bolt ohne Änderungen) funktioniert soweit, dass zumindest die drei bereits auf der Ur-Shrediquette vorhandenen Status-LEDs angesprochen werden :-)
Das ist natürlich nur der erste Test um zu verifizieren, ob der µC prinzipiell arbeitet, letztlich nur ein kompliziertes “Hello, world!”.
Die vorhandene Software wird jetzt sukzessive um Funktionen erweitert, die mir für den xNQ wichtig erscheinen. Zu allererst kommt natürlich eine Routine, die den Empfänger bedient. Hier kann ich im Wesentlichen auf die Funktionen zurückgreifen, die bereits im sNQ für den Infrarot-Empfänger oder den Deltang Rx31 ihren Dienst verrichteten. Das Ganze muss nur etwas angepasst werden, damit der Code auch auf dem XMega korrekt läuft, wobei ich in Teilen auf die ebenfalls lauffähige Version der Steuerung von Matthias (Cheguevara) zurück greifen kann, was sehr hilfreich ist.
Als Nächstes muss der Code ein bisschen verschlankt werden, denn im Original bedient der µC 6 Motoren, im xNQ sind nur 4 vorhanden. Direkt im Anschluss lernt der xNQ Williams GUI kennen, einhergehend mit der Fähigkeit, sich Einstellungen und Parameter im EEPROM zu merken.
Der letzt große Schritt in Richtung Fertigstellung ist der Einbau einer Funktion, die es erlaubt, die ESCs auf den Fernsteuersender einzulernen und zu programmieren. Der erste Ansatz, das per PC gesteuert zu erledigen, wird wieder verworfen, nachdem er funktioniert. Geeigneter erscheint mir, nach Altväter Sitte die Einstellungen mit dem Gasknüppel am Sender vorzunehmen.
Abschließend wird noch eine Akkuspannungsüberwachung und die “Autolevel”-Funktion von Nils eingebaut. Letztere erlaubt es, eine im Flug als waagerecht empfundene Lage als Default abzuspeichern, man erspart sich damit mehrfache, iterative Gänge zum PC, mit denen die ACC-Offsets des MPU60x0 vormals einzustellen waren.
Ach ja, eine Änderung war noch notwendig, weil ich mir ohne vorherige intensive Beschäftigung mit dessen Eigenschaften, einen Spektrum DX6i Sender gekauft habe, der zwar tatsächlich 6 Kanäle hat, wovon aber nur 4 analog sind. Die beiden anderen Kanäle sind rein Digital, man kann nur zwei diskrete Werte einstellen und an den Empfänger übermitteln. Das macht es unmöglich, mit nur einem Kanal zwischen AUS, ACRO und HOVER zu wählen. Folglich musste der 6. Kanal für diese Unterscheidung mit herhalten. Kanal 5 schaltet jetzt also die Motoren AN oder AUS, Kanal 6 unterscheidet zwischen HOVER (0) und ACRO (1).
In diesem Zusammenhang drängt sich natürlich eine Netzsuche mit den Begriffen “DX6i erweiterung analog” auf und man landet unweigerlich auf der Seite von Stephans DX6i Channel Expander (Nachtrag 05/2017: Die Seite von Stephan ist leider nicht mehr erreichbar ), der den DX6i um viele Sonderfunktionen erweitert. Dieser Weg ist viel versprechend, und wird zukünftig zu eruieren sein :-)
Der nächste Schritt ist die Montage und Inbetriebnahme der ESCs und Motoren.
Im ersten Ansatz kommen erneut die Hextronik 10 mm 2 Gramm Typen D1000 (Bezeichnung bei Hobbyking) zum Einsatz, die bereits im sNQ V2 BL ihren Dienst verrichten sollten, aber auf Grund ihrer jämmerlichen Rundlaufeigenschaften den Erfolg damals nachhaltig verhindert haben. Ich gebe ihnen dennoch eine Chance, weil ich glaube und hoffe, dass der abgesetzte Sensor eine Verbesserung bringen wird. Natürlich verwende ich andere Motoren für den xNQ. Und natürlich ist auch bei einem dieser neuen Motoren ein Anschlussdraht schrottig angelötet, so dass nach dem Einbau kein Kontakt mehr besteht. Trotz vorheriger Kontrolle durch vorsichtiges Ziehen an den Anschlüssen hat es dieser Motor in den xNQ geschafft. Die kleinste Torsionsbelastung beim Anlöten der Drähte an den ESC lässt die Lötstelle im Schrumpfschlauch brechen.
Hier ein Bild aus der sNQ V2 BL-Serie:
Da meine 1 mm Schrumpfschläuche zu dick sind und nur ein Anschluss abgerissen ist, habe ich die Isolierung Isolierung sein lassen und den Draht einfach nur wieder angelötet:
Rein subjektiv laufen die vier neuen, selektierten Motoren (4 aus 7) recht ruhig. Mal sehen, was letztlich der MPU6000 dazu sagt.
Ich zeige in loser Reihenfolge verschiedene Ansichten des fertig aufgebauten xNQ V1.
Ansicht von links. Im Vordergrund der Stecker für die Kommunikation zum PC (GUI oder Terminal für Debugausgaben), am linken Ende der Platine der Stecker für den Akku. Hier nicht sichtbar auf der gegenüber liegenden Seite der 4-polige Stecker für den Programmer. Ich verwende den Diamex All-AVR. Der hat für den gedachten Einsatzfall alle Optionen an Bord, funktioniert problemlos mit Bascom und ist vergleichsweise preiswert. Über eine Steckbrücke auf dem All-AVR kann man die 3,3 V Versorgung des Target (hier der xNQ) einschalten, so dass die Programmentwicklung ohne zusätzliches Netzteil oder gar den Akku erfolgen kann. Nur die ESCs und Motoren lassen sich so nicht in Betrieb setzen, die erhalten ihre Betriebsspannung direkt vom Akku und würden auch zu viel Strom ziehen.
Der XMega32A nimmt erheblichen Platz auf der Platine in Anspruch. Durch die einseitige Ausführung sind einige Drähte notwendig, ich verwende hier gerne die sehr dünnen und flexiblen Litzen aus den für die Gewinnung der Motoren für den sNQ Stretcho geschlachteten Silverlit TandemZ Hubschraubern.
In der Ansicht von oben sieht man, es ist sogar noch ein klein wenig Luft zwischen Propeller und Grundboard-Umriss, ideale Voraussetzungen für einen ungestörten Luftstrom nach unten.
Der Sensor hängt momentan noch unbefestigt an den Anschlussdrähten in der Luft oberhalb des XMega. Später wird das Sensorboard mit ein oder zwei Lagen Spiegelklebeband auf dem µC festgeklebt. Der Deltang Rx31 sitzt am hinteren Ende des Grundboards auf seinem Stecker in Flugrichtung ausgerichtet. Links zu sehen sitzt der Reset-Taster, der mir gute Dienste bei der Entwicklung der ESC-Einlernroutine geleistet hat. Hier musste ich immer wieder einen Neustart der Copter-Firmware einleiten, für den ich ohne den Taster jedes Mal den Akku hätte abziehen und anstecken müssen. Rechts neben dem Taster das 4-polige PDI-Programmierinterface.
Die Hextronik Brushless Motoren werden in den an den Auslegerenden vorgesehenen Löchern festgeklemmt und halten ohne Verklebung. Zum einsetzen und ausbauen der
Motoren muss die Klemmung mit einem von unten in den Schlitz des Auslegers eingeschobenen Schraubenzieher gelöst werden. Man geht dabei sehr vorsichtig vor, damit
das Platinenmaterial nicht zu stark gestresst wird. Den Schraubenzieher nicht durch Verdrehen verkanten sondern nur mehr oder weniger weit in den Schlitz einschieben.
Unterhalb des Motors sitzt die Positions-LED, vorne jeweils eine Blaue, hinten sind es Rote. Die LEDs sind seitlich aufgelötet und strahlen so nach außen.
Hier noch einmal alle elektronischen Bauteile des xNQ V1 auf einen Blick. Neben den größeren Bauteilen bzw. Funktionsgruppen sitzt nur noch der 3,3 V LowDrop Spannungsregler links zwischen Akku-Stecker und µC.
Der Inbetriebnahme, im ersten Ansatz die Adaption von Williams Firmware für seinen auf der IMAV 2012 erfolgreich geflogenen BOLT, steht nichts mehr im Wege :-)
Na ja, soweit der theoretische Ansatz. In Wirklichkeit kämpfe ich drei Tage mit dem Code, bis sowohl die Steuerkommandos vom Sender als auch die Regelungsvorgaben vom IMU-Sensor korrekt an die Motoren weitergegeben werden.
Was mich dabei am meisten erstaunt hat ist, dass mein neu erstandener Sender, ein Spektrum DX6i, mit der ersten Akkuladung - ich verwende 4 Eneloop Mignons mit der Aufschrift “Min. 1900 mAh” - in diesen drei Tagen mindestens 15 Stunden gelaufen ist und noch immer 5,1 V Akkuspannung anzeigt. Gestartet habe ich mit 5,4 V im Display.
Die Irrungen und Wirrungen im Zuge der Anpassung der Bolt-Firmware an den xNQ möchte ich hier nicht im Einzelnen breit treten. Immerhin habe ich jetzt den strukturellen Aufbau von Williams Programm verstanden, kann die Datenpfade im Programm nachvollziehen und an den richtigen Stellen zielführende Änderungen einbringen. Ich bin aber immer noch meilenweit davon entfernt, den regelungstechnischen Aspekt zu verstehen.
Als die Software soweit in trockenen Tüchern schien, musste ich schweren Herzens die liebevoll ausgetüftelten Steckverbindungen in den Plusleitungen der ESCs wieder ausbauen, da diese den Einbau des Akku verhindert haben. Das muss beim nächsten Layout berücksichtigt werden ;-)
Durch diese notwendige Maßnahme wird die Verkabelung auf der Unterseite des xNQ wirklich übersichtlich und insgesamt schrumpfen die Kabellängen um einige Zentimeter. Das hat durchaus Positives.
Eine weitere Maßnahme ist der Anbau eines zweiten Akkusteckers am hinteren Ende des Grundboards. Vordergründig hilft das erst einmal bei der Verwendung der größeren Akkus, die ich beim xNQ einsetzen will. Die haben nämlich schon ein kurzes Kabel mit einem 2-poligen Stecker im 2,54 mm Raster, ich spare mir hier also die Umrüstung der Akkus auf die winzigen 1,27 mm Raster-Buchsen, mit denen ich sowieso nicht richtig glücklich bin, da deren Stromtragfähigkeit nach Datenblatt nicht für den Betrieb der vier Brushless Motoren ausreicht.
Die ersten Flugversuche sind im Film festgehalten und verliefen... na ja, sagen wir mal, viel versprechend :-)
Der xNQ hat reichlich Power, die aber zu bändigen gelernt werden muss. Die Regelung arbeitet noch sehr verbesserungswürdig.
Der xNQ hebt schön ab und verschwindet seitwärts im Off ;-)
Allerdings hat er sauber die Höhe von ca. 10 cm gehalten, bis die Motoren abgeschaltet
wurden... und das bei einer gefühlten Drehzahl von 200 Upm... um die Hochachse!
Die Stabilisierung macht bis auf die Yaw-Achse einen guten Eindruck. Die scheint zu
verstärken statt zu stabilisieren -> Yaw-Einfluss vom Gyro negieren.
Der 2. Versuch. Eigentlich der 3., denn nach der Korrektur am Yaw-Gyro war Yaw von der Funke vertauscht. Das habe ich nicht für euch aufbereitet, lohnt nicht, wir haben es vor dem Start gemerkt ;-)
Hier nun sieht man, wie der xNQ nach dem Abheben (nennen wir die ersten 500 ms mal so ;-) seitlich weg kippt, die Regelung einhakt und irgendetwas nicht so Schönes tut...
Um zu verhindern, dass ich den xNQ bei, genauer nach den Tests immer irgendwo aufsammeln muss, habe ich ihn auf zwei gekreuzten, zwischen Stuhlbeinen gespannten Gummis fixiert.
Hmm... ich habe nur die Motoren eingeschaltet, sie starten mit Idle-speed, dann habe ich gewartet.
Irgendwann fangen leichte Vibrationen an, die sich ruck zuck aufschaukeln.
Die Regelung ist offensichtlich suboptimal eingestellt...
Ok, mittlerweile weiß ich aus berufenem Munde, dass Gummifäden als Lagerung der absolute Horror für eine Regelung sind und demnach keine gute Idee, um PID-Parameter zu erfühlen.
Die zweite Erkenntnis: Die eingesetzten Hextroniks Motoren sind auch für den xNQ mit abgesetzt montiertem Sensor unbrauchbar. Von weiteren Tests mit diesem Setup habe ich deshalb vorerst einmal abgesehen, ich werde Plan B umsetzen und den nächsten xNQ mit AP-02 Motoren ausrüsten.
Nachtrag (01/2014)
Der xNQ lernt gerade MultiWii ;-)
Da mich die GUI der MultiWii schon länger interessiert, weil dort so schön alle Parameter und auch die Sensordaten live angezeigt werden, habe ich schon den sNQ V2 testweise auf MWC getrimmt, das Thema damals aber nicht weiter verfolgt, weil ich zeitgleich den xNQ auf Kiel gelegt habe, der mich mehr interessierte :-)
Einen kleinen Eindruck der Irrungen und Wirrungen beim Versuch, eine unbekannte Software an die eigene sNQ-Hardware anzupassen möchte ich für die Nachwelt festhalten.
Rückblende. Eines Novembers anno 2013...
Mannomann!
Ich habe heute mal wieder den inneren Schweinehund überwunden (das fiel mir heute etwas leichter, da ich keine Stelle in meiner Homepage mehr gefunden habe, die ich aufschiebend noch hätte verbessern können ;-) und mich erneut an die Portierung der MultiWii Software auf den sNQ gesetzt.
Im Netz im rc-heli-fan Forum habe ich ein Tutorial gefunden, das Mezzo für Anfänger wie mich geschrieben hat. Er erklärt, wie man die Sensoren einer proprietären Lösung (wie der sNQ eine ist) an den MultiWii Code anflanscht.
Das hat sehr schön funktioniert, da er auch die Stelle im Code angegeben hat, an der man eingreifen muss, sollte die StandardConfig nicht stimmen. Ich habe gemerkt, dass ich an der falschen Stelle rumgepatcht hatte. Dank WinMerge kann ich meine falschen Änderungen schnell finden und rückgängig machen.
Leider passte dann immer noch nichts aufeinander :-(
Das Problem ist, ich habe zwei Sätze Sensoren (Gyro, ACC) und 3 Kanäle auf der Funke, die passend zusammen gemischt und dann auf die richtigen Motoren aufgeschaltet werden müssen.
Das bekommt man ja noch irgendwie gebacken, aber die MultiWii-Gemeinde hat als erste Stufe der Erniedrigung noch die GUI auf die Menschheit losgelassen.
Man geht also ohne Motoren vor und stellt alles solange ein und um, bis die GUI die Bewegungen des Copters UND die Auswirkungen der Knüppelbewegungen an der Funke korrekt auf die stilisierten Motoren überträgt. Alles Schwarzwälder Kirsch mit Sahnehäubchen, sollte man meinen :-)
Dann versucht man, die Drehzahländerung der Motoren mit den Anzeigen in der GUI in Verbindung zu bringen, was von vorne herein zum Scheitern verurteilt ist, da der sNQ einfach nicht stark genug ist, um den Copter in der Hand nennenswert zu bewegen. Nur hinhören und/oder die Temperatur an der Hand versuchen zu interpretieren (Luftzug = kalt) klappt nicht. Die Motoren sitzen auf dem sNQ so dicht zusammen, dass die akustische Auflösung nicht fein genug arbeitet. Die sensuelle Wahrnehmung am Rücken der linken Hand ist kaum besser. Man erkennt also nicht, was die Motoren wirklich tun oder zumindest versuchen zu tun :-(
Aber man hat ja mittlerweile gelesen… Alles! Und noch ein bisschen mehr :-)
Da mein sNQ LEDs an den PWM-Ausgängen hat um Überspannungen an den ESC -Eingängen zu vermeiden (der µC läuft mit 5 V, der ESC mit 3,x V), kann man die ESCs abklemmen und den Code per #define EXT_MOTOR_RANGE auf reine PWM (0 ..2000) umstellen. Jetzt kann man an den LEDs sehr schön die Drehzahlvorgaben anhand der Helligkeit erkennen…
…und stellt entsetzt fest, dass die GUI-Anzeige aber auch gar nichts mit der Ansteuerung der Motoren gemein hat.
Einige Stunden später, kurz vor dem finalen Nervenzusammenbruch, habe ich meinen Fehler bei der Motorzuordnung erkannt.
Ich muss die Beaufschlagung der Motoren mit den Werten aus dem Mischer nicht beim PIDMIX einstellen, sondern die hier mit Werten gefüllten motor[x] Variablen bei der Zuordnung zu den PWM-Erzeugern korrekt sortieren.
Hier ist nicht unbedingt hilfreich, dass die Motorzuordnung im MultiWii-Code bei XQUAD falsch kommentiert ist. Aber das nur am Rande…
Ok, jetzt müsste alles stimmen, compile-download-start-Copter beweg - ok - Knüppel beweg … Schei…!!
Schon wieder anders als erwartet :-(
Ok, einen Versuch gebe ich mir noch. Ich ignoriere die Darstellung in der GUI und stelle den Code so um, dass nach Adam Riese und Eva Zwerg die Motoren richtig angesteuert werden… Yepp!
Ok, ESCs wieder mit Strom versorgen. Einzeln, weil vorhin beim Hantieren am Copter mal was gepitscht und gestunken hat :-(
Genau, einer der ESCs ist mal wieder in die ewigen Jagdgründe eingegangen… zum Glück habe ich gerade doppelt so viele geliefert bekommen, wie ich ersteigert hatte (Ich wollte 5 haben, habe mich noch über den hohen Preis geärgert, aber was soll's… dann teilt mir der Verkäufer mit, dass es noch ein bisschen dauert, aber ich bekäme zwei für das in der Versteigerung angegebene Geld… ok, habe ich also 10 statt 5 hier rum liegen).
Den tausche ich morgen… oder irgendwann die Tage… jetzt habe ich keine Lust mehr.
Das alles, weil ich den sNQ nicht mit dem Lötkolben bearbeiten will, um den MultiWii Code ans Laufen zu bekommen. Ich bin also auf die softwaremäßige Zuteilung der Ausgänge zu den Regelalgos angewiesen. Immerhin soll ja später vielleicht auch wieder der Shrediquette Code auf dem sNQ laufen.
Die Lösung, die Ausgänge wie bei Standard-MultiWii zu verdrahten, ist ja nun wirklich nur was für Weicheier und Steaks-mit-der-Grillzange-Wender :-)
Soweit ein kleiner Ausschnitt der Probleme mit einer Hardware, die mit dem AtMega328p immerhin den passenden µC an Bord hat.
Da der xNQ mit einem XMega befeuert ist, für den die MultiWii-Software im ursprünglichen Zustand nicht geeignet ist, habe ich zuerst mal Nachforschungen angestellt, ob die Portierung der MWC-Software auf XMega vielleicht schon erfolgt ist.
Eine komplette Portierung habe ich nicht gefunden, aber Matthias K. hat einen Copter mit einem XMega als zentraler Steuerung programmiert, indem er alle “überflüssigen” #ifdef aus dem Code entfernt und den resultierenden Code dann noch in weiten Teilen überarbeitet und für sich optimiert hat. Die Routinen zur Kommunikation mit der GUI hat er leider entfernt und anschließend komplett anders implementiert.
Diesen Code hat er mir zur Verfügung gestellt, so dass ich ein Grundgerüst besaß, auf dem ich aufbauen konnte.
Inzwischen läuft der Code im Wesentlichen auf meiner xNQ-Hardware und ich kann auf die Suche nach PID-Werten gehen, mit denen der xNQ zurecht kommt.
In den letzten Tagen habe ich, unterstützt durch eine Routine in meiner MWC-Adaption, die Propeller und Motoren von zwei xNQ-Prototypen (xNQ V1 mit Hextronik D1000 Motoren und xNQ V2 mit AP-02 Motoren) ausgewuchtet. Besser gelungen ist mir das beim xNQ V2. Dieser V2 musste dann natürlich sofort zeigen, was er kann.
Er wurde also ins Wohnzimmer expediert und in den (vergleichsweise nahezu) freien Luftraum entlassen ;-)
Hier zuerst ein Filmchen im Acro-Modus:
Anschließend wurde der Hover- oder Level-Modus getestet:
Bei beiden Flügen wurde der xNQ mit einem 600 mAh-Akku versorgt. Die Steigleistung war entsprechend eingeschränkt, wobei bewusst auf größere Höhen verzichtet wurde, da die PID-Parameter zu diesem Zeitpunkt noch nicht optimal eingestellt waren, also jederzeit mit einem Absturz zu rechnen war.
Bei den Flugübungen schien sich akustisch anzudeuten, dass das Regelverhalten der ESCs (EAZY 3A) nicht sonderlich gleichmäßig ausfällt. Ein anschließender Test auf dem Schreibtisch zeigte dann auch deutlich, dass die ESCs der gleichmäßigen Ansteuerung nur in Stufen folgen.
Da kann möglicher Weise Abhilfe geschaffen werden...
Besucher seit
25.11.2000