X-Ufo Sensorplattform -> IMU

Hallo zusammen,
ich bin seit einiger Zeit dabei, ein eigenes X-Ufo zu entwickeln. Ich hab jetzt eine erste Teilaufgabe abgeschlossen und die Sensorplattform fertiggestellt. Hier ein Foto der fertigen IMU:

Bild hier  

Einge Daten:
- 3 Beschleunigungssensoren für die X Y Z Achse. Messbereich jeweils +-2g.
- 3 Kreisel für die X Y Z Achse. Messbereich jeweils +-300°/s.
- Automatische Offsetkompensation bei Systemstart.
- Selbsttestfunktion für alle Sensoren.
- Temperaturkalibrierung für alle Sensoren. z.Z. liegt der Arbeitsbereich zwischen 10°C und 50°C.
- Sensor Samplingrate 1kHz (!).
- FIR Filter 8. Ordnung für alle Sensoren (!)
- Ausgabe der aufbereiteten Sensordaten über RS232 oder I2C mit max 500Hz.
- Abmessungen: 45x29x57 (BxHxT)
- Gewicht: <45g
- Spannungsversorgung: 5-12V / 60mA.

Cool,

das will ich auch haben!!

Wie viel hat das denn gekostet?

Hi,

Ich habe einen interessanten Link zu dem Thema:

http://www.hanfordsite.com/

Vielleicht kennst du das noch nicht :)

Gruß

Hi,
cool!!
Haste die Platinen selber geätzt?
Gruß Michi

Ähm das ist nicht meine Page =;

Hab ich nur mal aus Zufall gefunden....

Aber so wie es auf den Fotos aussieht, denke mal schon das die das so gemacht haben.

Gruß

Hi,

Zitat:

---

Ähm das ist nicht meine Page

---

ich habe nicht die Platinen dieser Seite gemeint, ich hab die Platinen des Fotos von DerMarkus gemeint!!
Gruß Michi

Hi,
also die reinen Materialkosten liegen bei ca. 300€.
Die Platine habe ich bei PCB Pool fertigen lassen.

Hi,

Zitat:

---

ca. 300€.

---

oha!! :shock: :shock:
was ist daran so teuer? etwa die Kreisel? Oder die Beschleunigungssensoren?
Was ist der Unterschied zwischen den Kreiseln und den Beschleunigungssensoren?
Gruß Michi

Die Kreisel kosten etwa 40€ pro Stück. Die Platine ca. 90€.
Der Rest geht dann für die "Kleinteile" drauf :). Die Beschleunigungssensoren hab ich als Samples bekommen.
Mit einem Kreisel kann man die Drehgeschwindigkeit um die Drehachse messen. Mit den Beschleunigungssensoren misst man die Beschleunigung in Achsrichtung.

Cool, genau so hatte ich das auch geplant, gleiche Anordnung, gleiche Sensoren ;-) Das sind ADXL202 für die Beschleunigung und ADXRS150EB als Kreisel, richtig? Sieht super aus. Kannst du das Platinendesign mal posten? Oder noch besser, kannst du dich mal mit einem der hier im Netz vertretenen Shops kurzschließen, daß die dir das Konzept "abkaufen" und das Teil genau in der Form fertig anbieten?
Ich hätte mir das aus Lochrasterplatinen zusammengebastelt, aber deins sieht deutlich eleganter aus...

Gruß, Nils

Nicht ganz, das sind ADXRS300 ;)
Hast du schon erfahrung mit den Shops ? Werden dort öfter Dinge aus dem Forum verkauft ? Wen kann ich da am besten ansprechen ?

Hi Markus,

sieht professionell aus! Würdest Du mir die Schaltpläne zukommen lassen? Mich würde Deine beschaltungsversion sehr interessieren! Vorallem wie Du die Störungen ausblendest!

Grüße
Alex

Hallo

Mich würden die Schaltpläne also auch interessieren.
Von wo hast du die Kreisel bestellt? Direkt von Analog Devices?

es grüsst eichhof

@alex
Also elektrisch gibt es keine besondere Beschaltung. Die Filter sind alle digital im AVR.

@eichhof
Die Kreisel hab ich direkt von Analog. Das hat super geklappt.

zu den Filter hätte ich trotzdem noch eine Frage:
ich nehme an du gehst via Antialiasing Filter und ADC auf den uP und dort?! Hast du das Signal mittelwertgefiltert oder ähnlich?! Wie sieht es mit den verwendeten Frequenzen (fg, resp. Samplingfrequenz) aus?

@eichhof
Ja, genau, erst nen Antialiasing Filter -> ADC -> uP.
Auf SW Seite ist dann ein FIR 8. Ordnung mit 1kHz Samplingrate implementiert.

Mist, hab den Thread jetzt erst entdeckt...

Mann, die IMU sieht echt gut aus! Habe bisher ein bisschen mit der Rotomotion-6DOF-IMU gebastelt, die aber wesentlich größer gebaut ist. Da stellt sich mir gleich die Frage, ob man das denn nicht noch kleiner kriegen könnte. Das hieße, die Gyros direkt auf die Platine zu löten - mit BGA etwas schwierig, aber vielleicht von einer Firma zu machen. Ich lasse meine Platinen meist bei Q-PCB machen; die bieten seit kurzem auch SMD-Bestückung an...

Auf welche Weise willst Du die Daten weiterverarbeiten, mit einem zweiten ATMega128 oder soll's etwas schnelleres werden? Ich frage mich, ob man die maximale Abfragerate von 500 Hz praktisch überhaupt erreichen wird. Will man die Daten per I2C auslesen, sind das schätzungsweise 35000 bit/s, d.h., bei 100 kHz I2C-Bustakt geht schon ein Drittel der Zeit für die Übertragung drauf. Hm, da hab ich wohl eher ne Milchmädchenrechnung gemacht.

Und was ist, wenn die Abfrage in wesentlich kleineren Raten geschieht - macht dann der Controller eine Integration der Daten? Hast Du Dir schon Gedanken über die Kompensation der Sensordrift gemacht?

Also ich bin schwer neidisch auf Deine IMU und hoffe, dass Du bald etwas darüber berichtest, wie sie sich im harten Einsatz verhält und über welchen Zeitraum die Daten verlässlich sind etc.

Gruß, Achim.

Hi voidpointer !
Ich habe deine HP schon vor einiger Zeit entdeckt, du baust auch ziemlich interessante Sachen :)

Zu der Größe. Da kann man schon noch einiges rausholen. Die BGA´s müsste man dann bestücken lassen. Das Layout ist auch noch recht großzügig. Einige mm^2 kann man schon sparen.

Die Daten werde ich mit einem Gumstix weiterverarbeiten. Wenn ich mich recht entsinne hast du den auch in Gebrauch ? Die Daten die übertragen werden müssen wären pro Takt p, q, r, bx, by, bz wenn man float Werte überträgt kommt man auf: 6 * 4Byte * 500 = ~12KB/s. Mit einem entsprechend getakteten I2C Bus ( 400kHz ) ist das schon machbar. Meine bisherigen Regler laufen bereits mit 100Hz stabil so das ich noch genug Reserve habe.

Die einfache Integration der Gyro Daten ist sehr problematisch, weil sich aufgrund des verrauschten Signals sehr schnell die Fehler aufsummieren. Das aufintegrierte Signal ist für max einige Sekunden ( < 15 ) verlässlich.

Bei der Lagewinkelschätzung werde ich wohl auf einen Kalman Filter zurückgreifen. Das ist momentan aber noch Zukunftsmusik... ;)

Super Arbeit Markus!

Wenn du noch Gewicht sparen möchtest, könntest du 1mm FR4 Platinen nehmen. Ich denke, dass die bei den kleinen Abmessungen und dem 3D Aufbau steif genug sein sollten...
Gruß Sigo

Hi "DerMarkus",

vielleicht solltest Du / sollten wir wirklich mal eine kleine Serienproduktion aufsetzen, wenn Du die IMU für einsatztauglich hältst und wenn Du das Projekt als Open Source verbreiten willst. Ich hätte zumindest auch Interesse an einem Fertigprodukt oder Bausatz, auch wenn es ziemlich teuer ist. Aber eine IMU pro Jahr kann man sich glaubich leisten ;-)

Ja, den Gumstix habe ich auch im Gebrauch. Mittlerweile logge ich GPS-Daten und Sensordaten, die über I2C reinkommen mit einem kleinen C-Programm. I2C funkioniert gut mit dem Gumstix, weiss aber grad nicht, ob der standardmäßig 100kHz oder 400kHz macht. Problematisch ist bei meiner Schaltung, dass die Sensoren unterschiedliche Spannungen haben und man einen Levelshifter für I2C braucht. Arbeitet Deine Schaltung mit 3.3V? Das wäre ein weiterer Vorteil.

Ich hätte erstmal vermutet, dass 1 Byte pro DOF zur Übertragung genügt, aber wenn Du einen digitalen Filter drüberlaufen lässt, kommst Du vermutlich nicht mit 8 Bit oder 16 Bit aus. Hier wäre aber Potenzial für die Verringerung der Bandbreite.

Zum Thema Kalman-Filter habe ich auch noch nichts gemacht. Es wäre aber günstig, wenn er auf dem Gumstix läuft, weil man ihn dort mit Hilfe der GPS-Daten korrelieren könnte.

OK, viel Erfolg weiterhin,
Achim.

@sigo
Dank Dir ! Die Idee mit den dünnen Platinen ist gut. Da kann man sicher noch ein bissel sparen !

@voidpointer
Ich habe schon länger über die Bausatz / OpenSource Idee nachgedacht. Das gefällt mir eigentlich sehr gut. Allerdings ist sowas sicher ne menge Arbeit und sehr zeitintensiv. Momentan habe ich meine Priorität auf den X-Ufo Nachbau gelegt, da bleibt dann nicht viel Zeit :)
Die Schaltung ist auf 5V ausgelegt. Aber der Atmel sollte auch mit 3.3V I2C Signalen klar kommen. Ich hab das noch nicht getestet könnte das klappen ?
Wie meinst du "1 Byte pro DOF" ? Die Outputdaten sind ja die Daten der Kreisel und der Beschleunigungsmesser und das für 3 Achsen also mindestens 6Byte bei 8Bit Auflösung ( was sehr wenig ist ).
Die Filter rechnen mit 16Bit Fixpoint, damit die hohe Samplingrate erreicht werden kann. Die Signalaufbereitung rechnet dann mit float weiter, weil hier genug Reserve vorhanden ist. Ich könnte mir vorstellen den Part auch mit Fixpoint zu realisieren und die Daten dann im Fixpoint Format auszugeben dann sind 16Bit pro Sensorwert sicher ausreichend.

Ja, der Atmel kommt sicher mit 3.3V-Signal zurecht, aber will ja zum Senden auch Signale auf den Bus geben. Die dürfen dann nicht 5V haben, weil das vielleicht dem Gumstix nicht gut tut. Da hilft entweder ein Levelshifter, der nicht leicht zu beschaffen ist oder man macht es mit ein paar Widerständen wie hier .

Mit "1Byte pro DOF" meine ich, dass Du wahrscheinlich für jeden Freiheitsgrad (Degree of Freedom) einen AD-Wandler mit 8 oder 10 Bit Tiefe benutzt. Mit digitalen Filtern kenne ich mich nicht aus, aber 16 Bit Ausgabe sollten doch hinzukriegen und ausreichend sein.

So weit ich weiss sind die I/O Leitungen der I2C Devices als Open Collector ausgelegt. D.h. du legst durch die Pullup Widerstände der SCA und SCL Leitung fest, welches Potential du benötigst. Der Atmel der mit eine Versorgungsspannung von 5V arbeitet, zieht dann die 3.3V auf der I2C Leitung auf Masse, er gibt aber keine 5V auf die Leitung ! Falls alle deine Devices mit 3.3V zurechtkommen sollte es da keine Probleme geben. Falls du wirklich 3.3V und 5V auf einen I2C Bus mischen musst wird das ganze natürlich ungleich schwieriger.

Vielleicht reden wir gerade aneinander vorbei, aber für jeden Freiheitsgrad gibt es ja _2_ Sensorwerte, einmal die Winkelgeschwindigleit und die Beschleunigung. Deswegen war ich über ein Byte pro DOF etwas verwirrt. Man benötigt ja mindestens 2 Byte pro DOF.

Ja, Du hast wohl recht. 5V-Slaves sollten kein Problem machen. Bin halt bisher auf Nummer sicher gegangen und habe den MAX3373 dazwischengesetzt.

Was den Begriff DOF betrifft - den habe ich so von den Rotomotion-Leuten. Die betrachten Linear- und Winkelbeschleunigung als jeweils eigenen Freiheitsgrad. Eine IMU, die jeweils 3 Beschleunigungs- und Kreiselsensoren hätte, wäre demnach eine 6DOF-IMU. Aber das sind nur Begrifflichkeiten...

Ahso, ok jetzt hab ich das mit den Byte pro DOF verstanden :)

Hi Markus,

ich hol den Thread nochmal hoch. Habe mir Gedanken über das Timing Deiner IMU gemacht. Wenn Du vom Gumstix-Rechner aus im Takt von 500 Hz Daten auslesen willst, erfordert das im Programm einigen Aufwand. AFAIK ist die Mindestzeit für das Scheduling unter Linux 10 ms. D.h., man kann nicht einfach einen Timer programmieren, der 500 mal pro Sekunde eine Funktion aufruft, welche Daten ausliest. Vielmehr müsste man die 500 Hz über nanosleep erzeugen, was den restlichen Programmablauf stören könnte.

Andere IMUs benutzen zur Datenübertragung häufig die serielle Schnittstelle, wie auch die Crista IMU. Hast Du die Entscheidung für I2C aus bestimmten Gründen getroffen oder war es nur eine Vorliebe? Hast Du schon Erfahrung in der Programmierung von Embedded Linux?

Gruß, Achim.

Hi Achim,
eigentlich habe ich nicht vor die Daten mit 500Hz auszulesen, das ist nur der maximal mögliche Wert. Momentan arbeitet der Regler ( in der Simulation ) mit 100Hz. D.h. in der Regler Schleife wird die Funktion zum Auslesen der Imu Daten aufgerufen. Würde der Regler mit 500Hz laufen, so würde die Funktion 500 mal aufgerufen. Es gibt also keinen extra Thread der periodisch die Imu Daten lesen müsste. Neben der I2C Schnittstelle ist die RS232 Schnittstelle auch verwendbar. Allerdings fällt mir gerade kein Grund ein warum die RS232 besser geeignet sein sollte als I2C, ausser das man die Imu leichter an den PC anschliessen kann ? Mit dem Embedded Linux auf dem Gumstix habe ich bisher noch nicht gearbeitet. Erfahrungen habe ich bisher u.a. mit vxworks.

Hi Markus,
seriell hat m.E. gegenüber I2C den Vorteil, dass der Hauptcontroller (z.B. der Gumstix) dabei passiv ist. Er muss also nicht im exakten Timing eine Abfrage starten (wir gehen davon aus, dass er I2C-Master ist) sondern bekommt zum richtigen Zeitpunkt eine Nachricht. Wenn er nicht sofort reagieren kann, ist auch nicht schlimm, weil die serielle Schnittstelle einen gewissen Puffer hat. Trotzdem muss er sich irgendwann die Zeit nehmen, die Nachricht abzuholen. Wenn dies in einem eigenen Prozess / Thread geschieht, haben wir wieder die möglichen Timingprobleme :-(

Aber ich merke gerade, dass ich Deinen Beitrag ge-hijackt habe - ursprünglich ging es ja um das X-UFO. Dort hat man natürlich andere Voraussetzungen...

Hi Achim,
ist auf dem Gumstix das I2C Interface denn in Software implementiert ? Der PXA255 hat doch ein sehr mächtiges serielles Interface mit DMA, Interrupts und allem Drum und Dran.
Siehe:
http://www.intel.com/design/pca/appl...s/27869302.pdf Unit 9

Selbst wenn I2C in Software implementiert wird und man das Clock Signal "per Hand" erzeugen muss ist das für eine 400MHz CPU ein Problem ? Bei 400kHz I2C Takt gibt es alle 1.25us einen Interrupt. Da wird schnell der SDA Pin gelesen, das Datenbyte geshiftet noch ein bissel Protokoll Overhead erledigt, das wars. Hoff ich ;)

Wie schauts mit deinem Flieger aus ? Bist du noch dran ?

Hi Markus, danke für den Link.

Zitat:

---

ist auf dem Gumstix das I2C Interface denn in Software implementiert ?

---

Ich hoffe nicht. Unter Linux benutzt man einfach nur Devices und überlässt die Implementation dem jeweiligen Treiber. Ich gehe stark davon aus, dass der die Hardware richtig nutzt.
Nein, mein Problem ist das Prozess-Scheduling unter Linux. Derzeit läuft auf dem Gumstix "normales" Linux, bei dem der Scheduler zum Umschalten zwischen zwei Prozessen mindestens 10ms benötigt. D.h., das I2C-Clock ist kein Problem, aber den richtigen Zeitpunkt zu finden, um das Device anzusprechen um Daten auszulesen, könnte ein Problem werden. Möglicherweise hilft da auch der Einsatz eines Echtzeit-Linux.

Zitat:

---

Wie schauts mit deinem Flieger aus ? Bist du noch dran ?

---

An dem konkreten Flieger hab ich erstmal die Lust verloren. Er hat sich als Fehlkonstruktion herausgestellt. Er hat zwar einen senkrechten Absturz überlebt, aber die Reperaturen sind noch nicht ganz abgeschlossen. In den letzten Wochen habe ich ein propellergetriebenes Fahrzeug gebaut, das ich zum Testen der Steuerungssoftware einsetze. Ich habe schon ein Logger-Programm geschrieben, das GPS-, IMU-. Servo- und andere Daten im Gumstix protokolliert. Seit dieser Woche entwickele ich ein einfaches Programm zur autonomen Steuerung - man muss klein anfangen :-) Ich hoffe, dass ich das Fahrzeug demnächst hier mal vorstellen kann. Bei der Programmierung des Loggers war das Timing wichtig, was mich erst auf die o.g. Probleme gebracht hat. Auf diesem Gebiet bin ich aber noch Anfänger - es wird sich sicher eine Lösung finden.

Gruß, Achim.

Hi Achim,
wie wärs denn wenn du den I2C Treiber so modifizierst, das er dir immer komplette Datensätze deines I2C Gerätes zurückgibt ? Dann brauchst du keinen zweiten Task, der die Daten formatiert, das würde alles der Treiber erledigen. Deine Applikation würde dann die Daten nur noch aus einer Queue lesen. Ich nehme doch mal an, das die Umschaltung zwischen Treiber und Applikation schneller als 10ms geht ? Sonst könnte man noch an jeden Datensatz einen Zeitstempel anhängen um die Daten zu synchronisieren ?
Ich bin mal sehr gespannt auf dein neues Fahrzeug ! Wann hast du vor es hier vorzustellen ?

Hi Markus,
einen speziellen Treiber zu programmieren, wäre eine Idee. Die Sourcecodes der vorhandenen Treiber kann man ja lesen und hoffentlich verstehen. Da gab es neulich ein schönes Buch über Linux-Treiber. Muss ich mir mal zulegen...

Das Fahrzeug wollte ich erst vorstellen, wenn es einigermaßen autonom fahren kann. Ähnlich wie Du mit der IMU ;-) Aber im Anhang schonmal ein kleiner Vorgucker :-)

Gruß, Achim.

@voidpointer:
Deine Idee sieht interresant aus! Wie wird der Gelenkt?

Mfg.Attila Földes

Uuups, ich hätte das Bild nicht posten sollen :-s

@techboy: das Bugrad wird über ein Servo gelenkt, wie bei einem Modellflugzeug. In max. 2 Wochen gibt es mehr Info in einem Extra-Thread, OK?

Ich bin gespannt :)

kannst du die bilder bitte nochmal uploaden? danke!
sc0pe