[Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo

eccomi di nuovo alle prese col "mostro"

allora ecco il mio problema:
1 o 2 canali non vengono visti, dico uno o due perchè attualmente ho la GUI fuori uso perchè ho fatto una cattiva scelta sul sistema di comunicazione (uso 3 pin collegati all'atmega che sono 1 per reset, uno per tx e uno rx però i fili non stanno collegati per bene...) e perchè se provassi a fare il trim degli accelerometri (che attualmente non ho) il led lampeggia solo sul pitch...

per terminare un ultima domanda:
http://www.watterott.com/en/MinIMU-9-Gyro
(piccolo edit) e questa? http://www.watterott.com/en/IMU-Digital-Combo-Board-6-Degrees-of-Freedom-ITG3200/ADXL345
come vi pare questa imu? il prezzo è davvero interessante.. (contate che ora ho solo WMP)

ah dimenticavo dovo posso trovare la v1.8 rev by astro? XD

sto guardando la imu..

il giroscopio sembra molto buono, 16 bit di precisione, un output fino a 800HZ, e 3 range di lettura
accelerometro + magnetometro viaggiano in coppia, sempre 16bit di risoluzione, output fino a 1000Hz, 3 range per l'accelerometro e ben 7 per il magnetometro(anche abbastanza inutili, credo)

insomma a me sembra una ottima imu per quel prezzo, bisognerebbe vedere le frequenze di risonanza... ma di queste cose non ne so quindi taccio.
Dubito che quella imu sia già supportata da qualche codice, il che rende la cosa moolto sbatti se non sai già programmare bene

Salve Raga :slight_smile:
torno alla carica mostrandovi la nuova schedina progettata da me e superlol :slight_smile: è ancora la V1 beta (Ma tanto beta :slight_smile: è la mia prima fotoincisione e non è venuta un granchè) :slight_smile:
appena la provo pubblico il master :), ogni consiglio è ben accetto... occhio sulla board non cè il regolatore per i 3.3V che è stato sostituito da 2x1N4007 che però sono esterni alla scheda... Metterò anche il rendering 3D così si capisce meglio...

ratto93:
Salve Raga :slight_smile:
torno alla carica mostrandovi la nuova schedina progettata da me e superlol :slight_smile: è ancora la V1 beta (Ma tanto beta :slight_smile: è la mia prima fotoincisione e non è venuta un granchè) :slight_smile:
appena la provo pubblico il master :), ogni consiglio è ben accetto... occhio sulla board non cè il regolatore per i 3.3V che è stato sostituito da 2x1N4007 che però sono esterni alla scheda... Metterò anche il rendering 3D così si capisce meglio...

bello tornare a scrivere sul pc :stuck_out_tongue:

comunque io avevo proposto un LD1117 per i 3.3v e un jumper per selezionare i 5 o i 3.3V (alcune imu hanno già i convertitori on board)
ora devo vedere i feedback di ratto per poi farmene inviare una XD

lo schema l'ho realizzato io mentre lui ha fatto lo sbroglio (l'avevo fatto anche io ma lui può confermare che faceva schifo :wink: )

attualmente la scheda implementa tutte le possibilità offerte dal software multiwii (in pratica il fatto del monitorare la batteria ma non ancora i servi per il camera gimbal XD )

magari penso che farò uno schema completo per una scheda con tanto di sensori :stuck_out_tongue:

ce nessuno? :slight_smile:

Ci siamo si :slight_smile:
hai visto che schedina abbiamo fatto io e superlol ? :slight_smile:
domani ne stampo due, spero vengano bene.. perchè quella li ha sbavato un poco.. devono essere belle come quelle di DanielaE 8)

ratto93:
Ci siamo si :slight_smile:
hai visto che schedina abbiamo fatto io e superlol ? :slight_smile:
domani ne stampo due, spero vengano bene.. perchè quella li ha sbavato un poco.. devono essere belle come quelle di DanielaE 8)

io e te? diciamo pure solo te :slight_smile:

dai che voglio averlaaaaa XD

ieri mi è arrivata la imu 10dof della drotek e oggi l'ho provata con solo gyro e magne e volava decisamente bene :slight_smile:
appena ho un po di tempo calibro bene anche l'acc e lo provo :slight_smile:

io ci sono! e ho trovato un paio di formulette che potrebbero far comodo: il modo per usare il GPS!
certo, non son complesse come le formule che prendono in considerazione il fatto che l'arco della terra è variabile, ma almeno non tira una linea retta, ma tende a seguire la via più breve fattibile.
Non ho scritto io le formule, ho preso da: http://www.movable-type.co.uk/scripts/latlong.html e da: http://williams.best.vwh.net/avform.htm

non ho acnora testato la performance e la precisione della formula sull'arduino, ma eccola: (attenzione: essa restituisce la tangente rispetto al NORD geografico della curva da seguire se da un punto A si vuole andare ad un punto B . Essendo curva va ricalcolata durante il percorso!)

float b = atan2(sin(lon1-lon2)*cos(lat2), cos(lat1)*sin(lat2)-sin(lat1)*cos(lat2)*cos(lon1-lon2) );

lat1 e lat2 sono le coordinate rispetto al NORD, espresse in secondi
lon1 e lon2 sono le coordinate rispetto ad OVEST, espresse in secondi (attenzione, i GPS sono rispetto ad EST, quindi il valore dato dal vostro GPS va invertito di segno)

(notare che non serve la distanza nella formula, in questo modo si evita di perdere la precisione doppiamente)

attenzione che la bearing in teoria è sempre compresa tra 0 e 2*PI, quindi dovreste normalizzarla prima di confrontarla con quella del vostro magnetometro, per esempio (modo molto alla spicciola):

while (b>2.0*PI){
  b-=2.0*PI;
}

per calcolare la distanza che trascorrerete in quel viaggio, che essendo curvo sarà un più lungo che la classiga riga retta, ecco la formulazza:

float asin1 = sin((lat1-lat2)/2.0);
float sin1 = sin((lon1-lon2)/2.0);
float d = 2*asin(sqrt(2.0*asin1*asin1 + cos(lat1)*cos(lat2)*sin1*sin1));
printf("distance in KM: %f\n", d*6366.71);

domani sento un mio compagno che ha finito l'itaer e vediamo che ne pensa XD (sta studiando ing. aerospaziale)

più che errori di formula ci sono errori di precisione... forse bisogna usare i double, forse numeri a virgola fissa (che sono già inclusi in GCC e in AVR-GCC, ma a quanto pare in AVR sono buggati e bisogna patchare a mano)

Se voi genialoidi delle formule smazzaste un po' di codice funzionante io potrei testarlo al parchetto :slight_smile:
Il freddo ci ha fatto diventare delle personcine tranquille?

Fede

Federico:
Se voi genialoidi delle formule smazzaste un po' di codice funzionante io potrei testarlo al parchetto :slight_smile:
Il freddo ci ha fatto diventare delle personcine tranquille?

Fede

tu hai un GPS e un magnetometro a casa? possiamo fare un paio di test... per esempio vedere se il bearing calcolato è sufficente preciso anche nel caso di punti ravvicinati una decina di metri...

Ho il magnetometro che e' montato sulla imu 9dof drotek e ho un gps, questo
http://www.watterott.com/en/EM406-SiRF-III-GPS

Mi stupisco di avere sempre tutto, tranne quello che al momento realmente mi serve...

camba192:
ieri mi è arrivata la imu 10dof della drotek e oggi l'ho provata con solo gyro e magne e volava decisamente bene :slight_smile:
appena ho un po di tempo calibro bene anche l'acc e lo provo :slight_smile:

Poi magari vieni a calibrare pure il mio :frowning:

aahhaha ok, allora, sei in grado di estrapolare i gradi o i radianti rispetto al nord? se sì sono in senso orario o antiorario (il mio codice lavora in senso antiorario)

a quel punto leggi il gps, dai le coordinate attuali in pasto all'agoritmo, ovviamente avendo settato a priori il punto di arrivo. poi seguendo col magnetometro le inclinazioni suggerite dall'agoritmo provi a vedere se da qualsiasi punto della casa la bussola segna la direzione giusta, ovvero il punto di arrivo!

se non hai il codice per il magnetometro, provo a buttare giù un codice al volo. Sarebbe utile anche avere uno schermino LCD così da indicare in che direzione ti devi ruotare, e la distanza stimata.

il GPS lavora con sentenze NMEA, se hai già del codice funzionante postalo che fa comodo, e per la imu posso fare qualcosa, ma sicuramente non per oggi

lesto:
io ci sono! e ho trovato un paio di formulette che potrebbero far comodo: il modo per usare il GPS!

E' una formulazione molto approssimativa, sopratutto perché non tiene conto di come varia il raggio terrestre, se ti va bene ottieni una precisione di +/- 100 metri e comunque servono calcoli in double precision su un 32bit, ovvero 64 bit.
La questione GPS l'ho già risolta in modo molto efficiente, ovvero pesa poco come tempo cpu, lavorando su un core Arm Cortex M3, l'mBed, che è quello che avremo sulla DUE quando arriverà, speriamo prima della fine del mondo :).
Se trovo il tempo oggi posto tutta la parte matematica e il software già scritto per l'mBed, ma utilizzabile/verificabile anche su un normale pc previa ricompilazione con un qualunque compilatore C ANSI (no C++).
Ho già fatto diversi test pratici, cioè gps (Garmin eTrex) alla mano e mBed con GPS (Venus 638) collegato e display, ottenendo una precisione di +/- 1 metro rispetto al punto di partenza su un percorso complessivo di 500 metri tra andata e ritorno (fatti a piedi), EGNOS agganciato errore dichiarato dal GPS 3 metri.

astrobeed:

lesto:
io ci sono! e ho trovato un paio di formulette che potrebbero far comodo: il modo per usare il GPS!

E' una formulazione molto approssimativa, sopratutto perché non tiene conto di come varia il raggio terrestre, se ti va bene ottieni una precisione di +/- 100 metri e comunque servono calcoli in double precision su un 32bit, ovvero 64 bit.
La questione GPS l'ho già risolta in modo molto efficiente, ovvero pesa poco come tempo cpu, lavorando su un core Arm Cortex M3, l'mBed, che è quello che avremo sulla DUE quando arriverà, speriamo prima della fine del mondo :).
Se trovo il tempo oggi posto tutta la parte matematica e il software già scritto per l'mBed, ma utilizzabile/verificabile anche su un normale pc previa ricompilazione con un qualunque compilatore C ANSI (no C++).
Ho già fatto diversi test pratici, cioè gps (Garmin eTrex) alla mano e mBed con GPS (Venus 638) collegato e display, ottenendo una precisione di +/- 1 metro rispetto al punto di partenza su un percorso complessivo di 500 metri tra andata e ritorno (fatti a piedi), EGNOS agganciato errore dichiarato dal GPS 3 metri.

però possiamo dire che alle nostre latitudini (sui 45°) l'errore si riduce di molto.

non stiamo volando dall'equatore ai poli...

riguardo la parte 32-64 bit sono moooolto meno esperto :sweat_smile:

comunque a me interessa la parte matematica dai :stuck_out_tongue:

superlol:
però possiamo dire che alle nostre latitudini (sui 45°) l'errore si riduce di molto.
non stiamo volando dall'equatore ai poli...

Affermazione totalmente priva di significato, anche limitandoci alla sola Italia la latitudine cambia tra circa 38° e 47°, con la relativa variazione del raggio terrestre, e poi la formulazione proposta da Lesto è solo una approssimazione che va sicuramente bene per fare navigazione con una nave o un aereo su lunghe distanze, poco importa se arrivi al punto desiderato con qualche centinaio di metri d'errore, non va bene per una navigazione di precisione sulle piccole distanze come nel caso di un quadricottero.

ma sinceramente non capisco troppo questo problema delle altezze. i waypoint che eventualemente il mezzo deve seguire sono impostati dall'utente, che specifica coordinate e alzezza rispetto al livello del mare.

trovo inutile sapere l'altezza del suolo tramite formule, visto che comuque viste le nostre altezze di volo ci sono talmente tanti impedimenti (pali della luce, corrente, palazzi etc..) che comuque i waypoint dovrebbero essere settati a mano uno per uno, pianificando a priori con l'aiuto di un cellulare.

all'utente basta specificare coordinate e altezza dal livello del mare scelta (tanto sia il baromentro sia le sentenze nmea prendono quello come riferimento)

capisco invece benissimo il problema della precisone, tanto è vero che uso solo i minuti senza calcolare nemmeno i secondi, questo già di per sè crea un errore molto significativo (che però non saprei quantificare al volo, c'è da fare un pò di conti, ma questo l'errore dovrebbe aumentare all'equatore no?) e poi abbiamo l'errore della matematica float, in questo caso l'errore dovrebbe aumentare essere abbastanza "ondulante" per via dei seni e coseni, più ci si avvicina a numeri tondi (per la matematica di seni e coseni, quindi multipli di PI) e meno errore c'è.