Go Down

Topic: Official topic: multicotteri con arduino! (Read 361211 times) previous topic - next topic

astrobeed


non per fare il pingolo ma le dev sono divise in diversi files ma poi nelle stable sono riuniti in uno per semplificare la vita poi a chi deve fare il quadri che non sempre è un esperto di arduino-elettronica.


Guarda che il problema del MultiWii non è come è suddiviso in file, è una questione secondaria, il vero problema è che ci sono molte cose che sono scritte alla come capita capita e/o di puro copia incolla preso dal web, p.e. il pid non è vero pid, il kalman è molto generico e poco efficace, e tante altre cosette.
Intendiamoci non intendo denigrare il lavoro dell'autore, anzi tutt'altro, però ci sono grossi margini di miglioramento per le prestazioni, zero margini per aggiungere nuove funzionalità perché siamo al limite della CPU.

Quote

comunque allora buttiamo giù qualche equazione per il GPS? io sono un novellino in questo campo, posso fare qualcosina sul codice ma non molto  :(


E come intendi gestirlo il GPS ?
Ovvero ti basta rimandare i dati a terra per visualizzare la posizione del multicoso su una mapppa tramite pc oppure vuoi implementare una vera e propria navigazione autonoma ?
Nel primo caso non ci sono particolari problemi, nel secondo caso scordatelo di farlo con una MCU 8 bit qualunque essa sia, come minimo serve un dsPIC33, meglio ancora utilizzare un ARM di medio livello, p.e. un Cortex M3 sotto forma di modulo mBed.
Scientia potentia est

astrobeed


allora, se mi dai qualche output di esempio del gps (latitudine, longitudine etc..)


L'hai detto da solo, il GPS ti fornisce latitudine e longitudine, in più l'orario, la velocità e la quota, quest'ultima può avere grossi margini di errore.
Non devi fare altro che ragionare sulle coordinate espresse come meglio preferisci, per fare i conti è sicuramente più pratico usare il formato in gradi con i vari decimali, almeno otto (matematica a 64 bit obbligatoria), piuttosto che il formato gradi, minuti, secondi e millesimi di secondi.
Non ti scordare che al variare della latitudine e della longitudine cambia la distanza tra i meridiani i paralleli descrivono aree sempre più piccole andando verso i poli, buon divertimento  :)
Se non ti è chiaro il concetto osserva attentamente un mappamondo e guarda come cambiano gli spicchi compresi tra due meridiani e due paralleli.

p.s.
Stamattina sono buono, ricordati che le coordinate GPS sono referenziate ad un determinato modello geodetico, quindi per poterle utilizzare devi tenere conto anche del modello su cui lavorano.
Se pensi che determinare la distanza tra due coordinate GPS, anche di punti vicini, sia una cosa semplice e che esiste una formuletta semplice per farlo allora non sai in guaio ti stai cacciando  :D
Scientia potentia est

lestofante


Premesso che pure a me non piace come è scritto MulitWii, ma per altri motivi, mi spieghi cosa c'entrano le classi col scrivere un programma diviso in più file ?
Guarda che nulla vieta di usare un file per ogni funzione con i relativi file.h, tecnica normalmente usata quando su un programma ci lavora più di una persona.
Lo stesso IDE di Arduino permette di dividere il programma in più file, cosa praticamente obbligatoria da fare quando lo sketch cresce troppo per via delle pesanti limitazioni dell'editor dell'IDE di Arduino, cosa a cui preferisco ovviare utilizzando un vero editor per programmatori esterno.
Per quanto riguarda le #define in buona parte servono per la compilazione condizionale, ovvero permettono di decidere quali parti del programma compilare in funzione dell'hardware utilzzato, pure queste non hanno nulla a che vedere con le classi e sono indispensabili, semmai poteva raggrupparle in un apposito file .h di definizione invece di lasciarle dentro il programma rendendolo ostico da leggere.


io uso una classe per gestire i motori, contenuta nella classe del pid, poi una classe "stabilizzazione" che esegue l'algoritmo che contiene una classe IMU che legge i sensori, ed infine una classe che si occupa di leggere la radio tramite interrupt. ogni sensore/algoritmo di stabilizzazione/settaggio dei motori è (virtualmente, visto che per ora ce né solo una) una classe a parte. Il codice rimane molto più pulito e intercambiabile, e comunque un ciclo di aggiornamento dura meno di 2ms..


scusami ma quà non sono d'accordo. Il vantaggio delle classi, è che oltre a contenere funzioni possono contenere anche valori. In pratica sono una struct che oltre a contenere variabili, contiene anche funzioni (cosa possibilissima da fare in C usando puntatori a funzioni, credo che siano stati fatti proprio così i linguaggi ad oggetti...)

in oltre esiste una cosa chiamata ereditarietà ed overloading dei metodi. Per esempio, la mia classe astratta dei sensori non può essere usata (è astratta), ma può essere estesa. nell'estensione puoi scrivere tutto il codice che vuoi, ma sei costretto a fornire i metodi della classe astratta, ovviamente seguendo le linee guida contenute in essa. Quindi, nel mio caso, sei costretto a creare un metodo init() che eventualmente inizializza il sensore, un metodo update() che legge i volori dai sensori, e un metodo leggi() che ritorna un array di float dal sensore (come e cosa ci sia nell'array è una linea guida che varia dalla tipologia)
Il mio programma terrà la tua classe in una variabile di tipo superclasse astratta, quindi potrà usare solo i metodi che ti ho esplicitamente costretto a creare, ma questio metodi al loro interno potranno usare tutte le funzioni di classe. Quindi se vuoi cambiare un sensore, non modifichi le define, ma solo l'istanziamento della classe.
Così eviti tutta la storia della compilazione condizionale, anzi, se vuoi modificare un sensore, sai subito dove mettere le mani, anzichè impazzire in un pde chilometrico.

Poi ovvio che puoi usare le librerie, ma io sono un fan della programmazione ad oggetti (anche se un poco rallentano il codice)


Quote

Quando finalmente riuscirò a fare il primo volo(cioè appena sistemo definitivamente il wmp+nunchuck) posterò tutto il codice.


Il mio consiglio è di lasciar perdere il Nunchuk come sensore accelerometrico, troppo bassa la risoluzione per essere realmente utile, con gli stessi soldi acquisti un sensore decisamente migliore e senza tutti i problemi di interfacciamento attraverso il WMP.


già, l'ho notato, ma è quello che ho in casa. E fare un ordine apposta spendo più dispedizione che di sensore. Certo ci fosse qualcosa che trovi al supermarket...




non per fare il pingolo ma le dev sono divise in diversi files ma poi nelle stable sono riuniti in uno per semplificare la vita poi a chi deve fare il quadri che non sempre è un esperto di arduino-elettronica.


Guarda che il problema del MultiWii non è come è suddiviso in file, è una questione secondaria, il vero problema è che ci sono molte cose che sono scritte alla come capita capita e/o di puro copia incolla preso dal web, p.e. il pid non è vero pid, il kalman è molto generico e poco efficace, e tante altre cosette.
Intendiamoci non intendo denigrare il lavoro dell'autore, anzi tutt'altro, però ci sono grossi margini di miglioramento per le prestazioni, zero margini per aggiungere nuove funzionalità perché siamo al limite della CPU.


una cosa che non ho ancora capito è perchè hanno riscritto il protocollo i2c usando direttamente i registri...che gli costava usare la wire.h?

Quote
Stamattina sono buono, ricordati che le coordinate GPS sono referenziate ad un determinato modello geodetico, quindi per poterle utilizzare devi tenere conto anche del modello su cui lavorano.
Se pensi che determinare la distanza tra due coordinate GPS, anche di punti vicini, sia una cosa semplice e che esiste una formuletta semplice per farlo allora non sai in guaio ti stai cacciando  smiley-grin


pensavo ad un atmega solo per il GPS... però devo ammettere che ancora non ho iniziato nemmeno a spulciare il protocollo e la sua "traduzione". Quando sarà tempo (ovvero il quad vola, con magnetometro e barometro che ancora devo comprare e implementare) sicuramente ci sbatterò la testa, e se ardino dovesse fallire (e le finanze lo permetteranno :P) mi prenderò volentieri qualcosa di superiore come il dsPIC33 o (non vedo l'ora) un'ARM.
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

astrobeed

#333
Jul 29, 2011, 05:35 pm Last Edit: Jul 29, 2011, 05:47 pm by astrobeed Reason: 1

scusami ma quà non sono d'accordo. Il vantaggio delle classi, è che oltre a contenere funzioni possono contenere anche valori


Voglio sperare che non stai cercando di spiegare a me cosa sono e a cosa servono le classi ?  :)

Quote

Così eviti tutta la storia della compilazione condizionale, anzi, se vuoi modificare un sensore, sai subito dove mettere le mani, anzichè impazzire in un pde chilometrico.


Ecco qui ti sfugge completamente il senso della compilazione condizionale, che tra parentesi si usa anche in C++.

Quote

ma io sono un fan della programmazione ad oggetti (anche se un poco rallentano il codice)


Un poco ?
Il peso, in termini di memoria usata, sia flash che ram, e di rallentamento velocità d'esecuzione è molto alto, sopratutto su una piccola MCU a  8 bit, e questo è uno dei motivi della lentezza di Wiring.
Per lavorare in modo efficiente, parliamo di software di sistema e controllo di processo, su una piccola MCU, ma anche su un super micro, il solo ed unico linguaggio, a parte l'assembly, è, e almeno per il momento rimane, il C ANSI, tutto il resto è fuffa  :)

Quote

già, l'ho notato, ma è quello che ho in casa. E fare un ordine apposta spendo più dispedizione che di sensore. Certo ci fosse qualcosa che trovi al supermarket...


Ovvio che non ha senso spendere 10 Euro di corriere per 15-20 Euro di merce, però alla prima occasione metti in conto la sostituzione del Nunchuk con un normale accelerometro.

Quote

una cosa che non ho ancora capito è perchè hanno riscritto il protocollo i2c usando direttamente i registri...che gli costava usare la wire.h?


Non ho ancora approfondito il discorso I2C del MultiWii, ma credo abbia riscritto le routine per renderle più efficienti ed evitare alcune condizioni di blocco che ci sono nelle wire.h

Quote

pensavo ad un atmega solo per il GPS... però devo ammettere che ancora non ho iniziato nemmeno a spulciare il protocollo e la sua "traduzione".


Il problema non è interpretare le sentenze NMEA, sono solo delle stringhe ASCII con un certo formato e i dati sono scritti in chiaro, ecco un esempio:

Code: [Select]

$GPRMC,151036.999,A,4536.81050,N,00857.63140,E,0.09,27.90,260308,,,A*5F


$GPRMC        è l'identificatore della sentenza, ne esistono molti tipi diversi perché si usano anche per altra tipologia di strumenti.
151036.999   ora UTC (hhmmss.sss)
A                stato: A = Active, valido; V = Void, nullo
4536.81050    latitudine (ddmm.mmmmm)
N                N = nord; S = sud
00857.63140  Longitudine (dddmm.mmmmm)
E                E = est; W = ovest
0.09                Velocità in nodi
27.90        Direzione di movimento in gradi reali
260308        Data (ddmmyy)
                Variazione / Declinazione Magnetica in gradi (*)
                Versi della variazione / declinazione (*)
A                Tipo di rilevazione: A = Autonomous
*5F                Checksum

Alcuni campi possono non essere presenti, sono quelli vuoti tra le virgole, dipendono dalle caratteristiche tecniche del GPS, in pratica basta un parser per estrapolare in un vettore i dati reali che ci interessano.
Il vero problema è tutta la parte matematica necessaria per calcolare la distanza tra due coordinate GPS e che, per via della risoluzione richiesta, è obbligatorio l'uso della matematica a 64 bit.
Scientia potentia est

lestofante

la compilazione condizionale rimane, ma anzichè essere sparsa per tutto il codice rimane solo all'inizializzazione delle classi. molto più comodo no?

per quanto riguarda la lentezza, sinceramente per ora uso circa 7 o 8 classi, ma non ho assolutamente problemi di lentezza del codice, quindi non vedo perchè preoccuparsi (per ora). Pensavo di diminuire di 2 classi, semplicemente evitando di usare una classe per sensore (una per i giro, una per gli accelerometri, etc..) e usarne una "globale" detta IMU (già presente che raccoglie le classi sensori). Ma comunque per ora devo far andare i sensori :)

per l'i2c ho notato che la wire è bloccante, e l'unico modo per non essere "bloccati" è usando gli interrupt (fornisce già le funzioni da "overridare")

per il GPS sarebbe da aprire un post a parte perchè bisognerebbe prima di tutto capire quale matematica serve, creare il tipo di dato adatto, e mettere assieme tutti i pezzi.. non facile
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

FEDERICO

Per il gps io ci sono, ho anche un gps da 40e che ancora non ho avuto tempo di interfacciare ad arduino...
Invece per la questione di ampliamento delle funzionalita', non si potrebbe pensare di usare 2 o piu'  atmega?
Federico - Sideralis
Arduino &C: http://www.sideralis.org
Foto: http://blackman.amicofigo.com

superlol


....

per il GPS sarebbe da aprire un post a parte perchè bisognerebbe prima di tutto capire quale matematica serve, creare il tipo di dato adatto, e mettere assieme tutti i pezzi.. non facile

http://arduino.cc/playground/Multiwii/GPS
http://www.aug-altogarda.it/ <- Il nuovo AUG per basso trentino e dintorni!

milvusmilvus

ragazzi io posso darvi una mano per l' algoritmo del gps, ma solo in modo teorico, perchè nono ho ancora messo l emani ne su arduino ne su un gps, e quindi sono un po con le mani legate...

superlol

beh comunque come ha detto astro bisogna ripiegare su un altro processore, però credo sia fattibile poi si potrebbe senza fare troppe modifiche al codice multiwii attaccare i giroscopi ecc a questa MCU che legge anche i dati e ricrea dei "falsi" dati come venissero dalla IMU in modo da ridirigere nel punto giusto il quadri  :smiley-roll-blue: insomma un lavoro disumano  ]:D
http://www.aug-altogarda.it/ <- Il nuovo AUG per basso trentino e dintorni!

astrobeed

Fino a domani tarda mattinata sono incasinato con un lavoro che devo assolutamente finire, dopo vi passo la matematica di base necessaria per calcolare il vettore 3D, quindi modulo e due angoli, tra due coordinate GPS non sulla stessa quota, così finalmente vi rendete conto della quantità di calcoli e della loro complessità.

p.s.
Anche volendo semplificare la cosa ragionando solo in 2D non è che cambia molto la complessità del tutto, per passare dal 2D al 3D finale basta applicare Pitagora.
Scientia potentia est

ratto93


beh comunque come ha detto astro bisogna ripiegare su un altro processore, però credo sia fattibile poi si potrebbe senza fare troppe modifiche al codice multiwii attaccare i giroscopi ecc a questa MCU che legge anche i dati e ricrea dei "falsi" dati come venissero dalla IMU in modo da ridirigere nel punto giusto il quadri  :smiley-roll-blue: insomma un lavoro disumano  ]:D

Si e che MCU???
voglio dire se comincia a diventare un ARM magari in package strani da 200 pin diventa complicato l'uso per utenti normali e non super accessoriati... e per di più non è più arduino  :smiley-mr-green:
Se corri veloce come un fulmine, ti schianterai come un tuono.

astrobeed


Si e che MCU???


Da decidere.

Quote

voglio dire se comincia a diventare un ARM magari in package strani da 200 pin diventa complicato l'uso per utenti normali e non super accessoriati... e per di più non è più arduino  :smiley-mr-green:


Esistono molte board con ARM che costano relativamente poco e sono già dotate di tutto quello che serve per farlo funzionare.
Ho già linkato a titolo d'esempio l'mBed che ha i connettori a passo 2.54 pertanto facilmente utilizzabile, oltretutto ha una filosofia di programmazione molto simile ad Arduino anche se non usa Wiring, ovvero non è necessario sapere esattamente come funzionano le periferiche interne e la miriade di registri macchina per farlo funzionare.
Arduino ha i suoi limiti, la navigazione real time con GPS è uno di questi.
Scientia potentia est

milvusmilvus

#342
Jul 29, 2011, 07:47 pm Last Edit: Jul 29, 2011, 09:21 pm by milvusmilvus Reason: 1
vi scrivo un algoritmo in linguaggio "umano" poi è da implemetare... io farei cosi, è molto rozzo ma dovrebbe funzionare con poca potenza di calcolo:

assumerei la posizione attuale, come posizione 0;0 del piano cartesiano quindi:

x = longTarget - longAttuale
y = latTarget - latAttuale

quindi:
distanza = sqrt(x^2*y^2)

avendo i 2 cateti, posso sapere l' angolo, quindi

a = arctg(x/y)

ora il problema è: come faccio a ruotare il multicottero di a??? (questo vedetelo voi perche non posso fare porve :D)

poi per semplificare sia la parte dell altitudine, sia evitare di troare ostacoli, salirei ad un altezza si 20m, mi ruoterei e poseguirei verdo il target, controllando 2 volte al secondo la direzione e la distanza

quando

distanza < 1m

mi fermo e scendo alla quota target


la distanza iniziale, non sara corretta, ed avrà un errore rilevante, ma ricalcolando la distanza, l' errore diminuisce, e siccome il tragitto effettivo, è maggiore di quello rettilineo calcolato, si arriverà ad un punto in cui il rov, avra effettuato piu metri di quelli calcolato all inizio, ma sara comunque a piu di 1m dal target, e quindi continuerà a muoversi in quella direzione, sarebe utile rallentare quando la distanza dal target è di 10m.... per muoversi, in modo obliquo, direttamente verso il punto target, è un problema sia di calcolo, che di controllo del mezzo, perche muoversi con un angolo da terra di tot gradi puo creare problemi con la gestione della potenza dei motori, visto che sono loro che si occupano di sollevarsi di quota

ratto93

Quote
Ho già linkato a titolo d'esempio l'mBed che ha i connettori a passo 2.54 pertanto facilmente utilizzabile......

Perdono,,, mi era sfuggito....
Se corri veloce come un fulmine, ti schianterai come un tuono.

superlol

aggiornato playground multiwii chiedo conferma nelle resistenze di pullup e pin, inoltre ho messo giù le prime idee per il GPS (messo le equazioni di milvusmilvus e la scheda di Astrobeed, ovviamente potete editare quello che vi pare, mi pare ovvio, anzi FATELO!!!  XD)
http://www.aug-altogarda.it/ <- Il nuovo AUG per basso trentino e dintorni!

Go Up