Neues Sensorboard?

[guenter]

Hallo Forum,

für den nächsten Controller habe ich mal diese Sensoren im Plan...
http://www.watterott.com/de/MinIMU-9-Gyro

[msepp]

Spannend !!!

Hallo Günter,

ich poste mal mit dem Account meiner Jungs... weil ich sie im Elektronik- und Firmwarebereich unterstützen werde. Ich arbeite seit einigen Jahren als Ingenieur im Elektronikbereich und würde mich freuen wenn ich nicht nur bei meinen Jungs sondern auch bei diesen Weiterentwicklungen beitragen könnte/dürfte. Vielleicht ist die künftige Version ja schon für meine Jungs interessant.

Ich hätte für mein Verständnis ein paar Fragen. Weil meine Jungs sich erst seit wenigen Wochen mit dem Thema Wheelie beschäftigen habe ich viele Dinge und speziell auch das momentane Design noch nicht wirklich intus.

Ich finde den Ansatz, die Sensoren über I2C anzubinden auf jeden Fall auch interessant, die bisherigen Sensoren waren doch an analoge Eingänge des Controllers angebunden, oder?
Wieso planst Du den Wechsel zu diesen neuen Sensoren? Höhere Auflösung oder laufen die bisherigen in der Herstellung aus? Ein Gewinn sollte auf jeden Fall der Rauschabstand sein wenn die analogen Sensorsignale nicht mehr von zerhackten Motorströmen gestört werden.

Was mir auch noch nicht klar ist: Prinzipiell würde ja ein einachsiger Sensor ausreichen. Zwei Achsen verstehe ich auch noch wenn man z.B. das Fahren seitlich am Berg verbessern will. Wofür die dritte Achse?

Der "neue" kann ja ausserdem noch einiges mehr: Kompass, Beschleunigungsmesser und Gyroscope. Hast Du da schon Anwendungsfälle im Kopf, die das ausnutzen können? Ich habe mir den Regler auch noch nicht angeschaut... bestimmt ist da in der Abstimmung des Reglers für Geschwindigkeit mit den Geartooths und mit dem Lageregler schon einiges an detaillierter Erfahrung drin

Entschuldige bitte die Unsumme an Fragen und ich hoffe dass das Mitdenken überhaupt erwünscht ist. Ausserdem würde ich Deine Wheelievarianten sehr gerne mal anschauen Vielleicht ergibt sich ja mal die Gelegenheit.

Viele Grüße,

Udo

[guenter]

Hallo Udo,

die bisherigen Sensoren sind fast nicht mehr zu bekommen. Außerdem habe ich meinen ganzen Bestand an ICs bei Reparaturen anderer Wheelies aufgebraucht. Da für die Gearsensoren sowieso schon I2C genutzt wird, ist das kein großer Akt mehr. Netterweise sind die winzigen Sensoren schon aufgelötet und die Platine ist kleiner als die Alte. So sollte sich auch ein Adapter bauen lassen.
Einen Einsatzbereich für die Z-Achse siehst du hier: http://www.youtube.com/watch?v=A5TO7ZRy8B8

Mitknobeln ist natürlich erwünscht!

[msepp]

Hallo Günter,

guten Morgen. Ich habe mir die beiden Datenblätter mal überflogen, kann aber im Moment schlecht gegen die frühere Version vergleichen weil ich nicht weiß welche Sensoren bisher verwendet wurden. Vielleicht kannst Du mir ja den Typ sagen?

Hast Du eine kurze Beschreibung des Reglers (welche Signale, in welchen Achsen verwendest Du als Reglereingang, wo schleust Du die GTs ein)?

Was mir zur Umstellung von analogen Eingängen zu I2C als einfällt ist die nötige Übertragungszeit. Bei I2C standard mode fallen für die Übertragung alleine der Gyrodaten grob geschätzt 100 Takte auf dem I2C bus an, was im standard mode ~1ms bedeuten würde. Dazu kommen noch die Beschleunigungssensoren und evtl. die Magnetometerdaten vermutlich mit ähnlichem Zeitbedarf, die Zeit für die GT-Sensoren und der Prozessoroverhead.

Wenn ich es richtig weiß haben wir einen Reglertakt von 100Hz (?). Passt das mit dem Timing oben wohl zusammen? Vielleicht habe ich aber hier ja noch einen Denkfehler... Oder man müsste die I2C Übertragung aus der Prozessorlaufzeit rausnehmen. Wenn der Controller das kann.

Viele Grüße, schönes Wochenende,

Udo

[guenter]

Hallo Udo,

im Moment werden die analogen Werte des Gyros (IDG300) und des Beschleunigungssensors (ADXL320) von ADCs des ATMega32 eingelesen. In der letzten Version lese ich 3x Gyroachsen, 2 Beschleunigungsachsen, Batteriespannung, Lenker und Fußschalter (Fußschalter? Das hat historische Gründe )
Dazu werden im Moment 9 Byte per I2C empfangen:
2 Byte Geschwindigkeit links
2 Byte Geschwindigkeit rechts
2 Byte Motorstrom links
2 Byte Motorstrom rechts
1 Byte mit den Richtungsflags der Motoren

Das I2C dauert im Moment 0,32ms

Gruß Günter

[guenter]

Zu deiner Timingfrage:

Bis jetzt wird gewartet bis alle 9 Bytes per I2C abgeholt sind erst danach fährt der Code fort.
Der ATMega32 kann aber bei einem empfangenen I2C-Byte einen Interrupt auslösen, in dem man das Byte wegspeichert. Dadurch könnte man Zeit einsparen. Dagegen spricht im Moment nur, dass die komplette Regelung bereits in einem Interrupt liegt (warum? Das hat historische Gründe ) und bei den ATMegas ein weiterer Interrupt erst nach dem Beenden des ersten Interrupts ausgelöst wird.
Man könnte nun die Regelung aus dem Interrupt entfernen, dann gehts. Auch könnte man einen XMega verwenden, der priorisierbare Interrupts bietet, mehrere I2Cs hat und auch schneller läuft.

[msepp]

Ah ja, da hatte ich mich in der Beschreibung des Boards verlesen. Die sagen, sie konnten es "up to 400kHz" betreiben und ich dachte die könnten nur die den I2C Standard Modus mit 100kHz fahren. Damit viertelt sich die Zeit für die Datenübertragung natürlich.

Die bisherigen Bytes für Motorstrom, Geschwindigkeit und Richtung liest Du aus einem einzelnen Chip aus? (nehme ich mal an weil nur einmal Adresse für den ganzen Leseblock da ist).

Wenn meine Jungs mit ihrem mSEPP rechtzeitig soweit sind könnte ich mir gut vorstellen da die neuen Sensoren einzusetzen... wobei da so komfortable Sachen wie Debugging auf dem Wheeliedisplay bestimmt nicht in nächster Zukunft zur Verfügung stehen

[guenter]

Hallo Udo,

ein zuätzlicher ATMega8 misst die beiden Geartoothsenoren und stellt die Werte als I2C-Slave bereit. Da die ADCs des ATMega32 mit der 3V-Referenz der Balancesensoren läuft, kann ich da die Stromsensoren mit ihrem 5V Ausgangssignal nicht anschließen. Deshalb sind sie am ATMega8 mit dran.

[udo]

Zu deiner Timingfrage:

Bis jetzt wird gewartet bis alle 9 Bytes per I2C abgeholt sind erst danach fährt der Code fort.
Der ATMega32 kann aber bei einem empfangenen I2C-Byte einen Interrupt auslösen, in dem man das Byte wegspeichert. Dadurch könnte man Zeit einsparen. Dagegen spricht im Moment nur, dass die komplette Regelung bereits in einem Interrupt liegt (warum? Das hat historische Gründe ) und bei den ATMegas ein weiterer Interrupt erst nach dem Beenden des ersten Interrupts ausgelöst wird.
Man könnte nun die Regelung aus dem Interrupt entfernen, dann gehts. Auch könnte man einen XMega verwenden, der priorisierbare Interrupts bietet, mehrere I2Cs hat und auch schneller läuft.

... ab jetzt mit eigenem Forenaccount

Ich kenne die Produktzyklen der Atmel Prozessoren nicht, ein Umstieg auf den XMega könnte eventuell sinnvoll sein wenn man Angst vor dem Auslaufen des ATMega32 hat.
Wegen der Interruptroutine: Was hältst Du davon wenn das komplette I2C-handling in einer ISR ablaufen würde und die eingelesenen Daten in globale Variablen schreiben würde?
Man könnte ja eine Funktion fRead_I2C_Data schreiben. Die schaltet den I2C-Interrupt frei, schreibt die zu sendenden Bytes rein und erwartet n empfangene Bytes ab um sie in einen globalen string zu schreiben.

Ich könnte mich gerne um den Teil kümmern... leider habe ich NullkommaNull Entwicklungsumgebung um mich herum um das zu machen Ich würde mindestens einen Mastercontroller, einen Slavecontroller (z.B. mit Deiner ATMega8 GT-Software) brauchen.

Viele Grüße,

udo

[guenter]

Hallo Udo,

EIN Interrupt würde den Vorteil wieder zunichte machen.
Besser wäre nur das eine bereits empfangene Byte wegzuschreiben und sofort zur Hauptschleife zurückzukehren.