Official topic: multicotteri con arduino!

milvusmilvus: il funzionamente è abbastanza semplice, ma non ho capito come fa a capire quanto il laser colpisce l' oggetto,

In teoria è semplicissimo, in pratica è complicatissimo, tanto per cominciare la luce in un nanosecondo percorre circa 29.8 cm (nell'aria la velocità della luce è circa 298.000 km/s), quindi primo problema come misurare il tempo con la risoluzione di almeno 1 ns per avere la precisione spannometrica di +/-30 cm. Secondo problema, per vedere il riflesso del laser con la necessaria rapidità serve un costosissimo fotodiodo a valanga e un delicatissimo amplificatore a rumore praticamente 0 e banda ultra ampia, parliamo di GHz. Terzo problema, raccogliere molta luce in poco tempo se non si vuole fare la misura in tempi lunghissimi perché vengono usati treni d'impulsi laser successivi in tempi molto precisi per aumentare la quantità di luce ricevuta e migliorare la sensibilità del sensore. Tutto questo ha un costo enorme se non fai una produzione in serie di molte unità, per non parlare delle varie competenze in campo analogico e digitale necessarie per il progetto. Non è che i telemetri laser costano un capitale, da qualche centinaio a diverse migliaia di Euro, per un capriccio dei produttori, costano tanto perché c'è un elevato costo dei componenti, non ultimo il laser stesso che non è certo il puntatorino cinese, e di sviluppo del progetto. Esistono sistemi di misura della distanza tramite laser che non utilizzano il tempo di volo, p.e. tramite misura dell'angolo di fase di una portante a 100-150 MHz che modula il laser, ma risolvono solo il problema della misura del tempo a livello del picosecondo ( 3 mm di risoluzione), tutti gli altri rimangono immutati. Esistono anche sistemi telemetrici basati sull'errore di parallasse leggendo la posizione apparente del punto laser tramite una telecamera, ma richiedono la potenza di calcolo di un processore molto veloce per via dell'analisi tramite visione artificiale e pure questi sono ingombranti e pesanti. Per farla breve scordati il telemetro laser sul quadricottero e scordati di realizzarlo con Arduino.

astrobeed:

milvusmilvus: io ho visto video di tricotteri che toccavano punte di 60 km/h ma lanciandoli al massimo della potenza consumano molto di piu.... e la durata arriva a 5 min....

La velocità massima arriva senza problemi anche oltre i 100 km/h, esattamente come per un modello di elicottero. Un classico errore è confondere la potenza necessaria per accelerare e quella necessaria per il volo, quando si passa dal volo stazionario a quello traslato le quattro eliche diventano a tutti gli effetti un'ala con la conseguente portanza, più veloci si vola e meno potenza serve per sostenere il mezzo. Ovviamente c'è un punto oltre il quale la resistenza aerodinamica invalida l'effetto portante dei rotori e serve maggiore potenza per volare rispetto a quella per il volo stazionario. Quale sia la velocità massima per il volo traslato ove si raggiunge la massima efficienza, cioè minor consumo di energia in funzione dello spazio percorso, dipende da molti fattori, però mi sento di azzardare che per un quadricottero ben costruito sia attorno ai 30-35 km/h, diciamo che se in hovering le batterie durano 10 minuti in questa condizione di volo durano almeno 13-14 minuti.

1° legge della dinamica: un corpo non soggetto a nessuna forza si muove di moto rettilineo uniforme 2° legge della dinamica (1° di Newton): F=ma

questo dovrebbe farti capire che una volta portato alla giusta velocità basta che il quadri si stabilizzi orizzontalmente e sostenga solo il suo peso (tipo hovering) che manterrà la sua velocità (ok c'è l'attrito dell'aria ma avete capito il senso).

comunque tornando sul tema del posizionamento come ho detto non possiamo prendere valori come se si muovesse su un piano senza avere troppe complicazioni e calcoli strani? tanto poi sulla terza dimensione agisce il barometro (io non mi fido dell'altitudine dettata dai GPS, la trovo molto approssimativa)

superlol: comunque tornando sul tema del posizionamento come ho detto non possiamo prendere valori come se si muovesse su un piano senza avere troppe complicazioni e calcoli strani? tanto poi sulla terza dimensione agisce il barometro (io non mi fido dell'altitudine dettata dai GPS, la trovo molto approssimativa)

Il problema di base sono le coordinate del GPS, come ho già puntualizzato non sono riferite ad un piano, sono corrette in base ad un modello geodetico della terra, ed è questo che complica notevolmente le cose, oltre al fatto che comunque ti muovi in uno spazio 3D e i calcoli ne devono tenere conto.

pensavo vi fossero sistemi telemetrici, lowcost e con precisione “ridicola” diciamo che 10 cm di errore mi basterebbero, tanto un eventuale atterraggio lo farei con il sensore ad ultrasuoni… che ha altri problemi… comunque era solo curiosità.

un corpo a 60km/h ne ha di attrito… per questo io voglio fare un tricottero piu aredinamico possibile…

per piccole distanze si puo considerare il piano a 2 diimensioni, ed affidare il cacolo l’ altezza al barometro o fare una retta tra i due punti ache obliqua. ma senza tener conto della sfericità terrestre, se poi devi fare qualche km… allora ildiscorso cambia

le coordinate de tipo, 40° 16’ 40" N e 16°… E sono riferite al piano, e mni pare che non tengano conto dell altrezza, comunque prendi l’ angolo rispetto al nord, da una posizione ad un altra e ti movi con quell angolo finche la dinzanza non diventa <x le coordinate possono anche essere espresse in patate si dovrebbe raggiungere comunque la meta :smiley:

spiego meglio;
asse y —>nord-sud
asse x —> est ovest

suppongo di stare nella posizione 0;0 e di dover andare nella posizione 5;5 la bussola mi dice che sono diretto (la parte d’avanti) verso il lato positivo dell asse y, quindi nord, per andare nel punto 5;5 mi devo girare di 45°, e spostarmi di ?50. se faccio cosi la sfericità terrestre crea problemi.
invece se mi giro di 45° e inizio ad andare avanti, finchè la posizione letta dal gps(il punto in cui mi trovo) è uguale a quella del punto in cui devo andare, è zero non dovrei avere problemi, oviamente bisogna evitare di spuperare il punto, correggere l’ angolo in caso di vento, rallentare al momento opportuno ecc

milvusmilvus:
le coordinate de tipo, 40° 16’ 40" N e 16°… E sono riferite al piano

Eccome se tengono conto dell’altezza, infatti il GPS raggiunge la massima precisione solo quando aggancia almeno 4 satelliti e può misurare anche la quota.
Altro punto importante, le coordinate non semplicemente gradi minuti e secondi, ci sono pure i centesimi/millesimi di secondo altrimenti te la scordi la precisione, ho già spiegato a quanto corrisponde un singolo secondo d’arco come spazio reale.
Tutte queste cose messe assieme rendono il problema molto più complesso di come può sembrare ad una prima analisi superficiale.

40°35'41.97"N 16° 9'30.30"E queste sono delle coordinate prese con il mio cellulare, sono per un rilevamento faunistico, e sono abastanza precise per essere usate, per ritrovare il posto (una pietra in mezzo al fiume) i gps tengono anche conto dell' altezza, ma le coordinate che restituiscono sono riferite al piano, poi si aggiunge l' altezza

42459/360 = 117.94166666667

117.942/60 = 1.9657

1.9657/60 = 33cm

33cm è la distanza (all'equatore) tra 2 secondi di longitudine.

ho sbagliato i calcoli? :roll_eyes:

anche se dovremmo contare che per semplificari i conti sarebbe meglio ragionare non in gradi primi secondi ma in gradi decimali

A me torna che 1" sono 30,9m

La circonferenza terrestre, all'equatore, sono esattamente 40.000 km pertanto 1 secondo d'arco vale :

40000/(360*60*60) = 0.0309 km = 30.9 metri.

In un post precedente avevo erroneamente scritto 300 metri, comunque il succo del discorso non cambia, occorre tenere conto almeno dei centesimi di secondo, meglio se dei millesimi, alcuni GPS arrivano addirittura a computare i decimillesimi. Ovviamente le ultime cifre delle coordinate cambiano in continuazione per via dell'errore che ha una sua variazione ciclica, però vengono utilizzate per mediare i vari conteggi e migliorare la precisione globale, più o meno lo stesso discorso di quando si prendono più campioni dall'ADC per poi farne la media in modo da ridurre il rumore. Da non scordarsi che un conto è la reale precisione e un conto è la risoluzione di una misura, nel caso del GPS la risoluzione è molto alta, però la reale precisione è almeno un ordine di grandezza minore.

Ho montato al volo su una breadboard, vedere immagine allegata, la schedina del Wii Mote Plus e un accelerometro ADXL345, ho riconfigurato lo sketch di multiwii per questa configurazione, è stato necessario riconfigurare anche l’assegnazione degli assi, e ho messo il tutto sotto torchio.
Dopo oltre due ore di funzionamento continuato non ho riscontrato nessuno sganciamento del Wii Mote Plus come paventato dall’autore del software, però il problema potrebbe dipendere dalla configurazione Nunchuk più WMP, nel mio caso sto usando un accelerometro diverso.
Per il momento il tutto pare comportarsi bene, ho provato ad agitare non poco il gruppo sensori senza riscontrare sostanziali perdite di assetto inteso come capacità di livellare il multicottero, anche perché più di questo il multiwii non può fare.

potresti fare la stessa prova ma facendo andare il WMP a 400.000kbit/s, modificando adeguatamente il twi.h, secondo le specifiche (e provato di persona) funziona. WMP+nunchuck oltre all'obbligo di viaggiare a 100.000kbit/s e di fare una lettura ogni 3ms, pena sovrapposizione dei dati, per ora mi hanno funzionato senza problemi, farò a breve una prova a lungo termine... per ora gli unici problemi li ho avuti col nunchuck da solo in fase di inizializzazione(si blocca l'inizializzazione), ma per ora non si è più verificato. Che codice stai usando?

edit: è ancora prematuro, ma per schiarirmi le idee: che magnetometro consigliate? quali specifiche e perchè deve avere per essere scelto? stessa cosa per il barometro.

magari potessi fare io le prove.... non ho comprato ancora niente.... aspetto 1800€ per un lavoro che ho fatto(li aspetto da febbraio... grazie Tremonti!), e fino a quando non li avrò sono fermo a google sketchup...almeno ho tempo di proggettarlo come si deve.... ancheperche ho intenzione di farlo il piu possibile impermeabile, quindi devo progettarlo in modo da poterlo chiudere ermeticamente...

astrobeed: Dopo oltre due ore di funzionamento continuato non ho riscontrato nessuno sganciamento del Wii Mote Plus come paventato dall'autore del software, però il problema potrebbe dipendere dalla configurazione Nunchuk più WMP, nel mio caso sto usando un accelerometro diverso.

Dov'e' che e' specificato questo difetto? Non ho trovato il riferimento... Io possiedo un adxl335 che pero' non e' ne' i2c ne' figo come il tuo 345, secondo te c'e' modo di implementarlo come hai fatto tu? Eee come mai hai una scheda del WMP? :-) Ti sei incuriosito? Fede

[OT] @ Uwe, in qualità di Moderatore del Forum: Suggerisco, dopo quasi 1600 visite e 260 contatti, che questo Topic venga stickato, ora che hai il potere di farlo. Superlol ha avuto questa idea ed è riuscito nel suo intento di attivare un Topic specifico anche se non "ufficiale", visto che non è partito dagli amministratori. Mi preme sottolineare che non ho alcun interesse personale su questo argomento, infatti non sono mai intervenuto; quindi il suggerimento è assolutamente disinteressato. Buona continuazione a tutti.

lesto: potresti fare la stessa prova ma facendo andare il WMP a 400.000kbit/s, modificando adeguatamente il twi.h, secondo le specifiche (e provato di persona) funziona.

Già fatto, a 400 kHz il WMP non funziona, ho quello originale Nintendo, però è strano perché in diversi siti dicono che funziona a 400 kHz, dovrò fare qualche verifica con il solo WMP e software dedicato.

Che codice stai usando?

L'ultima release del multiwii, la 1.7, ho solo modificato alcune define e l'ordine degli assi accelerometrici perché il posizionamento sulla breadbord non è quello previsto dal progetto.

edit: è ancora prematuro, ma per schiarirmi le idee: che magnetometro consigliate? quali specifiche e perchè deve avere per essere scelto? stessa cosa per il barometro.

Per il sensore di pressione il BMP085, già previsto in modo nativo da multiwii. Come avevo già sottolineato qualche post fa il BMP085 è un sensore ottimo e molto preciso, costa pure meno degli altri normalmente usati, p.e. MPX4115, col vantaggio che integra un adc a 19 bit, indispensabile per poter discriminare il singolo metro di quota, e un sensore di temperatura che consente di compensare la misura senza doverne usare uno esterno. Come magnetometro il multiwii prevede il HMC5843 o HMC5883, sulla carta il secondo sembra essere migliore del primo e costa pure di meno, però c'è un piccolo giallo da risolvere, il prezzo di sparkfun per la breakout board del 5843 è 19$, da Watterott costa 43.20 Euro (attualmente non disponibile). Va bene che sul prezzo in $ tocca aggiungere iva e dazio, ma è un +25% e col cambio attuale il costo in Euro è meno di quello in dollari, 19 / 1.4 * 1.25 = 17 Euro, addirittura vende il solo sensore, ed è un case QFN, a ben 17.26 Euro, costa molto meno acquistarlo da Digikey dove il 5883 (a quanto pare il 5843 è un prodotto vecchio e sta per andare fuori produzione) costa 3.6 Euro ivati. Questi sensori in specifico non li ho mai usati quindi non so dirti se sono realmente validi per questa applicazione, al prossimo ordine che faccio da Digikey (next week) ne prendo qualcuno per provarli.

astrobeed: [...]

Già fatto, a 400 kHz il WMP non funziona, ho quello originale Nintendo, però è strano perché in diversi siti dicono che funziona a 400 kHz, dovrò fare qualche verifica con il solo WMP e software dedicato.

[...]

L'ultima release del multiwii, la 1.7, ho solo modificato alcune define e l'ordine degli assi accelerometrici perché il posizionamento sulla breadbord non è quello previsto dal progetto.

[...]

a 400kHz il normale non funziona, solo alcuni cloni che hanno gli itg3200 o simili e diversi integrati di conversione riescono ad andare a 400kHz

noi che usiamo arduino potremmo anche provare del dev che sono le ultime uscite con nuove integrazioni. sono piene di bug ma potremmo dare una mano alla community (sono divise in più files quindi è più comodo verificarle e modificarle).

inoltre nelle dev è previsto il supporto anche a più sensori tra cui il supporto nativo alla nuova freeimu v0.3.5_MS che contiene giroscopi, accelerometri e magnetometro su 3 assi nonchè anche barometro di precisione.

Federico ne avrà sentito parlare visto che ora guarda anche sul forum del barone XD

Federico: Dov'e' che e' specificato questo difetto? Non ho trovato il riferimento...

Ne viene fatto riferimento sia dove spiega perché usa un pin di Arduino per alimentare il WMP, con i due diodi in serie, e da qualche altra parte che non mi ricordo :) In pratica sfrutta lo stato logico 1 di un pin come alimentazione, in caso di perdita della comunicazione con il WMP e il Nunchuk lo porta a 0 e poi nuovamente a 1 per resettare i due sensori e ripristinare la comunicazione. Però in oltre due ore di funzionamento continuo non ho riscontrato nessun blocco del funzionamento.

Io possiedo un adxl335 che pero' non e' ne' i2c ne' figo come il tuo 345, secondo te c'e' modo di implementarlo come hai fatto tu? Eee come mai hai una scheda del WMP? :-)

L'ADXL335 è pure meglio per questa applicazione, per contro ha l'uscita analogica e devi usare tre canali ADC per leggerlo e sul ATmega hai solo 10 bit di risoluzione, puoi fare un leggero oversampling e portarli a 12 bit. Il multiwii prevede l'uso di un accelerometro con i tre assi analogici su ADC, #define ADCACC, tocca un attimo vedere come tratta i valori ed eventualmente ritoccare la relativa funzione per adattarla al 335. Ho preso il WMP Lunedì mentre ero da Unieuro alla ricerca di un televisore di piccole dimensioni, l'ho visto e l'ho preso, il resto è venuto da solo :)

superlol: a 400kHz il normale non funziona, solo alcuni cloni che hanno gli itg3200 o simili e diversi integrati di conversione riescono ad andare da 400kHz

Sul WMP originale i due giroscopi, uno a due assi e uno a singolo asse, sono con uscite analogiche, quindi non hanno nulla a che vedere con la velocità della I2C, poi c'è un micro che legge gli assi con ADC a 14 bit, sicuramente fa anche qualche operazione di filtro, e invia i dati sulla I2C, inoltre c'è un secondo bus I2C indipendente al quale è possibile collegare altri device wii. Da notare che il WII mote dialoga sulla I2C a 400 kHz, l'avevo verificato a suo tempo e comunque lo trovi confermato qui che è la fonte primaria di informazioni sull'hardware wii, quindi non vedo nessun motivo per cui il WMP originale non deve funzionare a 400 kHz, salvo problemi del multiwii a tale frequenza. Comunque in giornata avrò la risposta definitiva perché provo a dialogare con il WMP in diretta scrivendo io uno sketch dedicato così diamo subito la risposta a questo mistero.

superlol: Federico ne avrà sentito parlare visto che ora guarda anche sul forum del barone XD

Dietro tuo consiglio :-) Mi hai scoperto! Ho letto cosi' tanti topic che gia' non capisco piu' niente :-) Pero' mi pare gente molto competente e sto trovando molte cose interessanti... Se non mi sbaglio, ad occhio e croce c'e' pure un utente redfox74 che aveva scritto a lungo sul nostro forum

Risolto il "mistero" del WMP a 400 kHz, la colpa è delle resistenze di pull up, se sono troppo alte il segnale viene fortemente distorto e diventa illeggibile. Quando ho montato il tutto sulla breadboard come pull up ho messo 5.6k, un valore abbastanza alto, per risparmiare un pochino di corrente sul 3.3V, con l'ADXL 345 non ci sono problemi, lavora benissimo e il segnale è ottimo, mettendo sullo stesso bus il WMP il segnale degrada notevolmente a 400 kHz. Il motivo è legato alle specifiche della I2C che non stabiliscono una distanza massima, il limite è dato dalla capacità complessiva della linea, cavi e device, che non deve superare i 400 pf, inoltre la corrente minima che deve scorrere sulle resistenze di pull up è stabilita a 3 mA, se poi ci si vuole attenere alle specifiche I2C con carico di linea fino a 200 pf vanno bene le pull up, tra 200 e 400 pf andrebbe usato un generatore di corrente a 3 mA. Con la tensione di 3.3V e 5.6 k scorrono solo 3.3/5.6k = 590 uA, molto meno di quello previsto normalmente per il bus I2C, va bene lo stesso a patto che la capacità complessiva della linea non sia tale da produrre una costante di tempo (RpullIp * Clinea) che rallenta eccessivamente i fronti di salita e discesa del segnale. Nel caso del WMP + ADXL345 + cavi + breadboard a quanto pare la capacità complessiva è decisamente alta e l'I2C non funziona, mettendo come pull up delle 3.3k il tutto ha iniziato a funzionare, al controllo strumentale il fronte di salita dei segnali è ancora molto lento, ma nei limiti di funzionamento, con 1.5 k ( = 2.2 mA a 3.3 V) i segnali sono buoni. Credo che i problemi di sgancio del WMP citati dall'autore siano dovuti pure a questo problema, cosa ancora più strana è che nelle indicazioni di collegamento tra il WMP e Arduino, nel suo caso la versione nano, non ci sono proprio le pull up, e senza non può funzionare.