Problem mit Kompass Achsen (Mega644p + HMC5883L)

[Philipp M. (lord-maricek)]

Hallo,

für ein aktuelles Projekt haben wir uns Platinen ätzen lassen, auf dem 
Board sind ein HMC5883L und ein Mega644p, verbunden über I2C.
Zum testen habe ich es schematisch wie im Arduino Beispiel Code gemacht:
Hier http://www.sparkfun.com/products/10530 -> Documents -> Example Code
Benutzten tue ich außerdem die I2C Lib von Peter Fleury.

Wenn ich den Kompass drehe, zeigt er immer nur Werte von 280 Grad bis 
360 Grad an.
Hier ein paar Beispiele (immer um 90° weiter gedreht):
1.
Heading: 309
X: -9
Y: 11
Z: 6

2.
Heading: 351
X: -14
Y: 2
Z: 7

3.
Heading: 339
X: -27
Y: 10
Z: 7

4.
Heading: 325
X: -23
Y: 16
Z: 6

Das Heading berechne ich so:
angle = atan2((double)y,(double)x) * 180 / 3.14159265 + 180;

Hier der Code:
die Main.c (Hier werden die Funktionen nur ausgefürhrt, die I2c 
funktionen sind weiter unten)

#define F_CPU 20000000UL
#define BAUD 115200UL
#include <util/delay.h>
#include <avr/io.h>
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include "compass.h"

#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)
 
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
  #warning Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! 
#endif 

/*void delay_ms(double t)
{
  for(int i=0;i<t;i++)
  {
    _delay_ms(1);
  }
}*/

void uart_init(void)
{
  //UART0 
    UCSR0B |= (1<<RXEN0)|(1<<TXEN0)|(1<<RXCIE0);    
    UCSR0C |= (1<<UCSZ01)|(1<<UCSZ00);
 
    UBRR0H = UBRR_VAL >> 8;
    UBRR0L = UBRR_VAL & 0xFF;

  //UART1 
    UCSR1B |= (1<<RXEN1)|(1<<TXEN1)|(1<<RXCIE1);                      
    UCSR1C |= (1<<UCSZ11)|(1<<UCSZ10); 

  UBRR1H = UBRR_VAL >> 8;
  UBRR1L = UBRR_VAL & 0xFF;
}

int uart_putc(unsigned char c)
{
    while (!(UCSR0A & (1<<UDRE0)))
    ;                             
    UDR0 = c;
  
  while (!(UCSR1A & (1<<UDRE1)))
    ;                             
    UDR1 = c;                    
    return 0;
}

void uart_puts (char *s)
{
    while (*s)
    {
        uart_putc(*s);
        s++;
    }
}


int main(void)
{
  DDRB = 0xff;
  uart_init();
  delay_ms(100);
  char tmp = compass_init();
  if(tmp==0)
  {
    uart_puts("\ncompass init failed\n");  
  }
  else
  {
    uart_puts("\ncompass init\n");  
  }
  delay_ms(100);
      
    while(1)
    {
    PORTB = 0xff;
        int x,y,z;
    tmp = compass_get_axis(&x,&y,&z);
    if(tmp==0)
    {
      uart_puts("\ncompass read failed\n");
    }
    else
    {
      int angle= atan2((double)y,(double)x) * 180 / 3.14159265 + 180;
      char send[255];
      int n = sprintf(send,"\nNew Data:\nHeading: %d\nX: %d\nY: %d\nZ: %d\n",angle,x,y,z);
      for(int i=0;i<n;i++)
      {
        uart_putc((unsigned char)send[i]);
      }
    }
    PORTB = 0x00;
    delay_ms(3000);
    }
}

compass.h

#ifndef COMPASS_H_
#define COMPASS_H_

#include "i2cmaster.h"

#define COMPASS_READ 0x3D
#define COMPASS_WRITE 0x3C

void delay_ms(int t);
extern unsigned char compass_init(void);
extern unsigned char compass_get_axis(int * x,int * y, int * z);

#endif /* COMPASS_H_ */

compass.c

#include "compass.h"
#ifndef F_CPU
# warning "F_CPU not defined for compass.h"
# define F_CPU 1000000UL
#endif

#include <util/delay.h>
void delay_ms(int t)
{
  for(int i=0;i<t;i++)
  {
    _delay_ms(1);
  }
}

unsigned char compass_init(void)
{
  unsigned char tmp;
  i2c_init();
  _delay_ms(10);
  tmp = i2c_start(COMPASS_WRITE);
  if(tmp!=0)
  {
    i2c_stop();
    return 0;
  }
  tmp = i2c_write(0x02);
  if(tmp!=0)
  {
    i2c_stop();
    return 0;
  }
  tmp = i2c_write(0x00);
  if(tmp!=0)
  {
    i2c_stop();
    return 0;
  }
  i2c_stop();
  return 1;
}


unsigned char compass_get_axis(int * x,int * y, int * z)
{
  unsigned char tmp;
  tmp = i2c_start(COMPASS_WRITE);
  if(tmp!=0)
  {
    i2c_stop();
    return 0;
  }
  tmp = i2c_write(0x03);
  if(tmp!=0)
  {
    i2c_stop();
    return 0;
  }
    
  tmp =i2c_rep_start(COMPASS_READ);
  if(tmp!=0)
  {
    i2c_stop();
    return 0;
  }
  
  *x = i2c_readAck()<<8;
  *x |= i2c_readAck();
  
  *z = i2c_readAck()<<8;
  *z |= i2c_readAck();
  
  *y = i2c_readAck()<<8;
  *y |= i2c_readNak();
    
  i2c_stop();  
  return 1;  
}

Das Programm ist nur so zum testen zusammen gefuscht.
In der compass_init(), wird lediglich das Register 0x02 auf 0x00 
gesetzt, für den Continuous-measurement mode mit 15Hz (default).
Die compass_get_axis(...) wird alle 3 Sekunden ausgeführt, also das 
passt locker mit 15Hz. In der Funktion wird erst der Register Indexer 
auf 0x03 gesetzt und ab da dann 8 Bytes ausgelesen und in Varibalen 
gespeichert.

Aber irgentwie passt das mit den Werten alles nicht.
habt ihr ne Idee was falsch sein könnte? Wie gesagt habe ich das alles 
nur aus nem Arduino Beispielcode und sollte eigentlich Funtzten.

Danke schon mal im voraus.

MfG
Philipp

[olf79 (Gast)]

wie ist i2c_readAck deklariert?

wenn nur ein 8-Bit-Wert zurückgegeben wird (so sieht es aus), schieb man 
den beim shiften ohne Typecast ins Nirvana..
*x = i2c_readAck()<<8;

Ich würde mal
*x = ((int)i2c_readAck())<<8;
probieren..

[olf79 (Gast)]

.. und die Endianess berücksichtigen .. also ggf. muss der Wert 
andersrum zusammengesetzt werden, erst das LowByte, dann das HighByte..

[olf79 (Gast)]

oder vielleicht so:

unsigned char *pbyte;

pbyte = x;

*pbyte     = i2c_readAck();
*(pbyte+1) = i2c_readAck();

oder halt

*(pbyte+1) = i2c_readAck();
*pbyte     = i2c_readAck();


dann das gleiche mit z und y

[Philipp M. (lord-maricek)]

Moin,

Hier die Funktionen:

unsigned char i2c_readAck(void)
{
  TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWEA);
  while(!(TWCR & (1<<TWINT)));    

    return TWDR;

}/* i2c_readAck */

unsigned char i2c_readNak(void)
{
  TWCR = (1<<TWINT) | (1<<TWEN);
  while(!(TWCR & (1<<TWINT)));
  
    return TWDR;

}/* i2c_readNak */

Der Typecast funktioniert auch nicht.

Hier ein Auszug ausm Datenblatt:

Address Location Name Access
00
Configuration Register A
Read/Write
01
Configuration Register B
Read/Write
02
Mode Register
Read/Write
03
Data Output X MSB Register
Read
04
Data Output X LSB Register
Read
05
Data Output Z MSB Register
Read
06
Data Output Z LSB Register
Read
07
Data Output Y MSB Register
Read
08
Data Output Y LSB Register
Read
09
Status Register
Read
10
Identification Register A
Read
11
Identification Register B
Read
12
Identification Register C
Read

Zuerst kommt MSB dann LSB.

MfG
Philipp

[Philipp M. (lord-maricek)]

unsigned char *pByte;
  pByte = x;
  *(pByte+1) = i2c_readAck();
  *pByte = i2c_readAck();
  
  pByte = z;
  *(pByte+1) = i2c_readAck();
  *pByte = i2c_readAck();
  
  pByte = y;
  *(pByte+1) = i2c_readAck();
  *pByte = i2c_readAck();

So isses wieder wie vorher, andersherum, sehen sind die Achsen schon im 
Tausender Bereich, so wies sein soll, aber ein vernünftiges Heading 
bekommen wir trotzdem immer noch nicht raus.

MfG
Philipp

[Interpreter (Gast)]

Philipp Maricek schrieb:
> Hier ein Auszug ausm Datenblatt:
> 00
> Configuration Register A
>...

Mit dem unformatierten Zeugs meinst du wahrscheinlich:

Address Location Name           Access
00  Configuration Register A    Read/Write
01  Configuration Register B    Read/Write
02  Mode Register               Read/Write
03  Data Output X MSB Register  Read
04  Data Output X LSB Register  Read
05  Data Output Z MSB Register  Read
06  Data Output Z LSB Register  Read
07  Data Output Y MSB Register  Read
08  Data Output Y LSB Register  Read
09  Status Register             Read
10  Identification Register A   Read
11  Identification Register B   Read
12  Identification Register C   Read

[Wolfgang H. (Firma: AknF) (wolfgang_horn)]

Hi, Philipp,

> Wenn ich den Kompass drehe, zeigt er immer nur Werte von 280 Grad bis
> 360 Grad an.

Das ist typisches Symptom für Fehlkalibrierung: Der Sensor misst nicht 
nur das geomagnetische Feld, sondern auch die magnetischen Felder, die 
von magnetischen Remanenzen in Stahl und Eisen erzeugt werden sowie von 
elektrischen Strömen.

Mancher Autofahrer kauft sich einen neckischen Kompass und wundert sich, 
dass das Einschalten der Heckscheibenheizung den Nordpol ferngesteuert 
springen, und der Nordwert mit dem Gas einstellen lässt.

Dagegen hilft:
1. Stationäre Kalibrierfehler: Neukalibrierung mitsamt der gesamten 
mobilen Plattform (für die häufigsten Fälle siehe Anhang).
2. Nicht-stationäre Fehler durch veränderliche Stromflüsse auf der 
Platine: Außerordentlich problematisch. Ansatz zur Minimierung: Sensor 
zur Messung eines solchen Stromflusses, dann dessen Beitrag aus den X-, 
Y- und Z-Komponente heraus rechnen.

Nicht ohne Grund werden Kompasse in Flugzeugen und Schiffen in extremen 
Positionen montiert, von tief im Kiel bis zum Ende der Tragfläche.

Ciao
Wolfgang Horn

[Wolfgang H. (Firma: AknF) (wolfgang_horn)]

Hi, Philipp, zweiter Punkt.

> Das Heading berechne ich so:
> angle = atan2((double)y,(double)x) * 180 / 3.14159265 + 180;

Deine Formel ist schön einfach. Ich hatte für denselben Zweck eine mit 
Fallunterscheidungen, je nach Quadranten habe ich die Vorzeichen 
gewechselt.

Ciao
Wolfgang Horn

[Michael A. (Gast)]

Philipp Maricek schrieb:
> Hier ein paar Beispiele (immer um 90° weiter gedreht):
> 1.
> Heading: 309
> X: -9
> Y: 11
> Z: 6
> ...

Bei deinen Y-Werten ist die Verstärkung im Vergleich zu X fast einen 
Faktor 2 zu niedrig und du hast Offsets von x0=-18 und y0=-10 auf deinen 
Werten. Das einfachste ist, wenn du den Sensor einmal langsam um 360° 
drehst und deine XY-Wertepaare in ein XY-Diagramm einträgst. Das 
Erdmagnetfeld beschreibt dann idealerweise einen Kreis und der 
Permanentmagnetvektor deines Aufbaus verschiebt den Mittelpunkt aus dem 
Ursprung.
Wenn deine Daten auf einem Ursprungskreis liegen, kannst du mit dem Atan 
anfangen zu rechnen.

[Philipp M. (lord-maricek)]

Hallo,

hab nochmaln bisschen getestet, und festgestellt, dass die x,y,z 
Register wahrscheinluch vertauscht sind. Ich muss noch rausfinden, wie 
genau.

MfG
Philipp

[Florian G. (floppes)]

Ich verwende einen sehr ähnlichen Code mit dem HMC5883L und habe das 
gleiche Problem, dass meine Berechnete Richtung sich nicht ändert, egal 
wie ich den Sensor drehe.

Hast du mittlerweile eine Lösung gefunden?

[Tbd (ids2001)]

Hallo,

ich schließe mich hier den Thread auch an. Habe ein ähnliches Problem.
lg
Dieter

[Florian G. (floppes)]

Ich habe das Problem bei mir gefunden: mein Magnetometer saß zu nah an 
einem Lautsprecher mit Magnet. 5 cm weiter weg liefert es jetzt gute 
Werte.

[Randy S. (randy_s)]

Hallo,

hat mittlerweile jemand eine Lösung des Problems? Bei mir kommen leider 
auch nur Werte oberhalb 280...

... habt ihr MSB und LSB als signed int oder unsigned int laufen?

Vielen Dank schon mal für Eure Hilfe!!! :-)

[Frank M. (frank_m35)]

Euer Code?
Und bevor ihr versucht den Winkel auszurechnen, wie sehen die RAW Daten 
denn aus? Ergeben die Sinn? Was passiert wenn ihr eure Platine um 360 
Grad um eine Achse dreht? Lasst euch die Werte per RS232 oder LCD 
ständig ausgeben.
Was passiert wenn ihr einen schwachen Magnet von weit außen annähert?
Habt ihr magnetisierbare Objekte in dichter nähe? (Eisen, Schrauben, 
Lautsprecher, ...)
Habt ihr den IC selber gelötet oder fertig auf einer Platine bestellt? 
Falls selbst gelötet, habt ihr beim Schaltungsentwurf die im Datenblatt 
stehenden Dinge beachtet?

Hier mein Code der auf einem PIC24 funktioniert. Ich habe ihn nicht 
exakt getestet, da ich den Magnetsensor bisher nicht gebraucht habe, 
jedoch hat er bei den Tests sinnvolle Werte geliefert und auch der 
Winkel wurde sinnvoll berechnet.
Die Formel für den Winkel ist die selbe die der Threadstarter benutzt 
und entstammt aus einer Homepage die ich bei der Formel angegeben habe. 
Vielleicht solltet ihr die Homepage mal genauer durcharbeiten, denn dort 
stehen auch weitere nütliche Links.

int MAG_init();
int MAG_set_conf(char subaddr, char config);
unsigned char MAG_get_conf(char subaddr);
void MAG_get_heading(int* Xptr, int* Yptr, int* Zptr);
int MAG_get_angle();

#define MAG_ADDRESS_WRITE      0x3C
#define MAG_ADDRESS_READ      0x3D

#define MAG_CONF_REG_A        0
#define MAG_CONF_REG_B        1
#define MAG_MODE_REG        2
#define MAG_DATA_X_H        3
#define MAG_DATA_X_L        4
#define MAG_DATA_Y_H        5
#define MAG_DATA_Y_L        6
#define MAG_DATA_Z_H        7
#define MAG_DATA_Z_L        8
#define MAG_STAT_REG        9
#define MAG_ID_REG_A        10
#define MAG_ID_REG_B        11
#define MAG_ID_REG_C        12


/*****************************************************************************
 * Function:   MAG_init
 * Overview:   function initiates Magnetic sensor
 * Input:     None
 * Output:     0 successful, 1 error occured
 *****************************************************************************/
int MAG_init()
{
  int error=0;

  // 8-average, 15 Hz default, normal measurement
  error |= MAG_set_conf(MAG_CONF_REG_A, 0x70);

  // Gain=5
  error |= MAG_set_conf(MAG_CONF_REG_B, 0xA0);

  // Continuous measurement mode
  error |= MAG_set_conf(MAG_MODE_REG, 0x00);

  return error;
}


/*****************************************************************************
 * Function:   MAG_set_conf
 * Overview:   set value of register
 * Input:     None
 * Output:     0 successful, 1 error occured
 *****************************************************************************/
int MAG_set_conf(char subaddr, char config)
{
  int error = 0; 

  I2C_start();
  error |= I2C_send_byte(MAG_ADDRESS_WRITE);
  error |= I2C_send_byte(subaddr);
  error |= I2C_send_byte(config);
  I2C_stop();

  return error;
}


/*****************************************************************************
 * Function:   MAG_get_conf
 * Overview:   get value of register
 * Input:     address of register to read
 * Output:     value of read register
 *****************************************************************************/
unsigned char MAG_get_conf(char subaddr)
{
  unsigned char temp;
  
  // send address  
  I2C_start();
  I2C_send_byte(MAG_ADDRESS_WRITE);
  I2C_send_byte(subaddr);
  
  // receive config
  I2C_restart();
  I2C_send_byte(MAG_ADDRESS_READ);
  temp = I2C_receive_byte(I2C_NACK);
  
  //I2C_Ack();  
  I2C_stop();
  
  return temp;
}


/*****************************************************************************
 * Function:   MAG_get_heading
 * Overview:   retrieve all 6 bytes, containing x, y, and z values
 * Input:     pointers for data to store
 * Output:     assembled 16-bit X, Y and Z value
 *****************************************************************************/
void MAG_get_heading(int* Xptr, int* Yptr, int* Zptr)
{
  // send address  
  I2C_start();
  I2C_send_byte(MAG_ADDRESS_WRITE);
  I2C_send_byte(MAG_DATA_X_H);

  // receive all 6 bytes
  I2C_restart();
  I2C_send_byte(MAG_ADDRESS_READ);
  *Xptr =  I2C_receive_byte(I2C_ACK)<<8;
  *Xptr |= I2C_receive_byte(I2C_ACK);
  *Zptr =  I2C_receive_byte(I2C_ACK)<<8;
  *Zptr |= I2C_receive_byte(I2C_ACK);
  *Yptr =  I2C_receive_byte(I2C_ACK)<<8;
  *Yptr |= I2C_receive_byte(I2C_NACK);
  I2C_stop();
}


/*****************************************************************************
 * Function:   MAG_get_angle
 * Overview:   calculates the angle based on the received values
 * Input:     - 
 * Output:     calculated 16-bit angle
 *****************************************************************************/
int MAG_get_angle()
{
  int X, Y, Z;
  MAG_get_heading(&X, &Y, &Z);
  
  // calibrate YOUR compass, so compass raw x,y (,z) data is centered around 0,0,0 axis!
  // To do this read do an XY scatter plot for 2D xy data, and just "read"
  //   work out or guess the offset to center the data (you need to rotate the compass to get lots of data pairs)
  //   for my compass the values where x=-100, y=-100 (did not work out z axis!)
  // http://usabledevices.com/wiki/index.php?title=Compass_Honeywell_HMC5883L
  const int x_offset = 0;
  const int y_offset = 0;
  //const int z_offset = 0;
  
  return atan2((double)Y - y_offset,(double)X - x_offset)* (180 / 3.14159265) +180; // angle in degrees

}

[Moses (Gast)]

"Vielleicht solltet ihr die Homepage mal genauer durcharbeiten, denn 
dort
stehen auch weitere nütliche Links."

404 - Page not found...

Gibts das noch irgendwo anders?

Habe das gleiche Problem.

[Frank M. (frank_m35)]

Definiere gleiches Problem.
Wie sieht dein physikalischer Aufbau aus?
Meinen Source code mal getestet, selbes Problem?

[Michael (Gast)]

Moses schrieb:
> Habe das gleiche Problem.

Dann zeige doch mal einen Scatterplot von deinen Rohdaten, so wie sie 
aus dem Sensor kommen.

[Moses (Gast)]

Ok, das erste Problem, dass da irgendwelche sinnlosen, wilden Kurswerte 
berechnet wurden, alle zwischen 240 und 310 Grad, hat sich erledigt. Ich 
sollte einfach lesen lernen und darauf achten, in welcher Reihenfolge 
die x-, y- und z-Werte aus dem Sensor kommen...

Was jetzt noch bleibt ist, dass die Kurswerte noch heftig rumeiern.
Also wenn ich den Kompass um 90 Grad drehe erwarte ich eigentlich auch 
eine Änderung der Gradzahl um diesen Betrag.
Wenn ich das aber mache (Orientierung an der Tischkante, immer 90 Grad 
weitergedreht, ebene Fläche) kommen diese Werte raus (auf den nächsten 
5er gerundet):
   x      y      z  kurs
 130    125   -435    40
-230     35   -430   170
-155   -335   -435   245
 195   -275   -450   305

Statt immer ca 90 Grad sind die Differenzen zwischen 60 und 130 Grad.
Im Moment bin ich ein bisschen überfragt, wie ich diese großen 
Abweichungen kompensieren kann.

Der relevante Teil des Codes ist:

Init des HMC:

  i2c_start_wait(COMPASS_ADDR_WRITE);
  i2c_write(0x02);
  i2c_write(0x00);
  i2c_stop();

  i2c_start_wait(COMPASS_ADDR_WRITE);
  i2c_write(0x01);
  i2c_write(0x20);
  i2c_stop();

  i2c_start_wait(COMPASS_ADDR_WRITE);
  i2c_write(0x00);
  i2c_write(0x10);
  i2c_stop();

  _delay_ms(6);

Berechnung in der Hauptschleife, wird mit 15 Hz ausgeführt:

  i2c_start_wait(COMPASS_ADDR_WRITE);
  i2c_write(0x03);
  i2c_stop();

  i2c_start_wait(COMPASS_ADDR_READ);
  x_raw = i2c_read(1); x_raw <<= 8;
  x_raw |= i2c_read(1);
  z_raw = i2c_read(1); z_raw <<= 8;
  z_raw |= i2c_read(1);
  y_raw = i2c_read(1); y_raw <<= 8;
  y_raw |= i2c_read(0);
  i2c_stop();

  float heading = 0;
  heading = atan2((double)y_raw,(double)x_raw);
  heading = heading * 180 / M_PI;
  if (heading < 0) heading = heading + 360;
  if (heading >= 360) heading = heading - 360;

Ich hoffe, ihr habt dazu eine Idee.

LG

[Randy Stiegler (Gast)]

Da ich das gleiche Problem kürzlich auch hatte ...

Dein Problem ist, dass dein Sensor nicht kalibriert ist.
D.h. in der Umgebung in der er eingebaut ist bzw momentan getestet wird
musst du offset Werte ermitteln und hinterlegen.

Schreib ein Kalibrier-Programm, welches ständig den größten und
kleinsten Messwert jeder Achse speichert
if (messwert-x < min-x ) min-x = messwert-x...

Nachdem du deinen Sensor in jede erdenkliche Lage gebracht hast, weißt
du nun in welche Richtung dein Offset geht.
-420 bis 420 wäre ein offset=0
-440 bis 400 ergibt offset=-20

Nach deiner Kalibrierung kannst du nun bei jedem Messwert in deiner
Anwendung -20 abziehen ... Also jeden Messwert dieser Achse +20 rechnen.
Dann stimmt dein Winkel hoffentlich.

Evtl. noch die Magnetfeldkorrektur für deine geografische Lage
hinterlegen um vom mag Norden auf geo Norden zu kommen - fertig.

Hoffe das hilft - gib bitte feedback

[Moses (Gast)]

wahhh ich könnt dich jetzt sowas von abknutschen... wenn du ne Frau 
wärst ;)

Der Tipp war goldrichtig, jetzt zeigt er sauber die richtigen Werte an.
Danke!

Hab immer nicht verstanden, was die in den Quellcodes vom Multiwiikopter 
oder bei MicroKopter da mit der Konstante nach dem Abgleich machen bzw 
wie die die ermitteln, aber jetzt hats klick gemacht :)

Nochmal vielen vielen Dank!

[Randy Stiegler (Gast)]

Haha :-)
Kein Problem!

Falls du rausfindest wie man die Neigung mit in die Rechnung einbezieht 
... Ich habe noch einen ACC und Gyro mit kalman-filter und PID fertig 
... Aber mit dem Magnetfeld bin ich noch nicht so sehr zufrieden.
Zwar bekomme ich nun ordentliche Werte zwischen 0 und 360, aber ich bin 
der Meinung, dass Norden doch noch 20° daneben ist...?!

Kalibrierung allerdings auf Tisch mit PC(WLAN, Bluetooth...), Handy und 
vielen elektr. Geräten.
Wo/wie hast du kalibriert?

[Jonathan (Gast)]

Moses schrieb:
> Im Moment bin ich ein bisschen überfragt, wie ich diese großen
> Abweichungen kompensieren kann.

Erstmal solltest du das ein bisschen genauer messen. Zeichne doch 
einfach mal die (x,y,z) Datenpunkte auf, während du den Kompaß langsam 
in allen Raumrichtungen drehst. Jeweils zwei der Parameter gegeneinander 
geplottet müssen einen Kreis ergeben. Erst wenn da saubere Kreise 
rauskommen, macht es Sinn daraus Winkel zu berechnen.

[Moses (Gast)]

Auf dem Schreibtisch, mindestens 30 cm von allen elektrischen Geräten 
entfernt.
Für die Praxis nachher muss ich dann eh eine Routine einbauen, die die 
Minimal- und Maximalwerte ermittelt und daraus das Offset bestimmt.
Mir gings jetzt erstmal um die generelle Lösung des Problems.

Die Neigungskompensation ist dann der nächste Schritt. Gedacht ist das 
Ganze für einen Quadrokopter. Von der Steuerplatine bekomme ich die 
aktuellen Neigungswerte in x- und y-Richtung (Gyro und ACC bereits 
fusioniert). Die muss ich mir dann noch normieren und dann werde ich das 
mal mit diesen Formeln hier versuchen:

$$Xh = XM * cos(Pitch) + ZM * sin(Pitch)$$

$$Yh = XM * sin(Roll) * sin(Pitch) + YM * cos(Roll) - ZM * sin(Roll) * cos(Pitch)$$

Quelle: 
http://www.loveelectronics.co.uk/Tutorials/13/tilt-compensated-compass-arduino-tutorial

[Randy Stiegler (Gast)]

Ich glaube wir sollten Kontakt bleiben - baue auch einen quadcopter.
Momentan hängt das aber etwas mit der tiltcompensation bei mir.

Falls du Hilfe brauchst bei Gyro, Acc, Kalmanfilter, PID ... Habe ich 
soweit alles laufen.
Die gleichen Formeln habe ich auch im Controller aber irgendwie stimmt 
da was nicht. Kann auch daran liegen, dass die falschen Werte verrechnet 
werden. Ist ein komplettes board (gy80) - vielleicht sind die Achsen 
nicht so wirklich kompatibel - z.B. Winkelx+ entspricht magx- oder so.

Werde mir das heute anschauen - Wenn du das hinbekommst melde dich mal 
bitte ;-)

[Michael (Gast)]

Moses schrieb:
> Für die Praxis nachher muss ich dann eh eine Routine einbauen, die die
> Minimal- und Maximalwerte ermittelt und daraus das Offset bestimmt.

Offset reicht nicht, die Skalierungsfaktoren der Achsen müssen auch 
stimmen.

[Randy Stiegler (Gast)]

... D.h. ich muss selftest bit setzen - dann zeigt er mir feste Werte 
an. Und dann?

Da wusste ich nicht auf welchen Wert ich skalieren soll

[Randy Stiegler (Gast)]

Achso und ganz wichtig - in welcher Reihenfolge?
Ich nehme mal an erst nach der Kombination msb&lsb skalieren und danach 
offset finden...richtig?

[Randy S. (Gast)]

Ok ... Habe im Datenblatt die Antwort gefunden (siehe Anhang)
Nachdem msb&lsb kombiniert wurden wird der scale_factor multipliziert.
Bei +-1.3 Ga z.B. 0.92

Mit diesen Werten dann Offset bestimmen und bei jeder Messung abziehen.
Wenn ich mich irre korrigiert mich bitte.

[Moses (Gast)]

Hallo Michael,
hast du dafür mal ein konkretes Beispiel? Mit der Skalierung stehe ich 
noch etwas auf dem Schlauch.
Der Self-Test zeigt doch meines Erachtens nur, ob die ausgegebenen Werte 
bei der gewählten Verstärkung (Gain) innerhalb akzeptabler Grenzen 
liegen. Wenn nicht, muss man Gain so viele Stufen runterdrehen, bis es 
passt. Und wenn die Werte viel zu klein sind, dann eben Gain etwas nach 
oben.
Oder haben ich das falsch verstanden?
Dieses Beispiel im Datenblatt

If Gain = 6, self test limits are:
Low Limit = 243 * 330/390 = 206
High Limit = 575 * 330/390 = 487

zeigt doch nur, wie man die in den Spezifikationen für Gain=5 (+- 4.7 
Ga) angegebenen Grenzwerte für andere Verstärkungen berechnet, also
Grenzwert für Gain=5 mal neuer Verstärkungsfaktor geteilt durch Faktor 
für Gain=5 gibt den Grenzwert für die aktuelle Verstärkung.
Damit muss man doch im praktischen Betrieb nachher nicht mehr arbeiten, 
oder?

Was später vielleicht noch interessant wäre ist die 
Temperaturkompensation. Wenn ich das richtig verstanden habe muss mann 
dazu einfach immer wieder mal für ein paar Zyklen (bei 15 Hz ist das ja 
grad mal ein Wimpernschlag und das auch nur alle paar Sekunden) in den 
Selftestmodus schalten und den Maximalwert mit dem Referenzwert für eine 
bestimmte Temperatur vergleichen. Aktueller Maximalwert / Referenzwert = 
Faktor, mit dem dann alle Messwerte im Normalmodus multipliziert werden. 
Danach dann wieder in den Normalmodus schalten.
Klingt einfach und ist es hoffentlich auch...

LG

[Randy S. (mcstieg)]

Moses schrieb:
> Hallo Michael,
> hast du dafür mal ein konkretes Beispiel? Mit der Skalierung stehe ich
> noch etwas auf dem Schlauch.

Das habe ich einen Post weiter oben beschrieben. Schau dir das Bild dazu 
an. Du erhälst vom Sensor msb und lsb, machst eine 16bit draus und dann 
kommt der Faktor 0.92 (für +-1.3Ga, andere siehe Bild) dazu.
Damit ist alles getan - jetzt kann der Winkel berechnet werden.

Der Self test zeigt dir (nehme ich an):
...ob du msb & lsb korrekt kombiniert hast.
...ob du, wie du selbst beschrieben hast, mehr oder weniger Gain 
benötigst
...ob die Temp anders ist.

Ich würde mal behaupten, dass man den Selftest während des Fluges nicht 
benötigt - ich lasse mich aber gern eines besseren belehren.
Bisher habe ich die genaue Anwendung des Selftests nicht verstanden.

[Moses (Gast)]

Nun, jede Achse mit 0.92 zu multiplizieren macht doch eigentlich nur 
zusätzlichen Aufwand für den µC (Kommazahlen, igitt...).
Und am Ende ist es doch egal, ob man atn2(100/100) oder atn2(92/92) 
rechnet, der Faktor in der Klammer ist der gleiche.
Auch bei den Kompensationsformeln für die Neigung sollte das doch kein 
Problem sein. Mit dem Faktor kommt Xh und Yh eben um den Faktor 0.92 
kleiner raus und in der Winkelberechnung fliegt der Faktor doch eh raus.
Oder bin ich da jetzt auf dem falschen Dampfer?

Zur Temperaturkompensierung: Das ist wohl dann sinnvoll, wenn man im 
Schatten bei ungefähr Zimmertemperatur startet und dann in die pralle 
Sonne geht. In dem Beispiel im Datenblatt ist ja eine recht große 
Differenz (mal eben um 100 runter mit dem Wert). Aber die absolute 
Differenz ist ja auch unerheblich. Interessanter ist, wie groß die 
Unterschiede zwischen den Achsen bei Zu- bzw Abnahme werden. Also ob bei 
dem gleichen Temperaturunterschied die eine Achse um 100 abnimmt während 
die andere vielleicht nur 80 weniger zeigt. Dann passt die Gradzahl am 
Ende nicht mehr. Ich denke mal, das muss man einfach ausprobieren und 
wenn die Differenzen zu groß werden eben auch im Flug gelegentlich für 
ein paar Takte in den Selftest schalten, um die Werte des Selftests mit 
den Referenzwerten bei Zimmertemperatur zu vergleichen und danach 
entsprechend zu korrigieren.

LG

[Moses (Gast)]

Auch wenn hier nichts mehr passiert ist wollte ich doch nochmal 
Rückmeldung zum aktuellen Stand geben.
Nach längerer Pause (zu viel um die Ohren...) habe ich mich jetzt 
nochmal an den Kompass gesetzt und siehe da, es funktioniert.
Als Formeln für die Neigungskompensation habe ich jetzt folgende 
verwendet:

$$xh = x*cos(pitch) + y*sin(pitch)*sin(roll) - z*cos(roll)*sin(pitch)$$

$$yh = y*cos(roll) + z*sin(roll)$$

$$winkel = atn2(y,x)$$

Pitch und roll bekomme ich von der Steuerung des Copters, der Winkel 
ändert sich bei Neigung jetzt praktisch nicht mehr.

Als nächstes werde ich die Formeln nochmal testen, die ich weiter oben 
genannt hatte. Die hatte ich erst verworfen weil der Winkel mit denen 
total rumgesponnen hat, dann aber bemerkt, dass ich mich bei einer 
vertippt hatte und yh statt xh genommen hatte. Damit konnte es ja nicht 
funktionieren.
Wie gesagt, Test steht noch aus.

Als nächstes muss jetzt die Regelung her und dann ab damit in die Luft.

LG

[Moses (Gast)]

winkel = atn2(yh, xh) muss das natürlich heißen...
LG

[Attila C. (attila)]

Hallo!

Ich spiele auch grade mit einem HCM5883L rum.

1) Vielen Dank für die Beiträge hier, sie haben mir sehr geholfen.
2) Faszinierend was der Sensor für so wenig Geld leistet!
3) Ich glaube bei dieser Formel:

angle = atan2((double)y,(double)x) * 180 / 3.14159265 + 180;

muss es am Ende +179 heißen da man sonst einen Winkel von 360 und 0 
erhält.

Ich hoffe das die Beteiligten dieses Threads selbigen noch beobachten da 
ich mich gerne weiter austauschen würde!

Gruß

[Attila C. (attila)]

Hallo nochmal!

Auf die Gefahr hin mich hier zu weit aus dem Fenster zu lehnen:

Eine Neigungs-Kompensation? Wozu denn? Die Verhältnisse der Vektoren X 
und Y bleiben doch immer gleich?

Gruß

[Randy (Gast)]

Ja ich würde sagen das war zu weit ;)

Probier es mal ohne Kompensation aus und neige den Sensor ...
Dann ist Norden überall - aber nicht im Norden.

Hintergrund ist, dass der gemessene Anteil X & Y dann real mit der 
Z-Komponente überlagert ist. Diesen Anteil musst du natürlich mit 
beachten um X & Y im richtigen Maß zu korrigieren.

[Attila C. (attila)]

Randy!

Ich stimme Dir 100% zu! :-)

Jetzt fehlt nur noch eine Berechnung der Lage im Raum nach dem Prinzip: 
Der Einfluss von Z auf X und Y ist ja vorhersehbar!

Wer hat die Formel? :-) :-) :-)

Gruß

[Jan H. (janiiix3)]

Randy Stiegler schrieb:
> Schreib ein Kalibrier-Programm, welches ständig den größten und
> kleinsten Messwert jeder Achse speichert
> if (messwert-x < min-x ) min-x = messwert-x...

Hallo,

sorry wenn ich noch mal Nachfrage.
Ein "Offset" von ~500 ist bisschen zu viel des guten oder :D?

Den Offset ermittle ich folgendermaßen:

    compass_get_axis(&x,&y,&z);
      
    if (x < min_x )
    {
      min_x = x;
    }     
      
    if (x > max_x )
    {
      max_x = x;
    }  
    
    char Buffer[20];

    sprintf(Buffer,"Max_X : %d   Min_X : %d",max_x,min_x);
    uart_puts(Buffer);
    uart_puts("\n\r");