1

Mittwoch, 2. Juni 2010, 02:54

FP&Koax GyroMixer, ein open-source Projekt: Dokumentation

[SIZE=3]Dieser Thread ist nur für die Dokumentation im unten stehenden Sinne gedacht, bitte postet hier nur dementsprechende Beiträge.[/SIZE]

Zum Thread für die Diskussion und aller sonstigen Beiträge geht es hier.


Hinweis: eine Verlinkung zu einzelnen Posts ist über das Notepad-Symbol in der linken unteren Ecke neben dem Datum eines jeden Posts möglich

2

Mittwoch, 2. Juni 2010, 03:23

FP&Koax GyroMixer, ein open-source Projekt: Dokumentation

Einleitung und Projektbeschreibung


Hallo Zusammen,

so, nun mal wieder eine BL-Umbau-Projekt, der etwas anderen Art.

Drei verschiedene Varianten sind ja mittlerweile hinlänglich bekannt, sprich die "4in1/3in1-mit-Konverter"-, die "Brushless-Boardless-mit-SenderMixer"-, und die "Brushless-Boardless-mit-seperatem-Mixer"-Variante (üblicherweise mit BLBL gemeint). Alle drei Methoden haben so ihre Pferdefüsse, aber die Letztere hat sich meinem Eindruck nach duchgesetzt. Dies liegt sicher mit daran, dass dies i) technisch die beste Lösung ist, ii) die Gyros mittlerweile sehr billig zu bekommen sind, sowie iii) geeignete Mischer komerziell verfügbar sind bzw. mit mehr oder weniger grossem Aufwand von Hobbyisten leicht selber zu bauen sind. Zum Beispiel, wie es "genial einfach" geht hat Ralf hier gezeigt, und in "Deluxe" gibt's das von Achim hier.

Ein "kleiner" Nachteil des BLBL-Umbaus ist vielleicht "der ganze Aufwand", hat man sich doch statt mit der kleinen, niedlichen 4in1 nun mit 2 BESCs, 1 Gyro-Klotz, sowie einem Mischer rumzuschlagen. Wenn man dann noch Licht, Liposaver, etc haben will wird's schnell "wüst". Das, und weil ich keine Lust auf Gyro-Klötze hatte, hatte mich motiviert kurzerhand die 4in1 so umzustricken, dass sie alles bis auf die 2 BESC enthält, das Ergebnis war die 4-1+2in1. Obwohl das zu kleinen, leichten, und kompakten Lösungen führt, bin ich in dem Bestreben nach Verbesserung/Vereinfachung doch auch schnell an (meine) Grenzen gestossen. Ein Problem sind die Gyro-Bausteine. 10Eur für einen LPR-MEMS-Gyrosensor auszugeben um festzustellen, dass der nicht taugt ist ja vielleicht noch OK, aber 30-40Eur oder sogar noch deutlich mehr... das hat mich doch etwas abgeschreckt... und dann kommen die auch noch in zunehmend winzigeren - sprich handunlötbareren - Gehäusen daher... kurz, der Hardwareaufwand ist doch beachtlich. Zudem bin ich auch softwaremässig an Grenzen gestossen, muss doch die Funktion eines Gyros nachprogrammiert werden. Das liest sich einfach, und ist es im Prinzip auch, aber obwohl ich mit meiner 4-1+2in1 Lama nachwievor sehr gerne fliege, ist es offensichtlich, dass deren Gyro nicht an den Stand der Dinge heranreicht.

In etwa zeitgleich zu den Verbesserungsbemühungen habe ich angefangen CP-Heli zu fliegen - und so war dann doch plötzlich ein Gyro-Klotz im Hause - und wurde auch mal aufgeschraubt. Und siehe da, eine viel bessere Idee war geboren... der FP&Koax Gyro Mischer.

Konkret ist mir ein HK401B ins Haus geflogen, und was ist da drinnen? Nun, der uns Koaxianern so altbekannte Murata Gyro-Sensor, sowie ein Atmega88... also ein ATmel... ein Mitglied meiner "Lieblings"-Mikrokontrollerfamilie... von der ich SO begeistert bin :D :w. Was liegt also näher als einfach den Atmega8 so umzuprogrammieren, dass er neben dem Gyro auch noch das Mischen mitmacht? Deswegen der Name Gyro-Mischer. Warum aber FP&Koax? Nun, ich habe zwar keinen FP (was ist eigentlich aus dem Kestrel 500SX geworden?), aber dort wird für einen BL-Umbau genau das Gleiche benötigt, die Mischrate mag vielleicht anders sein. Warum dann, als Koaxianer im Koaxforum, FP&Koax und nicht Koax&FP? Nun, klinbt irgendwie besser... :)

Und tatsächlich, hardwäremässig ist (meistens) alles dabei was man so braucht: ein Gyro-Sensor, ein uC, die Stromversorgung, sogar zwei Potis für Gain und Prop, ein oder zwei Leds wie bei 4in1en gewohnt, und als Bonus noch ein oder zwei Schalter mit den man vielleicht Dinge machen kann von denen man noch gar nicht zu träumen wagt... das erscheint mir das attraktive an diesem Projekt, der grosse einschränkende Faktor vieler Projekte, der Aufwand für die Hardware, geht nahezu gegen Null, 4 Kabel an die ISP-Pins und fertig (wie man unten sehen wird muss man dazu noch nicht einmal zwingend löten :tongue:)(obwohl es natürlich nützt :D). Und einen Gyro braucht man sowieso. Zudem scheint es dass nahezu alle der jüngeren, billigeren Gyros quasi identische Hardwareplatformen bieten, so das Software, die für einen Gyro geschrieben wurde, leicht auf viele Andere übertragen werden kann.

Leider nur hat der liebe Gott dem Menschen die Gabe gegeben diese zunehmend winzigeren - sprich handunlötbareren - Gehäuse zu erfinden... und leider wurde wohl der HK401B weiterentwickelt, den auf den im Web verfügbaren Bildern des HK401B-Innenlebens ist noch ein TQFP Gehäuse zu sehen, während in echt mittlerweile ein ATmega8 im MLF Gehäuse zu finden ist... und ich kann da keine Kabel an die ISP-Pins dranlöten. Und so begab es sich, dass ich mich auf die Suche nach einen Gyro begab, der i) billig ist, ii) ein ATmega in TQFP Gehäuse enthält, oder iii) noch besser die ISP-Pins gleich auf Pads herausgeführt hat. Und sie liesen sich finden... dazu abermehr unten.

Den Vorteil einer vereinfachten Hardware erkauft man sich allerdings auch mit einem Nachteil, nämlich dem eine geeignete Software programmieren zu müssen. Und was liegt da näher, als ein open-source Projekt?

Das Projekt ist also klar:
(1) geeignete Gyro's zu finden
(2) geeignete Software zu schreiben
Bei Beidem hoffe ich auf die rege Mitarbeit von vielen Leuten. Weil ich mir nicht jeden Gyro kaufen kann und will, weil ich die besten Software-Tricks die einen guten Gyro ausmachen nicht kenne, und in Hoffnung auf die Schwarmintelligenz.

Anmerkung zu (1):
Wenn jetzt jeder seine daheim liegenden Gyros aufschraubt und mal reinschaut, und im Falle des Falles Bilder postet, dann denke ich wird sich recht schnell eine gute Sammlung von geeigneten Gyros ergeben (mich würde ja z.B. der GY192 sowie der BA Nano "brennend" interessieren)

Anmerkung zu (2):
Ich selbe programmiere mit AVR Studio in C. Aber ich denke nicht, dass man sich auf eine Sprache einschränken braucht. Ob ASM, Bascom, oder C, irgendwie sind die alle ähnlich. Die Details, wie die Hardwareeigenschaften angesprochen werden, sind natürlich verschieden, aber auf die kommt es ja nur wenig an, bzw., lassen sich auch mit Worten oder Metasprache beschreiben. Der entscheidende da schwierigste und funktional wichtigste Teil, die Gyro-Programmierung, wird nur einen Bruchteil eines Programs ausmachen und lässt sich ziemlich sprachunabhängig darstellen. Deswegen, ob ASM, Bascom, oder C,... ist egal.


In den folgenden Posts werde ich einige Gyros und deren Innenleben kurz vorstellen, einige Grundlagen und Konventionen einführen, und meine erste Variante eines Umbaus eines Gyros zu einem KoaxGyroMischer plus zugehöriger Software beschreiben. Ich bitte euch mir bevor ihr in diesen Thread postet die Zeit zu lassen das alles erstmal reinzustellen (habe die Bilder fertig, kann aber trotzdem ein paar Tage dauern).

Angeregt durch Achim's Vorgehen bei seinem Mixer-Projekt möchte ich dieses Projekt auch auf zwei Threads aufteilen. Die Trennung ist nicht so klar wie bei Achim, da ich ja auf Beiträge in beiden Threads baue. Ich stelle mir das so vor, dass hier in diesem Thread nur die Dokumentation, Zusammenfassung, Aufbereitung, usw von Ergebnissen, Einsichten, usw gepostet werden, während im Diskussionsthread eben die Diskussion geführt wird deren Ergebnsise dann hier in aufbereiteter zusammengfasster Form landen. Ich nehme an, dass ihr dieses kleine Notepad-Symbol unten links neben dem Datum bei jedem Post kennt :w.

Soweit,
Olli

3

Mittwoch, 2. Juni 2010, 03:57

FP&Koax GyroMixer, ein open-source Projekt: Dokumentation

Gyro HK401B

So, dann will ich mal mit dem ersten Gyro anfangen, dem HK401B (HK) bzw. dem Mystery (DealExtreme). Beide sind baugleich. Ursprünglich hatte ich grosse Hoffnungen auf diesen Gyro gesetzt, da diese Gyros sehr billig sind und die Bilder im Web andeuteten, dass ein ATmega88 im TQFP Gehäuse verbaut ist. Leider ist dem mittlerweile nicht mehr so. Also, glücklich sei der, der noch "alte" HK401B oder Mysterys hat oder auftreiben kann.

Obwohl diese Gyros eigentlich nicht zum Projekt taugen, will ich trotzdem Bilder vom Innenleben um vom Schaltplan posten, da man, wie ich finde, einiges lernen kann. (einen Schaltplan vom HK401B hatte ich schon mal gepostet, dieser hier ist aber verbessert und erweitert)

[RCLTV]3144[/RCLTV] [RCLTV]3145[/RCLTV]

Was ist interessant:

- es ist ein ATmega88 verbaut, Taktfrequenz wird von einer Keramik geliefert, 8MHz.

- der Gyro-Sensor ist der wohlbekannte Murata-Sensor, so wie er in quasi allen 4in1/3in1 eingebaut ist

- die Beschaltung des Gyro-Sensors ist minimal, während z.B. bei den CX2 und (alten) Esky 4in1en ein aufwendige Beschaltung mit OPs zur Signalkonditionierung zu finden ist, geht's hier direkt über einen Tiefpass (Grenzfrequenz 235Hz) an einen der ADC pins. Dies ist auf den ersten Blick doch sehr erstaunlich, da der Ausgangsbereich des Sensors für +-300°/s gerade mal +-0.2V beträgt. Der ADC-Bereich (hier 0...2.23V) wird also gerade mal zu 18% ausgenutzt, bzw. es werden mehr als 2 bits verschenkt. Der HK401B gilt als nicht schlechter Gyro, man lernt also, dass es der Murata-Sensor mit minimaler Hardware tut, kann aber vermuten, dass die Software irgendetwas "cleveres" macht (ausser oversampling/decimation).

- der Rudd-Eingang geht über einen Inverter an den ICP-Pin, der Gyro-Gain oder Sense Eingang geht über einen Serienwiderstand an den INT0-Pin. (wozu es den Inverter braucht ist mir nicht klar, Pegelanpassung kann es ja nicht sein, denn dann würde man es auch beim Gain-Eingang so machen müssen). Damit kann man sich gut vorstellen was die SW macht um die Eingangssignale einzulesen.

- der Gyro-Ausgang ist über einen Serienwiderstand mit dem OC1B-Pin verbunden. Auch damit kann man sich gut vorstellen was die SW macht um das Ausgangsignal zu erzeugen.

- dem ADC wird eine relativ aufwendig stabilisierte Ref-Spannung angeboten, vielleicht mit ein Grund für die gute Performance des Gyros. Das Schaltungslayout hat aber keine klar getrennte Massen (im Gegensatz zum KDS800, siehe unten).

- 2 Potis, 1 Led
»OlliW« hat folgendes Bild angehängt:
  • gyro_HK401B_schaltplan_v2.png

4

Mittwoch, 2. Juni 2010, 04:23

Gyro KDS800


Und weiter geht es mit dem KDS800. Dieser Gyro ist ja nun wirklich bekannt, und gilt als sehr gut. Die Bilder im Web waren sehr vielversprechend, aber nach der HK401B-Enttäuschung war mein Mütchen etwas gekühlt. Ausserdem ist der nicht wirklich billig. ABER:

BINGO
:shine:

Erst zum Preis: man kann ihn gebraucht kaufen, oder für 23Eur inkl ALLEM über EBay aus UK kaufen. Letzteres habe ich gemacht, das mit den 23Eur hat perfekt funktioniert, nur kam er wegen einer (angeblichen?) Verwechslung aus China (keine Mehrkosten, es waren echte 23Eur).

Dann zur Schaltung: Die ISP PINS SIND HERRAUSGEFÜRHT.
Einfacher geht's nun wirklich nimmer mehr. Wer nicht löten kann oder will oder darf, man könnte mit Klemmen arbeiten, Leitsilber, etc. ...

Übrigens: der DragonSky GY401B und Detrum GY48V sind baugleich (nicht aber der KM-601, was mich überrascht hatte, da ich schon so weit war zu behaupten dass man es den Gyros "ansehen" kann was drinnen ist)

[RCLTV]3146[/RCLTV] [RCLTV]3147[/RCLTV]

Was ist interessant:

- es ist ein ATmega88 verbaut, Taktfrequenz wird von einer Keramik geliefert, 8MHz.

- der Gyro-Sensor ist der wohlbekannte Murata-Sensor, so wie er in quasi allen 4in1/3in1 eingebaut ist

- die Beschaltung des Gyro-Sensors ist minimal, während z.B. bei den CX2 und (alten) Esky 4in1en ein aufwendige Beschaltung mit OPs zur Signalkonditionierung zu finden ist, geht's hier direkt über einen Tiefpass an einen der ADC pins. Dies ist auf den ersten Blick doch sehr erstaunlich, da... fällt euch etwas auf?

- der Rudd-Eingang geht über einen Inverter an den ICP-Pin, der Gyro-Gain oder Sense Eingang geht über einen Serienwiderstand an den INT0-Pin... fällt euch etwas auf?

- der Gyro-Ausgang ist über einen Serienwiderstand (+C=Tiefpass) mit dem OC1B-Pin verbunden... aber jetzt fällt euch etwas auf, oder?

- dem ADC wird eine relativ aufwendig stabilisierte Ref-Spannung angeboten, und das Schaltungslayout hat auch vorbildgerechte getrennte Massen. :ok: :ok: (da kann man was von lernen)

- 2 Potis, 1 Led

Zusammenfassung:
der KDS800 taugt für unsere Zwecke perfekt. Vielleicht ein klitzekleines bischen billiger könnte es gehen.

Anmerkung:
die bessere Qualität des KDS8000 macht sich nicht nur in so Details wie stabiles Metalgehäuse oder eine Gyroplatine die an zwei Seiten angelötet ist bemerkbar, sondern auch in der Schaltung.

Noch eine Anmerkung:
wie schon beim HK401B ist auch beim KDS800 der Eingansgkondesnator C1 tatsächlich vorhanden aber nicht an GND angeschlossen.
»OlliW« hat folgendes Bild angehängt:
  • gyro_KDS800_schaltplan.png

5

Mittwoch, 2. Juni 2010, 04:52

FP&Koax GyroMixer, ein open-source Projekt: Dokumentation

Gyro EK2-0704B

Da mir jetzt aber der KDs800 doch etwas zu teuer war, nur um ihn zu verschiessen (noch wusste ich ja nicht ob's wirklich klappt:)), und ich denn eigentlich auch noch in verschiedener Weise testen will, war das noch nicht das Ende meiner Suche. Dankenswerterweise hatte mich Achim im Zusammenhang mit dem 4-1+2in1 Projekt auf den Esky EK2-0704B aufmerksam gemacht (und als "Dank" habe ich mir seine Fotos "ausgeliehen", ich hoffe, ist OK). Der kann nun wirklich als billig gelten, und, das schöne, ein Atmega8 im TQFP Gehäuse... da geht mit meinen Fingern und Augen noch gerade etwas... allerdings hat der eine sehr "eigentümliche" Beschaltung des Gyro-Sensors, die hier diskutiert wurde, aber das für uns hier irrelevant.

[RCLTV]3148[/RCLTV] [RCLTV]3149[/RCLTV]

Was ist interessant:

- es ist ein ATmega8L verbaut, Taktfrequenz wird von einer Keramik geliefert, 8MHz.

- der Gyro-Sensor ist der wohlbekannte Murata-Sensor

- die Beschaltung des Gyro-Sensors ist vergleichsweise aufwendig, das ganze ergibt einen Tiefpass 3.ter Ordnung ohne Verstärkung, die Grenzfrequenz ist noch nicht ganz klar, aber wird sich auch in der 250Hz-Gegend bewegen.

- der Rudd-Eingang geht über einen Inverter an den ICP-Pin, der Gyro-Gain oder Sense Eingang geht über eine Diode an den INT0-Pin. Hier ist also sowohl bei Rudd als auch Gain eine Pegelanpassung gemacht worden.

- der Gyro-Ausgang ist über einen Serienwiderstand mit dem OC1B-Pin verbunden.

- dem ADC wird eine minimal stabilisierte Ref-Spannung angeboten, und das Schaltungslayout hat keine klar getrennte Massen

- 2 Potis, 1 Led, 1 Schalter

Zusammenfassung:
Zum rumspielen und lernen ist der EK2-0704B gerade recht.

Die Schaltung weist einige Merkwürdigkeiten auf, die für uns nicht wirklich relevant sind, aber doch merkwürdig.

"Gut": Eingangs-C ist an Masse angeschlossen, Gain-Eingang gegen Überspannung geschützt, aufwendiges aktives Filter fürs Gyro-Signal ohne jedoch zu verstärken

"Seltsam": Spannungsstabilisierung unaufwendig, Beschaltung der 2 Potis in Reihe mit zuätzlichem RC-Glied, schlechtes Design der ADC-Refspannung mit R15=10K (Eingangswiderstand von ARef ist 32K!), ADC-RefSpannung zu niedrig um Delay-Poti noch sinnvoll auszulesen und muss dafür also an VCC geschlossen werden, 2ter OP auf Platine vorhanden aber nicht z.B. zur Verstärkung = bessere ADC Nutzung benutzt
»OlliW« hat folgendes Bild angehängt:
  • gyro_EK2-0704B_schaltplan.png

6

Mittwoch, 2. Juni 2010, 05:22

FP&Koax GyroMixer, ein open-source Projekt: Dokumentation

Gyro Assan GA410 pro

Dieser Gyro ist nun nicht so wirklich billig, und deswegen habe ich nur Bilder die ich im Netzt gefunden habe. Leider konnte ich jetzt nicht mehr finden wo ich diese BIlder her habe, und ich möchte sie nicht ohne Quellenangabe posten, aber... auch bei diesem Gyro ist offensichtlich ein Atmega8X verbaut (die Oberfläche ist verkratzt, aber die Schaltung ist eindeutig), ein Murata drinnen (aber wohl die kleine Variante, macht aber nichts), ICP, INT0, OC12B verschaltet, 2 Potis, 1 Led, 2 Schalter, und... tata... die ISP-Pins sind an Pads herrausgeführt...

vielleicht weis ja jemand mehr oder kann gute Bilder posten, aus denen man den Schaltplan ablesen kann... (das aber bitte dann im Diskussions-Thread:))

sieht jedenfalls wie ein weiterer sehr guter, allerdings auch teurer Kandidat aus

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »OlliW« (2. Juni 2010, 12:05)


7

Mittwoch, 2. Juni 2010, 05:32

Die obigen Schaltpläne machen eines klar, alle vier Gyros sind sehr ähnlich:

- Murata ohne Verstärkung an ADC
- Atmega8X
- Rudd an ICP, Gain an INT0, Gyro-Ausgang an OC1B
- 2 Potis, 1 Led, mindestens 1 Schalter

Damit haben wir also eine Art Katalog einer "Standard-Hardware", und wissen schon in etwa wie eine Software auszusehen hat.

Hardwaremässig wird jetzt "nur" noch ein zweiter Ausgang benötigt (wir haben ja zwei BESC, Motoren, Rotoren!). Ideal wäre es jetzt dazu den OC1A Pin zu nehmen, denn dann könnten wir die Ausgangssignalerzeugung für beide Ausgänge elegant der Hardware des Atmega überlassen. Allerdings ist dieser Pin bei keinem der obigen Gyros verschaltet. Da wir aber eh an die ISP-Pins ran müssen, können wir einen davon nehmen. Ich habe mich für den SCK-Anschluss entschieden, da so eine ISP-Programierung auch mit angeschlossenen BESC noch geht. Aber das kann jeder machen wie er will.

So, das ist dann mein Teil soweit zu dem Projektteil (1), den Gyros. In den nächsten Posts werde ich meinen Umbau der EK2-0704B sowie die Software zeigen. Gebt mir dazu aber bitte noch etwas Zeit. :)

8

Mittwoch, 2. Juni 2010, 11:21

Umbau des EK2-0704B zum Koax-GyroMixer

Dieser Umbau ist eigentlich straight forward: in die Hand nehmen, aufschrauben, öffnen, Platine aus dem Gehäuse entnehmen,... die nächsten Schritte sind im Bild gezeigt

[RCLTV]3150[/RCLTV]

Zur Erinnerung, hier sind die ISP-Pins nicht herrausgeführt, allerdings ist ein Atmega8L im TQFP Gehäuse mit ausreichend viel Platz aussenrum da. D.h., hier kommt man nicht umhin die vier nötigen Kabel zum Reset, SCK, MOSI, und MISO anzulöten. Beim Reset ist es noch sehr einfach, weil man dazu an Widerstand R14 gehen kann. Die drei Kabel für SCK, MOSI und MISO muss man direkt an die Pins des Atmega anlöten.

Zunächst braucht man allerdings Platz für den zweiten Ausgang, also z.B. die Stiftleiste entfernen und einen Doppelpfostenleiste einlöten. Leider verschieben sich die Stifte beim Anstecken der Stecker sehr leicht, wichtig ist also, nachdem alles verlötet ist und funktioniert, FESTKLEBEN. Dann habe ich ein Kabel an den SCK Pin angelötet. Das geht eigentlich sehr gut, da man die Lötkolbenspitze vom Eck aus zuführen kann. Die zwei Kabel für MISO und MOSI brauchten etwas mehr Vorsicht, geht aber doch auch ganz gut (zumindest für Rechtshänder:))(vielleicht an einem kaputten Gehäuse vorher ein bischen üben). Der Anschluss zum Reset ist dann ein Kinderspiel. Ja, das war es dann auch schon. Noch eine Zacke weg gebrochen, und wieder zusammengeschraubt. Man hätte natürlich, ganz KDS800-mässig, auch einfach nur ein Kabelbündel herrausführen können, wäre im nachhinein betrachtet vielleicht besser gewesen.

Übrigens: ich habe einen Ersa 30W Handlötkolben mit ner 1mm Spitze, das geht also auch mit grossen "Waffen", sehr nützlich fand ich allerdings 0.5mm Lötzinn.

Die Lama V4, wie ich sie dann zum Testen und Erproben benutze, sieht dann im Bild so aus
[RCLTV]3151[/RCLTV]
Da ich bisher nur eine BL-Lama habe, kommt hier einfach die 4-1+2in1-Lama zum Einsatz. Alles noch keine Dauerlösung.

9

Mittwoch, 2. Juni 2010, 11:28

AVR ISP-Programmer

Ja, dann fehlt ja jetzt nur noch etwas Software. Die man natürlich auch programmieren muss, d.h., man braucht einen AVR-Programmer. Da hat jetzt sicher jeder so seine eigene Lösung. Ein Aspekt der beachtet werden will ist, dass die Stromversorgung des Atmega über einen Spannungsregler auf 3.6 V geschieht, d.h. der Programmer muss mit Programmierpegel von 3.6 V zurechtkommen (was er eigentlich immer sollte), die Versorgungsspannung für den GyroMixer sollte aber 5V haben. Ich sehe da 3 Lösungen: i) der gekaufte Programmer kann das bereits, ii) wenn der Programmer mit 3.6V zurecht kommt die 5V Versorgung extra bereitstellen, iii) Schutzwiderstände und den Atmega mit 5V Pegeln betreiben. Ich habe ein Pollin-Eval-Board bzw. benutze die dort benutzte Schaltung, und mache Letzteres. Hat man das also auch.

EDIT: Korrektur: die Schaltung des ISP-Programmer die ich benutze ist "nur" ähnlich zum Pollin-Board, tatsächlich ist es diese (2tes Bild)

Könnten wir also eigentlich endlich über Software reden. Aber nein, halt, um hier gemeinsam miteinander reden zu können braucht es ein paar Konventionen, mindestens bzgl der Vorzeichen und Einheiten. Vielleicht ist es auch nützlich sich auf bestimmte Begriffe zu einigen. Jedenfalls will ich nächstens einführen wovon ich rede.

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »OlliW« (2. Juni 2010, 15:30)


10

Mittwoch, 2. Juni 2010, 17:45

(meine) Vorzeichen, Einheiten, Konventionen

Jeder kann das natürlich machen wie er will, trotzdem will ich meine Vorzeichen und Einheiten vorstellen. Leider hängt die Wirkung z.B. des Gains von vielen Faktoren ab, so dass eine Angabe wie ein Gain von 6.7 ziemlich wenig besagt, insbesondere wenn sie von verschiedenen Leuten und/oder in Bezug auf verschiedene Helis kommen, trotzdem wäre es im Prinzip nützlich wenn die Angaben in irgend einem Sinne vergleichbar wären. Dazu dient dieser Post. Aber wie gesagt, jeder kann das natürlich machen wie er will. Im Zuge dessen kommt man auch gleich auf ein bischen Regelungstechnik.

Meine Vorstellungen sind in den folgenden zwei Schaubildern zusammengefasst:
»OlliW« hat folgendes Bild angehängt:
  • FpCoaxGyroMixer_Conventions_v2.jpg

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »luxemburger« (7. Juni 2010, 08:27)


11

Mittwoch, 2. Juni 2010, 17:46

und dieses Bild zur Regelung
»OlliW« hat folgendes Bild angehängt:
  • FpCoaxGyroMixer_ControllerSchemes.jpg

12

Mittwoch, 2. Juni 2010, 20:51

im ganzen Spiel kommen (mindestens) 8 Grössen vor (leider habe ich gerade gesehen das ich in dem ersten Bild noch "Gier" und "Rudd" stehen habe, obwohl es mittlerweile "Rudd" und "ppmRudd" heisst, weis nicht ob man Anhänge ändern kann, ist aber auch nicht wichtig).

Rudd: ist eine Angabe wie der Rudd bzw Gier Knüppel steht, Achtung: dass muss und wird im Allgemeinen NICHT gleich dem vom Sender bzw Empfänger abgegeben Signal entsprechen (dieses heisst bei mir ppmRudd)! In der Sprache der Regeltechnik ist das die Sollgrösse.

Yaw: ist eine Angabe welche Drehrate der Gyro-Sensor detektiert, Achtung: dass muss und wird im Allgemeinen NICHT gleich der vom mit dem Gyro-Sensor verbundenem ADC-Wert sein (dieses heisst bei mir adcYaw)! In der Sprache der Regeltechnik ist das die Istgrösse.

Rate: das ist die tatsächliche Drehrate des Helis, in der Sprache der Regeltechnik die Regelgrösse. Diese wird in einem Program als solche nicht unbedingt direkt vorkommen.

ppmRudd: das ist das PPM Signal fürs Rudd wie es vom Empfänger kommt

ppmA: das ist das PPM Signal für das BESC für den OBEREN Rotor (A)

ppmB: das ist das PPM Signal für das BESC für den UNTEREN Rotor (B)

Dann braucht man noch Angaben zum Throttle, bei mir Thro und ppmThro, die spielen im Moment aber noch keine Rolle.

Die Unterscheidung zwischen Rudd und ppmRudd, bzw. Thro und ppmThro ist nicht zwingend notwendig, aber sehr nützlich, da man dann leicht mit veschiedenen Offsets und Einheiten rechnen kann, was mich zu Vorzeichen und Einheiten bringt. Da es beim Gyro um Drehraten geht (heading hold lassen wir im Moment mal aussen vor), brauchen wir uns nur darum Gedanken machen.

Vorzeichen: wie im Bild angedeutet soll eine Drehung des Helis ENTGEGEN dem Uhrzeigersinn einen GROSSEN bzw POSITIVEN Wert entsprechen, und die Drehung MIT dem Uhrzeigersinn einen KLEINEN bzw NEGATIVEN Wert. Das kommt auch daher dass bei den Sendern/Empfängern die ich habe (ESky,Spektrum) das PPM-Rudd-Signal bei einer Rudd-Knüppelbewegung nach links länger wird bzw in Richtung 2ms geht, und für nach rechts kürzer wird. Um eine Drehung ENTGEGEN des Uhrzeigersinns zu erreichen muss das PPM Signal für den OBEREN Rotor länger bzw grösser bzw in Richtung 2ms gehen (so dass sich dieser schneller dreht) und/oder das PPM-Signal für den UNTEREN Rotor kürzer werden (dies gilt für einen Koax bei dem sich der obere Rotor entgegen dem Uhrzeigersinn dreht)

Einheiten: Eine sinnvolle Einheit für eine Drehrate wäre z.B. °/s, für das Signal des Gyrosensors z.B. V, für ein PPM Signal z.B. ms, usw. Im ATmega werden diese Grössen natürlicherweise durch einen integer (mit oder ohne Vorzeichen, aber 2 Bytes) repräsentiert. In einem Atmel ergibt sich als ganz natürliche Wertegrösse 10bit. Der ADC hat 10bit, wenn man den Timer1 bei 1MHz laufen lässt entspricht der Zeitabstand des PPM-Signals genau 10bit, 10bit bieten mehr als ausreichende Auflösung, etc. Deswegen mein Vorschlag, 10bit als Wertebereich für alle Grössen anzunehmen. In einem "echten" Program kann man das natürlich anders machen, aber zum Diskutieren kann eine gemeinsamme Basis nützlich sein. Eigentlich ist damit alles gesagt, bis auf die Drehrate. Die +-300°/s des Murata-Sensors sind ein sehr typischer Bereich, deswegen mein Vorschlag diese auch auf 10bit abzubilden.

Regelstrecke: Damit können wir zum zweiten Bild kommen. Dieses zeigt eigentlich nur die Regelstrecke, oben so wie man sie in jedem Lehrbuch findet, und unten ein bischen detaillierter so wie sie im Koax realisiert ist. Sinn und Zweck des Bildes ist es wieder einige Grössen zu verdeutlichen. In dem Program das ich unten posten werde habe ich diese Grössen genau so benannt wie im Bild, man sollte sich also leicht zurechfinden. Nun wird vielleicht auch die Unterscheidung zwischen ppmRudd und Rudd, bzw. adcYaw und Yaw etwas klarer. Bei Beiden wird ein Offset abgezogen und so skaliert dass der Wertebereich 10bit bzw. +-512 ist. Dann lohnt es sich Gedanken zu den Grössen F(w), G(w), und R(w) zu machen. F(w) ist einfach, dies ist ja gerade der Teil den wir ins Program programmieren, aber R(w) und G(w) sind die grossen Unbekannten. Die zu wissen, wäre auch noch schön. Für den einfachsten Fall eines P-Reglers (über den ich noch nicht hinausgekommen bin), sind R(w) und G(w) einfach nur Zahlen (die Frequenzabhängigkeit also irrelevant).

Für den Zusammenhang zwischen der Soll- und Regelgrösse gilt

y = ( F*R )/( 1 + F*R*G ) * x

bzw.

Rate = (F*R)/(1+F*R*G) * Rudd

Wenn also F*R*G sehr viel grösser als 1 ist, was wir (im Prinzip) durch ein hohes Gain bzw P erreichen, dann ergibt sich

Rate =ca 1/G * Rudd

(=ca soll in etwa heissen). Dieser Zusammenhang ist nicht ganz unwichtig. Durch G geben wir also vor welche Rudd-Knüppelstellung zu welcher Drehrate führen soll. Dieser Zusammenhang ist im wesentlichen NICHT durch das Gain bzw P bestimmt, in einem Programm müssen wir also auf G ein bischen aufpassen um uns nacher nicht zu wundern.
Zwei Beispiele: ist G=1, dann bedeutet Rudd ganz nach rechts dass sich der Heli mit 300°/s IM Uhrzeigersinn dreht, ist G=2, dann würde sich der Heli aber nur mit 150°/s IM Uhrzeigersinn drehen (wer das jetzt nicht sieht, sollte nochmals zu den Vorzeichen/Einheiten zurückgehen :)).

So, ich glaube jetzt habe ich alles gesagt was ich im Moment dazu sagen wollte.

13

Mittwoch, 2. Juni 2010, 21:39

Empfänger Protokolle

so, jetzt bin ich gleich durch, es fehlt nur noch eine kleine Info, nämlich wie die PPM-Signale zeitlich aus dem Empfänger rauskommen, da unterscheiden sich ESky und Spektrum (andere Empfänger kenne ich nicht).

Die zeitliche Abfolge der PPM Signale ist

Spektrum AR6100:
Aile, Aux1, Elev, Rudd, Thro, Gear
dazwischen ist jeweils eine Lücke von 70us
der Abstand zum nächsten Frame ist konstant, bei mir etwa 21.5ms (DX6i, weis nicht ob das vom Sender abhängt)

ESky 35MHz Empfänger aus der Lama:
Roll, Nick, Thro, Rudd, Ch5, Ch6, Ch7
WICHTIG: dazwischen ist KEINE Lücke, Ende und Anfang kommen also zeitgleich
der Abstand zum nächsten Frame variert mit den Knüppelstellungen, in "Normalstellung" ist er bei mir (mit meinem auf 7 Kanäle aufgerüsteten Sender) etwa 19ms, das hängt bekanntermassen aber auch ein bischen vom Sender ab.

14

Mittwoch, 2. Juni 2010, 21:54

erste basic Software

ja, wer es bis hierher geschafft hat... kann einen Blick in meine erste Variante einer Software werfen... die man als funktionsfähig bezeichnen kann in dem Sinn dass man den Heli eigentlich ganz gut fliegen kann (ist sehr ähnlich zu dem was ich meiner 4-1+2in1 habe), zumindestens so dass ich Spass habe. Allerdings, ganz klar, sonst bräuchte es dieses ganze Projekt nicht, es hat Schwächen...

Nun also das Program (in AVR Studio C) als .pdf
»OlliW« hat folgende Datei angehängt:

15

Mittwoch, 2. Juni 2010, 21:55

und da man keinen Text anhängen kann als .zip, welches das .c enthält
»OlliW« hat folgende Datei angehängt:

16

Mittwoch, 2. Juni 2010, 23:03

Ein paar Worte zum Programm.

Ich habe NICHT versucht besonders "schlau" zu programmieren. Dass sieht man z.B. daran dass ich mir keine Mühe gegeben habe das ICP so zu benutzen wie es sich gehört, sowie den Ausgang für A, welcher bei mir der ehemalige Gyro-Ausgang war, also am OC1B Pin hängt, per hardware PWM zu erzeugen. IMHO ist das wirklich nicht entscheidend, und lässt sich immer leicht nachholen. Fragwürdiger ist vielleicht, dass ich den Timer1 mit den vollen 8MHz laufen lasse, und nicht mit Prescaler8 auf 1MHz, was i) automatisch zu dem 10bit Wertebereich führen würde, ii) völlig ausreichen würde, und iii) eine Variable zum kein-Signal detektieren überflüssig machen würde. Nun, ist halt so gekommen.

Das Program so wie es ist, funktioniert für Spektrum. Ich habe es mir einfach gemacht und lasse alles synchron zu den einkommenden PPM Frames laufen. Das ist unelegant aber einfach. Vorallem beschränkt es die Geschwindigkeit der Regelung auf die ca 20ms. Asynchron wäre viel eleganter und vermutlich auch viel besser. Das wäre sicher einer der ersten Verbesserungsmöglichkeiten (und eigentlich auch nicht schwer). Achim hat schon ausgetestet dass die Trunigy6A, die ich, wie vermutlich viele auch, als BESC verwende, locker mit z.B. 4ms zurecht kommen. Das wäre auch eine gute Zeit in der man alles gut erledigen könnte.

Die generelle Struktur und Funktion ist denke ich einfach.
1) Initialisieren
2) warten bis ein Signal anliegt (solange leuchtet die Led)
3) wenn ein Signal anliegt checken ob Thro entweder "lange" auf Unten oder "lange" auf Oben steht (die Led blinkt mit etwa 2.5Hz)

wenn Thro beim Start auf oben dann
(Led blinkt sehr schnell)
a) die Rudd Knüppelstellung einlesen und im Eeprom abspeichern, der Rudd-Knüppel sollte also in der Mitte stehen!
b) einfach Thro direkt an beide Ausgänge für A und B durchreichen. Damit kann man dann die BESC auf den Thro-Knüppelweg trainieren!
Abbruch durch Abschalten

wenn Thro beim Start auf low dann
4) Prop, Gain, und das Signal vom Gyro-Sensor einlesen.
wegen der komischen Beschaltung der Potis beim EK2-0704B muss der ADC Wert für Gain und Prop noch nachbearbeitet werden, um auf die 10bit Wertebereich zu kommen
5) Mittelwert für Rudd aus dem Eeprom lesen, falls dort etwas gespeichert ist
6) Werte für Prop, Gain, und dem Gyro-Mittelwert ins Eeprom speichern. Das ist nur zum Testen, den so kann man später auslesen welche Werte man hatte.

zur Hauptschleife
wenn ein neues Signal, also neues ppmThro und ppmRudd angekommen ist, dann
7) das Gyro-Signal per ADC einlesen
8 ) alle Grössen auf 10bit umrechnen
9) ein P-Regler durchlaufen
10) ein Mischer durchlaufen
11) das PPM für A
12) das PPM für B

Der P-Regler wird abgeschaltet wenn das Gain auf Null ("-" auf der Frontplatte des Gyros) steht. Die Led blinkt dann mit etwa 5Hz. Der Sinn ist den Wert für die Übertragungsfunktion R(w) abschätzen zu können (können wir im DiskussionTherad diskutieren). Für R bekomme ich soetwas wie 1/8.

Bei "normaler" Funktion ist der P-Regler aktiv. Die Led ist aus.

Der entscheidende Teil ist der

// Cntrl= adcGain/1024*2*( Rudd - Yaw/4 )
sli= 2*Rudd - Yaw/2;
sli= adcGain*sli;
sli/= 1024;
Cntrl= sli; //gain is approx ??

Cntrl*= 8; //scale to T1 time
ppmA= -Cntrl + (signed int)ppmThro -(signed int)(adcProp/2)-256;
ppmB= +Cntrl + (signed int)ppmThro;

Die ersten vier Zeilen implementieren den P Regler. Die Regelabweichung wird hier mit einem Faktor "verstärkt", der von 85/1024*2 bis 1024/1024*2, also 0.17...2 eingestellt werden kann. Das ist ein sehr weiter Bereich, dementsprechend empfindlich ist das Poti. Da der Wert von R etwa 1/8 ist, kann der Wert von F(w) bzw von P im Bereich 1.3...16 eingestellt werden. Die Regelabweichung ist Rudd-Yaw/4, d.h., G = 0.25, was bedeutet dass volles Rudd zu 1200°/s führen sollte. Irgendwie stimmt da aber noch irgendetwas nicht, ich habe irgendwie das Gefühl irgendwo einen Faktor 2 oder so verschlampt zu haben, muss ich noch genauer checken. Wie auch immer, man kann damit "vernünftig" fliegen.

Die letzten drei Zeilen implementieren den Mischer. Entsprechend der Vorzeichenkonvention muss die Struktur von der Art
A prop_to - Cntrl + Thro
B prop_to + Cntrl + Thro
sein (prop_to heisst proportional zu, und ist Latex entlehnt). Der obere Rotor braucht etwas weniger Saft, da er ja wegen der Paddelstange zu einem grösseren Drehmoment führt. Dies wird hier einfach durch Subtraktion von Prop gemacht. Etwas Revo-artiges wäre sicher besser. Das wäre auch einer der ersten sinnvollen Verbesserungen.

Im Program sind noch ein paar Testsignale drinnen gelassen. Ich hatte mir überlegt die rauszunehmen, aber sie dann doch drinnen gelassen. Kann nicht stören, und wenn es stört, die Del-Taste ist ja bekannt. :)

Zum Schluss noch eine Bemerkung zu Failsafe. Ich habe den Eindruck das manchmal sehr viel Grips in ein optimales Failsafe investiert wird. IMHO ist das aber "für die Katz", den was auch immer man als Reaktion auf die Erkenntnis, dass die Verbindung während dem Flug abgerissen ist, programmiert, wird zu oft in der aktuellen Flugsituation die falsche sein. Das einzige sinnvolle Failsafe ist IMHO sicher zu verhindern das am Anfang etwas ungewolltes passiert. Wie gesagt, ist meine ganz persönliche Meinung, muss man nicht übernehmen. :)

So, ich denke das war es soweit was ich sagen wollte. Hat nun doch keine mehrere Tage gedauert. Pfingsten sei Dank. Und Euch für eure Geduld. Dann bin ich ja mal gespannt wer als erstes seinen eigenen Umbau wagt... :)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »OlliW« (3. Juni 2010, 00:19)


17

Mittwoch, 9. Juni 2010, 21:20

Gy192A

Hi Olli,
BTW: lies mal dein PN's... kriegst Du kein Popup?...

Hier mal der Gy192.


18

Mittwoch, 9. Juni 2010, 21:22

Gy192B



Wie man sieht eher Microchip... also PIC; ist nicht so meine Baustelle momentan...

19

Donnerstag, 10. Juni 2010, 21:39

Hi Olli,

Zitat

Original von OlliW
ESky 35MHz Empfänger aus der Lama:
Roll, Nick, Thro, Rudd, Ch5, Ch6, Ch7
WICHTIG: dazwischen ist KEINE Lücke, Ende und Anfang kommen also zeitgleich
der Abstand zum nächsten Frame variert mit den Knüppelstellungen, in "Normalstellung" ist er bei mir (mit meinem auf 7 Kanäle aufgerüsteten Sender) etwa 19ms, das hängt bekanntermassen aber auch ein bischen vom Sender ab.


Kleiner Nachtrag zur Doku. Der/Die Esky Sender halten ziemlich genau eine Pause von 10ms zwischen dem Ende des letzten Kanal (kann auch ein pseudo-Kanal sein) und dem Anfang des ersten Kanals des nächsten Frames ein.

Siehe auch hier: Esky 2.4Ghz, brauch Licht ins Dunkle

20

Sonntag, 17. August 2014, 15:47

hi Guys

plz post file hex for atmega8 ? because i can't use AVR studio,i don't know many about it , i only know flash firmware for esc to use multicopter

thanks