Sensori MARG la nuova frontiera dei multirotori

[ciskje]

La nuova frontiera per i multirotori sono i gruppi di sensori MARG, che oltre a gyro e acc aggiungono la bussola.

Grazie al sapiente lavoro di un "piccolo" scienziato di nome Sebastian Madgwick, il signore in questione ha saputo sfruttare la pendenza del campo magnetico per aiutare gli altri sensori nell'orientamento del multirotore.

E' si perchè anche se non sembra qui in italia la bussola non dovrebbe indicare solamente il nord, ma punta decisamente verso il basso.



Qual'è il risultato di tutto questo? Il fatto che con 3 sensori non c'e' nessun drift, e il velivolo sa esattamente il suo assetto con una rapidità impensabile fino a qualche tempo fa:



Il calcolo matriciale che il buon scienziato ci ha messo a disposizione è abbastanza semplice persino per un processore come arduino.

Cosa si può fare ora? Dimenticare quel pesante e lento Kalman, e iniziare finalmente la navigazione GPS. Ci mettiamo al lavoro?

[redfox74]

La nuova frontiera per i multirotori sono i gruppi di sensori MARG, che oltre a gyro e acc aggiungono la bussola.

Grazie al sapiente lavoro di un "piccolo" scienziato di nome Sebastian Madgwick, il signore in questione ha saputo sfruttare la pendenza del campo magnetico per aiutare gli altri sensori nell'orientamento del multirotore.

E' si perchè anche se non sembra qui in italia la bussola non dovrebbe indicare solamente il nord, ma punta decisamente verso il basso.



Qual'è il risultato di tutto questo? Il fatto che con 3 sensori non c'e' nessun drift, e il velivolo sa esattamente il suo assetto con una rapidità impensabile fino a qualche tempo fa:



Il calcolo matriciale che il buon scienziato ci ha messo a disposizione è abbastanza semplice persino per un processore come arduino.

Cosa si può fare ora? Dimenticare quel pesante e lento Kalman, e iniziare finalmente la navigazione GPS. Ci mettiamo al lavoro?

Anche qualcun altro ha provato a convincermi rispetto all'uso di questo approccio ... ma poi e' tornato sui suoi passi ... infatti il campo magnetico terrestre e' molto "diverso" a seconda delle zone e il volo indoor e' praticamente impossibile .. ti basta una porta metallica e sei belle che fatto
Cmq la nuova testina sensori che sto' mettendo appunto per MP32 avra' acc , gyro e magnetometro . Oltre che i n opzione il gps collegato direttamente a MP32
Quindi si potranno fare tutti gli esperimenti che si vogliono di questo algoritmo .. con una potenza di calcolo fino a 24x rispetto ad arduino
Saluti
Roberto

[danveal]

Anche qualcun altro ha provato a convincermi rispetto all'uso di questo approccio ... ma poi e' tornato sui suoi passi ... infatti il campo magnetico terrestre e' molto "diverso" a seconda delle zone e il volo indoor e' praticamente impossibile .. ti basta una porta metallica e sei belle che fatto
Cmq la nuova testina sensori che sto' mettendo appunto per MP32 avra' acc , gyro e magnetometro . Oltre che i n opzione il gps collegato direttamente a MP32
Quindi si potranno fare tutti gli esperimenti che si vogliono di questo algoritmo .. con una potenza di calcolo fino a 24x rispetto ad arduino
Saluti
Roberto

Mmm le tue osservazioni mi sembrano corrette, aggiungo il volo in prossimità di linee elettriche e/o costruzioni etc.
Un altro problema che potrebbe inficiare completamente la cosa e' il campo magnetico generato dai magneti dei motori ma sopratutto quello generato dalla corrente nei cavi.
Spesso ho notato derive sullo yaw con magnetometro attivo causato da questo fenomeno, se non si cura la disposizione del cablaggio, quando si da piu' o meno gas, immagina l'effetto sul marg...

[ciskje]

Ho avvicinato un magnete al neodimio da 4000 Gauss, al magnetometro, ne ha sentito l'influenza a 10 cm.
Il limite dell'inquinamento elettromagnetico in campo aperto è di 3uT, cioè 30mG cioè circa da 10 a 100 volte meno del campo terrestre.
Influiscono di più le variazioni giornaliere del campo terrestre stesso (ben più potenti).
Il valore indicato del nord, alle nostre latitudini è influenzato pesantemente dall'inclinazione verso il basso, che è quasi verticale, a quel punto l'indeterminazione del tilting influisce pesantemente.
Quel che fa Sebastian, è usare il valore di flusso verso il basso, aiutando sia l'accelerometro che lo yaw.
In ogni caso non ci sono alternative.

[elettro]

ti sei basato su questa marg?
imumargalgorithm30042010sohm - Project Hosting on Google Code
(è lo stesso sito da cui ho preso la IMU)
l'algoritmo funziona molto bene, a vedere il video, solo fai attenzione che le formule che usa non "depurano" gli input, ad esempio nel filtro IMU se l'accelerometro da in input 0,0,0 "crasha" l'algoritmo... quindi dai un'occhiata al codice!

secondo me il fatto che il campo magnetico sia differente da zona a zona o che possa variare nel lungo termine o che ci siano interferenze non è un grosso problema:
una configurazione iniziale dello "zero" del magnetometro all'accensione dovrebbe bastare per voli che durano meno di giorni;
per eliminare eventuali interferenze, si può usare il modulo della lettura del magnetometro. per quanto ci si possa allontanare il campo magnetico terrestre non varia moltissimo, eventuali valori che superano un dato limite possono essere scartati, tanto la lettura è assoluta, e quindi al momento in cui si riotterranno buone letture si riaggiusta l'inclinazione yaw. Fino a quel momento si vola con un "classico" IMU...

rimangono problemi di magnetismo dati dai motori o cavi.. ma sono problemi su cui possiamo agire direttamente, e quindi risolvibili (aumentando i bracci, spostando o schermando cavi e motori, per esempio)

[ciskje]

ti sei basato su questa marg?
imumargalgorithm30042010sohm - Project Hosting on Google Code
(è lo stesso sito da cui ho preso la IMU)

No Varesano ha fatto un ottimo lavoro di adattamento dell'algo di Sebastian:
Varesano.net | Fabio Varesano Personal Website

C'e' sempre il GPS comunque che compensa, appena avremo un quadri che vola tra torino e palermo.

[elettro]

ho dato un'occhiata al codice, è basato sullo stesso del link che ti ho passato, infatti ho usato il codice processing
usando il trucco della sqrt di gawain ci risparmio 100microsec a radice quadrata.. prova! nel mio caso che uso solo IMU vuol dire velocizzare il codice del 20%

float Stabilizzazione::invSqrt(float number) {
  long i;
  float x, y;
  const float f = 1.5F;

  x = number * 0.5F;
  y = number;
  i = * ( long * ) &y;
  i = 0x5f375a86 - ( i >> 1 );
  y = * ( float * ) &i;
  y = y * ( f - ( x * y * y ) );
  return y;
}

ho anche "sistemato" un atto il codice di processing, eliminando tra l'altro la funzione decodeFloat:

void readQ() {
  if(myPort.available() > 0) {
    String inputString = myPort.readStringUntil('\n');//non serve il cast a int(o meglio char) se usi '
    print("letto: ");
    println(inputString);
    if (inputString != null && inputString.length() > 0) {
      String [] inputStringArr = split(inputString, ',');
      if(inputStringArr.length == 5) {
        Q[0] = Float.parseFloat(inputStringArr[0]);
        Q[1] = Float.parseFloat(inputStringArr[1]);
        Q[2] = Float.parseFloat(inputStringArr[2]);
        Q[3] = Float.parseFloat(inputStringArr[3]);
      }
    }
  }
}

[ciskje]

Ti sei perso il mio commento poco prima del tuo (se sei "lesto"), non serve proprio usare le stringhe, si può trasmettere un floating point (in binario) con soli 4 byte:

Su arduino mandi con:

void serialFloatPrint(float val)
{
char *addr=(char *)(&val);
Serial.write(addr[3]);
Serial.write(addr[2]);
Serial.write(addr[1]);
Serial.write(addr[0]);
}

In processing, you can read directly the 4 byte IEEE754 data, without ASCII overhead:


import java.nio.*;

void readQ() {
if(myPort.available() >= 16) {
byte[] inBuffer=new byte[4];
myPort.readBytes(inBuffer);
Q[0] = ByteBuffer.wrap(inBuffer).getFloat();
myPort.readBytes(inBuffer);
Q[1] = ByteBuffer.wrap(inBuffer).getFloat();
myPort.readBytes(inBuffer);
Q[2] = ByteBuffer.wrap(inBuffer).getFloat();
myPort.readBytes(inBuffer);
Q[3] = ByteBuffer.wrap(inBuffer).getFloat();
}
}

[elettro]

comodo ma non c'è il rischio che se ci sono dati errati che superano lo split (tipo una scritta con 5 virgole) spari valori a caso? perché io stampo altre info di debug che leggo "ad occhio" e quindi non vorrei incasinare le cose

comunque ottima soluzione, non ho mai usato il ByteBuffer

[redfox74]

comodo ma non c'è il rischio che se ci sono dati errati che superano lo split (tipo una scritta con 5 virgole) spari valori a caso? perché io stampo altre info di debug che leggo "ad occhio" e quindi non vorrei incasinare le cose

comunque ottima soluzione, non ho mai usato il ByteBuffer

E' un metodo molto diffuso per le conversioni float ,binario da usare nei protocolli di comunicazione ... l'evoluzione che noi abbiamo implementato in Quadfox e' il protocollo rpc dove addirittura mandiamo via i byte raw di una struttura e li andiamo a reindicizzare quando vengono ricevuti , praticamente prendi il raw dei dati memorizzati da una struttura c , vengono trasmessi e dall'altra parte conoscendo la struttura originale non fai altro che riassegnare il puntatore e con 2 istruzioni vai a reimpostare una struttura anche molto compressa fatta da centinaia di parametri.
Un saluto
Roberto

[ciskje]

comodo ma non c'è il rischio che se ci sono dati errati che superano lo split (tipo una scritta con 5 virgole) spari valori a caso?

Non trasmetti nulla come stringa.
4 valori da 4 byte per il quaternione, 16 byte sempre e comunque.

[elettro]

nono, io sto usando un altro codice per arduino, sfrutto solo il processing
non capisco perchè se uso solo accelerometro lo yaw inizia a girare su se stesso, è normale ma dai video non dovrebbe influenzare così tanto...

[ciskje]

nono, io sto usando un altro codice per arduino, sfrutto solo il processing
non capisco perchè se uso solo accelerometro lo yaw inizia a girare su se stesso, è normale ma dai video non dovrebbe influenzare così tanto...

Mi sa che non ci capiamo, quei due pezzi di codice puoi usarli dove vuoi. Serve solo per trasmettere un qualsiasi numero floating point da arduino a processing (anche nei tuoi programmi).
E dal video non influenza tanto perchè sto usando una bussola, perchè altrimenti non è un sensore MARG.

Gira per forza senza perchè anche il minimo offset del gyro dello yaw, genera un movimento che si accumula molto rapidamente.

[elettro]

l'algoritmo che ho usato io (che poi è lo stesso tuo senza magnetometro) è questo: YouTube - An efficient orientation filter for IMUs (real-time demonstration)
forse dipende dalla frequenza di aggiornamento... ma mi succede anche se come input dei gyro passo 0,0,0
però ho notato che questa rotazione non inizia mai se prima non muovo l'accelerometro.. ho provato a escludere le letture di accelerometro con modulo troppo diverso da 1G, ma ancora nulla.

[elettro]

trovato, mi ero dimenticato un - in giro
ora non mi resta che normalizzare un pò i giroscopi, gli hk401b hanno una risoluzione troppo alta ( 7°/s per ogni "uno" dell'analogRead)