Druckbare Version
Ich meinte damit nur dass Du nicht BEIDE Versionen gleichzeitig installieren sollst.
Was genau ist denn aktuell noch das Problem?
Lassen sich die orginalen unveränderten Beispielprogramme übersetzen?
(falls ja, liegt das Problem nicht bei der avr-gcc Installation ;) )
MfG,
SlyD
EDIT:
Ach hattest die Ordnerstruktur ja weiter oben was gepostet.
Aber: Welche Dateien sind genau im Verzeichnis drin und heissen die genau so wie im makefile angegeben?
hallo SlyD,
hier das ganze zusammengefasst:
Zitat:
Zitat von SlyD
da ich nicht weiss, wo das problem liegt, dachte ich eher daran, die deb version als ersatz zu verwenden, da dort „alles aus einer hand“ und von avr ist. Nachdem ich über eclipse zu code:blocks kam und mit letzterem eigentlich zufrieden war tauchten diese probleme auf (siehe weiter unten). Jetzt möchte ich wissen, ob ich (so wie Dirk) mit make und makefile weiterkomme...
der letzter stand, die reaktion auf ein make im terminal, da suche ich die antwort drauf...
Code:georg@netzserver:~/workspace/gyro_test_3$ make
-------- begin -------- avr-gcc (GCC) 4.5.3 Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
make: *** Keine Regel vorhanden, um das Target »gyro_test_3.elf«, benötigt von »elf«, zu erstellen. Schluss.
georg@netzserver:~/workspace/gyro_test_3$
eigentlich weiss weder Dirk, noch ich woran es liegt. Ich versuche mal das problem zu beschreiben:Zitat:
Zitat von SlyD
dieser code:
lässt sich:Code:#include "RP6ControlLib.h"
#include "RP6I2CmasterTWI.h"
#include "RP6Control_MultiIOLib.h"
#include "RP6Control_I2CMasterLib.h"
#include "RP6Control_OrientationLib.h"
//#include "RP6ControlServoLib.h"
#define I2C_RP6_BASE_ADR 10
/************************variables*****************************************/
uint8_t ch;
char item[12];
char dir[3];
/*********************I2C-fehlermeldungen******************/
void I2C_transmissionError(uint8_t errorState) //gibt I2C fehlermeldungen über LCD aus
{
clearLCD();
writeStringLCD_P("I2C ERROR -->");
setCursorPosLCD(1, 0); // line 2
writeStringLCD_P("TWI STATE: 0x");
writeIntegerLCD(errorState, HEX);
}
/**
* Returns a 2 character string for the eighth
* parts of the direction calculated from the
* heading value.
*
* Input: heading -> Heading value [0..359]
*
*/
void calculateDir(char *dir, uint16_t heading)
{
dir[1] = ' ';
dir[2] = '\0';
if ((heading <= 22) || (heading >=338)) dir[0] = 'N';
if ((heading >= 23) && (heading <= 67)) {dir[0] = 'N'; dir[1] = 'E';}
if ((heading >= 68) && (heading <= 112)) dir[0] = 'E';
if ((heading >= 113) && (heading <= 157)) {dir[0] = 'S'; dir[1] = 'E';}
if ((heading >= 158) && (heading <= 202)) dir[0] = 'S';
if ((heading >= 203) && (heading <= 247)) {dir[0] = 'S'; dir[1] = 'W';}
if ((heading >= 248) && (heading <= 292)) dir[0] = 'W';
if ((heading >= 293) && (heading <= 337)) {dir[0] = 'N'; dir[1] = 'W';}
}
/************************Write a floating point number to the LCD.******/
/*
* Example:
*
* // Write a floating point number to the LCD (no exponent):
* writeDoubleLCD(1234567.890, 11, 3);
*
* The value of prec (precision) defines the number of decimal places.
* For 32 bit floating point variables (float, double ...) 6 is
* the max. value for prec (7 relevant digits).
* The value of width defines the overall number of characters in the
* floating point number including the decimal point. The number of
* pre-decimal positions is: (width - prec - 1).
*/
void writeDoubleLCD(double number, uint8_t width, uint8_t prec)
{char buffer[width + 1];
dtostrf(number, width, prec, &buffer[0]);
writeStringLCD(&buffer[0]);
}
void writeDouble(double number, uint8_t width, uint8_t prec)
{char buffer[width + 1];
dtostrf(number, width, prec, &buffer[0]);
writeString(&buffer[0]);
}
/*****************gyroscope***************/
void gyroscope(void) // L3GD20 gyroscope
{
// orientation_init();
task_I2CTWI();
readL3GD20(); // Get sensor values
normalizeL3GD20();
task_I2CTWI();
setCursorPosLCD(0, 0); // line 1
writeStringLCD_P("X");
writeIntegerLCD(x_axisg, DEC);
writeStringLCD_P(" ");
setCursorPosLCD(0, 8); // line 1 pos 9
writeStringLCD_P("Y");
writeIntegerLCD(y_axisg, DEC);
writeStringLCD_P(" ");
setCursorPosLCD(1, 0); // line 2
writeStringLCD_P("Z");
writeIntegerLCD(z_axisg, DEC);
writeStringLCD_P(" ");
#ifdef GET_TEMP
temperatureg = calcTempL3GD20(temperatureg) + 5;
temperatureg += OFFSET_TEMP;
setCursorPosLCD(1, 8); // line 2 pos 9
writeStringLCD_P("T");
writeIntegerLCD(temperatureg, DEC);
writeStringLCD_P(" ");
#endif
task_I2CTWI();
mSleep(3000);//4,5 sec
clearLCD();
}
/************accelerometer****************/
void accelerometer(void) // LSM303DLHC accelerometer
{
// orientation_init();
clearLCD();
task_I2CTWI();
readLSM303DLHC_A(); // Get sensor values
task_I2CTWI();
setCursorPosLCD(0, 0); // line 1
writeStringLCD_P("X");
writeIntegerLCD(x_axisa, DEC);
writeStringLCD_P(" ");
setCursorPosLCD(0, 5); // line 1 pos 6
writeStringLCD_P("Y");
writeIntegerLCD(y_axisa, DEC);
writeStringLCD_P(" ");
setCursorPosLCD(0, 10); // line 1 pos 11
writeStringLCD_P("Z");
writeIntegerLCD(z_axisa, DEC);
writeStringLCD_P(" ");
normalizeLSM303DLHC_A(); // Normalize data
positionLSM303DLHC_A(); // Calculate position
setCursorPosLCD(1, 0); // line 2
writeStringLCD_P("P");
writeDoubleLCD(pitch, 6, 1);
writeStringLCD_P(" ");
setCursorPosLCD(1, 8); // line 2 pos 9
writeStringLCD_P("R");
writeDoubleLCD(roll, 6, 1);
writeStringLCD_P(" ");
task_I2CTWI();
mSleep(3000);
}
/*****************magnetometer************/
void magnetometer(void) // LSM303DLHC magnetometer
{
// orientation_init();
clearLCD();
task_I2CTWI();
readLSM303DLHC_M(); // Get sensor values
task_I2CTWI();
setCursorPosLCD(0, 0); // line 1
writeStringLCD_P("X");
writeIntegerLCD(x_axism, DEC);
writeStringLCD_P(" ");
setCursorPosLCD(0, 5); // line 1 pos 6
writeStringLCD_P("Y");
writeIntegerLCD(y_axism, DEC);
writeStringLCD_P(" ");
setCursorPosLCD(0, 10); // line 1 pos 11
#ifndef GET_TEMP_M
writeStringLCD_P("Z");
writeIntegerLCD(z_axism, DEC);
writeStringLCD_P(" ");
#else
temperature_imu = (double) temperaturem / 8.0 + OFFSET_TEMP_M;
writeStringLCD_P("T");
writeDoubleLCD(temperature_imu, 5, 1);
#endif
normalizeLSM303DLHC_M(); // Normalize data
headingm = headingLSM303DLHC_M(); // Calculate heading
calculateDir(dir, headingm);
setCursorPosLCD(1, 0); // line 2
writeStringLCD_P("H");
writeIntegerLengthLCD(headingm, DEC, 3);
writeStringLCD_P(" ");
writeStringLCD(dir);
headingtc = headingLSM303DLHC_TC(); // Calculate TILT COMPENSATED
calculateDir(dir, headingtc); // heading
writeStringLCD_P(" C");
writeIntegerLengthLCD(headingtc, DEC, 3);
writeStringLCD_P(" ");
writeStringLCD(dir);
writeStringLCD_P(" ");
mSleep(3000);//4,5 sec
clearLCD();
task_I2CTWI();
}
/*************** hauptprogramm ***********/
int main(void)
{
initRP6Control();
initLCD();
setLEDs(0b1111);
mSleep(500);
setLEDs(0b0000);
I2CTWI_initMaster(100);
I2CTWI_setTransmissionErrorHandler(I2C_transmissionError); //aktiviert I2C fehlermeldungen
multiio_init();
orientation_init();
// Voltage & current sensor test:
LTC2990_measure();
setCursorPosLCD(0, 0);
//writeStringLCD("BAT Current: ");
//writeDoubleLCD(cbat, 6, 1);
writeStringLCD(" accu: ");
writeDoubleLCD(vbat, 4, 1);
writeStringLCD( " V");
mSleep(1500);
showScreenLCD(" RP6Control M32", " gyro_test_3");
mSleep(2500);
clearLCD();
while(true)
{
/*****************anzeige gedrückter buttons****************/
clearLCD();
pressedMultiIOButtonNumber = getMultiIOPressedButtonNumber();
setCursorPosLCD(0, 0);
writeStringLCD("Button: ");
writeIntegerLCD(pressedMultiIOButtonNumber, DEC);
mSleep(500);
uint8_t key = getMultiIOPressedButtonNumber();
/********************funktion der buttons*********************/
if(key)
{
switch(key)
{
case 1://
setLEDs(0b0001);
gyroscope();
break;
case 2://
setLEDs(0b0010);
accelerometer();
break;
case 3://
setLEDs(0b0100);
magnetometer();
break;
case 4://
setLEDs(0b1000);
gyroscope();
accelerometer();
magnetometer();
break;
}
}
}
return 0;
}
- bei Dirk wie auch bei mir fehlerfrei kompilieren
- bei Dirk kompilierte version läuft bei uns beiden problemlos
- die bei mir kompilierte version läuft bei mir NICHT (ob sie bei Dirk läuft weiss ich jetzt nicht mehr, vermutlich nicht)
- Dirk kompiliert mit make und makefile
- ich arbeite mit code:blocks, welche art der compilierung da im hintergrund läuft weiss ich nicht
- das problem trat zuerst mit den dateien auf, in denen Dirks libs für das multi-IO board und die minIMU verwendet wurden (RP6Control_OrientationLib.c, RP6Control_Orientation.h, RP6Control_OrientationLib.h)
Zitat:
Zitat von SlyD
files aus der gyro_test_3:
angaben im makefile:Code:#include "RP6ControlLib.h"
#include "RP6I2CmasterTWI.h"
#include "RP6Control_MultiIOLib.h"
#include "RP6Control_I2CMasterLib.h"
#include "RP6Control_OrientationLib.h"
dateien im verzeichnis:Code:# you would write: TARGET = RP6Base_MyProgram
TARGET = gyro_test_3
###############################################################################
###############################################################################
# Specify relative path to RP6 library files here.
# This is "../../RP6lib" or "../RP6lib" usually.
RP6_LIB_PATH=../RP6lib
RP6_LIB_PATH_OTHERS= $(RP6_LIB_PATH)/RP6control $(RP6_LIB_PATH)/RP6common
###############################################################################
SRC += $(RP6_LIB_PATH)/RP6control/RP6ControlLib.c
SRC += $(RP6_LIB_PATH)/RP6common/RP6uart.c
#SRC += $(RP6_LIB_PATH)/RP6common/RP6I2CslaveTWI.c
SRC += $(RP6_LIB_PATH)/RP6common/RP6I2CmasterTWI.c
SRC += RP6Control_I2CMasterLib.c
SRC += RP6Control_MultiIOLib.c
SRC += RP6Control_OrientationLib.c
SRC += RP6Control_LFSBumperLib.c
SRC += $(RP6_LIB_PATH)/RP6control/RP6ControlServoLib.c
Code:gyro_test_3.c
makefile
RP6Control_I2CMasterLib.c
RP6Control_I2CMasterLib.h
RP6Control_LFSBumperLib.c
RP6Control_LFSBumperLib.h
RP6Control_MultiIO.h
RP6Control_MultiIOLib.c
RP6Control_MultiIOLib.h
RP6Control_Orientation.h
RP6Control_OrientationLib.c
RP6Control_OrientationLib.h
Hallo Inka,
> ich arbeite mit code:blocks, welche art der compilierung da im hintergrund läuft weiss ich nicht
Naja wird wohl den avr-gcc verwenden den Du schon installiert hast.
IDEs erzeugen oft auch nur ein makefile und rufen dann make auf und analysieren die Ausgaben.
Code::blocks verwendet aber glaube ich was eigenes.
Einen offensichtlichen Fehler kann ich da im makefile nicht erkennen.
Pack den ganzen Ordner inklusive RP6Lib mal (zip oder tar.gz) und schick ihn mir per Mail.
Ich schau mir dass dann mal an.
Und nochmal die Frage:
Lassen sich die orginalen unveränderten Beispielprogramme (ohne Code::blocks, direkt mit make!)
fehlerfrei übersetzen und laufen die dann auch auf dem RP6?
Das ist der erste Test den Du machen solltest um zu prüfen ob mit dem avr-gcc alles OK ist.
MfG,
SlyD
hi SlyD,
ist unterwegs...Zitat:
Zitat von SlyD
die antwort auf ein make im terminal ist die gleiche - ich wüsste zu gerne welche "regel" er da sucht...Zitat:
Zitat von SlyD
den ordner für diesen test schicke ich auch...Code:-------- begin --------
avr-gcc (GCC) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
make: *** Keine Regel vorhanden, um das Target »RP6Base_SELFTEST.elf«,
benötigt von »elf«, zu erstellen. Schluss.
georg@netzserver:~/workspace/RP6_selftest$
Naja das kann so natürlich nicht funktionieren (wenn das exakt die Ordnerstruktur ist die Du verwendest).
Den Ordner 2012_lib_komplett hast Du gar nicht ins makefile eingetragen.
(make ist absichtlich dumm gehalten, Du musst dem Tool ALLES explizit mitteilen damit eindeutig klar ist welche Dateien genommen werden sollen)
Und die Unterordner der RP6Lib sind ja komplett entfernt und alles in einen Ordner gepackt worden (warum?).
Aber dann muss man auch die Pfade im makefile entsprechend anpassen.
Das mit dem Selftest kann aus demselben Grund nicht funktionieren - Du hast nicht mehr die Ordnerstruktur aus den Beispielprogrammen - dann kann das makefile was dabei ist nicht funktionieren.
Mit "mit den orginalen Beispielen probieren" meinte ich: Archiv entpacken und alles genau so lassen nicht einzelne Ordner da rauskopieren ;)
Die Lösung ist einfach: Pfade anpassen!
Dann läufts problemlos durch.Zitat:
RP6_LIB_PATH=../2012_lib_komplett
RP6_LIB_PATH_OTHERS= $(RP6_LIB_PATH)/RP6control $(RP6_LIB_PATH)/RP6common
SRC += $(RP6_LIB_PATH)/RP6ControlLib.c
SRC += $(RP6_LIB_PATH)/RP6uart.c
#SRC += $(RP6_LIB_PATH)/RP6common/RP6I2CslaveTWI.c
SRC += $(RP6_LIB_PATH)/RP6I2CmasterTWI.c
SRC += RP6Control_I2CMasterLib.c
SRC += RP6Control_MultiIOLib.c
SRC += RP6Control_OrientationLib.c
SRC += RP6Control_LFSBumperLib.c
SRC += $(RP6_LIB_PATH)/RP6ControlServoLib.c
MfG,
SlyD
- - - Aktualisiert - - -
PS:
Im makefile vom Selbsttest ist ein (eigentlich bereits bekannter) winzig kleiner bug drin: RP6Lib versus RP6lib funktioniert unter Linux nicht (Windows unterscheidet nicht zwischen Klein- und Großbuchstaben). Aber das war bei Dir nicht das Problem sondern das oben genannte.
Hast Dir da aber das einzige Programm aus allen Beispielen rausgepickt wo das der Fall ist bei allen anderen passts ;)
Den Bug wollte ich schonmal letztes Jahr korrigieren, aber hab wohl nicht mehr dran gedacht.
Hi SlyD,
auf der gleichen "höhe" der struktur ist auch ein ordner "RP6Lib", der auch die entsprechenden unterordner hat. Das habe ich, nach dem es mit meinem ordner "2012_lib_komplett" nicht funtioniert hat versucht. Habe ich bei dem vielen schreiben vergessen zu erwähnen...Zitat:
Zitat von SlyD
den pfad im makefile habe ich angepasst gehabt:Zitat:
Zitat von SlyD
- RP6_LIB_PATH=/2012_lib_komplett
- RP6_LIB_PATH=../2012_lib_komplett
- RP6_LIB_PATH=../../2012_lib_komplett
keine der drei varianten funktionierte...
weil es für code:blocks einfacher war...ansonsten s.o.Zitat:
Zitat von SlyD
was bedeutet eigentlich nun die fehlermeldung über die fehlende regel? Die kommt doch immer, egal wie ich die pfade gesetzt habe - und irgendeine version der pfade und der verzeichnisse hätte doch funktionieren müssen!?!Zitat:
Zitat von SlyD
Sind in dem RP6Lib Ordner denn auch die ganzen anderen Datei drin die da normalerweise nicht dabei sind (inka.c und der ganze MultiIO kram)?Zitat:
Zitat von inka
Du musst ALLE Ordner und wichtigen lib Dateien im makefile drin haben.
Wenn Du es auf ZWEI Ordner aufgeteilt hast, muss das entsprechend angepasst werden.
../ heisst ein Verzeichnis höher und ist hier richtig.Zitat:
den pfad im makefile habe ich angepasst gehabt:
- RP6_LIB_PATH=/2012_lib_komplett
- RP6_LIB_PATH=../2012_lib_komplett
- RP6_LIB_PATH=../../2012_lib_komplett
keine der drei varianten funktionierte...
Zwei Verzeichnisse höher passt natürlich nicht.
/ ist das Wurzelverzeichnis (quasi das "C:" von Linux)
Jede Datei muss über die Angaben im makefile gefunden werden können.Zitat:
was bedeutet eigentlich nun die fehlermeldung über die fehlende regel? Die kommt doch immer, egal wie ich die pfade gesetzt habe - und irgendeine version der pfade und der verzeichnisse hätte doch funktionieren müssen!?!
Wird auch nur eine einzige nicht gefunden, kommt die Fehlermeldung (ist ziemlich nichtssagend, ich weiss, k.a. warum da nicht mal jemand etwas bessere Fehlermeldungen eingebaut hat ;) ).
Du hast da scheinbar einiges auf zwei Ordner aufgeteilt (dein 2012_komplett Ordner und RP6Lib). Hast das aber nicht im makefile drin stehen.
Das ist auch das einzige Problem hier: Du hast nicht alle Pfade korrekt angegeben.
Wie gesagt - wenn ich das hier so wie oben schon gepostet ändere funktioniert es sofort.
Entpacke doch mal das Archiv das Du mir geschickt hast 1:1 irgendwo hin und passe nur das makefile genau so an wie ich oben geschrieben habe.
Dann sollte es eigentlich klappen.
MfG,
SlyD
hi SlyD,
es waren die pfade :-(Zitat:
Zitat von SlyD
nach der anpasssung der pfade auf:
################################################## #############################
# Specify relative path to RP6 library files here.
# für ein gemeinsames verzeichnis "../2012_lib_komplett"
RP6_LIB_PATH_OTHERS=../2012_lib_komplett
RP6_LIB_PATH=../2012_lib_komplett
################################################## #############################
und änderungen bei der einbindung der sourcedateien lief es dann. Muss zugeben, bin richtig erschrocken, als make zum erstenmal fehlerfrei durchlief...
die probleme bei code:blocks sind auch behoben, dort war es eine andere ursache. Nachdem ich das programm deinstalliert habe und eine neuere version installiert habe, meldete sich code:blocks beim ersten kompilieren mit "<bits/predef.h> missing", nach längerem googeln musste ich libc6-dev-i386 nachinstallieren und ein pfad beim compiler von code:blocks ändern...
so habe ich nun auch die möglichkeit die ergebnisse von code:blocks mit make zu überprüfen...
vielen dank noch einmal an beide: SlyS und Dirk für euere mühe und geduld...
@Dirk: ich habe Dir eine *.c und die dazugehörige hex geschickt: welche werte liefert bei Dir button1?
Ah sehr gut!
;)Zitat:
Muss zugeben, bin richtig erschrocken, als make zum erstenmal fehlerfrei durchlief...
MfG,
SlyD
@inka:
Du hast eine Mail.Zitat:
ich habe Dir eine *.c und die dazugehörige hex geschickt: welche werte liefert bei Dir button1?
@Dirk:
nachdem meine kompilier-umgebung nun wieder läuft bin ich die kalibriervorschrift mal durchgegangen. :-(
Wäre es nicht besser sich einen winkelstück (oder kugelgelenk mit klemmschraube) zu bauen mit dem man die verschiedenen lagen der minIMU simulieren kann ohne sich auf den boden legen zu müssen um auf dem RP6 der auf dem kopf steht die LCD abzulesen? Abgesehen davon dass man sehr aufpassen muss um den auch waagerecht zu halten!
@inka:
Prima, dass bei dir jetzt alles wieder läuft.
Ja, eine Testumgebung braucht man.
In der Appnote AN3192 von ST, S. 15, wird eine hölzerne (!!!) Plattform (ohne Nägel/Schrauben/Metallteile!) empfohlen, auf der ein nivellierter Teller gedreht werden kann. Zusätzlich gibt es noch einen Kippmechanismus für den Sensor auf dem Teller und eine zuverlässige Nordmarkierung.
Mir war das zu umständlich, so dass ich mitten in einem Raum (weit weg von Kabeln, Metallteilen, ...) einen ca. 1m hohen "Turm" aus Holzkisten, Plastikkisten o.ä. aufgebaut habe. Oben drauf der RP6, auf einer glatten Fläche (Folie o.ä.) manuell drehbar. Eine Kippvorrichtung habe ich nicht vorgesehen, weil die Kalibrierung ja nicht variable Winkel braucht (außer 90° Winkel, die man auch so hinkriegt).
Also: Du kannst das sehr aufwändig, aber auch eher einfach machen. Wichtig bei Eigenanfertigungen dafür: Nur Kleben, nicht verschrauben oder mit Metallwinkeln befestigen!
@Dirk,
ich habe mir eine kleine vorrichtung für die kalibrierung gebaut, aus kunststoff, würfelförmig, ein gewinde für die platinenbefestigung und drei durchgangsbohrungen für die befestigung des würfels in 3 achsen. So kann der RP6 stehen bleiben und nur die platine wird jeweils gedreht. Befestigung mit messingschrauben. Schicke demnächst ein foto...
frage: bei der einstellung des beschleunigungsmessers und des magnetometers ist die rede von "negativem maximalwert". Wenn ich messe "-43" und "-173" ist der negativer maximalwert "-43", oder?
@inka:
Wow, klingt gut. Ich schicke dir meinen RP6 zum Kalibrieren! ;)
Ja, MAX wäre dann -43 und MIN -173.Zitat:
Wenn ich messe "-43" und "-173" ist der negativer maximalwert "-43", oder?
@Dirk:
kann man den das in der anleitung nicht irgendwie userfreundlicher formulieren? Mann könte doch von dem
kleinsten absoluten wert mit einem "-" zeichen versehen
sprechen?
Vielleicht bin ich komisch, das würde ich aber auf anhieb verstehen...
Hi inka,
Ok.Zitat:
Mann könte doch von dem
kleinsten absoluten wert mit einem "-" zeichen versehen
sprechen?
Wie könnte man das in der Anleitung besser formulieren?
Drehen Sie den RP6 mehrmals um 360 um die Z Achse und notieren Sie den kleinsten absoluten Wert der mit einem "-" versehen ist ( den grösten negativen Wert)??
Aber:
Es können ja 3 Fälle auftreten:
MIN <-> MAX
-173 <-> -43 (beide Werte negativ)
-14 <-> +56 (ein Wert negativ, ein Wert positiv)
123 <-> 346 (beide Werte positiv)
Wie kann man das eindeutig beschreiben?
Eigentlich sind die Begriffe Minimal- und Maximalwert da ziemlich eindeutig. Oder?
Du hast ja recht...
ein anders problem: ich habe nun mit meiner vorrichtung werte aufgenommen, problem habe ich - ich habs schon fast erwartet - beim magnetometer, da werden die "maximalen negativ-werte" garnicht negativ:
Code:// L3GD20 gyroscope calibration data:
#define MAX_X 20000 // Max. X-axis value
#define MIN_X -20000 // Min. X-axis value
#define OFFSET_X 3625 // Offset X-axis
#define MAX_Y 20000 // Max. Y-axis value
#define MIN_Y -20000 // Min. Y-axis value
#define OFFSET_Y 375 // Offset Y-axis
#define MAX_Z 20000 // Max. Z-axis value
#define MIN_Z -20000 // Min. Z-axis value
#define OFFSET_Z 1065 // Offset Z-axis
// L3GD20 temperature sensor definitions:
//#define GET_TEMP // Use temperature sensor
//#define OFFSET_TEMP 0 // Temperature offset [°C]
// LSM303DLHC accelerometer:
#define I2C_MULTIIO_LSM303DLHC_A_ADR 0x32 // Default
// LSM303DLHC accelerometer calibration data:
#define MAX_X_A -100 // Max. X-axis value 1019
#define MIN_X_A -1024 // Min. X-axis value -1057
#define MAX_Y_A -106 // Max. Y-axis value 1029
#define MIN_Y_A -1013 // Min. Y-axis value -1064
#define MAX_Z_A 1041 // Max. Z-axis value 965
#define MIN_Z_A 950 // Min. Z-axis value -1057
#define OFFSET_PITCH_A 0.0 // Offset Pitch [°]
#define OFFSET_ROLL_A 0.0 // Offset Roll [°]
// LSM303DLHC magnetometer:
#define I2C_MULTIIO_LSM303DLHC_M_ADR 0x3c // Default
// LSM303DLHC magnetometer calibration data:
#define MAX_X_M 533.0 // Max. X-axis value 420.0
#define MIN_X_M 25.0 // Min. X-axis value -94.0
#define OFFSET_X_M 0 // Hard iron X-axis offset
#define MAX_Y_M 258.0 // Max. Y-axis value 341.0
#define MIN_Y_M -2.0 // Min. Y-axis value -125.0
#define OFFSET_Y_M 0 // Hard iron Y-axis offset
#define MAX_Z_M 128.0 // Max. Z-axis value 467.0
#define MIN_Z_M -5.0 // Min. Z-axis value -30.0
#define OFFSET_Z_M 0 // Hard iron Z-axis offset
#define DECLINATION_M 0.0 // E at local position [°]
in der praxis äußert sich das so, dass der RP6 "grob" richtung NORD steht, zeigt WEST an und beim drehen ist der bereich zwischen N und S ca. 90 °, die restlichen 270 grad verteilen sich auf den rest...
Also ziemlich verschoben, und nun?
ich kann mich noch an den film "Die Schatzinsel" erinnern, wo ein gewisser captain Flint den schiffskompass mit einer drunter gelegten axt beeinflusst hat. Wo finde ich eine solche axt?
Ich möchte nun ein bischen mit den werten rumspielen: Kann man (unser guru?) zumindest andeuten welche von den gemessenen werten welche größe beeinflusst? Ich meine z.b. wenn ich den MAX_Y_M von 258 in -200 ändere verschiebt es die N-anzeige um 25° nach ost?
Hi inka,
Ja, wozu braucht man eigentlich den ganzen neumodischen Kram ... :)Zitat:
... "Die Schatzinsel" erinnern, wo ein gewisser captain Flint den schiffskompass mit einer drunter gelegten axt beeinflusst hat. Wo finde ich eine solche axt?
Zum Gyro:
Sieht gut aus. Der X-Offset scheint mir ein bissl hoch (oder lebst du auf einem Hausboot oder im schwankenden Hochhaus im 20.Stock)?
Zum Accelerometer:
Die Max-X, Max-Y und die Z-Werte sind nicht ok. Durch die Kalibrierung müßte jede Achse auf die volle Erdbeschleunigung zu kalibrieren sein. Das heißt:
Max und Min Werte sollten fast identisch im hohen 3-stelligen bis niedrigen 4-stelligen Bereich sein bis auf das Vorzeichen, das bei Min ein "-" ist und bei Max ein "+".
Typische Werte also z.B. bei allen Achsen:
MIN <-> MAX
-1100 <-> +1045
-967 <-> +1012
Woran kanns liegen?
Die Achsen zeigen evtl. bei der Kalibrierung nicht genau Richtung Erdmittelpunkt (Max-Werte) bzw. genau von ihm weg (Min-Werte).
Zum Magnetometer:
Die Min-Werte scheinen mir etwas zu hoch und der Max-Z-Wert zu niedrig.
Woran kanns liegen? Magnetfeldeinflüsse? Metalle in der Nähe?
Wie hast du den Sensor angebracht? Wieviel Abstand hat er zur MultiIO bzw. zum RP6? Stimmen die Sensorachsen mit denen des RP6 überein?
... vielleicht klappt das dann ohne die Axt ... ;)
nein, erster stock, nicht schwankend. Ich habe probeweise der X-offset auf etwa die hälfte (1625) verringert, die anzeige des X-gyro-wertes schnellte sofort um fast 2000 hoch, die anderen bewegen sich im bereich +/- 10 um null herumZitat:
Zitat von Dirk
also lasse ich es erstmal...
ich habe die werte probehalber geändert:Zitat:
Zitat von Dirk
die aufteilung auf die 360° ist besser, N ist noch um ca. 90° cw versetzt (bei der anzeige case3, also eigentlich magnetometer)...Code:// LSM303DLHC accelerometer:
#define I2C_MULTIIO_LSM303DLHC_A_ADR 0x32 // Default
// LSM303DLHC accelerometer calibration data:
#define MAX_X_A 1000 // Max. X-axis value 1019 -100
#define MIN_X_A -1024 // Min. X-axis value -1057
#define MAX_Y_A 1060 // Max. Y-axis value 1029 -106
#define MIN_Y_A -1013 // Min. Y-axis value -1064
#define MAX_Z_A 1041 // Max. Z-axis value
#define MIN_Z_A -950 // Min. Z-axis value -1057 950
#define OFFSET_PITCH_A 0.0 // Offset Pitch [°]
#define OFFSET_ROLL_A 0.0 // Offset Roll [°]
der sensor ist hinten, die befestigungsschraube der Multi_IO neben der sicherung habe ich durch eine messingsäule (conrad) ersetzt, höhe zu platine ca 70mm, die bestückung des sensors ist unten (richtung RP6), die anschlusspins liegen in fahrtrichtung vorne...Zitat:
Zitat von Dirk
frage:
wenn ich die normalize-funktion auskommentiere, kümmert sich das kalibrierprogramm um die (noch alten) eingetragenen Offset-werte (alle drei sensoren), oder werden diese angaben ignoriert?
Hi inka,
du willst es jetzt aber wissen.
Ok. Das sollte aber auch problemlos zu kalibrieren sein!Zitat:
(Zum Accelerometer: ) ...ich habe die werte probehalber geändert:
Mach es doch so, dass du z.B. den RP6 in der Hand hältst und auf die rechte Seite neigst. Beobachte dabei den X-Wert und kippe den RP6 so lange in der Rechts-Seitenlage umher, bis der X-Wert maximal wird. ACHTUNG: Lies erst weiter unten den Text zur Ausrichtung des Sensors, die bei dir anders ist, sonst hast du ganz andere Achsen als ich!!
Die Werte des Accelerometers nehmen NUR Einfluss auf das TILT COMPENSATED Heading (Neigungs-kompensierte Richtung,- das ist der Wert in der 2. Zeile hinter "C" der Magnetometer-Ausgabe). Wenn die Richtungsangaben "versetzt" sind, kann das NUR am Magnetometer liegen.Zitat:
die aufteilung auf die 360° ist besser, N ist noch um ca. 90° cw versetzt (bei der anzeige case3, also eigentlich magnetometer)...
1. Die Höhe ist ok, ich würde aber eher Plastikabstandhalter und eine Plastikschraube nehmen. Müßte aber auch mit den Messing-Dingern klappen, wenn da kein Eisenanteil drin ist.Zitat:
der sensor ist hinten, die befestigungsschraube der Multi_IO neben der sicherung habe ich durch eine messingsäule (conrad) ersetzt, höhe zu platine ca 70mm, die bestückung des sensors ist unten (richtung RP6), die anschlusspins liegen in fahrtrichtung vorne...
2. Bestückung des Sensors nach UNTEN ist ok.
3. Anschlusspins in Fahrtrichtung vorn: Die Lib ist so geschrieben, dass die Anschlußpins der minIMU-9 v2 (hast du genau die auch??) in Fahrtrichtung RECHTS sind. Schaut man also von oben in Fahrtrichtung des RP6 (man steht also hinter dem RP6) auf den Sensor, dann kann man die Beschriftung aufrecht lesen, SDA/SCL sind rechts und die Y-Achsen-Beschriftung zeigt nach vorn, die der X-Achse nach links.
Die Normalize-Funktionen können immer drin bleiben, müssen also auch beim Kalibrieren nicht auskommentiert werden.Zitat:
frage: 1) wenn ich die normalize-funktion auskommentiere, kümmert sich das kalibrierprogramm um die (noch alten) eingetragenen Offset-werte (alle drei sensoren), oder werden diese angaben ignoriert?
Nachdem du die Kalibrierungs-Werte ermittelt und in der RP6Control_Orientation.h geändert hast, muss das Programm neu kompiliert werden. Vorher unbedingt die .st und .o Dateien der Orientation-Lib löschen! Dann kannst du erst prüfen, ob deine Kalibrierung gelungen ist. Wenn nicht, müßtest du sie wiederholen.
In der 2. LCD-Zeile der Anzeige für das Magnetometer erscheint ja ein "H" für Heading, dahinter die Gradzahl und daneben die Grobrichtung als Buchstabe (N, SE, W ...). Dahinter erscheint das "C" für Tilt compensated Heading mit der Gradzahl, daneben wieder die Grobrichtung.Zitat:
frage: 2) in der magnetometeranzeige - die einzige, in der ich beim drehen des RP6 eine richtungsänderung erkenne - wird diese nur grob in himmelsrichtungen angezeigt. Wie müsste ich diese anzeige/den code verändern um beim drehen des RP6 zahlen zu sehen (N=0, E=90,....)? Dann hätte ein weiteres experimetieren mit willkürlichen änderungen an den offsets noch eine aussicht auf erfolg....Zumindest verspreche ich mir davon eine etwas genauere erkenntnis über abhängigkeiten...
Da ist doch alles drin, oder?
- - - Aktualisiert - - -
Noch ne Ergänzung:
1. Die Ausgabe aller Werte auf dem LCD in der Demo liegt ja daran, dass das GPS-Modul den UART braucht. Wenn du NUR die minIMU testen willst, sende doch die Werte an das Terminal, da sind sie besser zu erkennen und zu beschriften.
2. Da der Gyro-Test erstmal nicht gebraucht wird, kommentier ihn doch in der Demo 05 aus, dann gibt es schon mal 1 Anzeige weniger.
Hi Dirk,
die frage hätte ich schon viel früher stellen sollen, ich hatte da was in erinnerung von der HDMM, dort hatte ich die anschlüsse vorne. Ist evtl. im RN-artikel ein bild auf dem man die lage der minIMU erkennen kann? Konnte jetzt keinen finden...Zitat:
Zitat von Dirk
jetzt passen auch in etwa die ausgaben! Ich habe jetzt den RP6 auf einen holzdrehteller gestellt:Zitat:
Zitat von Dirk
wenn ich ihn jetzt mit der frontseite in richtung N ausrichte und dann so drehe, als das das heck richtung N zeigt, wird im LCD nicht 180° sondern 192° angezeigt. Muss man damit leben, oder noch einmal kalibrieren? Hast Du mal mit Deinem so etwas getestet?
hast Du nicht mal sowas geschrieben?Zitat:
Zitat von Dirk
Zitat:
Zu 2:
Wichtig ist, dass du dir die ROHWERTE, die der Sensor direkt ausgibt, ansiehst. Für den Gyro wären das also die Werte, die die Funktion readL3GD20() ausgibt. Wenn die Werte erst durch die Normalisierungsfunktion normalizeL3GD20() gejagt sind, kannst du sie für die Kalibrierung nicht mehr verwenden, weil die Normalisierungsfunktion ja genau die von dir angegebenen Kalibrierungswerte nutzt, um die Rohwerte anzupassen.
habe ich vor lauter kalibrieren übersehen :-)Zitat:
Zitat von Dirk
Hi inka,
klingt so, als wenn du inzwischen Land siehst.
Stimmt. Es gibt in der Lib nur die Lagebeschreibungen der Sensoren in den Funktionen headingHDMM01() für den HDMM01 und headingLSM303DLHC_M() für die MinIMU-9 v2.Zitat:
Ist evtl. im RN-artikel ein bild auf dem man die lage der minIMU erkennen kann? Konnte jetzt keinen finden...
Ich werde die Lage noch in RN-Wissen übernehmen.
Nein, das ist zuviel. Eine absolute Abweichung von 3-4° ist ok. Die kann man noch etwas durch die Declination (Mißweisung) verbessern.Zitat:
das heck richtung N zeigt, wird im LCD nicht 180° sondern 192° angezeigt. Muss man damit leben, oder noch einmal kalibrieren?
Auf welchen Wert beziehst du dich? H oder C?
Ja. Meine Schuld. Damals hatte ich noch normalize-Funktionen, die man zum Kalibrieren weglassen mußte. Das hat sich jetzt geändert (weil zu fehlerträchtig). Im RN-Wissen habe ich das dann auch schon rausgenommen.Zitat:
(Die Normalize-Funktionen können immer drin bleiben, müssen also auch beim Kalibrieren nicht auskommentiert werden.) ... hast Du nicht mal sowas geschrieben?
Es hat aber auch nicht geschadet, wenn du sie fürs Kalibrieren auskommentiert hast: Das Kalibrieren funktioniert trotzdem.
Hi Dirk,
Ja, dank Deiner hilfe...Zitat:
Zitat von Dirk
habe Dir zwei fotos geschickt, auch die kalibriervorrichtung, vielleicht kanns Du damit was anfangen...Zitat:
Zitat von Dirk
hab es mit änderungen an den kalibrierdaten auf ca. 2° runterbekommen...Zitat:
Zitat von Dirk
edit: - die H und C werte sind bei mir identisch...
wie unterscheidet der RP6, bzw. die IO platine ob ich kalibrieren oder mormal messen will (ich denke hier z.b. an die demo_05)?Zitat:
Zitat von Dirk
Hi inka,
Gar nicht. Die angezeigten X/Y/Z-Werte sind immer die Rohwerte aus dem Sensor.Zitat:
wie unterscheidet der RP6, bzw. die IO platine ob ich kalibrieren oder mormal messen will (ich denke hier z.b. an die demo_05)?
Die kalibrierten X/Y/Z-Werte werden in der Demo 05 nicht angezeigt.
Jetzt habe ich auch die Ausrichtung der minIMU-9 v2 und des HDMM01 auf dem RP6 im RN-Wissen-Artikel dargestellt: Klick!
Hi Dirk,
ich habe diesen code nun weitgehends aus der demo_05 rauskopiert:Zitat:
Zitat von Dirk
Fragen:Code:void magnetometer(void) // LSM303DLHC magnetometer
{
mSleep(1000);
task_I2CTWI();
readLSM303DLHC_M(); // Get sensor values
task_I2CTWI();
setCursorPosLCD(0, 0); // line 1
writeStringLCD_P("X");
writeIntegerLCD(x_axism, DEC);
writeStringLCD_P(" ");
setCursorPosLCD(0, 5); // line 1 pos 6
writeStringLCD_P("Y");
writeIntegerLCD(y_axism, DEC);
writeStringLCD_P(" ");
setCursorPosLCD(0, 10); // line 1 pos 11
#ifndef GET_TEMP_M
writeStringLCD_P(" Z");
writeIntegerLCD(z_axism, DEC);
writeStringLCD_P(" ");
#else
temperature_imu = (double) temperaturem / 8.0 + OFFSET_TEMP_M;
writeStringLCD_P("T");
writeDoubleLCD(temperature_imu, 5, 1);
#endif
normalizeLSM303DLHC_M(); // Normalize data
headingm = headingLSM303DLHC_M(); // Calculate heading
calculateDir(dir, headingm);
setCursorPosLCD(1, 0); // line 2
writeStringLCD_P("H");
writeIntegerLengthLCD(headingm, DEC, 3);
writeStringLCD_P(" ");
writeStringLCD(dir);
headingtc = headingLSM303DLHC_TC(); // Calculate TILT COMPENSATED
calculateDir(dir, headingtc); // heading
writeStringLCD_P(" C");
writeIntegerLengthLCD(headingtc, DEC, 3);
writeStringLCD_P(" ");
writeStringLCD(dir);
writeStringLCD_P(" ");
mSleep(1000);
// clearLCD();
task_I2CTWI();
}
1) sind die werte, die hier auf dem LCD-display angezeigt werden nun die rohwerte oder die normalisierten werte?
2) da nach dem was oben steht das normalisieren in der "RP6Control_MultiIO_05.c" nicht mehr stattfindet, was bedeutet die zeile
--------------------------------------
#ifdef IMU_9D
// 9D-IMU test:
// L3GD20 gyroscope:
task_I2CTWI();
readL3GD20(); // Get sensor values
normalizeL3GD20();
----------------------------------
????
super...Zitat:
Zitat von Dirk
was sagst Du zu meinem kalibrierwürfel?
Hi inka,
Die Rohwerte.Zitat:
1) sind die werte, die hier auf dem LCD-display angezeigt werden nun die rohwerte oder die normalisierten werte?
Wenn du etwas in die Lib reingucken willst: Die Variablen "x_axis?" sind die X-Rohwerte. Wenn das "?" gleich "g" ist (also x_axisg), sind das die Rohwerte des Gyro, bei "a" die des Accelerometers und bei "m" die des Magnetometers.
Das bleiben auch nach der Kalibrierung die Rohwerte.
Wenn du die kalibrierten X/Y/Z-Werte ansehen willst, dann sind das die Variablen xg, yg, zg (Gyro), xa, ya, za (Accelerometer), xm, ym, zm (Magnetometer). Diese Werte werden von der jeweiligen normalize-Funktion ausgespuckt.
Warum findet kein Normalisieren mehr statt? Für jeden der 3 minIMU-Sensorern gibt es doch eine Normalisierungsfunktion. Ohne diese Funktionen würden die Kalibrierungswerte nicht genutzt.Zitat:
2) da nach dem was oben steht das normalisieren in der "RP6Control_MultiIO_05.c" nicht mehr stattfindet, was bedeutet die zeile normalizeL3GD20();
Genial. Da fällt das Kalibrieren leicht und man kann ja den Würfel auch nach dem Kalibrieren drinlassen, um die Anpassung an die RP6-Achsen zu machen.Zitat:
was sagst Du zu meinem kalibrierwürfel?
Klasse. :)
Hi Dirk,
das heisst ich muss im prinzip beim kalibrieren beide variablen ausgeben/sehen: x_axism und xm. Die x_axis_m messe ich zunächst, verändere (kalibriere) sie durch eintragen von MAX_X_M (und MIN_X_M) und nach erneutem kompilieren kann ich das ergebnis in xm erst sehen?Zitat:
Zitat von Dirk
um auf Deine frage aus der mail einzugehen: der würfel ist aus PVC, kantenlänge 10mm. Die drei sich kreuzenden 3mm löcher hätten etwas näher an die gemeinsame ecke sein können, in einer der drei positionen beim kalibrieren war es zu der 6kantstange etwas eng...Zitat:
Zitat von Dirk
Hi inka,
Exakt.Zitat:
das heisst ich muss im prinzip beim kalibrieren beide variablen ausgeben/sehen: x_axism und xm. Die x_axis_m messe ich zunächst, verändere (kalibriere) sie durch eintragen von MAX_X_M (und MIN_X_M) und nach erneutem kompilieren kann ich das ergebnis in xm erst sehen?
Nur eine kleine Ergänzung: Zum Kalibrieren brauchst du nur die Rohwerte. Nach dem Kalibrieren und Neukompilieren kann mit den kalibrierten Werten zuverlässig Pitch, Roll, Heading, TC-Heading berechnet werden.
Also:
Mit den X/Y/Z-Werten (roh oder kalibriert) kann man ja eigentlich wenig anfangen.
Beim Accelerometer errechnet man daraus Pitch und Roll,
beim Magnetometer die Richtung und aus beiden die neigungskompensierte Richtung.
Mehr wird da draus nicht.
Der einzige Sensor, bei dem man i.d.R. mit den X/Y/Z-Werten weiter rechnet, ist der Gyro.
Hi Dirk,
ich habe den code für den gyro um die ausgabe der normalisierten werte ergänzt, die funktion sieht jetzt so aus:
ich habe Deine erklärungen so verstanden, dass die normalisierten werte sich durch die normalisierung von den rohwerten unterscheiden, in der ausgabe dieser funktion sind beide zeilen gleich, oben die rohwerte (x_axisg) unten die normalisierten (xg). Da ist doch irgendwas falsch, oder?Code:void gyroscope(void) // L3GD20 gyroscope
{
mSleep(1000);
task_I2CTWI();
readL3GD20(); // Get sensor values
normalizeL3GD20();
task_I2CTWI();
clearLCD();
setCursorPosLCD(0, 0); // line 1
writeStringLCD_P("X");
writeIntegerLCD(x_axisg, DEC);
setCursorPosLCD(0, 6); // line 1 pos 6
writeStringLCD_P("Y");
writeIntegerLCD(y_axisg, DEC);
setCursorPosLCD(0, 12); // line1 pos 12
writeStringLCD_P("Z");
writeIntegerLCD(z_axisg, DEC);
setCursorPosLCD(1, 0); // line 2
writeStringLCD_P("X");
writeIntegerLCD(xg, DEC);
setCursorPosLCD(1, 6); // line 2 pos 6
writeStringLCD_P("Y");
writeIntegerLCD(yg, DEC);
setCursorPosLCD(1, 12); // line 2 pos 12
writeStringLCD_P("Z");
writeIntegerLCD(zg, DEC);
#ifdef GET_TEMP
temperatureg = calcTempL3GD20(temperatureg) + 5;
temperatureg += OFFSET_TEMP;
setCursorPosLCD(1, 8); // line 2 pos 9
writeStringLCD_P("T");
writeIntegerLCD(temperatureg, DEC);
writeStringLCD_P(" ");
#endif
mSleep(2000);//3 sec
clearLCD();
task_I2CTWI();
}
Die Variablen xg, yg und zg sind Floating Points.
Du müßtest also die Funktion writeDoubleLCD() zur Ausgabe nehmen.
Das passt dann kaum noch aufs LCD: Ich würde die Werte über das Terminal ausgeben.
ok, habe nun den code etwas verändert:
Code:// setCursorPosLCD(1, 0); // line 2
// writeStringLCD_P("X");
writeString_P("x: ");
writeDouble(xg, 5, 5);
writeString_P("\n");
im terminal wird der wert der xg-variablen jetzt ausgegeben, ist aber immer noch identisch mit x_axis_g, nur mit angehängten 5 nullen hinterm koma...
ob die zwei zahlen 5, 5 nun passend sind weiss ich nicht so genau, auch bei 1, 1 verändert sich nur die zahl der nullen...
irgendwie habe ich erwartet, dass der unterschied zwischen x_axis_g und xg signifikanter ist?
Hi inka,
du bist ja da beim Gyro:
Die "Normalisierung" geschieht in der Funktion normalizeL3GD20() zum einen durch eine Begrenzung der Werte nach oben/unten auf 20000/-20000.
Zum anderen wird ein OFFSET addiert (OFFSET_X/Y/Z).
Nach der Normalisierung werden sich die kalibrierten Werte (xg, yg, zg) nicht von den Rohwerten (x_axisg, y_axisg, z_axisg) unterscheiden.
@Dirk,
die sache mit dem "make" und den "strukturen" scheine ich jetzt verstanden zu haben. Die kalibrierung des gyro mit der "demo_05_02" hat auch einigermassen geklapt, jetzt möchte ich weitermachen mit accelerometer und magnetometer.
Dieser code hier (als beispiel für den accelerometer):
sollte das "normalize" nun auskommentiert werden, oder nicht? Wie ist der letzter stand in der lib?Code:#ifdef IMU_9D
// LSM303DLHC accelerometer:
task_I2CTWI();
readLSM303DLHC_A(); // Get sensor values
task_I2CTWI();
setCursorPosLCD(0, 0); // line 1
writeStringLCD_P("X");
writeIntegerLCD(x_axisa, DEC);
writeStringLCD_P(" ");
setCursorPosLCD(0, 5); // line 1 pos 6
writeStringLCD_P("Y");
writeIntegerLCD(y_axisa, DEC);
writeStringLCD_P(" ");
setCursorPosLCD(0, 10); // line 1 pos 11
writeStringLCD_P(" Z");
writeIntegerLCD(z_axisa, DEC);
writeStringLCD_P(" ");
normalizeLSM303DLHC_A(); // Normalize data
positionLSM303DLHC_A(); // Calculate position
setCursorPosLCD(1, 0); // line 2
writeStringLCD_P("P");
writeDoubleLCD(pitch, 6, 1);
writeStringLCD_P(" ");
setCursorPosLCD(1, 8); // line 2 pos 9
writeStringLCD_P("R");
writeDoubleLCD(roll, 6, 1);
writeStringLCD_P(" ");
task_I2CTWI();
mSleep(1000);
clearLCD();
#endif
btw: meine kalibriervorrichtung, auf die ich soo stolz war taugt nicht viel. habe festgestellt, dass beim umschrauben 1° versatz reicht, um völlig andere werte zu bekommen. Eigentlich müsste man sich über eine genaue und zwar wiederholbar genaue befestigung der minIMU gedanken machen!
@inka:
Beschleunigungssensor:
In der Funktion normalizeLSM303DLHC_A() werden die X/Y/Z-Rohwerte nur begrenzt. Außerdem erfolgt die Ausgabe in der Demo ja VOR Aufruf der normalizeLSM303DLHC_A()-Funktion, so dass du sie ruhig drin lassen kannst.
Aber: Pitch und Roll werden NACH Normalisierung berechnet, also aus den begrenzten Rohwerten.
Magnetfeldsensor:
Auch hier werden die Rohwerte in der Demo VOR der Normalisierungsfunktion ausgegeben, so dass sie unverändert sind.
Aber: Die Berechnung der Richtung erfolgt dann mit den normalisierten Rohwerten.
@Dirk:
ich kämpfe immer noch mit dem begriff "negativer Maximalwert". Beim kalibrieren des magnetometers waren diese negativen maximalwerte werte alle drei (X,Y und Z) nahe null, oder sogar gleicn null. Die "negativen Minimalwerte" entsprachen in ihrem absolutwert aber in etwa dem absoluten wert der "positiven Maximalwerte". Irgendwie würde ich dazu tendieren für das "nullen" eines sensors die jeweils maximalen "ausschläge" in positiver wie auch negativer richtung zu verwenden. Gibt es eine allgemeinverständliche erklärung dafür, dass es hier anders ist?
@inka:
Möglicherweise habe ich mich nicht mathematisch korrekt ausgedrückt:
Zur Kalibrierung wird der jeweils größte (MAX) und jeweils kleinste Wert (MIN) benötigt.
Beispiele:
a) -20 -14 -8 +2 +23 +177
==> MIN = -20 und MAX = +177
b) +44 +56 +126 +1244 +2833
==> MIN = +44 und MAX = +2833
c) -2833 -574 -233 -88 -12
==> MIN = -2833 und MAX = -12
So klarer?