Go Down

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

FEDERICO

Dopo un po' di sklero ho modificato la funzione per l' adxl335 (posizionato come in foto) cosi
Code: [Select]

void adc_ACC_getRawADC() {
  //Originale MultiWii
  //accADC[ROLL]  =  -analogRead(A1);
  //accADC[PITCH] =  -analogRead(A2);
  //accADC[YAW]   =  -analogRead(A3);
 
  //Modifica Fede
  accADC[ROLL] = analogRead(A3); // X
  accADC[PITCH] = analogRead(A2); // Y
  accADC[YAW] = -analogRead(A1); // Z

  acc_1G = 75;
  acc_25deg = 32; // = acc_1G * sin(25 deg)
  accPresent = 1; 
}


Non ho capito bene perche' ho fatto cosi :-) ma sembra girare correttamente. A dire il vero a fondo corsa, quando arrivo intorno ai 90 gradi o piu', il disegno va un po' strano, ma dovrei provare con un pc + decoroso di questo che mi va a cpu al 100% quasi quando lancio il sofware di test)

Federico - Sideralis
Arduino &C: http://www.sideralis.org
Foto: http://blackman.amicofigo.com

astrobeed

#481
Aug 03, 2011, 08:20 am Last Edit: Aug 03, 2011, 08:22 am by astrobeed Reason: 1
Sarebbe il caso di cominciare a definire nei dettagli questo progetto, altrimenti non partirà mai.
Prima di tutto è bene definire lo scopo finale, ovvero realizzare un UAV nel vero senso della parola, poi ci saranno vari gradi intermedi che permetteranno di optare per scelte diverse come complessità, costi e prestazioni.
L'elettronica non può essere composta da un singolo micro, nemmeno se è un super micro, una scelta ottima l'ha fatta MikroKopter che ha diviso il tutto in due schede principali, la FlightCtrl e la NaviCtrl.
La FlightCtrl  controlla l'assetto del mezzo, pilota gli ESC, accetta i comandi da una normale ricevente per aeromodelli, può essere governata dalla NaviCtrl, è realizzata attorno ad un ATMEGA644 @ 20MHz, i sensori, tre giroscopi, un accelerometro a triplo asse, un sensore di pressione, sono montati sulla scheda e sono tutti di tipo analogico, vengono letti tramite ADC.
La NaviCtrl si occupa della navigazione, oltre alle informazione della IMU utilizza un GPS e una bussola, è realizzata attorno a una MCU con core ARM9, non è dichiarato il clock, ma normalmente questi core lavorano a oltre 200 MHz, questa scheda permette al MikroKopter di volare da solo tra vari waypoint, può mantenere l'hovering a punto fisso, ma non è in grado di atterrare e decollare da solo.
Ho fatto questa introduzione perché vorrei adottare una soluzione come la loro, cioè una scheda base Arduino like che si occupa della stabilizzazione e che permette il volo assistito in varie modalità, una scheda che permette la navigazione e il volo autonomo, quest'ultima richiede per forza un processore ben più potente di qualunque AVR a 8 bit.
Dato che "dovrebbe" essere in arrivo a breve un Arduino ufficiale a 32 bit direi che per il momento è il caso di aspettare per la parte navigazione, tanto lo sviluppo e la messa a punto del software per la scheda base richiederà come minimo un paio di mesi quindi inutile crearsi problemi adesso su che hardware utilizzare per la navigazione GPS.
In tutti i casi sarà sicuramente possibile collegare il GPS alla scheda base per inviare a terra assieme alla telemetria tutti i dati ottenuti da GPS, se si utilizza una postazione a terra con un PC diventa possibile far controllare il multicoso da questo e ottenere comunque il volo autonomo attraverso dei waypoint.
Per il momento battezzo le due schede come Fli.C (contrazione di Flight Controller) e Nav.C (contrazione di Navigation Controller), giusto per identificarle facilmente, poi si troverà un nome definitivo, intanto serve un nome per il progetto, possibilmente evitando gli abusatissimi Arduqualcosa e qualcosaIno, spremetevi le meningi e fate delle proposte.
Nel prossimo post metterò a fuoco le caratteristiche primarie della Fli.C e i primi step per lo sviluppo del suo software.
Scientia potentia est

superlol


Sarebbe il caso di cominciare a definire nei dettagli questo progetto, altrimenti non partirà mai.
Prima di tutto è bene definire lo scopo finale, ovvero realizzare un UAV nel vero senso della parola, poi ci saranno vari gradi intermedi che permetteranno di optare per scelte diverse come complessità, costi e prestazioni.
L'elettronica non può essere composta da un singolo micro, nemmeno se è un super micro, una scelta ottima l'ha fatta MikroKopter che ha diviso il tutto in due schede principali, la FlightCtrl e la NaviCtrl.
La FlightCtrl  controlla l'assetto del mezzo, pilota gli ESC, accetta i comandi da una normale ricevente per aeromodelli, può essere governata dalla NaviCtrl, è realizzata attorno ad un ATMEGA644 @ 20MHz, i sensori, tre giroscopi, un accelerometro a triplo asse, un sensore di pressione, sono montati sulla scheda e sono tutti di tipo analogico, vengono letti tramite ADC.
La NaviCtrl si occupa della navigazione, oltre alle informazione della IMU utilizza un GPS e una bussola, è realizzata attorno a una MCU con core ARM9, non è dichiarato il clock, ma normalmente questi core lavorano a oltre 200 MHz, questa scheda permette al MikroKopter di volare da solo tra vari waypoint, può mantenere l'hovering a punto fisso, ma non è in grado di atterrare e decollare da solo.
Ho fatto questa introduzione perché vorrei adottare una soluzione come la loro, cioè una scheda base Arduino like che si occupa della stabilizzazione e che permette il volo assistito in varie modalità, una scheda che permette la navigazione e il volo autonomo, quest'ultima richiede per forza un processore ben più potente di qualunque AVR a 8 bit.
Dato che "dovrebbe" essere in arrivo a breve un Arduino ufficiale a 32 bit direi che per il momento è il caso di aspettare per la parte navigazione, tanto lo sviluppo e la messa a punto del software per la scheda base richiederà come minimo un paio di mesi quindi inutile crearsi problemi adesso su che hardware utilizzare per la navigazione GPS.
In tutti i casi sarà sicuramente possibile collegare il GPS alla scheda base per inviare a terra assieme alla telemetria tutti i dati ottenuti da GPS, se si utilizza una postazione a terra con un PC diventa possibile far controllare il multicoso da questo e ottenere comunque il volo autonomo attraverso dei waypoint.
Per il momento battezzo le due schede come Fli.C (contrazione di Flight Controller) e Nav.C (contrazione di Navigation Controller), giusto per identificarle facilmente, poi si troverà un nome definitivo, intanto serve un nome per il progetto, possibilmente evitando gli abusatissimi Arduqualcosa e qualcosaIno, spremetevi le meningi e fate delle proposte.
Nel prossimo post metterò a fuoco le caratteristiche primarie della Fli.C e i primi step per lo sviluppo del suo software.

credo che sul dividere le schede fossimo tutti d'accordo, io direi di definire i sensori invece che è più importante:
direi supporto per la freeIMU 0.3.5_MS, wii motion plus e magari un altro accelerometro tipo l'adxl335 di Federico

poi direi che visto che sono state effetttuate prove con atmega 644 ed arduino aspetterei e metterei il software su atmega 328 poi magari passiamo alla stessa piattaforma di mk.

per il nome la butto li ma direi quadcontroller se già non esiste o quadcoptercontrol
http://www.aug-altogarda.it/ <- Il nuovo AUG per basso trentino e dintorni!

astrobeed


credo che sul dividere le schede fossimo tutti d'accordo, io direi di definire i sensori invece che è più importante:
direi supporto per la freeIMU 0.3.5_MS, wii motion plus e magari un altro accelerometro tipo l'adxl335 di Federico


Ho solo fatto un riassunto e messo in evidenza i punti fondamentali, per la IMU la decisione è già stata presa, nella prima versione del software pieno supporto alla 9 dof di Sparkfun con aggiunto il sensore di pressione BMP085 su breakout board per la versione full, supporto al WMP, o al ITG3200, con aggiunti i vari sensori presenti sulla 9 dof singolarmente per le versioni più semplici, e meno costose, della IMU per chi si accontenta solo del sistema di stabilizzazione.
Il supporto alla Freeimu verrà aggiunto più avanti, anche perché è impossibile aggiungerlo senza averla in mano per i test.

Quote

poi direi che visto che sono state effetttuate prove con atmega 644 ed arduino aspetterei e metterei il software su atmega 328 poi magari passiamo alla stessa piattaforma di mk.


Come hardware minimo un ATmega 328 in configurazione stand alone, oppure un scheda Arduino a piacere vera e propria, configurazione massima e ottimale una ATmega 2560 perché non pone nessun limite di memoria, GPIO e periferiche, p.e. le 4 seriali che fanno molto comodo nel caso di voler collegare il GPS e mandare la telemetria a terra mantenendo nel contempo una seriale dedicata per la programmazione e il debug/taratura tramite pc, ne avanza una per future espansioni.
Va da se che qualunque AVR che si pone tra il 328 e il 2560, o superiore, è utilizzabile compatibilmente con le prestazioni desiderate e le sue risorse, il che include il 644.
Con il 328 il vero problema è il limitato numero di GPIO disponibile e che ha una sola porta seriale, assolutamente impensabile di utilizzare una seriale software in questa applicazione.
Il 644 risolve la questione GPIO e mette a disposizione il doppio della flash e della ram, sicuramente un'ottima alternativa al 328 visto che esiste anche in case dip 40 pin pertanto non ci sono problemi per montarlo su una mille fori o farsi un pcb in proprio.
Scientia potentia est

FEDERICO

Col 644 ci sarebbe il "Sanguino", certo che se ce ne fosse uno "originale"...
Per l'hardware la prima descrizione di qualche post fa mi pareva interessante, e' vero che il 335 e' un adxl diffuso ma il 345 permetterebbe di usare il bus i2c, risparmiando pin e semplificando il cablaggio.
Per la freeIMU ho letto su baronerosso.it che varesano sta approntando il suo modello, forse intende dare una mano per il sofware? Non so cosa andra' ad utilizzare.
Federico - Sideralis
Arduino &C: http://www.sideralis.org
Foto: http://blackman.amicofigo.com

astrobeed


Col 644 ci sarebbe il "Sanguino", certo che se ce ne fosse uno "originale"...


Per la Fli.C l'hardware utilizzabile è vasto, praticamente qualunque scheda che monta come minimo un ATmega 328, poi basta ricompilare il software in funzione del micro e, se necessario, disattivando le funzionalità aggiuntive incompatibili con l'hardware, p.e. la telemetria con i dati del GPS, se non si usa una mcu con almeno due porte seriali hardware è impossibile.

Quote

Per l'hardware la prima descrizione di qualche post fa mi pareva interessante, e' vero che il 335 e' un adxl diffuso ma il 345 permetterebbe di usare il bus i2c, risparmiando pin e semplificando il cablaggio.


Oltre al fatto di recuperare pin, comunque un paio di input analogici li lascerei disponibili, c'è il fatto che i sensori su bus I2C hanno internamente un loro ADC che è decisamente superiore a quello dell'ATmega come risoluzione, vuol dire disporre di dati a 13-14 bit nativamente e già prefiltrati.

Quote

Per la freeIMU ho letto su baronerosso.it che varesano sta approntando il suo modello, forse intende dare una mano per il sofware? Non so cosa andra' ad utilizzare.


Visto che Fabio ci legge magari ci dice direttamente cosa sta facendo.

Scientia potentia est

lestofante


Quote

Per l'hardware la prima descrizione di qualche post fa mi pareva interessante, e' vero che il 335 e' un adxl diffuso ma il 345 permetterebbe di usare il bus i2c, risparmiando pin e semplificando il cablaggio.


Oltre al fatto di recuperare pin, comunque un paio di input analogici li lascerei disponibili, c'è il fatto che i sensori su bus I2C hanno internamente un loro ADC che è decisamente superiore a quello dell'ATmega come risoluzione, vuol dire disporre di dati a 13-14 bit nativamente e già prefiltrati.


Però il vantaggio dell'adxl335 è che in realtà, se il codice è scritto bene (vedi calibrazione), e il segno degli assi è corretto, in pratica supporti qualsiasi accelerometro analogico

La stessa cosa varrebbe anche con il giroscopi analogici (però, almeno nel caso della DCM che vuole la rotazione in radianti al secondo le cose si complicano un poco, nulla di troppo problematico datasheet del giro alla mano), e anche il magnetometro(per cui però non so se bastano i classici 10 bit)
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

astrobeed


Però il vantaggio dell'adxl335 è che in realtà, se il codice è scritto bene (vedi calibrazione), e il segno degli assi è corretto, in pratica supporti qualsiasi accelerometro analogico


Troppo semplicistico come ragionamento  :)
Ogni accelerometro ha le sue caratteristiche su cui va aggiustato il tutto, voler gestire troppo hardware diverso è l'errore tipico di molti progetti, alla fine funziona tutto in modo approssimativo e nulla in modo ottimale.

Quote

La stessa cosa varrebbe anche con il giroscopi analogici (però, almeno nel caso della DCM che vuole la rotazione in radianti al secondo le cose si complicano un poco, nulla di troppo problematico datasheet del giro alla mano),


Non vedo dove sia il problema nel convertire un qualunque valore in radianti salvo il tempo perso per il calcolo.
Comunque usare molti ingressi ADC per i sensori non mi piace come soluzione sia per la ridotta risoluzione sia per la bassa velocità di campionamento, a piena risoluzione, degli ATmega che va sommata alla necessità di dover comunque applicare un filtro digitale, anche se blando, tramite oversampling, cosa che comporta un ulteriore carico di lavoro per la CPU.

Scientia potentia est

lestofante

non so, per l'accelerometro, a parte il calcolo del valore di 1G per ogni asse (ho forse do per scontato la linearità della misura?) e il segno degli assi non saprei che altro serva
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

astrobeed


non so, per l'accelerometro, a parte il calcolo del valore di 1G per ogni asse (ho forse do per scontato la linearità della misura?) e il segno degli assi non saprei che altro serva


Per esempio la banda e la quantità di rumore, un accelerometro che ha una banda di 50 Hz va utilizzato in modo diverso da uno che arriva a 100 Hz, non è solo una questione di sensibilità e fondo scala che sono facilmente modificabili.
Ovviamente sto ragionando nell'ottica di ottimizzare al massimo l'efficienza della IMU per ottenere le migliori prestazioni possibili, altrimenti tanto vale usare uno dei vari software già pronti perché perdere tempo per fare un clone di questi non ha senso.
Scientia potentia est

astrobeed

Prima della prossima settimana non posso perché ho ancora diversi impegni di lavoro, però ho intenzione di progettare la FlyShield, nulla di complicato o costoso, è una shield per Arduino UNO/Mega per i vari sensori della IMU e con i connettori a tre contatti per i cavi della ricevente e per gli ESC in modo da rendere più semplice il cablaggio.
Sopra la FlyShield ci metto regolatore a 3.3V da 500 mA, un traslatore di livelli logici 3.3/5 V per l'I2C con le relative pull up, slot su misura per inserire le breakout board di Sparkfun dei sensori.
In realtà la faccio per il mio uso visto che sul quadri che ho iniziato a costruire, anzi ad assemblare dato che ho preso un telaio commerciale, ho deciso di utilizzare una Mega 2560 per la Fli.C e ho il "problema" di collegare tutti i vari cavi e sensori in modo affidabile e duraturo, però è una cosa che sicuramente può fare comodo a tutti.

Scientia potentia est

lestofante

Il problema delle diverse frequenze di lavoro o rumore (Non credo di aver visto in nessun software l'eliminazione di rumore, anche se magari lo fanno pre-filtro kallmann, che tipo di formule intendi usare? un filtro passa basso?) ce le abbiamo comunque perché la freeimu usa il BMA180, tu (da quel che ho capito) hai disponibile il ADXL345, io e federico l'ADXL335. Non ho controllato, ma spero che tra il 345 e il 335 cambi solo la possibilità di interfaccia I2C.

In oltre la stessa cosa è da fare tra i giro del WMP e gli ITG3200

Propongo prima di tutto un poco di analisi del software. NON dobbiamo prevedere mille componenti HW e son d'accordo, ma se seguiamo uno stile di stesura delle librerie (o classi, ma se vogliamo ottimizzare il più possibile..) "pulito", possiamo ottenere delle librerie facilmente rimpiazzabili. Metti che la freeIMU cambia accelerometro, o qualcuno (come me e fede) si ritrova con un sensore alternativo, secondo me può essere semplice da implementare, anche se non otteniamo un codice stra-ottimizzato. A parte i comandi I2C, che son da scrivere da sensore a sensore, la parte di frequenza, rumore, segno degli assi, etc... può essere fatta cambiando i valori di un paio di define, al massimo con qualche conversione dai valori sul datasheet ai valori reali.
Insomma una specie di libreria/classe formulario, ottimizzata ma mantenuta comprensibile attraverso grande documentazione. partendo da questa struttura "astratta", si possono fare tutte le ottimizzazioni del caso per i sensori che si intende usare. Ovviamente noi implementeremo i sensori che abbiamo deciso.
Altrimenti tanto vale scrivere il codice in assembly, come la kkboard, che è fatta per andare a 8MHz solo con giroscopi analogici, e implementare qualcosa di diverso vuol dire ripartire praticamente da 0.

ps. l'ADXL335 sono riuscito adesso adesso a leggerlo in analogico usando dei fili volanti! un paio di tentavi per l'asse Z che confina con GND, , mentre l'asse x e y son andati senza falsi contatti al primo colpo, probabilmente merito di una goccia di flussante che ho "spremuto" dal filo per stagnare.

pps. mi piace l'idea di avere una board,ma la farei già completa di sensori. E' ancora presto per pensarci, se hai i mezzi è molto comodo farsela.
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

ratto93

#492
Aug 03, 2011, 02:14 pm Last Edit: Aug 03, 2011, 02:19 pm by ratto93 Reason: 1
Per caso hai intezione di farla produrre da qualcuno poi ??? perchè come accennavo se sono 1 o 2 strati si fa in casa poi nada de nada ;)

Altra cosuccia.. se il veicolo è in modalità autonoma... servono sensori per rilevare ostacoli e quant'altro ?
Se corri veloce come un fulmine, ti schianterai come un tuono.

lestofante

#493
Aug 03, 2011, 02:36 pm Last Edit: Aug 03, 2011, 02:41 pm by lesto Reason: 1
se è in modalità autonome dipende... se non li metti devi essere te sicuro di cosa fai, o meglio del percorso che gli fai fare.
Se vuoi l'atterraggio autonomo serve un sonar o gli infrarossi, per l'altezza a meno di 1 metro con buona precisione. dipende anche dal tipo di superficie su cui vuoi atterrare (da quanto ho capito l'erba è abbastanza rognosa, molto meglio cemento o asfalto)

sarebbe bello avere un qualcosa stile kinect che ti fa la mappa 3d, certo poi per l'elaborazione un arm inizia a far fatica. ho visto un quadricottero fatto così, ma l'elaborazione avviene via PC (EEEPC con un atom a 1.2GHz se non ricordo male): http://www.youtube.com/watch?v=AgtYXPD_Vv8

edit: comunque prima facciamolo volare, poi ci pensiamo al resto
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

astrobeed


Il problema delle diverse frequenze di lavoro o rumore (Non credo di aver visto in nessun software l'eliminazione di rumore, anche se magari lo fanno pre-filtro kallmann, che tipo di formule intendi usare? un filtro passa basso?)


Il rumore si elimina tramite il Kalman, la banda ha molta importanza per il pid.

Quote

ce le abbiamo comunque perché la freeimu usa il BMA180, tu (da quel che ho capito) hai disponibile il ADXL345, io e federico l'ADXL335. Non ho controllato, ma spero che tra il 345 e il 335 cambi solo la possibilità di interfaccia I2C.


Il 345 dalla sua ha la possibilità di lavorare con fondo scala +/- 2G,4G,8G, 16G, selezionabili da software, come anche il BMA180, ha molto meno rumore del 335 perché al suo interno c'è un filtro digitale che esegue una prima pulizia, ha una banda reale di oltre 200 Hz contro i 100 scarsi del 335.

Per i discorso software si implementa in C ANSI, niente C++ sprecone di risorse e tempo macchina, non si usano le funzioni pappa pronta di wiring, anche loro sprecone, e tantomeno cose come la millis e la digital.qualcosa etc, sarà un software che va a sfruttare al 100% le possibilità degli ATmega.
La questione hardware diversi viene gestite tramite una libreria di funzioni con compilazione condizionale, ovvero tutte le varie parti hardware sono gestite da funzioni con lo stesso nome, p.e. Acc_Read(), però cambia la funzione che viene realmente compilata a seconda delle define, ovviamente tutte raccolte in un file .h dedicato e organizzato in modo logico, nel programma principale non ci deve essere confusione.

Quote

pps. mi piace l'idea di avere una board,ma la farei già completa di sensori. E' ancora presto per pensarci, se hai i mezzi è molto comodo farsela.


Inutile dire che l'ideale è lavorare con una sola board dove sopra c'è una MCU ben definita e tutti i sensori, però è una cosa costosa da realizzare in piccole quantità.
Scientia potentia est

Go Up