Druckbare Version
hallo oberallgeier,
hast recht, wenn man sich schon bei Wikipedia erkundigt, sollte man
es schon genau durchlesen oder sich die Grafik ansehen. Rein gefühlsmässig hätte ich auch eher eine Zunahme (Richtung Erdmittelpunkt) erwartet, sonst wäre wohl auch an Gold leichter ranzukommen.
Da gab's doch mal sowas wie "Reise zum Mittelpunkt der Erde", weiss aber nicht , was darin zu dem Thema stand.
Hallo Leute,
nicht ganz on topic - aber es betrifft diesen ELV-3-Achs-G-Meter. Vor mir liegt so ein hübsches Teil und ich will das natürlich in Betrieb nehmen. Bisher habe ich null Erfahrung mit I²C. Im Moment bekomme ich dummerweise mein USB-Lab nicht I²C-Logger ingang (das PC-Tool zum lesen, schreiben und senden der Daten läuft nicht - keine Ahnung wieso). Dieser Logger könnte nämlich nach Spezifikation angeblich I2C-Signale bis 200 kHz mitschneiden und I2C-Daten mit 100 kHz senden. Also muss ich selbst etwas basteln um mit dem ELV-Platinchen ingang zu kommen.
Dazu habe ich eine Platine mit mega168, ohne Quarz, derzeit mit 1MHz und angeschlossenem LCD 2x16.
Fragen :
Baue ich die Software mit der Fleury-Lib?
Wird / kann das mit dem 1MHz-quarzlosen Controller laufen - oder mit 8MHz? Oder ist ein Quarz zwingend erforderlich?
Oder gibt es eine sinnvolle Alterntive zum Selbstbau?
Danke für die Antworten - und sorry für das Beinahe-OT.
hallo oberallgeier,
ich hab das ELV-Platinchen am Atmega8 (Quarz 8MHz), die ASURO-Bib
(hat wohl auch die Fleury-Dateien) mit I2C.c und I2C.h und das Beispiel von Sternthaler aus diesem Thread. Das LCD (2x16 von Pollin) hab ich an einem PCF5... (Porterweiterung) auf Adresse
x40 und den Sensor auf Adresse x70 bzw. x71.
Gib z.Zt. ca alle halbe s die x,y,z - Werte auf dem Display aus.
Hab nur den Eindruck, dass zwar die Auflösung des Sensors mit 10 Bit sehr gut ist, die Genauigkeit ( Übersprechen) aber relativ schlecht.
Auch erreich ich nicht den Maximal-Wert in z-Richtung (+-255) , sondern liege wohl knapp über 230.
Werde aber mal versuchen, über arcsin/cos aus math.h die Winkel zu berechnen, bevor ich da genaueres sagen kann.
Gruss mausi_mick
hallo,
hab mal ein wenig experimentiert und festgestellt, dass die Werte für+- 1 g für die x,y,z Achse sehr unterschiedlich sind (ist aber auch im Datenblatt angegeben) und der Wert für +-1g von +-256 stark abweicht . Bei meinem Exemplar liegen die Kennlinien in diesem Bereich:
-90° +90°
x: -198 +264
y: -258 +220
z: -232 +228
Ich hab das dann auf 255 normiert und den Nullpunkt entsprechend verschoben.
Damit komm ich dann auf Werte von > 88 ° für die Maximalpositionen,
die auch mit der wirklichen lage des Sensors gut korrespondieren.
Ach, da beschleunigt der oberallgeier nun auch? ;-)
Bei mir hängt das Ding an einem ATmega644 ohne Quarz. Es läuft somit standardmäßig auch bei einem winzigen MHerzchen. Das Hochtakten im 644 auf 8 MHz geht auch ohne Quarz um noch Daten vom beschleunigten Leben zu lesen.
Und wie mausi_mick schon schrieb, ist die LIB vom Asuro mit dem Fleury-Code funktionsfähig.
@mausi_mick
Wie hast du die Winkel ausgerechnet?
Ich vermute, dass du 'Seiteneffekte' weg läßt und nur den Winkel über die Z-Achse gegen X- bzw. Y-Achse rechnest.
Oder betrachtest du auch eine waagerechte Lage mit einer echten seitlichen Beschleunigung?
Wie ist/sind da die Messwerte zu sehen? Ist Z dann immer noch bei 1g und nur X oder Y 'beschleunigen'? Wie kann man dann ausrechnen, wenn das Teil auch noch schief im Raum liegt, in welchem Winkel ich durch die Gegend sause/beschleunige?
Ach du meine Güte! Ich hoffe, dass du verstehst was ich da eigentlich frage ;)
Frohes Beschleunigen wünscht
Sternthaler
Hallo Sternthaler,
Ich hatte bei meinem grossen Monowheel (Big-MW) , bei dem ich den MMA7260Q verwende, auch das Problem, dass die Beschleunigungswerte, wenn ich nur z.B. die x-Richtung quer zur Fahrtrichtung betrachtete, von dem im Ruhezustand abwichen, auch wenn das Fahzeug garnicht in x-Richtung geneigt war.
Das lag wohl nicht nur an den "dynamischen" Beschleunigungen z.B. durch den Antrieb, sondern im Wesentlichen daran, dass das Innenfahrzeug nach dem Anfahren eine Schräglage einnimmt ( Es fährt anfangs vorne im Rad hoch, um den Ausennreifen in Drehung zu bringen, nach dem Anfahren (und Erreichen der rel. konstanten Fahrgeschwindigkeit) lag das Innenfahrzeug etwas (ca 20°) nach vorne geneigt im Rad . Dadurch bekam dann die Beschleunigung quer zur Fahrtrichtung nicht mehr den vollen g-Vektor mit.
Ich hab das dann anfangs korrigiert, indem ich die Nullage des Sensors etwas manipuliert habe, werd das jetzt aber wohl mit den unten angegebenen Formeln bzw. der Tabelle machen.
Zu Deiner Frage:
ich hab da vom MMA7260Q/Freescale eine Doku (AN3461), wo ein wenig Geometrie gemacht wird. Da gibt's dann die Winkel
rho = arctan(Ax/sqrt(Ay*Ay + Az*Az))
phi = arctan(Ay/sqrt(Ax*Ax + Az*Az))
und theta = arctan(sqrt(Ax*Ax + Ay*Ay)/Az)
und sqrt (Ax*Ax + Ay*Ay + Az*Az) = 1 g (falls nur Gravitation)
wobei bei theta - nehme ich an - ein Schreibfehler vorliegt
ich rechne mit
theta = arctan(Az/sqrt(Ax*Ax + Ay*Ay))
zusätzlich ist dort auch noch eine Umsetztabelle
von AD-Werten zu Winkeln ( der MMA7260 ist ja ein analoger Sensor).
Ich versuche mal, meinen (wohl nicht sehr schönen und vermutlich auch nicht ganz fehlerfreien) Code zu posten. Kansst Du Dir ja mal ansehen und verbessern.
Gruss mausi_mick
PS: Ich hab mit ELV telefoniert und ihnen mitgeteilt, dass mein
2. Sensor defekt ist. Ich hab dann geäussert, dass es mir lieber wäre , anstelle das defekte hin-und-her zu senden , noch zusätzlich zwei Sensoern portofrei zu erwerben.
Sie waren dann sehr kulant und haben mir ausserdem noch ein Exemplar kostenlos beigelegt.
Die Lieferung erfolgte dann auch innerhalb von 2 Tagen, nachdem ich bei den ersten Exemplaren mehr als 3 Monate gewartet hatte
Hallo alle,
puhhhh. Na ja, ich bekomme wenigstens Daten heraus.
Chip verdrahtet nach Bau- und Bedienungsanleitung 91521 von ELV, Bild 7. I2C-Bibliothek von PFleury und das "Programmschnippsel für die Neugierigen" von Sternthaler. Sternthalers Programmschnippsel an die Wortwahl (Befehle) von PF anpassen. Irgendwann wirds dann fehlerfrei compiliert. Flashen. Einschalten.
Schön, es gibt sogar eine Ausgabe am LCD - nachdem ich den UPULLUP (auch) auf +5V gelegt hatte. Aber die Ausgabe war nicht so richtig akzeptabel: die x-Werte schwanken um drei Digits, der Rest ist stabil. Wenn ich die Versorgung - Vcc und GND - von der Sensorplatine abklemme, dann wird nur der Text, nicht aber die Zahlenwerte angezeigt (Controller bleibt hängen), auch die "Ende Messung"-Meldung bleibt aus.Code:// =================================================================================
void DAA_lcd(void) // Daten lesen und Ausgabe aufs LCD-Modul
{ //
char zahlwort[5];
lcd_init(LCD_DISP_ON); // Initialisiere Display, Cursor aus
lcd_clrscr(); // loesche LCDisplay, Cursor 1 Zeile, 1 Spalte
lcd_puts ("L168-10x31, 17Okt10 1730");
waitms ( 10); //
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
// - - Es folgt die Datenerfassung, vergleiche dazu Sternthaler in
// https://www.roboternetz.de/phpBB2/ze...=507498#507498
//
// ----------------------------------------------------------------------------
// Defines: Adresse vom BMA020-3D-Beschleunigungssensor
//
#define I2C_BMA_W 0x70
#define I2C_BMA_R 0x71
//
unsigned char ACK, NAK;
int16_t x, y, z;
uint8_t ret;
uint16_t wloop;
wloop = 0;
//
// ----------------------------------------------------------------------------
// Die Werte aufs LCD schreiben
lcd_clrscr(); // loesche LCDisplay, Cursor 1 Zeile, 1 Spalte
// 012345678901234567890123
lcd_puts ("Wertx Werty Wertz ");
// ----------------------------------------------------------------------------
// Lesen von 6 Registern ab Register 0x02. X, Y, Z-Koordinate
// Ab hier Befehle ähnlich Sternthaler, aber aus der Fleury-Lib
//
while (1) //
{ //
wloop++; // Loop hochzählen
//
i2c_init(); //
//
ret = i2c_start (I2C_BMA_W);
ret = i2c_write (0x02);
i2c_stop ();
//
ret = i2c_start (I2C_BMA_R);
ret = i2c_read (ACK); x = (int16_t)ret;
ret = i2c_read (ACK); x = x | ((int16_t)ret << 8); x /= 64;
ret = i2c_read (ACK); y = (int16_t)ret;
ret = i2c_read (ACK); y = y | ((int16_t)ret << 8); y /= 64;
ret = i2c_read (ACK); z = (int16_t)ret;
ret = i2c_read (NAK); z = z | ((int16_t)ret << 8); z /= 64;
i2c_stop ();
//
// Die Werte für X, Y, Z-Koordinate sind gelesen
// ----------------------------------------------------------------------------
// ----------------------------------------------------------------------------
// Die Werte aufs LCD schreiben
//
utoa(x, zahlwort, 10); //
lcd_gotoxy( 1, 1); // Spalte 2 {0, 23} in Zeile 2 {0, 1}
lcd_puts(zahlwort); //
waitms( 1); //
//
utoa(y, zahlwort, 10); //
lcd_gotoxy( 9, 1); // Spalte 19 in Zeile 1
lcd_puts(zahlwort); //
waitms( 1); //
//
utoa(z, zahlwort, 10); //
lcd_gotoxy(18, 1); // Spalte 19 in Zeile 1
lcd_puts(zahlwort); //
waitms( 10); //
if (wloop == 1000) //
break; //
} // Ende von while (1)
//
waitms( 5000); //
lcd_gotoxy(0, 1); // Cursor auf Anfang untere Zeile
// 012345678901234567890123
lcd_puts (" Datenausgabe Ende "); // Text ausgeben
return;
}
Ahhhh - da war doch diese Geschichte mit den 10k von SCL und SDA nach Vcc. Ok, das ist schnell gemacht. Aber es ändert sich nix. Da die Gravitation nach Lage des Sensors gerade in Z-Richtung groß ist (ich habs ja nicht am Kniebrett und teste es in Formel1-Kurvenfahrt) - habe ich offenbar etwas falsch gemacht. Weiß jemand was? Danke im Voraus.Code://012345678901234567890123 - - Die folgenden 2 Zeilen symbolisieren das LCD 2x24
| Wertx Werty Wertz |
| 65533 0 65532 |
4
5
Hallo oberallgeier,
du nutzt nach dem Lesen von x, y und z die Funktion utoa(). Mir scheint es angebracht zu sein, dass du itoa() benutzen solltest. u sollte für UNsigned stehen. i steht für Integer und damit signed.
Auch die Variable zahlwort[5] solltest du länger machen. Im String ist IMMER das letzte Zeichen das Byte 0 als Abschlußzeichen. Netto also 4 Byte für Text. Ein Vorzeichen, Und schon wird es knapp.
Hallo mausi_mick,
oh, ich glaube, dass mir das von dir angegebene "sqrt (Ax*Ax + Ay*Ay + Az*Az) = 1 g (falls nur Gravitation)" schon echt auf die Sprünge hilft um geistig weiter zu kommen.
Nun fehlt mir zwar noch jede Menge weitere Mathe um irgendwann auch mal nur ansatzweise sagen zu können was das Teil im Raum macht, aber da verlasse ich mich lieber auf euch/dich.
Dein Code sieht gut aus.
An einer Stelle hätte ich noch einen Satz Klammern spendiert beim casten:
DU: xn = (int16_t)(double) xn * x_norm;
ICH: xn = (int16_t) ( (double) xn * x_norm);
Essen ist fertig.
Und tschüß
Sternthaler
Hi Sternthaler,
danke, das "utoa"-Problem war mir beim Abendessen aufgefallen. Hatte ich vorhin repariert - und schon gehts ohne diese großen Werte. X (das ist Richtung meines Rückens) ist jetzt negativ - also beschleunigt mein Schreibtisch leicht mit Werten -1 bis -3, die anderen Werte sind stabil auf Null.
Deine Anpassung an die char-länge - danke - hat an den vermurksten Werten nix geändert.
Nachtrag: 17. 10. 2010, 23:24 (Nachtschwärmer haben tagsüber Nachteile oder: eigen Fehler währen am längsten)
Irgendwie ging beim Code-Aufräumen etwas verloren: ACK und NAK schwebten irgendwo im begrenzten Werteraum des unsigned char. Kaum hatten die beiden den Wert 1 und Null (wieder) bekommen - dann liefs auch. (Wers nicht glaubt, darf auf das Bildchen klicken).
............Bild hier
............Ein Probelauf mit dem Testaufbau
hallo oberallgeier,
Gratulation !
Das Ergebnis sieht zwar noch etwas furchtbar aus (für die recht gute Linearität von 0,5% FS), aber da sind ja noch die Faktoren Sensivity (für 1g):
yx: 205 ... 256 ... 307
z : 166 ... 256 ... 346
zero offset g : +/- 220mg
und die Crossoversensivity von < 2%
(neben den temperatur - und alterungsbedingten Abweichungen).
Es gibt also noch viel zu manipulieren .
Viel Erfolg
mausi_mick
Sternthaler:
Werd das mal mit dem Casting ausprobieren.
Winkelberechung:
In der AN von Freescale ist auch noch eine Skizze, die das etwas veranschaulicht.
Oder dieser Link: http://books.google.de/books?id=cUY-...page&q&f=false
(