Mit dem Assan GA250 Gyro bekommt mein FP&Koax-Gyromischer Projekt wieder neuen Schwung. Die Arbeiten daran werde ich hier ganz im Blog-Sinne schrittweise dokumentieren.
Direkt zum letzten Eintrag: 22. Januar 2012
Aktuelle Firm- & Software: v022.014.016-20120122
Nachbauer/Nutzer:
Tommy@LA… der erste Mutige draut sich an das Projekt heran… [RCLine Thread]
Luvmyhelis… der Zweite… eigentlich war er der Erste, die Post hat nur länger gedauert…. [RCGroups Thread]
Tommy@LA gefällt der Gyromixer wohl, sein zweiter Heli damit, ein brushed Umbau [RCLine Thread]
bei rcgroups haben sich Einige einen Gyromixer „geordert“ rcgroups, bebev @ rcgroups, jrjr @ rcgroups (oder sein Blog), robby69 @ Kommentar unten.
Kurz zum Hintergrund. Vor ca 1 1/2 Jahren habe ich mich am Brushless-Umbau meiner Lama V4 versucht, zunächst mit einem fertigen Umbaukit. Das Ergebnis war aber alles andere als überzeugend (hier). Nun hätte ich einen boardless Umbau versuchen können, hatte ich aber keinen Bock zu. Da mir aufgefallen war, dass sich der uC der (alten) ESky 4in1 mehr oder weniger direkt durch den Atiny261/461/861 ersetzen lässt, ist stattdessen das 4-1+2in1 Projekt entstanden. Dazu braucht es aber doch einige Arbeit an der Hardware. Irgendwann bin ich dann darauf gekommen, dass einige der billigen China-Piezo-Gyros (HK401B, KDS800, EK2-0704B) eigentlich alle nötige Hardware mitbringen, d.h., einen Atmel-uC (ATmega8), einen Gyro-Sensor (Murata-ECN03-Piezo-Gyro-Sensor), ein bis zwei LEDs, sowie ein bis zwei Potis… und so entstand das FP&Koax-Gyromischer Projekt. Den bisherigen Verlauf des Gyromischer Projekts hatte ich ausführlich im RCLine-Forum dargestellt: Dokumentation, Diskussion und sonstiges. Die Response war allerdings nicht gerade überwältigend, war wohl nicht ganz nach deren Geschmack. 😉
Wie auch immer, bis auf Potis bietet auch der GA250 alles was man so braucht, und sogar mehr, da hier statt eines Piezo-Sensors der MEMS Gyro ISZ-650 von Invensense eingebaut ist. Nachdem ich mich in den letzten Tagen mit dem Entziffern des Schaltplans des GA250 beschäftigt hatte, habe ich mich heute nun daran gemacht mit dem Umbau zum FP&Koax-Gyromischer zu beginnen.
GA250 Schaltplan
Atmega8 Datenblatt
ISZ-650 Datenblatt
3. April 2011:
Der erste Schritt des Umbaus des GA250 zum FP&Koax-Gyromischer bestand darin, den Atmega8 zu löschen, den Bootlader von Haagen zu flashen (liegt auf dem SCK-Pin PB5), und die Boot-Fuses richtig zu setzen (BOOTSZ1:0=10, BOOTRST=0). Mit den herausgeführten ISP-Pins war das nicht schwierig:
Dann kam der eigentliche Umbau dran. Ich hatte zunächst versucht den zweiten PPM-Ausgang an das kleine zum Pin PD5 gehörige Pad anzulöten, hat sich aber gleich abgelöst. Da müsste man also vorsichtiger vorgehen. Ich habe jetzt den MOSI-Pin PB3 genommen. Neben den Kabeln für Throttle, Rudder, Motor A, und Motor B habe ich noch zusätzlich einen Anschluss am SCK-Pin PB5 verlegt, so kann man den uC ohne Abstecken über den Bootlader flashen. Was vielleicht noch wichtiger werden kann, da ja keine Potis da sind muss die Konfiguration über eine Programmierbox laufen, und das könnte komfortabel auch über diesen Anschluss laufen (wird sich aber erst noch zeigen). Nun noch die Bilder:
Fuse Setting (Atmega8, 0x1e9307)
ChkOpt=1, SUT1:0= 11, CKSEL3:0= 1111, BODEN= 0, BODLEVEL= 1
Bootloader @ PB5/SCK, Fuses BOOTSZ1:0= 10, BOOTRST= 0
low fuse: 0xBF, high fuse: 0xDC
Belegung der Ports des Atmega8
Zugänglich über Kabelanschlüsse:
– PB0/ICP: Rudder-Eingangssignal vom Empfänger
– PD2/INT0: Throttle-Eingangssignal vom Empfänger
– PB2/OC1B: Ausgangssignal für Motor B
Zugänglich über die ISP Pads:
– PB3/MOSI: Ausgangssignal für Motor A
– PB5/SCK: Verbindung zur Programierbox und/oder zum Bootloader
Intern verschaltet:
– PC1/ADC1: Zx4.5 out Signal vom ISZ-650 Gyrosensor (+-440°/s -> +-1V Gyrosignal)
– PB4/MISO: AZ pin des ISZ-650 Gyrosensor, wird nur beim Initialisieren einmal benutzt
– PD3: rote LED
– PD4: blaue LED
ACHTUNG: Bei den Fuses ist es wichtig den Brown-out Detektor einzuschalten, ansonsten leidet das EEPROM manchmal unter „Gedächtnisverlust“, das hatte ich leider anfänglich vergessen 0xFF für die low fuse angegeben. Die Low Fuse muss auf 0xBF gesetzt werden!
4. Mai 2011:
So, jetzt geht’s hier endlich mal weiter. Hat so lange gedauert weil ich den Schritt jetzt doch ziemlich mühselig fand. Das Problem ist, dass der GA250 keine Potis hat mit den man mal schnell einige wichtige Parameter einstellen könnte (und man braucht mindestens zwei, Prop und Gain, damit’s überhaupt Sinn macht ernsthaft los zu programmieren). Das heißt, die Parameter müssen irgendwie anders eingestellt werden, und ich wollte das über eine ProgBox, bzw. mit einem zur ProgBox umgebauten Robbe Programmer realisieren (dazu auch hier).
Jetzt hätte ich das genauso wie zuvor bei Achim’s Koaxmischer über Haagens Bootloader machen können… wollte ich aber nicht. Erstens wäre das auch nicht soo schnell gegangen, da ich das Menü für die Progbox trotzdem hätte neu programmieren müssen. Zweitens, wenn sich im Zuge der Entwicklung Änderungen an den Parametern ergeben hätten, was nun nicht gerade unwahrscheinlich ist, dann hätte ich auch jedes mal die Progbox neu programmieren müssen. Drittens kann man so die Parameter nicht im Betrieb einstellen, sondern muss immer hin und her fummeln. Der GANZ GROSSE Nachteil des Konzepts ist aber, dass man für jedes Gerät eine speziell programmierte ProgBox braucht, und ich habe natürlich null Bock für jeden Gerätetyp eine eigene ProgBox anzuschaffen und/oder jedes mal erst die PogBox auf das Gerät neu zu programmieren. Also, ätzend. Deswegen wollte ich eine Progbox die ich während des Betriebs, z.B. wenn Throttle low ist, einfach an und abstecken kann, und vor allem, die für alle meine Geräte (die ich noch so bauen werde :-)) universell funktioniert.
Das Letztere geht natürlich nur, wenn das Menü und alles was dazu gehört im Gerät selber gespeichert ist. Nachdem aber Menüs recht schnell viel Platz verbrauchen, das Ganze aber auch mit einem ATmega8 funktionieren soll, braucht man soetwas wie eine (einfache) Menü-„Beschreibungssprache“. Ein weiteres Problem ist der Verbindungsaufbau. Das Gerät muss ja mit dem an- und abstöpseln der ProgBox zurecht kommen, und umgekehrt muss die ProgBox merken ob sie am Gerät hängt oder nicht. Und das dritte Problem, alles muss über einen interruptfreien Software-UART laufen, da oft, wie z.B. beim GA250, kein Pin mit einem Interrupt frei und leicht zugänglich ist. Das heißt aber auch, dass zum Erkennen ob etwas empfangen wird gepollt werden muss, was wiederum heißt, das derweil alle anderen Interrupts abgeschaltet werden müssen, was wiederum heißt das derweil nichts aber auch gar nichts Anderes passieren kann und darf… was es kompliziert macht wenn man gleichzeitig noch die Empfängersignale einlesen und die PPM-Signale ausgeben muss…
Kurzum, ich habe also erstmal einen interruptfreien SW-UART für das Gerät programmiert, mit einem Timeout beim Pollen, und habe mich für die ProgBox damit beschäftigt wie der Hardware-UART bei 1-Wire verwende werden kann. Glücklicherweise ging das ganz zügig. Ich habe einfach darauf verzichtet „coolen“ Code zu erzeugen. Ist jetzt einfach alles in C und mit den eingebauten delay-Routinen programmiert, also nichts mit ASM und abzählen der Takte und so, aber bei der gewählten Baudrate von 38400 bps funktioniert mein Billig-Code einwandfrei.
Von der Hardwareseite hat die Lösung nun auch den netten Vorteil, dass an der Robbe Box gar nichts umgebaut werden muss, diese also so verwendet werden kann wie sie ist und nur umprogrammiert werden muss.
Das nächste große Problem war das Daten-Protokoll. Da habe ich tatsächlich die meiste Zeit dran verplempelt. Zwischendrin hatte ich mich mal für ein Protokoll ähnlich dem der Jeti-Box entschieden, d.h. das Gerät sendet regelmäßig einen Menüpunkt aus, und die ProgBox antwortet mit einem Byte mit den gedrückten Tasten (siehe z.B. hier). Allerdings habe ich hier nicht wie bei der Jeti-Box einfach den Text an die ProgBox geschickt, weil ich die ganze String-Verarbeitung und Dergleichen definitiv nicht im Gerät haben wollte, weil’s halt einfach viel Resourcen kostet. Da habe ich mir eine etwas geschicktere Codierung des Menüs überlegt. Wie das dann alles lief habe ich festgestellt, dass das Protokol ziemlicher Mist ist, wenn man das Gerät nicht alles erledigen lassen will. Das Datenpaket welches nach dem Tastenbyte geschickt wird kommt ja erst eine ganze Zeit später an, und in der Zwischenzeit können Tasten gedrückt worden sein, so dass das aktuelle Datenpaket nicht mit dem aktuellen Tastenzustand synchron ist. Kann man mit einem lock-unlock Mechanismus leicht lösen, macht die ganze Sache aber recht langsam und umständlich (im Vergleich dazu wie schnell man Tasten drücken kann).
Ich habe das jetzt so gelöst, dass das Gerät ein Erkennungs-Byte sendet, auf Empfang schaltet und 160 us wartet ob ein Byte empfangen wird, und danach wieder auf Senden schaltet. Dieses Byte wird als Kommando ans Gerät interpretiert, was es als nächstes machen und/oder senden soll. Die daraufhin zu sendenden Daten werden dann Byte für Byte, je nachdem wie es die anderen noch zu erledigenden Aufgaben erlauben, gesendet (bei 38400 bps dauert ein Byte ja nur 260us, diese Zeit findet sich). Die Zeit von einem Byte bis zum nächste Byte darf dabei höchstens ca. 8 ms betragen. Ist das Datenpaket gesendet, wird eine Zeitlücke von ca. 15 ms gewartet, und dann wieder das Erkennungs-Byte gesendet, usw. Dieses Zeitmanagment ist entscheidend, denn daran erkennt die ProgBox wann und wo ein neues Datenpaket anfängt.
Der im Gerät benötigte Code sind ca 900 Bytes, und jeder Menüpunkt belegt durchschnittlich 20-30 Bytes.
5. Mai 2011:
… und jetzt funktioniert das auch mit der Robbe Programmer Box. Da die zuvor als ProgBox für Achim’s Koaxmixer diente, wo die Programmierung ja über Haagens Bootlader läuft, und wofür zwei Widerstände umgebaut werden mussten, musste der Robbe Programmer erst wieder rückgebaut werden. Nun, das habe ich eben gemacht, und technisch ist die Robbe Box hardwaremäßig wieder im alten Zustand. Dann noch schnell neu programmiert, und schon hat alles funktioniert… supi 🙂
GA250 Gyromixer mit ProgBox
Fuse Setting
SUT1:0= 00, CKSEL3:0= 1111, Bootloader @ PD1/TXD, Fuses BOOTSZ1:0= 10, BOOTRST= 0
low fuse: 0xCF, high fuse: 0xDD, ext fuse: 0x04
ACHTUNG: Die RobbeBox gibt es mit dem ATmega88 (device signature 0x1e930a) oder ATmega88PA (device signature 0x1e930f). UNBEDINGT DEN RICHTIGEN BOOTLOADER AUFSPIELEN! (siehe auch hier)
9. Mai 2011:
Es ist Mitternacht, und eine erste ganz grobe Version einer Software (v0.05) für den GA250 Gyromixer ist fertig, und… Juchuuuuuu… der Koax fliegt 🙂
Meine Bemühungen gestern Abend waren etwas „frustrierende“, weil ich Glitches bei der PPM-Ausgabe hatte… aber jetzt klappt’s wie es soll. Im Moment kann ich nur Prop, Gain, und die Framelänge (ich habe im Moment 6 ms gewählt) einstellen, und die Gyro-Funktion entspricht einem einfachen Rate-Gyro. Aber das Teil fliegt gut, die Drehrate ist so wie ich mir das vorstelle, das Verhalten mit Gain ist genauso wie man es sich vorstellt, und die relativ starken Vibrationen des Koax scheinen nicht groß zu stören (ich benutze meine „abgenudelte“ Lama V4 No. 2 als Testplattform). Und das mit der ProgBox funktioniert auch. Bin Happy.
Das heißt, jetzt kann ich mich dran machen und den ganzen Schnickschnack rein zu programmieren.
16. Mai 2011:
Bei der vorhergehenden Code-Version ist mir aufgefallen, dass unter „extremen“ Bedingungen, also wenn man wild hin-und-her fliegt und/oder das Gain sehr groß gestellt hat, die Motoren kurzzeitig aussetzen können und der Heli quasi „herunterfällt“. Es war schnell klar das dies daran liegt, dass das Regelsignal bei abrupten Ruddersteuerungen zu groß wird. Es musste also „irgendwie“ begrenzt werden, und es war nur die Frage was hier am Sinnvollsten ist. Aber wie immer war die einfachste Lösung die Beste. Es hat sich nämlich gezeigt das ein Unterschied von 200 us zwischen dem PPM Signal für den oberen und unteren Motor bereits zu viel zu schnellen Drehungen des Koax führt. Also, Regelsignal einfach auf z.B. +-100 us begrenzen, und schon funktioniert’s. 🙂
Tatsächlich bin ich von dem Gyro beeindruckt. Der Heli ist mittlerweile wirklich in einem zerrupften Zustand. Also, von vibrationsarm keine Spur, und trotzdem, der Gyro verrichtet seine Arbeit einwandfrei. Ich hatte das Gyro-Signal zunächst 8 mal eingelesen, um eine Filterwirkung und eine Decimation zu erreichen. Aber 1x einlesen reicht völlig aus… ich kann zumindest soweit keinen Unterschied feststellen.
Die Framerate ist allerdings sehr wichtig. Die läßt sich im Moment von 6 ms bis auf 22 ms einstellen. Und bei 22 ms bekommt man ein sehr ruckeliges Flugverhalten. Also, die 6 ms sind schon gut. Leider komme ich wegen dem Support für die Progbox noch nicht weiter runter als 6 ms. Mal sehen ob mir da noch was einfällt, 3 ms wären schon schön…. (ob’s was bringt ist ne andere Frage).
Ich habe übrigens im Moment einfach nur einen popeligen P-Regler programmiert, also:
Cntrl= Gain*( Rudd_Rate*Rudd – Gyro );
LIMIT( Cntrl, -Cntrl_Limit, Cntrl_Limit );
MotA= Thro – Prop – Cntrl;
MotB= Thro + Prop + Cntrl;
Mit Rudd_Rate kann man die gewünschte maximale Drehrate einstellen.
Als nächstes kommt jetzt noch Revo und Expo rein, dann wird sich der Heli schon recht gut fliegen lassen. Und dann kommt natürlich noch HH.
22. Mai 2011:
Heute ist die Version v0.10 fertig geworden… und die funktioniert wie ich finde ZIEMLICH gut :-). Ich werde nächste Woche mal versuchen ein Video dazu zu machen.
Die Regelung ist nach wie vor ein einfacher P-Regler, aber das funktioniert wirklich schon ganz prächtig. Ein I-Anteil macht bei einem Rate-Gyro glaube ich keinen rechten Sinn. Ein D-Anteil (mit set point weighting) könnte vielleicht bei Pitchstössen noch helfen. Mal sehen ob ich das erst noch probiere, oder mich als nächstes endlich mal an einen HH-Gyro mache.
PS: habe ich heute Abend doch noch schnell ausprobiert, einen D-Anteil, und ich kann nicht erkennen dass der irgend etwas verbessert.
Es gibt nun eine ganze Reihe von (mit der Robbe ProgBox) einstellbaren Parametern, die ich auflisten möchte, auch um einen Eindruck vom Funktionsumfang zu geben.
PID Gain [0.0 … 10.0]
Gain wie bei Koaxen üblich und wie oben angegeben, entspricht Wert des P-Anteils
Prop [-100 … 100]
Prop wie bei Koaxe üblich und wie oben angegeben. Prop verschiebt die Gasgeraden für Motor A und B gegen einander, siehe auch hier
Revo [-100 … 100]
Ändert die Steigungen der Gasgeraden für Motor A und B für einen Throttle-abhängigen Drehmomentausgleich, siehe auch hier
Rudd Rate [0.0 … 3.0]
Maximale Drehgeschwindigkeit. 1.0 entspricht in etwa 1 Umdrehung pro Sekunde
Rudd Expo [0.00 … 1.00]
Expo Einstellung für Rudder. 1.00 entspricht einem vollständig flachen Verlauf
Thro Expo [0.00 … 1.00]
Expo Einstellung für Throttle. 1.00 entspricht einem vollständig flachen Verlauf
Thro Hover [25% … 75%]
Referenzpunkt für Revo und Thro Expo, siehe auch hier
Thro Min [0% … 35%]
Minimaler Wert der Motor-Gaskurven
Thro Max [65% … 100%]
Maximaler Wert der Motor-Gaskurven
LP Time [0 … 10]
„Zeitkonstante“ eines Tiefpassfilters, mit der das Gyro-Sensorsignal gefiltert wird
LP Average [1 … 8]
Anzahl der ADC-Samples des Gyro-Sensorsignals über die gemittelt wird
Frame Length [6 ms … 22 ms]
Zeitabstand mit der die PPM Signale für die Motoren ausgegeben werden. Eigentlich ist nur 6 ms sinnvoll, da die BESCs dies ab können sollten, und die Regelung damit am genauesten arbeitet.
Daneben gibt es noch weitere Parameter für Testereien:
Cntrl Limit [0 … 1000]
Damit wird das Regelsignal nach dem P-Controller eingeschränkt. Der Wert sollte gross genug sein so dass die maximale Drehrate nicht eingeschränkt wird aber auch nicht zu groß sein so dass die Regelung „spinnt“.
Rudd Sense [0.00 … 1.00]
Dieser Wert wird bei Gain = 0 wirksam, d.h. wenn der Regler „ausgeschaltet“ ist. Dann wird Cntrl= Rudd_Sense*Rudd benutzt, was einem erlaubt die „Empfindlichkeit“ des Rudder-Knüppels abzuschätzen.
Mot Min Value [us]
Minimal möglicher Wert bei der Motor-Gaskurve
Mot Max Value [us]
Maximal möglicher Wert bei der Motor-Gaskurve
Thro Min Value [us]
Dieser Wert wird bei der Throttle-Stick-Kalibrierung eingelesen
Thro Max Value [us]
Dieser Wert wird bei der Throttle-Stick-Kalibrierung eingelesen
25. Mai 2011:
Nun zwei Videos zum GA250-Koaxgyromixer-Umbau. Im ersten Video zeige ich einige der Funktionen und die Arbeitsweise. Das zweite Video sollte ein Flugvideo werden um zu zeigen wie gut oder schlecht der Gyromixer funktioniert… nur leider habe ich gleich mal einen Blattklatscher produziert… welcher gar nicht mal ganz zu sehen ist (keine Ahnung warum, hat mein Sohn vor Schreck die Kamera ausgeschaltet?)… und dann war keine Zeit mehr… da muss ich also nochmals ran.
2. Juni 2011:
Wie versprochen jetzt noch ein besseres Flugvideo. Ich denke man kann jetzt schon sehen was gut geht und was nicht so gut geht. Das Heck zeigt eine leichte Drift. Das liegt nun nicht am Gyro, das ist ja ein MEMS, sondern daran, dass die Prop-Einstellung über den Flug hinweg mit abnehmender Batteriespannung ständig geändert werden müsste. Da braucht es Heading-Hold. Es ist auch zu erkennen, dass sich das Heck bei plötzlichen Pitchstößen doch etwas wegdreht. Ich weiß nachwievor nicht woher das kommt, mit Revo bekommt man es nicht weg, und mit einem D-Term im Regler auch nicht. Hier lege ich meine Hoffnungen auch auf Heading-Hold. Aber ausser diesen „Kleinigkeiten“ fliegt das Teil denke ich doch ganz gut, das Flughandling fühlt sich für mich zumindest ganz gut an. 🙂
6. Juni 2011:
Ich bin gestern tatsächlich die Implementierung von Heading-Hold angegangen, also, raus aus den „theoretischen Überlegungen“ und so richtig rein in die Praxis. War lustig. Der basic Schritt war eigentlich schnell implementiert, aber ich musste lernen, dass ein Heading-Hold nur mit P Anteil (bzw. I in Bezug auf das Gyrosignal) nicht gut funktioniert, und das ein D Anteil (bzw. P in Bezug auf das Gyrosignal) ziemlich wichtig ist. Aber das war dann eigentlich schon klar. Nur mit einem P Anteil muss die Regelung dazu tendieren zu oszillieren, und ein Blick in die Zukunft wie er durch den D Anteil geboten wird ist daher sehr nötig. Finde ich aber trotzdem lustig, dass bei einem rate Gyro die Primitiv-Variante mit nur nen P Anteil schon ziemlich gut funktioniert, beim heading-hold Gyro aber nicht. Jedenfalls, jetzt wird tatsächlich das heading geholded… allerdings gefällt mir das Feeling noch nicht wirklich gut, irgendwie ein bischen zu ruppig. Das Hauptroblem im Moment ist aber, dass das mit den Pitchstössen so gar nicht gut funktioniert. Da dreht sich der Heli manchmal ziemlich weit raus und hat dann Probleme sich wieder zurecht zufinden. Da muss ich also noch mal ran und nach den Ursachen forschen. Ist dann doch nicht so einfach, das mit dem Heading-Hold.
9. Juni 2011:
Ich glaube jetzt habe ich’s im Wesentlichen… das Heading-Hold funktioniert G U T 🙂 🙂 🙂
Fühlt sich gut an, und beim Vollpitch kein Wegdrehen mehr. Beim Start gibt es noch ein leichtes Zittern, ich weiss nicht ob das an der Regelung liegt, also ob die Parameter vielleicht noch nicht gut eingestellt sind, oder ob das an der Mechanik liegt, aber soweit bin ich jetzt schonmal sehr zufrieden.
Yeah…
23. Juni 2011:
… und das mit dem Heading Hold funktioniert immer noch gut…. 🙂
Ich habe noch so das Eine oder Andere ausprobiert, wie z.B. set point weighting und verschiedene Filter, aber das hat’s nicht so gebracht.
Da ich die Kommunikation mit der Robbe Box eh darauf eingeschränkt hatte, nur während des Stillstands des Helis zu funktionieren (was anders macht ja auch nicht soo viel Sinn, ne), konnte ich mit einem „kleinen Trick“ nun auch problemlos eine minimale Framelänge von nun 4 ms statt bisher 6 ms erreichen (entsprechend 250 Hz statt 167 Hz). Dazu schalte ich die Framelänge einfach um, d.h. im Stillstand des Helis wird die Framelänge auf 18 ms gesetzt, und es bleibt dann alle Zeit der Welt für die Kommunikation mit der Progbox. Sobald der Heli in den Flugmodus wechselt wird die Framelänge entsprechend dem Parameter Frame Length gewählt, z.B. eben 4 ms. Die 2 ms Gewinn gegenüber vorher ergeben sich einfach daraus, dass nun eine Kommunikation mit der Progbox konsequent „abgeschaltet“ wurde.
Mit geringfügigem Umstellen des Codes, und Beschränkung des Maximalwerts für den Parameter LP Average auf 7 (statt 8)(so dass die Zeit um den aktuellen Gyrowert zu bestimmen kürzer als 1 ms bleibt), wären auch 3 ms entsprechend 333 Hz problemlos zu machen, aber irgendwie sehe ich die Notwendigkeit nicht richtig.
Neben bei bemerkt, es hat sich gezeigt, das im Gegensatz zum obigen Yaw-Regler, große Werte für die Filterparameter LP Time und LP Average eher schädlich sind! Einmal bedeutet das, dass es kein großer Grund für Traurigkeit wäre den Wert von LP Average auf 7 oder gar 4 einzuschränken. Wichtiger, der Tiefpassfilter wirkt nun nur auf den P-Anteil, aber nicht auf den I-Anteil.
Codemässig ist das Heading Hold bei mir nun als einfacher PI-Regler mit deadband und anti-wind-up implementiert:
if( abs(Rudd) < DeadBand ) Rudd= 0;
Cntrl= Gain*(Rudd_Rate*Rudd - Gyro);
ErrAngle+= (Rudd_Rate*Rudd - RawGyro);
LIMIT( ErrAngle, -2000, 2000 );
Cntrl+= I * ErrAngle
LIMIT( Cntrl, -Cntrl_Limit, Cntrl_Limit );
MotA= Thro - Cntrl;
MotB= Thro + Cntrl;
Hinzu kommen natürlich noch die ganzen Sachen wie Prop, Revo, Expo, etc. Wichtig war es auch die Begrenzung der Werte nach unten und oben sinnvoll zu gestalten. Die Art und Weise der Begrenzung nach oben war z.B. ausschlaggebend für ein korrektes Verhalten bei Vollpitch (also kein Wegdrehen bei Vollpitch).
So, nun aber genug getöst, hier zwei Flugvideos damit Ihr euch selber eine Meinung bilden könnt.
[embed width="350"]http://youtu.be/XbSSi2Sci98[/embed]
[embed width="350"]http://youtu.be/crtityIyO4A[/embed]
15. Juli 2011:
Die Hardware des GA250 erlaubt noch Erweiterungen, zum Beispiel um einen Liposaver.
Denn es gibt noch ein paar nicht genutzte „leicht“ zugängliche Ports. „Leicht“ heißt, dass sie nicht so direkt mühelos zugänglich sind wie die oben benutzten Anschlüsse, aber doch soweit, dass man sie ohne Mikrolöttechniker zu sein benutzen kann. Konkret handelt es sich um:
– PD5: dieser Anschluss ist über ein kleines Lötpad zugänglich (reißt leider sehr leicht ab)
– PC6/ADC0: dieser ADC Eingang wird original dazu benutzt den Temperatursensor des ISZ-Gyros auszulesen, aber wer braucht schon die Temperatur bei einem MEMS; lötet man den Widerstand R14 aus, dann wird dieser Port verfügbar
– PD0/PD1: diese beiden Ports sind kurzgeschlossen und über Widerstand R11 mit dem Gain-Eingang verbunden; lötet man R11 aus, ist dieser Eingang zugänglich
Damit ist der Weg zum Liposaver vorgezeichnet, R14 auslöten und dort einen Spannungsteiler aus einem 1k und 4.7k Widerstand anlöten. Die Widerstände erlauben es Spannungen bis 15 V zu messen, das ganze ist also auf bis zu 3S ausgelegt (Vref ist 2.7 V, und mit nem 1k,4.7k Spannungsteiler ergeben sich daraus 15.4 V max). An das Lötpädchen zum Port PD5 wird einfach ein Kabel angelötet, um z.B. daran eine Led mit einem externen Widerstand als Anzeigeelement anzubringen. In der Praxis sieht das dann z.B. so aus:
|
|
|---|
Mit diesem Umbau ist es zwar etwas sehr eng im kleinen Gehäuse des GA250 geworden, aber es geht gerade noch so, muss halt ein bischen feilen. Hardwaremässig funktioniert das aber tadellos. Was jetzt noch fehlt ist die Software… 🙂 (was leider noch ein bischen dauern kann)
21. Juli 2011:
Hier nun eine Bildergallerie, welche die einzelnen Schritte des Umbaus des GA250 zum Gyromixer (ohne Liposaver) detailliert darstellt:
ACHTUNG: Beim Umbau wie vorgestellt sind der Ausgang für MotorA und der Programmieranschluß NICHT mit einem Widerstand geschützt. Beim Programmieranschluß mag das unwichtig sein, beim MotorA-Anschluß aber evtl. nicht da hier eine „aktive“ BESC angeschlossen wird… ich hatte damit noch nie Probleme, aber Luvmyhelis. Wer mag, sollte den Mod so abändern dass noch zumindest ein 220-1k Widerstand in die MotorA-Signalzuleitung kommt! (eine Möglichkeit habe ich hier vorgestellt, ersetzt dann die Schritte 64-66)
24. Juli 2011:
Und nun noch eine Zusammenstellung der Materialliste der benötigten Teile zum Nachbauen (ohne Liposaver). Die ganze Combo besteht aus drei Einheiten, dem GA250 Gyromixer, der ProgBox, und dem Programmieradapter, wie im Bild gezeigt.
GA250 Gyromixer:
1 x ASSAN GA250 (z.B. Hobbyking Produkt ID: GA-250)
2 x ServoKabel (z.B. 40CM Servo Lead (JR) 32AWG Ultra Light 10pcs/bag, Hobbyking)
1 x Stück Schrumpfschlauch 2mm rot
1 x Stück Schrumpfschlauch 2mm blau
1 x Stück Schrumpfschlauch 2mm gelb
1 x Stück Schrumpfschlauch 2-3mm schwarz
1 x Stück Schrumpfschlauch 5-6mm schwarz
ProgBox:
1 x Robbe Roxxy BL Controller Programmer V2 No. 8642
1 x ServoKabel (z.B. 40CM Servo Lead (JR) 32AWG Ultra Light 10pcs/bag, Hobbyking)
Programmieradapter:
1 x USB-TTL Adapter mit FTDI FT232RL (z.B. Hobbyking Produkt ID: 009000003)
1 x ServoKabel (z.B. 40CM Servo Lead (JR) 32AWG Ultra Light 10pcs/bag, Hobbyking)
1 x Schalter
1 x Stiftleiste 2.54mm mit 6 Pins
1 x Stiftleiste 2.54mm mit 3 Pins
1 x Schrumpfschläuche nach belieben
1 x evtl. kleines Stück Lochrasterplatine 6×4 Löcher
1 x evtl. kleines Stück Lochrasterplatine 3×3 Löcher
|
|
|
|---|
ISP AVR Programmer:
Zum Programmieren des GA250 und der ProgBox, d.h. flashen der ATmega Mikrocontroller mit Haagens Bootloader und setzen der Fuses, wird zusätzlich noch (einmalig) ein ISP-Programmer für Atmel AVR Mikrocontroller benötigt, sowie natürlich Anschlusskabel usw. zu den ISP Pins. Der USB-TTL Adapter von Sparkfun kann dazu benutzt werden, aber die beste und günstigste Lösung ist vermutlich der USBasp Programmer, verfügbar z.B. bei Hobbyking (USBasp AVR Programming Device Produkt ID: 9171000003).
29. Juli 2011:
Die Firmware für das GA250 Gyromixer Projekt ist jetzt in einem Entwicklungsstadium, dass man sie posten kann. Die Firmware für den GA250 Gyromixer sollte nun eigentlich mit allen Empfängern zusammenarbeiten (wobei ich nur Spektrum und ESky selber testen konnte), und das Failsafe sollte auch sicher funktionieren. Das Failsafe spricht an sobald eines der beiden Signale Rudd oder Thro ausfällt, die Motoren werden dann innerhalb einer Sekunde abgeregelt. Das führt zwar im Wesentlichen zu einem Absturz, aber da bei Funkausfall normalerweise der Heli nicht mehr steurbar ist, erscheint mir der Weg nach unten sinnvoller als der Weg zur Seite in ein Fenster.
Das .zip File enthält fünf .hex Files, nämlich die Bootloader, welche auf den Atmega8 bzw Atmega88 des GA250 und der Robbe Box aufzuspielen sind, und die .hex Files für den GA250 Gyromischer in Version v0.19 und die ProgBox in Version v0.13. Zusätzlich gibt es noch ein .hex File, welches während des Umbaus des GA250 zum Gyromixer aufgespielt werden kann um zu Testen ob alles richtig gelötet wurde.
GA250 Gyromixer Projekt Firmware v019.013-20110731 (Firmware überholt)
31. Juli 2011:
ACHTUNG: Wenn der Anschluss am Servoport der ProgBox falsch herum eingesteckt wird kann es vorkommen, dass die ProgBox ihr Program „vergisst“ und von Grund auf neu geflasht werden muss. Also, UNBEDINGT AUF DEN RICHTIGEN ANSCHLUSS DER PROGBOX ACHTEN!
Die Gründe dafür sind mir nicht klar. Bei meinen Boxen, welche den Atmega88 eingebaut haben, hatte ich dieses Problem bisher noch nicht. Könnte also vielleicht etwas mit den ATmega88PA-Boxen zu tun haben, aber der wirkliche Grund ist mir wie gesagt bis dato unklar (Lösung steht im nächsten Eintrag).
7. August 2011:
Ursprünglich war die Firmware des Gyromixers nur für Spektrum-Empfänger geeignet, weil ich solch Einen eben benutze. Da sich Tommy@LA auf das GA250-Gyromixer Projekt eingelassen hatte (siehe den RCLine-Thread), aber ESky benutzt, hatte ich die Firmware so umgeschrieben, dass sie mit beiden Empfängertypen zusammenarbeiten sollte (siehe Eintrag vom 29. Juli 2011).
Leider hatte sich hier nicht nur ein kleiner (unwichtiger) Fehler eingeschlichen, sondern die Kommunikation mit der ProgBox funktionierte nicht mehr reibungslos, mit einigen unerwünschten Nebeneffekten. Die Probleme lagen daran, dass (i) das Rudd-Signal mit ICP aber das Thro-Signal mit INT0 eingelesen wird, (ii) beim ESky Empfänger das Thro-Signal vor dem Rudd-Signal ausgegeben wird während es beim Spektrum-Empfänger genau anders herum ist, und (iii) während der Daten-Übetragung zur und von der ProgBox alle Interrupts abgeschaltet werden müssen. Das führt beim ESky-Empfänger dazu, dass das Thro-Signal genau dann falsch eingelesen wird wenn es während einer Datenübertragung zur ProgBox auftritt. Beim Spektrum-Empfänger, bei dem zuerst das Rudd-Signal kommt, spielt das keine Rolle, da das Signal ja in jedem Fall wegen ICP richtig ausgelesen wird.
Ich habe das jetzt einfach so gelöst, dass wenn das Thro-Signal während einer Datenübertragung kommt, der gelesene Thro-Wert einfach ignoriert wird. Da die Firmware eh so geschrieben ist, dass eine Kommunikation mit der ProgBox nur dann möglich ist wenn Thro low ist, hat das im Flug keinerlei Auswirkungen.
Weiterhin habe ich gelernt, dass es anscheinend irgend einen Unterschied zwichen dem ATmega88 und ATmega88PA gibt. Das war mir neu, den die Migrating-Infos von Atmel (AVR512, AVR528) lese ich zumindest so, dass es keine Probleme geben sollte. Dieser Unterschied ist wichtig, denn die Robbe ProgBox gibt es sowohl mit dem ATmega88 als auch ATmega88PA (siehe hier). Da muss man also aufpassen! Dementsprechend enthält das Firmware .zip File nun auch die .hex Files des Bootloaders und der ProgBox Firmware für den ATmega88PA.
An dieser Stelle vielen Dank an Tommy@LA, für sein unermüdliches Durchführen der Tests, um die Probleme zu beseitigen. 🙂
ga250 gyromixer firmware v020-014-20110807 (Firmware überholt)
9. August 2011:
Nochmals kurz zum Thema ATmega88 vs Atmega88PA. Ich habe jetzt mal einfach mit fc die .hex Dateien verglichen, und siehe da, die Bootloader-Codes für die ATmega88-ProgBox und die ATmega88PA-ProgBox unterscheiden sich tatsächlich in einem Byte… aber die .hex Dateien mit der ProgBox-Firmware v0.14 sind exakt identisch. Das ist deswegen lustig, weil sich i) tatsächlich ein Unterschied in den Codes zwischen ATmega88 und ATmega88PA finden lässt, aber ii) die empirisch durch Versuch gefundene „Tatsache“, dass die ATmega88PA ProgBox mit der für den ATmgea88 kompilierten Firmware v0.14 nicht funktioniert mit der ATmgea88PA-Firmware aber schon (siehe in Tommy@LA’s Thread), an einer homöophatischen Potenzierung der Einstellen des Compilers auf ATmega88PA liegen muss…
10. August 2011:
Nachdem die Grundversion des GA250-Gyromixers so langsam in einen „ausgereiften“ Zustand kommt, möchte ich das Projekt ihn um einen Liposaver zu erweitern ernsthafter angehen. Das Ergebnis eines ersten Erweiterungsumbaus hatte ich oben schon gezeigt (15. Juli 2011). Hier nun eine Bildergallerie, welche die einzelnen Umbauschritte für die Liposaver-Erweiterung des GA250-Gyromixers detailliert darstellt:
Materialliste:
1 x GA250-Gyromixer
1 x ServoKabel ohne Stecker (z.B. Rest vom Umbau zum GA250 Gyromixer)
1 x Widerstand 1k Ohm, 1/8 W
1 x Widerstand 4.7k Ohm, 1/8 W
1 x Widerstand 100 Ohm, 1/8 W
1 x LED beliebigen Typs
1 x Stiftleiste 2.54mm mit 1 Pin
1 x Stück Schrumpfschlauch 5-6mm
1 x Stück Schrumpfschlauch 2mm rot
1 x Stück Schrumpfschlauch passend zur LED
Jetzt fehlt dann „nur“ noch die passende Software, aber das wird als nächstes angegangen. 🙂
3. November 2011:
Jetzt war es ein zeitlang still hier, was aber nicht bedeutet, dass es mit dem Projekt nicht weitergangen ist. Im Gegenteil, ich würde sagen die Kinderkrankheiten sind weg, und das Projekt könnte man nun doch langsam als „ausgereift“ bezeichnen. Dies drückt sich zum Einen in einer neuen Firmware für den GA250 Gyromixer aus, nun Version v0.21, in der einige zusätzliche Sicherheitsfeatures hinzugekommen sind, sowie die Bedienung an einigen Punkten, die wohl verwirrend sein konnten, verbessert worden ist. Der zweite wichtige Schritt ist dass ich mich daran gemacht habe ein Windows-PC Program mit dem Namen AvrConfig zu schreiben mit dem man den GA250 Gyromixer auch ohne ProgBox programmieren kann. Welchen Weg man selber für praktischer hält, den über die ProgBox oder den über das PC Program mag jeder selbst entscheiden (die ProgBox finde ich praktisch weil Parameter schneller geändert werden können und es keinen Computer in Reichweite braucht, das PC Program finde ich praktisch weil es alle Werte auf einen Blick anzeigt). Das PC Program bietet aber natürlich den finanziell betrachtet günstigeren Einstieg, da es neben dem Gyromixer nur noch den Programmieradapter braucht.
Firmware
Die Firmware Version v0.21 gibt es hier
Anleitungen
Es gibt mittlerweile auch einige Anleitungen (leider nur in English bisher):
– Funktionsweise/Bedienung der RobbeBox und AvrConfig PC Program
– Einstellparameter und Funktionsweise des GA250 Gyromixers, Zusammenspiel mit der ProgBox
– Übersicht über mögliche Konfigurationen, benötigte Hardware und Software
Und hier nun als „Appetizer“ ein Bild des AvrConfig PC Programs:
22. November 2011:
Wie schon im Post vom 21. Juli 2011 angemerkt, sind in den Signalleitungen zum Programmieren und für MotorA keine Schutzwiderstände vorhanden, was unter Umständen zu Ausfällen führen kann. Ich hatte damit noch nie Probleme, aber sicher ist sicher. Ein Schutzwiderstand wäre dann IMHO vorallem in der MotorA Zuleitung sinnvoll. Dem Schaltplan entnimmt man, dass sich in der Zuleitung für MotorB ein 220 Ohm Widerstand befindet, das gibt einem eine Idee für einen sinnvollen Widerstandswert, ich denke alles von 100-1k ist OK.
Es gibt nun natürlich zig Möglichkeiten einen solchen Schutzwiderstand auch für die MotorA Leitung einzubauen. In den Folgenden drei Bildern stelle ich eine Variante vor wie ich sie gewählt habe. Diese Bilder „ersetzen“ die Schritte 64-66 in der Umbau-Bildergallerie vom 21. Juli 2011.
22. Januar 2012:
Es gibt eine neue Firmware, Version v0.22, siehe hier.
Wichtigste Verbesserung: Das Heading Hold funktioniert jetzt noch besser als es eh schon funktioniert hatte.
26. Juni 2012:
Hobbyking hat (endlich) einen FTDI USB Adapter ins Program mit aufgenommen, und wie immer zu unschlagbar günstigen Preis: FTDI Adapter USB Controller Produkt ID: 009000003. Da es (bereits seit einiger Zeit) auch der ISP-AVR Programmer USBASP, der sehr zu empfehlen ist, für wenig Geld bei Hobbyking gibt (USBasp AVR Programming Device Produkt ID: 9171000003), ist der Umbau mittlerweile recht kosten-günstig möglich.
Aktuelle Firm- und Software
22. Jan. 2012:
GA250 Gyromixer Firmware Version 0.22: GA250_Coax_GyroMixer_Firmware_v022.hex
ProgBox Firmware Version 0.14:
Olliw_GA250_ProgBox_v014_m88.hex o. Olliw_GA250_ProgBox_v014_m88pa.hex je nach uC in der RobbeBox
AvrConfig Windows GUI Version 0.16: AvrConfig.exe
Alles zusammen in einer zip Datei: ga250 gyromixer firmware & software v022 [.zip]
3. Nov. 2011:
v0.21 Firmware als zip Datei: ga250 gyromixer firmware & software v021 [.zip]
Nutzungsbedingungen: Die Soft- und Firmware darf für private Zwecke kostenlos benutzt und an Kollegen und Freunde weiter gegeben werden. Eine kommerzielle Verwendung auch in Teilen ist ohne Zusage von mir ausdrücklich untersagt; „kommerzielle Verwendung“ schließt hierbei Alles ein, bei dem ein Gewinn von mehr als 0,- Eur ensteht oder anfällt, also auch z.B.Vergütungen für aufgewendete Arbeitszeit.
Terms of usage: The softwares/firmwares are not free. You may use it gratis and freely for private purposes. However, you may not use the work in full or in parts in any manner that is intended for or directed toward commercial advantage or private monetary compensation without explicit agreement by the author.
21 Kommentare