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

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.