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

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'è.

lesto:
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.

E chi ha parlato di altezza dal suolo ?
Qui stiamo parlando di variazione del raggio terrestre in funzione del luogo e devo rammentarvi per l'ennesima volta che le coordinate fornite dal GPS sono corrette in base ad un modello geodetico, tipicamente il WGS84, ma può essere un altro, e se non consideri questa cosa, oltre al reale raggio terrestre, te lo scordi di fare calcoli precisi.

capisco invece benissimo il problema della precisone, tanto è vero che uso solo i minuti senza calcolare nemmeno i secondi,

Se ti limiti ai minuti introduci un errore enorme, p.e. all'equatore dove la circonferenza terrestre è 40000 km esatti, s.l.m, un singolo minuto d'arco corrisponde a 1,852 km, ovviamente salendo di latitudine l'errore diminuisce, ma rimane sempre molto alto a meno che non sei quasi ai poli.

astrobeed:

lesto:
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.

E chi ha parlato di altezza dal suolo ?
Qui stiamo parlando di variazione del raggio terrestre in funzione del luogo e devo rammentarvi per l'ennesima volta che le coordinate fornite dal GPS sono corrette in base ad un modello geodetico, tipicamente il WGS84, ma può essere un altro, e se non consideri questa cosa, oltre al reale raggio terrestre, te lo scordi di fare calcoli precisi.

io credo che il modello usi una sfera come riferimento, dovrei cintrollare le formule. In pratica il tuo modello divide la terra in tanti spicchi in base alla longitudine, oppure qualche altro metodo? puoi postare le formule?

astrobeed:

capisco invece benissimo il problema della precisone, tanto è vero che uso solo i minuti senza calcolare nemmeno i secondi,

Se ti limiti ai minuti introduci un errore enorme, p.e. all'equatore dove la circonferenza terrestre è 40000 km esatti, s.l.m, un singolo minuto d'arco corrisponde a 1,852 km, ovviamente salendo di latitudine l'errore diminuisce, ma rimane sempre molto alto a meno che non sei quasi ai poli.

quello è un problema secondario, aggiungere i secondi è un breve calcolo, basta portarli in secondi (/60)... ma vorrei trovare qualche libreria per aumentare la precisione, magari a virgola fissa o qualcosa del genere... conosci qualcosa?