CHR-6d Board Gyro,ACC,Nick,Roll,Kalman Filter,Inbetriebnahme

Dies soll eine nützliche Beschreibung der Inbetriebnahme werden.

-Das Board wird mit 3,3 V betrieben.
-Die UART Schnittstelle ist aber 5V kompatibel.
Die UART Schnittstelle sendet keine Stop Bits. Es können keine Daten direkt
im Terminalprogramm angezeigt werden.
- Das Datenpaket besteht aus folgenden Bytes.
Byte1 =s
Byte2 =n
Byte3 =p
Byte4 = Befehlsbyte für Eingangbefehle wie "SET_ACTIVE_CHANNELS" 0x82
Byte5 = Anzahl der Bytes des kompletten Datensatzes
Byte6 bis 6-14 Datenausgabe der Kanäle je nach aktivierten Kanälen.
Byte danach1 = 2 Byte Checksumme addiert alle Werte
Byte danach2 = 2 Byte Checksumme addiert alle Werte

Es gibt eine neue Firmware mit Kalman Filter, die nick und roll als Winkel ausgeben.
Firmwareupdater und Firmware unter chrobotics.com
Darauf achten, das es die CHR-6d und nicht die 6dm Software ist.
Den Boot Pin aan der Platine auf 3,3V legen.
Gerät von der Betriebsspannung kurz trennen.
Jetzt kann über UART die neue Firmware installiert werden.

Eine Windowssoftware Namens IMU http://www.chrobotics.com/downloads/IMUKit.zip zeigt einem alle Achsen in Koordinatensystemen an. Man kann Filtereinstellungen ändern. Gyro und Acc Kanäle können ein und ausgeschaltet werden (UART Sender)
Falls das programm nicht funktioniert, müsst Ihr SDK Directx installieren.
http://www.microsoft.com/downloads/e...displaylang=en
Nun zu meinem Problem:

Ich bekomme die nick und roll Winkelangabe bei liegender Platine (IC`s nach oben) nicht auf null Grad. Einen Schalter um die Gyros auf null zu bringen existiert, für die ACC´s nicht. Die Platine liegt so auch richtig, da die Gyro Werte alle korrekt angezeigt werden.
Im Reiter General kann ich unter Bias Config bei x und y Accel die Werte verändern und bekomme auch eine annähernde Nullinie hin. Nur der Winkelausschlag ist dann super gering. Speichere ich die Werte in den Ram und Flash und resete die Platine, dann liegen die Werte wieder woanders.

Kann mir jemand das Bias Config und unter dem Reiter EKF das Process Weight erklären und gute Einstellungen posten?
Wo liegt mein Problem?
Die Youtube Anleitungen verstehe ich so gut wie gar nicht. Wer sich das angehört hat, kann mich sicherlich verstehen.

Bascom Code ist auch schon fast fertig. Ich muss noch die CHK bytes prüfen, um einen verlässlichen Datenstom zu erhalten.

Jetzt hoffe ich auf gutes Team working, damit wir eine schöne Anleitung hier im Netz für alle veröffentlichen können.

hi, ich hab leider nich deine imu dafür aber 5 andere und ein sensorik institut hinter mir, zufällig arbeite ich gerade an was in dieser richtung.
gerne helf ich dir !

hast du vielleicht skyp oder msn , icq?

vg
ersan

Nach langen Hin und her probieren mit den ACC bias Einstellungen, ist es mir gelungen die Winkel von nick und roll auf annähernd null zu bekommen. Mir ist aufgefallen, das wenn man einen Wert zB. von nick ändert und in den Ram überträgt der roll Wert um mindestens 100 Grad wegläuft. Bewege ich die Platine einmal 360 Grad um alle Achsen, dann normalisiert dieser Wert sich wieder.
Leider zeigt sich,das nick und roll bei mir irgendwie in einer Abhängigkeit stehen. Wenn ich die Platine rollseitig 90 Grad aufstelle, ist der angezeigte Rollwert auch recht genau, leider wandert der Nick Wert auch auf fast 90 Grad mit. Das Phänomen habe ich bei einer Achse.

Hallo Supercato,
erst bietest du mir deine Hilfe an und dann meldest du dich nicht. [-(
Ich habe dir eine PN mit meiner icq Nummer geschickt.

Nach weiteren Tests und einen Hinweis zu dem Link von Watterott, scheint die Firmware 2.0 noch einen Fehler zu haben.
Im chrobotics Forum zu finden
http://www.chrobotics.com/forum/view...f=8&t=11<br />
Warum gehen Pitch und roll auf null, wenn ich den Sensor um alle achsen bewege und dann flach auf den Tisch lege?
Warum Ist eine Achse Roll in einer Winkelrichtung mit der anderen Achse Pitch in einem Verhältnis? Drehe ich die Platine Pich links um egal wieviel grad, dann geht der Roll Wert mit.

In der Windows IMU Software ist auch x und x Gyro vertauscht worden.

Hat jemand Ahnung von dieser Programmierung und könnte dann eine funktionierende Firmware posten?

@Superkato: Wenn du wieder hier im Forum vorbeischaust, wäre das vielleicht eine machbare Aufgabe für dich.

Hier der Link zur Firmware 2.0:http://www.chrobotics.com/downloads/CHR6d.zip

Hallo Mirco,

ich habe seit ein paar Tagen die AHRS-Version...

Zitat:

---

Zitat von mirco99

Nach weiteren Tests und einen Hinweis zu dem Link von Watterott, scheint die Firmware 2.0 noch einen Fehler zu haben.

---

Welchen Fehler meinst Du?

Zitat:

---

Warum gehen Pitch und roll auf null, wenn ich den Sensor um alle achsen bewege und dann flach auf den Tisch lege?

---

weil dann der Winkel wieder null ist.

Zitat:

---

Warum Ist eine Achse Roll in einer Winkelrichtung mit der anderen Achse Pitch in einem Verhältnis? Drehe ich die Platine Pich links um egal wieviel grad, dann geht der Roll Wert mit.

---

ich würde mal die "factory defaults" laden...
Hältst Du Dich dabei ans Datenblatt und bleibst bei Winkeln <90°?

Hi Skydiver,
Zitat:
Warum gehen Pitch und roll auf null, wenn ich den Sensor um alle achsen bewege und dann flach auf den Tisch lege?

Skydiver: weil dann der Winkel wieder null ist.

die Werte sind nach dem einschalten der Platine und gerade auf dem tisch liegen bei mir nicht auf null( so um die 180°). Erst nach Drehung aller Achsen, das ja eigendlich nicht gemacht werden sollte.

Das mit den Winkeln <90° habe ich in diesem Fall natürlich nicht eingehalten.

Wird dein Nick und Roll Wert nahe der 0° Achse bei liegender Platine angezeigt? Werden nick und roll unabhängig achsenrichtig angezeigt?
Bei mir leider nicht.

Vielen Dank für deine Hinweise. Vielleicht schaffe ich ja doch noch ordentliche Werte aus der Platine zu bekommen.

Hallo Mirco

Zitat:

---

die Werte sind nach dem einschalten der Platine und gerade auf dem tisch liegen bei mir nicht auf null( so um die 180°). Erst nach Drehung aller Achsen, das ja eigendlich nicht gemacht werden sollte.

---

Ich habe in der PC-Soft unter "EKF" die entspr. waagrechte Lage mit "Set Accel Reference" und "Set Yaw Reference" übernommen und danach in den Flash geschrieben. Den autom. Gyroabgleich nach "Power On" habe ich aktiviert. Die IMU darf somit nach dem Einschalten für ~3 sek. nicht bewegt werden. Die Accel-Werte müssen dann aber (bis auf die Temperaturdrift) passen. Die Temperaturdrift ist übrigens erstaunlich gering.

Zitat:

---

Das mit den Winkeln <90° habe ich in diesem Fall natürlich nicht eingehalten.

---

Das ist bei der AHRS übrigens gar kein Thema, zumindest für mich nicht - Jede Achse geht von -360 bis +360°

Zitat:

---

Wird dein Nick und Roll Wert nahe der 0° Achse bei liegender Platine angezeigt? Werden nick und roll unabhängig achsenrichtig angezeigt? Bei mir leider nicht.

---

Ich denke immer noch, dass da mit Deiner Parametrisierung was nicht paßt. Kannst Du mal von den Settings einen Screenshot verlinken?

Mit Accel-Bias-Werten von "0" liegt die angezeigte Genauigkeit N+R bei +/- 0,5°, G +/- 1,5°. Mit Bias-Werten für X,Y und Z von 50 bei N+R +/- 0,2° und G +/- 1° über ca. 10 Minuten und bei anfangs "kalter", weil stromloser Elektronik (bei jeweils mech. fixierter IMU und entspr. Kalibrierung).

Ich jedenfalls bin von dem Zwerg bis jetzt begeistert und schon auf die ersten Flugtests gespannt...

Gruß
Rainer

Hallo Rainer,

da du von Yaw schreibst, hast du das chr6-dm Board. Ich habe nur das chr6-d.
Ich kann nur die einfache Imu Software benutzen. Yaw gibt mein board nicht raus.

Ich habe mich gestern Abend nochmal an meine Platine begeben.
Ich habe für mein "Hobbyraum" einen neuen Rechner gebaut und installiert, da mein alter xp Rechner nicht mehr stabil lief.
Nachdem ich die Firmware neu geflasht habe, zeigte die Imu Software mein Pitch und Roll auf annähernd 0° nach dem Einschalten an. Ich habe mit der Fehlersuche bestimmt 20 Stunden verbracht. Entweder war es mein Rechner oder die Software des chr6d Boards stimmte nicht.

Ich habe mir diese Platine zugelegt, damit ich die ganze Berechnungen der Gyro und acc Werte nicht selber machen muss. Wenn ich <90 Grad einhalte funktioniert die ausgabe super. Werde ich Größer, dann Zeigt mir eine Achse immer in eine Andere Richtung eine Abhängigkeit der anderen Achse an, somit wäre ein Absturz "vorprogrammiert"

Programmierst du in Bascom? Ich habe noch einen kleinen Fehler in meiner UARt Ausgabe. Könntest du mal deinen Bascom Code(Einlesen der Werte) posten?
Ich schreibe ein ein Array und suche dann das PNG in dem Datensatz, um den Angang zu finden. Es werden ja Bytes geschickt, ich kenne ein Array nur als String. Aus dem Array lese ich pro Wert wieder in ein Byte Hier muss ich mich weiter informieren.

Bis später.
PS: Welches Modell soll denn bei dir stabilisert werden?

Hallo Mirco,

freut mich, wenn es jetzt klappt!

Zitat:

---

da du von Yaw schreibst, hast du das chr6-dm Board. Ich habe nur das chr6-d. Ich kann nur die einfache Imu Software benutzen. Yaw gibt mein board nicht raus.

---

ja, aber die grundsätzlichen Einstellmöglichkeiten dürften die selben(?) sein...

Zitat:

---

Ich habe mir diese Platine zugelegt, damit ich die ganze Berechnungen der Gyro und acc Werte nicht selber machen muss.

---

dito. Ich wollte mal eine wirklich kompakte und robuste IMU, die alles onboard berechnet und die Daten entspr. gefiltert (mit der Möglichkeit der Einflußnahme auf die entspr. Parameter) zur Verfügung stellt und nicht "bloß" mit Komplementärfiltern arbeitet. Eine SPI wäre das I-Tüpfelchen gewesen. UARTs sind bei mir immer zu wenige vorhanden...

Zitat:

---

Programmierst du in Bascom? Ich habe noch einen kleinen Fehler in meiner UARt Ausgabe. Könntest du mal deinen Bascom Code(Einlesen der Werte) posten?

---

Ich programmiere in C. Ich werde div. Sourcen von meinen anderen Projekten (bspw. einen NMEA-Parser) anpassen und hier verwenden. Bzgl. Bascom kann ich Dir leider nicht weiterhelfen.

Zitat:

---

Ich schreibe ein ein Array und suche dann das PNG in dem Datensatz, um den Angang zu finden. Es werden ja Bytes geschickt, ich kenne ein Array nur als String. Aus dem Array lese ich pro Wert wieder in ein Byte Hier muss ich mich weiter informieren.

---

imho ist ein string ein array mit angehängtem \0 - zumindest in C. Ich werde den UART-Buffer nach Empfang bestimmter Anzahl Bytes lediglich nach der Startbedingung checken und dann die Daten im Parser in entspr. Variablen wegschreiben, Checksumme prüfen, usw.

Zitat:

---

PS: Welches Modell soll denn bei dir stabilisert werden?

---

Wenn die IMU sich beim "burn-in" bewährt, werde ich alles auf einen Quadrocopter in klassischer +-Anordnung packen.

Gruß
Rainer

In einen Quaddro soll meiner auch.
Bekomme gerade aus meinem Atmega werte, die nicht im CHR Datenblatt stehen. Habe unter Bascom Compiler dazu auch einen Thread auf und schreibe dann da weiter rein. Hast du dir die werte über deinen in c geschriebene Controler mal in einem Terminalprogramm angeschaut?
Wenn ich meine werte aus der udr einfach über die uart wieder ausgebe mit allen aktivierten achsen dann kommt das hier bei raus.
112
115
110
112
202
112
115
110
112
185
112
115
110
112
253
112
115
110
112
247
112
115
110
112
57
112
115
110
112
183
112
115
110
112
192
112
115
110
112
209
112
115
115, 110,112 ist laut Dateblatt "SNP" der Datensatzanfang.
Danach kommen aber nur 2 Werte,dann wieder der neue Datensatzanfang.
Im Datenblatt müsste SNP, PT,N,alle Achsen also 8,und 2 Check Bytes.
merkwürdig...

lt. Datenblatt (und das ist bei der CHR-6d und CHR-6dm identisch) beginnt jeder Datensatz mit "snp", d.h. jeder Datensatz beginnt mit:

dez. hex ASCII
115 0x73 's'
110 0x6E 'n'
112 0x70 'p'

Bei mir sieht ein Datensatz so aus (nur Y-,P- und R-Winkel im Datensatz aktiviert):

73 6E 70 B7 08 E0 00 E5 BB 01 D9 03 6C 05 D9

73 6E 70 "snp"
B7 packet-type
08 number of data bytes
E0 00 sensor data packet
E5 BB yaw (scale: 0,0109863°/digit)
01 D9 pitch (scale: 0,0109863°/digit)
03 6C roll (scale: 0,0109863°/digit)
05 D9 checksum

Ich würde über das PC-Tool mal die Datenrate auf das Minimum reduzieren und dann nochmal die Config überprüfen. Du brauchst nicht alle Werte, die standardmäßig ausgegeben werden. Fürs Erste sind nur der Nick- und Rollwinkel interessant. Alles zusätzliche strapaziert lediglich die Rechenleistung des Atmel und Deine Nerven bei der Fehlersuche...

Schick mir doch mal bitte von jeder Config-Seite des PC-Tools einen Screenshot per mail, damit ich mir einen Überblick über die möglichen Settings machen kann und etwaige Abweichungen zur AHRS-Version verstehe. Ich kann das dann hier verlinken, damit jeder was davon hat.

Morgen,
ich meine naturlich SNP. War ein Flüchtigkeitsfehler. Die Senderate habe ich auch schon auf 2 Datensätze pro Sekunde runtergeschraubt. Ist zum nachsehen wirklich besser. Den Atmega 168 takte ich vorsichsthalber mit 18,igendwas Megaherz. Der schafft auch die volle Sendefrequenz.

Ich will einen Mega für die Auslesung der CHR nehmen und als Slave über I2C die Daten dem "Haupt" Controler zur Verfügung stellen. Meine Regler werden auch über I2c gesteuert. Genauso kommt ein Controler für die Fernsteuerung zum Einsatz. So hat man alle nötigen Programme schön übersichtlich getrennt und der Haupt Controller kann im Kreisverfahren Daten empfangen und an die Regler ausgeben.

Du kannst doch die IMU Software starten und nicht verbinden, dann siehst du alle Einstellungen. Wenn ich es schaffe, kann ich heute Abend ein Paar Screenshots machen.

Hier die Imu Reiter. Habs schnell in der Firma gemacht 8-[

[quote="skydiver"]lt. Datenblatt (und das ist bei der CHR-6d und CHR-6dm identisch) beginnt jeder Datensatz mit "snp", d.h. jeder Datensatz beginnt mit:

dez. hex ASCII
115 0x73 's'
110 0x6E 'n'
112 0x70 'p'

Bei mir sieht ein Datensatz so aus (nur Y-,P- und R-Winkel im Datensatz aktiviert):

73 6E 70 B7 08 E0 00 E5 BB 01 D9 03 6C 05 D9

73 6E 70 "snp"
B7 packet-type
08 number of data bytes
E0 00 sensor data packet
E5 BB yaw (scale: 0,0109863°/digit)
01 D9 pitch (scale: 0,0109863°/digit)
03 6C roll (scale: 0,0109863°/digit)
05 D9 checksum
quote]

Ich sehe das bei dir die Sensordaten aus 2 Byte besteht. Wieso steht das so nicht im Datenblatt?
Mein Problem kann auch mit der gesplitteten UART zu tun haben.
Ich werde mir jetzt erstmal einen Atmel mit 2 UART's bestellen.

Zitat:

---

Zitat von skydiver

lt. Datenblatt (und das ist bei der CHR-6d und CHR-6dm identisch) beginnt jeder Datensatz mit "snp", d.h. jeder Datensatz beginnt mit:

dez. hex ASCII
115 0x73 's'
110 0x6E 'n'
112 0x70 'p'

Bei mir sieht ein Datensatz so aus (nur Y-,P- und R-Winkel im Datensatz aktiviert):

73 6E 70 B7 08 E0 00 E5 BB 01 D9 03 6C 05 D9

73 6E 70 "snp"
B7 packet-type
08 number of data bytes
E0 00 sensor data packet
E5 BB yaw (scale: 0,0109863°/digit)
01 D9 pitch (scale: 0,0109863°/digit)
03 6C roll (scale: 0,0109863°/digit)
05 D9 checksum

---

Ich sehe das bei dir die Sensordaten aus 2 Byte bestehen. Wieso steht das so nicht im Datenblatt?
Mein Problem kann auch mit der gesplitteten UART zu tun haben.
Ich werde mir jetzt erstmal einen Atmel mit 2 UART's bestellen.

Zitat:

---

Ich sehe das bei dir die Sensordaten aus 2 Byte bestehen. Wieso steht das so nicht im Datenblatt?

---

aus zwei Byte wird ein "signed int"

Zitat:

---

Mein Problem kann auch mit der gesplitteten UART zu tun haben.
Ich werde mir jetzt erstmal einen Atmel mit 2 UART's bestellen.

---

nicht, wenn Du erst nach Empfang eines kompletten IMU-Datensatzes Deine Daten rausschreibst.

Ich würde Dir einen ATMega644p mit fOSC=20MHz ans Herz legen. Dann könnten wir die jew. Firmware gegenseitig testen...

So viele Controller brauchts gar nicht. Das kann man alles mit einem 644p erschlagen - mit ein paar Countern, Timer und interrupts.

Bzgl. PC-Software gibt es zw. 6d und 6dm doch erhebliche Unterschiede...

Ich hatte eigendlich an einen ATXMEGA 16A4-AU gedacht. Da kannste nochmal 10 Mhz draufrechnen und man kann trotzdem mit 3,3V arbeiten.
Aber leider wird der nicht von Bascom unterstützt. nur der Große 100 Pin.
Der 644p hat ja 2 Hardware USART´s und wird auch von Bascom unterstützt.
Ich glaube den bestell ich mir.

der 644p paßt da schon...

Ich habe später vor, den Code auf einen AVR32 zu portieren. Das ganze Zeugs liegt hier schon rum, aber immer fehlt die Zeit, mich mal wirklich intensiv mit dem 32-biter zu beschäftigen.

Ich werde mir für die ersten Versuche bzgl. einstellen/optimieren der Regelparameter eine einfache Wippe mit zwei Motoren bauen.
Motoren dafür (und den ersten Quadro) sind MK2832/35 und BL2.0 vom MK. Funke ist eine MX16s mit JetiDuplex und dem RMK-Rx mit Summensignalausgang.
Die CHR-6d(m) soll Huckepack auf die Controllerplatine gesteckt werden können. Bei den Abmessungen und Bohrungsabständen orientiere ich mich an den MK-Maßen, damit das kompatibel wird und ich meine vorhandenen Rahmen weiter verwenden kann. Natürlich noch nicht beim Proto - der wird auf Lochraster aufgebaut.

Welche Motoren/Steller/Akkus wirst Du verwenden?

nach längerem Überlegen, weiss ich immer noch nicht ob für mich eine "ein" Controller Lösung gut ist, da man sich sehr schnell Timingprobleme einholt und ich dann nicht weiss woran es liegt. Ich bin zwar Elektroniker habe aber mit Programmierungen beruflich nichts zu tun. Ich frische jedesmal mein Bascom wissen von Projekt zu Projekt wieder auf.

Die Wippe wollte ich mir auch bauen.

Ich habe diese Regler (Patine) gekauft. Man kann sie normal an einen Empfänger anschliessen oder per I2c . Es ist ein Mega 8 darin verbaut.
https://www.mikrocontroller.com/inde...7bff79977e5821
Dazu gibt es noch bessere Mosfeets, die in dem Shop zu Apothekenpreisen verkauft werden. Ich habe sie in Japan bestellt. Wenn du auch bessere Mosfeets brauchst, kann ich dir welche verkaufen.
Ich habe auch eine ältere MX Funke, die kann man mit einem Jetiboard auf 2,4 Ghz umbauen. Ein Jeti Empfänger mit Summensignal soll auch zum Einsatz kommen. Die Funke habe ich aber noch nicht. Die Reglerteile sind unterwegs.

Ich habe beschlossen an meiner Schaltung ein Dogm Display anzuschliessen, um mir die Werte darüber anzeigen zu lassen. Vielleicht bekomme ich dann sicher alle Werte angezeigt. So brauch ich meine USART nicht zu splitten und hoffe den vermuteten Fehler in den überschriebenen Registern damit behoben zu haben.

Ich habe gestern die Daten Hexadezimal ausgegeben und mit deinen verglichen. Leider sind die Datensätzte unterschiedlich lang (durch den Fehler)
aber es sieht schonmal vielversprechend aus.

Ich kaufe die nächsten Teile wenn die Daten richtig auf meinem Display stehen.
Ich habe schon zu viel in dieses Projekt gesteckt. zuletzt war es ein neuer Rechner.

Wenn ich dann mal soweit bin, können wir uns über die Ansteuerung/ Einmixung der Sensorsignale mit den Fernsteuersignalen und Korrektur Motorberechnung unterhalten, wenn du lust hast.
Die Z Achse wollte ich mit dem Gyro leicht einmischen.

Motoren verwende ich auch preiswerte aus Japan. Habe einen dieser Motoren an meinem Flächenmodell und die Leistung passt (400-600gramm Schub).
Ich kann dir jetzt nicht das Modell nennen.
Fliegen möchte ich mit 2 LIPO´s um die 4 Amperestunden. Es fließen da schon so um die 25 Ampere. So kommt man (25 A Vollast bei 4Ah = knapp unter 10 Minuten) ich denke 15 bis 18 Minuten sind machbar.

Im Shop steht, das deine Motoren für 4 Lipos ausgelegt sind , drehen schön langsam, haben ordentlich Schub, verbrauchen aber auch mehr. Ich würde mir überlegen diese Motoren mit 3 Lipos zu betreiben. Bei 110 Watt aufgenommene Leistung und 4 Zellen (14,8V) sollten es 7,5 Ampere Verbrauch sein. Mess das mit deinen Luftschrauben mal nach.

Habe eine Eigenbau CNC Fräse, womit ich mir den Quattro Fräsen werde.
Die Zeichnung habe ich auch schon fertig.
Es gibt in der Werbe Branche so geschäumten Kunststoff einmal einfach und mit beidseitig laminiertem dünnen Alublech. Sehr stabil und leicht und lässt sich perfekt fräsen.
Mir fällt jetzt nicht der Name des Materials ein.

Hallo Mirco,

Zitat:

---

Zitat von mirco99

nach längerem Überlegen, weiss ich immer noch nicht ob für mich eine "ein" Controller Lösung gut ist, da man sich sehr schnell Timingprobleme einholt und ich dann nicht weiss woran es liegt.

---

so lange man für bspw. I2C, UART, SPI auf die Hardwareschnittstellen zurückgreift und von Interrupts gebrauch macht ist dieses Projekt mit einem 644p beherrschbar. Natürlich muß man sich von (leider) immer wieder anzutreffenden Funktionen wie "delay()" verabschieden. Zudem bringt ein I2C-Bus bzgl. Störempfindlichkeit auch gravierende Nachteile mit sich.

Zitat:

---

Ich habe diese Regler (Patine) gekauft. Man kann sie normal an einen Empfänger anschliessen oder per I2c . Es ist ein Mega 8 darin verbaut.

---

Ich kenne die Regler sehr gut, habe bereits ~40 Stck. in div. Coptern davon verbaut und selbst noch welche hier. Meine aktuellen sind nahezu baugleich, allerdings bis 30A Dauer. Ich würde da gleich Ultra-Low-ESR-Elkos bis 25V verbauen und den kompletten Regler mit Plastikspray gegen Feuchtigkeit versiegeln. Die sind da sehr empfindlich.

Zitat:

---

Wenn ich dann mal soweit bin, können wir uns über die Ansteuerung/ Einmixung der Sensorsignale mit den Fernsteuersignalen und Korrektur Motorberechnung unterhalten, wenn du lust hast.

---

Ja, der wirklich interessante Teil ;-)

Zitat:

---

Im Shop steht, das deine Motoren für 4 Lipos ausgelegt sind , drehen schön langsam, haben ordentlich Schub, verbrauchen aber auch mehr. Ich würde mir überlegen diese Motoren mit 3 Lipos zu betreiben. Bei 110 Watt aufgenommene Leistung und 4 Zellen (14,8V) sollten es 7,5 Ampere Verbrauch sein. Mess das mit deinen Luftschrauben mal nach.

---

Luftschrauben verwende ich 10x4,5. Mit den o.g. Motoren und ~1kg Startmasse dürfte der Schwebestrom mit 4S/2200 bei ~8A liegen und 15 Minuten Flugzeit mit Reserve drin sein.

Zitat:

---

Habe eine Eigenbau CNC Fräse, womit ich mir den Quattro Fräsen werde. Die Zeichnung habe ich auch schon fertig.

---

Ich werde den Quadro klassisch mit 15er VK-Alurohr und Centerplates aus 1er oder 1,5er Alu aufbauen. Wir haben in der Firma eine CO2 Flachbettlaser. Mein erster Rahmen war so gebaut und sehr stabil. Nach einem Crash den Motorträger zurechtgebogen, den Prop getauscht und weiter gehts... genau richtig für die Erprobung einer eigenen FlightControl ;-)

Zitat:

---

Es gibt in der Werbe Branche so geschäumten Kunststoff einmal einfach und mit beidseitig laminiertem dünnen Alublech. Sehr stabil und leicht und lässt sich perfekt fräsen.
Mir fällt jetzt nicht der Name des Materials ein.

---

Wäre für mich sehr interessant, den Hersteller und Produktnamen zu kennen.

Gruß
Rainer

Kannst du mir da mal für die Kondensatoren eine Reichelt Nummer anbieten?
Ich werde demnächst mal wider zu meiner Werbefirma hinfahren. Dann kann ich dir den Namen nennen. Ich bekomme immer noch nicht diesen blöden String in die richtigen Werte zerlegt. Erst dann geht es bei mir auch weiter.

Hi Rainer,endlich bekomme ich eine Anzeige, leider sind die Werte bei 0° = -733.
Multiplizierst du die Werte mit 0,0109863? In meinem Datenblatt stehen nur die Werte für ACC und Gyro m/s.

Ich lasse nick,roll und GyroZ ausgeben. Der gesendete N Wert ist 7. Es werden also 7 Sensordatenbytes geschickt. 3 Werte mal 2Byte sind bei mir 6.
Habs im Datenblatt gefunden. Nach dem N wird ein Byte mit aktiven Kanälen gesendet. Echt blöd erklärt im Datenblatt.

Wie bekomme bei x,y =0°
kann ich einfach die 733 - 733 rechnen lassen oder lieber in der Imu Software die Einstellungen vornehmen ?


Wie weit bist du mit deiner chr6dm?

Hallo Mirco,

die Elkos habe ich bei C bestellt:
Elko Ultra-Low-ESR 470µF/25V, Best-Nr. 446259 - 62 oder
Elko Low-ESR 470µF/25V, Best.-Nr. 442625 - 62

Bitte vergiß nicht, die Elkos an der Leiterplatte mittels bspw. Heißkleber zu fixieren. Die vibrieren sonst gleich wieder ab. Dabei ruhig die ganzen Drähte mit Klebstoff stabilisieren. Sollte dennoch ein Tausch der Elkos nötig sein, einfach den Heißkleber mit dem Lötkolben wegschmelzen. Das riecht furchtbar und anschließend sollte das Zimmer gut gelüftet werden.

Ja, ich multipliziere mit 1098 und dividiere anschließend durch 10000. Den Winkel erhalte ich dann in 1/10°. Float ist auf einem 8-biter sehr rechenintensiv. Ich mache das in long und anschließendem typecast in int. Ob ich das in int dem dig. Regler übergebe oder in char wandle muß ich erst noch checken.

Ja, die im Datensatz enthaltenen aktiven Kanäle sind im Datenblatt wirklich etwas vernachlässigt.

Bzgl Nullkalibrierung würde ich lieber die entspr. Sequenz an die IMU senden und danach den entspr. Wert im Flash ablegen lassen. Das muß man ja nicht oft machen. Die Temperaturdrift ist ja absolut im grünen Bereich. Nach dem Einschalten wird der automatische Gyroabgleich gemacht bzw. nach Knüppelstellungskombination manuell ausgelöst. Ich werde den manuellen bevorzugen, weil beim Einstecken des Akkus der Copter auf dem Landegestell meist etwas "wackelt" und das den Abgleich negativ beeinflußt. Für den ACC-Abgleich ist eine Dosenlibelle sehr hilfreich.

Mein IMU hat sich am "Handkardan" sehr gur bewährt. Ich werde demnächst die Wippe bauen und gleich in die Vollen gehen...

Gruß
Rainer

Zitat:

---

Zitat von skydiver

Bzgl Nullkalibrierung würde ich lieber die entspr. Sequenz an die IMU senden und danach den entspr. Wert im Flash ablegen lassen.

---

Diese Nullkalibrierung hat mein Board leider nicht.

Eine Dosenlibelle ist nicht schlecht dafür. Habe leider noch keine (gefangen). O:)

Ist es nicht Sinnvoll die CRR über einen Port des Controllers nach einer bestimmten Zeit einzuschalten? So werden keine Wackler beim Kalibrieren erzeugt.

Ich habe mit meinen Programm noch Probleme, das die Bytes warscheinlich falsch herum im Integer abgelegt werden. Hatte gestern Abend den Punkt überschritten, wo man noch gute Ideen hat.

Ja dann bin ich mal gespannt auf deine ersten Ergebnisse.
Ich versuche heute zur Werbewerkstatt zu fahren und bezüglich des Sandwich Materials zu fragen. Viel Erfolg.

Hi Rainer,
habe meine CHR Auswertung jetzt fertig.
Habe gleich die neue Jeti Fernsteuerung mit Telemetriesensor bestellt. Jetzt geht es mit Summensignal auswerten weiter. Der Empfänger kann mir dann auch Daten wie Akkuspannung, aktuelle Stromstärke und entnommene mAh zur Fernsteuerung auf ein Display zurücksenden.

Hi Rainer,
wie wertest du die Lage zur Fernsteuerung aus? Wie sehen deine Erfolge aus?

Ich dachte mir, das ich den (bei Fernsteuerungsmittelstellung) 0° Lagewert, den der Kopter über eine Case Tabelle automatisch "ausbalanciert" mit den Fernsteuerungsdaten verfälsche.

Die Case Tabelle finde ich passend, da ich so bei verschiedenen großen ist/ soll Werten mit anpassbaren Motordrezahlen arbeiten kann.
Wird der Unterschied kleiner, werden auch die Motordrehzahlen kleiner geregelt. Ich denke so fliegt er stabiler als eine lineare Berechnung.

Wie machst du das?

Meine Motoren sind leider immer noch nicht da, so das ich noch nicht testen kann. Meine LIPO´s sind aber schon gekommen. Die Kondensatoren habe ich jetzt auch. Meine JETI Fernsteuerung läuft und die Empfängersignale werden eingelesen. Ist eine Auflösung von ca 100 Schritten (Knüppel beidseitiger Endanschlag) ausreichend?

Hallo Mirco,

Zitat:

---

Zitat von mirco99

Hi Rainer,
Wie sehen deine Erfolge aus?

---

Der wirtschaftl. Aufschwung aus dem Tal der Tränen hat mich voll erwischt, so dass ich wieder andere Baustellen bedienen darf. Das Parsen der Daten klappt und die Auswertung des Summensignals habe ich aus einem anderen Projekt dazugelinkt. Weiter bin ich bis dato aus Zeitgründen noch nicht gekommen...

Zitat:

---

Ich dachte mir, das ich den (bei Fernsteuerungsmittelstellung) 0° Lagewert, den der Kopter über eine Case Tabelle automatisch "ausbalanciert" mit den Fernsteuerungsdaten verfälsche.

---

Ich werde (bis aufs Gas) die Steuerfunktionen als signed char proggen, also -127 bis 127. 0 ist dann Mittelstellung. Das Gas wird unsigned char von 0 - 230 gehen, mit Regelreserve bis 255 (Vollgas). Entspr. Parameter für Mindestgas (bei bspw. Failsafe - schnelles Sinken) und Maximalgas sind sinnvoll.
Ich werde mit dem jew. FS-Stick (nick/roll) den (skalierten) Schräglagewinkel als Sollwert vorgeben und alle Größen einem PI(D)-Regler übergeben. Der kümmert sich dann um die Regelabweichungen und die Motorstellerwerte. Die Parameter für den Regler kann man auf der Wippe ermitteln.

Zitat:

---

Die Case Tabelle finde ich passend, da ich so bei verschiedenen großen ist/ soll Werten mit anpassbaren Motordrezahlen arbeiten kann.
Wird der Unterschied kleiner, werden auch die Motordrehzahlen kleiner geregelt. Ich denke so fliegt er stabiler als eine lineare Berechnung.

---

Wie bereits geschrieben setze ich auf einen dig. Regler. Dein Lösungsansatz entspricht imho einer Fuzzy-Regelung. Das bringt den Nachteil, dass Du bei anderen Motoren/Prop-Kombi die jew. Werte neu ermitteln mußt. Beim dig. Regler sind lediglich die Parameter anzupassen (tlw. auch sehr zeitaufwändig) aber das wars dann auch.
Das Hauptproblem bei den üblichen Motrorstellern ist übrigens, dass die über keinen aktiven Freilauf verfügen, d.h. wenn die Drehzahl eines Motors zu hoch ist, braucht es Zeit, bis dieser wieder langsamer dreht. Bereits etwas schwerere Props können ein mühsam eingestelltes Setting schnell nahezu unfliegbar machen bzw. erfordern starke Nerven...

Zitat:

---

Ist eine Auflösung von ca 100 Schritten (Knüppel beidseitiger Endanschlag) ausreichend?

---

Für die ersten Versuche auf der Wippe allemal. Da ist ein sauberer Sollwert (ohne Jitter durch Händezittern) sogar von Vorteil O:)

Und bitte sieh von Anfang an einen Killschalter vor, der bei Betätigung zumindest die Motoren stromlos schaltet - Die Motoren entwickeln beträchtlichen Schub und bei einem Bug und umherfliegenden Notizzetteln ist schnell mal ein Propblatt ab oder der "nach dem Zettel greif Reflex" rächt sich mit tiefen Schnittwunden...

Gruß
Rainer

Hi Rainer,
schön zu hören das du beruflich wieder viele Aufträge hast. Bist du selbstständig?

Du weisst ja welche Regler ich benutzen werde.
ich weiss nur noch nicht, ob ich die regler per I2C oder per PWM ansteuern soll.
Wie weiss ich denn wie hoch die maximale Drezahl der Motoren ist, wenn ich per I2C Drezahlen vorgebe?

Meine Ausbalancierregelung regelt deshalb auch nur die Motorendrehzahlen auf der zu hohen Seite runter. So kann ich auch bei Vollgas die Regelung nutzen.

Welches Verhältnis benutzt du um den Kopter zu drehen ohne das er einen Höhenunterschied macht? Kann man Drehwert - rechte + linke Mototren rechnen?

Pid Regler habe ich mir noch nicht angeschaut und kann von dessen Programmierung und Vorteilen nichts sagen.

Ich bin auf die Bascom Libary angewiesen um die Fernsteuerungssignale einzulesen, da mir für die 6 Kanäle die Timer fehlen, es selber errechnen zu lassen. Habe leider den Falschen Empfänger gekauft (Kein Summensignal)
Ich hoffe -50 bis +50 reichen. Ich glaube die Lib hat Assemler Werte.
Das ist zu lange her, wo ich das mal gelernt habe. Da traue ich mich nicht ran. Ich denke die Werte sind deshalb so klein, da der Atmel mit 18 Mhz arbeitet. Bei 8 Mhz würde ich auch einen Regelbereich von 256 haben.
Wenn sich mit der Lib jemand auskennt, dann wäre es toll wenn ich diese Datei oder Änderungen bekommen könnte.

Meine Motoren sind leider noch nicht da. Aber in spätestens 2 Wochen geht es bei mir auch weiter.

bis denn

Hallo Mirco,

Zitat:

---

ich weiss nur noch nicht, ob ich die regler per I2C oder per PWM
ansteuern soll.

---

Ich denke, vom Timing her ist da I2C pflegeleichter (trotz aller bekannter Nachteile). Auch wenn es bei Int-Programmierung und mit einem 4017er auch recht gut funktioniert setze ich da auf Kompatibilität.

Zitat:

---

Wie weiss ich denn wie hoch die maximale Drezahl der Motoren ist, wenn ich per I2C Drezahlen vorgebe?

---

Das weißt Du bei PPM ebenso wenig. Du gibst eine Adresse vor und schreibst danach den Wert, also bspw. 0x52 und 0x64 (Motor 1 und 100 digits Gas). Oder hab ich Dich falsch verstanden?

Zitat:

---

Meine Ausbalancierregelung regelt deshalb auch nur die Motorendrehzahlen auf der zu hohen Seite runter. So kann ich auch bei Vollgas die Regelung nutzen.

---

Ich werde die Drehzahldifferenz symmetrisch verteilen, d.h. ein Motor wird um die Hälfte der Differenz erhöht, der andere reduziert. Der Gesamtauftrieb bleibt dadurch (annähernd) konstant.

Zitat:

---

Welches Verhältnis benutzt du um den Kopter zu drehen ohne das er einen Höhenunterschied macht? Kann man Drehwert - rechte + linke Mototren rechnen?

---

Die Summer der rechtsdrehenden und der linksdrehenden Momente muß sich ohne Gier aufheben, d.h. beim Gieren wird die Differenz ebenfalls auf die rechts- und linksdrehenden Motoren aufgeteilt. Die Summe muß immer passen.

Zitat:

---

Ich bin auf die Bascom Libary angewiesen um die Fernsteuerungssignale einzulesen, da mir für die 6 Kanäle die Timer fehlen, es selber errechnen zu lassen. Habe leider den Falschen Empfänger gekauft (Kein Summensignal)

---

Entweder greifst Du das Summensignal direkt innerhalb des Rx ab oder benutzt einen PPM<>Summensignalwandler. Ich würde die erste Variante wählen und das Signal mit dem Oszi suchen. Meist ist dort auch ein 4017 o.ä. verbaut...

Zitat:

---

Ich hoffe -50 bis +50 reichen. Ich glaube die Lib hat Assemler Werte.
Das ist zu lange her, wo ich das mal gelernt habe. Da traue ich mich nicht ran. Ich denke die Werte sind deshalb so klein, da der Atmel mit 18 Mhz arbeitet. Bei 8 Mhz würde ich auch einen Regelbereich von 256 haben.

---

In C würde ich hier lediglich den Prescaler und das Capt-Register im eigenen Source entspr. ändern. Und was heißt hier, "das trau ich mich nicht"?! Sind wir hier im Warmduschforum?! ;-)


Gruß
Rainer

Hi Rainer,

ich habe mich da wohl ein wenig blöd ausgedrückt.
Ich meine die maximal erreichbare Drezahl, die ja vom Motor,Akku und Propeller abhängt. Laut deinem Beispiel gibt man die Motorleistung in Prozent an? 1-100?

Ich werde mal schauen, ob mein Yeti R6 ein Summensignal hat.
Ein Osci habe ich. Im Netz habe ich nichts darüber gefunden. Es handelt sich ja auch um ein Duplex Empfänger, wo auch Daten über den gewünschten (Servo)Port zur Fernsteuerung zurückgeschickt werden.
Die Kanäle werden direkt von einem Controller kommen.

Hier im Forum hatten schon 2 Leute die Lib ändern wollen, leider ohne Erfolg.

Mal schauen...

schönen Sonntag

Hallo Mirco,

bei einem Multikopter geht man im Idealfall von einem Verhältnis Schub<>Gewicht von 2:1 aus, d.h. bei einem Startgewicht von 1kg sollten die Motoren 2kg Schub bringen. Die Regelreserve ist da bereits berücksichtigt. Die Steller sind bei einem Wert von 255 auf Vollgas (das Beispiel mit 100 war von mir unglücklich gewählt und entspricht keinem prozentuellen Leistungssollwert). Die Stickbegrenzung des FS-Senders auf 230 ermöglicht eine entspr. Regelreserve zu den max. 255. Die Skalierung spielt dabei keine Rolle bzw. zumindest noch nicht am Boden. In der Luft entscheidet diese aber über entspr. feinfühliges Steuerverhalten, das aber subjektiv ist und meist vom jew. Piloten entspr. angepaßt wird.
Die Antriebsauslegung (Akku, Motor, Prop) tangiert das nicht, weil diese ohnehin zum jew. Startgewicht passen muß.


Ein paar Bilder:

Bild hier  

Bild hier  

Bild hier  

Bild hier  

Bild hier  

Gruß
Rainer

Hi Rainer,

der wievielte Kopter ist das, den du gebaut hast?
auf den Bildern ist ja auch ein Hexa, ein Okto und 2 verschidene quad Gestelle zu sehen.

Sehr schön.

Wieviel wiegt dein Quadro ?

Ich warte immer noch auf Post aus Fernost. :frown:

Toll das deiner schon fliegt.

Ich habe leider nebenher noch ein anderes Projekt aufs Auge gedrückt bekommen. Mein Quadro hat leider jetzt Prio 2.