X-Ufo Sensorplattform -> IMU

[DerMarkus]

@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.

[voidpointer]

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.

[DerMarkus]

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.

[voidpointer]

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...

[DerMarkus]

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

[voidpointer]

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.

[DerMarkus]

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.

[voidpointer]

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...

[DerMarkus]

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 ?

[voidpointer]

Hi Markus, danke für den Link.

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.

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.