Official topic: multicotteri con arduino!

se il problema è solo la capacita di calcolo, credo che il 16 settebre esca il nuovo arduino a 32 bit....

cito Massimo Banzi ---> http://arduino.cc/forum/index.php/topic,66553.0.html

Non è cosi semplice migrare una community a 32bit, ci vuole tempo ed il prodotto giusto. bisogna fare un sacco di "test" sugli utenti etc.. Inoltre tutta la documentazione va aggiornata per far capire cosa ve e cosa non va....

Detto questo Il 16 settembre io leggerei il blog di Arduino....

per ora però si potrebbe implementare un sistema con 2 arduino, che comunicano 1 si occupa del "volo" e la stabilizzazione con il multiwii, l' altro si occupa di gestire i percorsi, l' atterraggio, il decollo, insomma tutte le funzionalità uav, e tramite il primo gestisce i motori

milvusmilvus: se il problema è solo la capacita di calcolo, credo che il 16 settebre esca il nuovo arduino a 32 bit....

cito Massimo Banzi ---> http://arduino.cc/forum/index.php/topic,66553.0.html

Non è cosi semplice migrare una community a 32bit, ci vuole tempo ed il prodotto giusto. bisogna fare un sacco di "test" sugli utenti etc.. Inoltre tutta la documentazione va aggiornata per far capire cosa ve e cosa non va....

Detto questo Il 16 settembre io leggerei il blog di Arduino....

per ora però si potrebbe implementare un sistema con 2 arduino, che comunicano 1 si occupa del "volo" e la stabilizzazione con il multiwii, l' altro si occupa di gestire i percorsi, l' atterraggio, il decollo, insomma tutte le funzionalità uav, e tramite il primo gestisce i motori

quindi 2 ardunio, più costi, nuove schede, con quel tanto si va ad acquistare un'altra scheda. per non parlare del fatto che molti non sanno di elettronica quindi gli arriva addosso una serie di cose da fare non da poco (a parte i collegamente che sono il male minore bisogna flashare 2 micro, verifiche di software non da poco e poi i costi salgono, un'altra scheda sono altri 20€ ed altro peso..)

per avere entrambe le funzioni di stabilizzazione e controllo autonomo, non converrebbe passare a versioni tipo l'ATmega 664 quello del Sanguino per intenderci? è sempre ad 8bit ma ha più memoria sia ram e flash.... oppure pensare davvero di usare il Multipilot Mega.... quello con abbordo l'ATmega 1280....

ratto93: per avere entrambe le funzioni di stabilizzazione e controllo autonomo, non converrebbe passare a versioni tipo l'ATmega 664 quello del Sanguino per intenderci? è sempre ad 8bit ma ha più memoria sia ram e flash.... oppure pensare davvero di usare il Multipilot Mega.... quello con abbordo l'ATmega 1280....

qui principalmente non è un problema di memoria ma appunto di velocità nell'eseguiree i calcoli, 1ms è tanto in questi sistemi e qui si sfora alla grande, insomma ci vuole un 32 bit perchè esegue più cicli, clock maggiore, stesse istruzioni svolte in un settimo del tempo

quello è perchè si passa al 32 bit non per il numero di pin o memoria

milvusmilvus: se il problema è solo la capacita di calcolo, credo che il 16 settebre esca il nuovo arduino a 32 bit....

Questo è da vedersi, inoltre il fatto che un micro sia a 32 bit non vuol dire che ha molta potenza di calcolo :) Ti faccio un esempio banale, un ARM7 a 60 MHz è il livello base di questi micro, è un 32 bit, può indirizzare tutta la ram/flash che desideri, parliamo di megabyte, però nei calcoli matematici complessi un "umile" dsPIC 33, è un 16 bit, con clock (interno) a 40 MHz gli fa marameo perché dispone di un core dsp che gli da una marcia in più, oltretutto costa meno della metà di un ARM7. Dovendo scegliere tra un ARM7 e un dsPIC per implementare la parte navigazione del quadricottero preferisco sicuramente usare il dsPIC.

per ora però si potrebbe implementare un sistema con 2 arduino,

Indubbiamente una architettura multiprocessore, quindi distribuendo i vari compiti, aiuta molto però una MCU a 8 bit non ha la potenza di calcolo per gestire in tempo reale la navigazione tra waypoint e tantomeno per gestire il volo totalmente autonomo del quadricottero. Un conto è stabilizzare gli assi, ovvero portare l'assetto a 0 non appena si rilasciano gli stick ed evitare movimenti troppo bruschi, e un conto è far volare da solo il tutto. Lo stesso autore del multiwii nelle f.a.q. è molto chiaro su questo punto, il software non è in grado di tenere il mezzo perfettamente fermo su un certo punto, può solo tenerlo livellato ed evitare che acceleri troppo in una direzione, tenere il quadri fermo in hovering, o farlo muovere, è compito del pilota.

una rduino nanon non pesa tantissimo.... però se vogliamo fare un uav con arduino, credo sia l' unica soluzione, per ora...oppure facciamo una scheda con 2 atmega, se qualcuno non vuole spendere altri 20 euro, o non vuole complicarsi la vita, o sempicemente non vuole un uav, si fa il multicottero "standard" come ce ne sono tanti in internet

non è una critica, solo che si potrebbe fare qualcosa in piu rispetto a quelli gia esistenti, oppure si aspetta arduino a 32 bit, e si implementano le funzioni uav

ratto93: per avere entrambe le funzioni di stabilizzazione e controllo autonomo, non converrebbe passare a versioni tipo l'ATmega 664 quello del Sanguino per intenderci? è sempre ad 8bit ma ha più memoria sia ram e flash.... oppure pensare davvero di usare il Multipilot Mega.... quello con abbordo l'ATmega 1280....

non credo sia solo questione di memoria, ma di capacità di calcolo, quindi o di monta un chip piu potente, o si cerca di farne lavorare 2 insieme

io credo che un arduino dedicato alla navigazione sia sufficente, forse con dei limiti, ma dovrebbe riuscire a fare qualcosa... forse il 32bit, non sara potentissimo, ma credo che se non fosse un passo in avanti, non sarebbe implementato

ATXmega..... si possono usare a 32Mhz ma hanno risorse ben più potenti dei normali ATmega Credo che in qualche modo modificando l'IDE di arduino si possano programmare....

Si Astrobeed si potrebbero usare i DsPic io avevo provato ad usarne uno ma l'Ide MPLAB non mi piace e usare MickroC non mi gusta nemmeno e poi non sono il nostro arduino :P

milvusmilvus: io credo che un arduino dedicato alla navigazione sia sufficente, forse con dei limiti, ma dovrebbe riuscire a fare qualcosa... forse il 32bit, non sara potentissimo, ma credo che se non fosse un passo in avanti, non sarebbe implementato

Al momento si potrebbe prendere in considerazione la scheda di Digilent, la chipKIT UNO32, o la versione Mega32, costa come un normale Arduino e sopra c'è un processore 32 bit che è decisamente superiore agli ARM7. E' vero che con la chipKIT ci sono problemi di compatibilità con alcune shield, ma ci saranno lo stesso anche con un ipotetico futuro Arduino ufficiale a 32 bit, e che diverse librerie esterne all'IDE non si possono usare senza prima modificare tutte le parti che accedono direttamente all'hardware, ma in questo caso non credo sia un problema. Diciamo che usare questa scheda è un modo semplice e poco costoso per poter disporre di molta potenza di calcolo, e anche molta memoria, senza doversi costruire schede e/o spendere molti soldi.

ratto93: ATXmega..... si possono usare a 32Mhz ma hanno risorse ben più potenti dei normali ATmega

Indubbiamente gli ATXmega sono più performanti degli ATmega, però siamo ancora lontani da quello che serve per un sistema di navigazione e volo autonomo.

astrobeed:

milvusmilvus: io credo che un arduino dedicato alla navigazione sia sufficente, forse con dei limiti, ma dovrebbe riuscire a fare qualcosa... forse il 32bit, non sara potentissimo, ma credo che se non fosse un passo in avanti, non sarebbe implementato

Al momento si potrebbe prendere in considerazione la scheda di Digilent, la chipKIT UNO32, o la versione Mega32, costa come un normale Arduino e sopra c'è un processore 32 bit che è decisamente superiore agli ARM7. E' vero che con la chipKIT ci sono problemi di compatibilità con alcune shield, ma ci saranno lo stesso anche con un ipotetico futuro Arduino ufficiale a 32 bit, e che diverse librerie esterne all'IDE non si possono usare senza prima modificare tutte le parti che accedono direttamente all'hardware, ma in questo caso non credo sia un problema. Diciamo che usare questa scheda è un modo semplice e poco costoso per poter disporre di molta potenza di calcolo, e anche molta memoria, senza doversi costruire schede e/o spendere molti soldi.

io ho sentito che hanno problemi coi bus, soprattutto I2C che in questo progetto è fondamentale.

però si potrebbe riscrivere il software da tutta la community italiana (nel senso riadattarlo) per un chip più potente "convertito" ad arduino.

intendo che alla fine arduino non è altro che una scheda con un microcontrollore e una serie di chip per rendere più facile la prototipazione e il caircamento, flashando da ISP un bootloader per dsPIC e facendo una schedina con le stesse caratteristice (anche i dsPic supportano il ICSP da quanto so) si potrebbe ampliare di molto il software lasciando magari prezzi accessibili o comunque immagino esistano dsPic in formato DIP che tutto possano saldare, se uno vuole la fa su millefori o si fa una scheda o si fanno una serie di schede senza e con componenti da distribuire.

il problema principale è che l'utente finale non può comprarsi un programmatore ISP e quindi bisognerebbe distribuire Pic con bootloader precaricato (come con arduino).

in pratica quello che vorrei è che la communiti si attivasse dicendo quello che vorrebbe da arduino (io ad esempio vorrei una scheda che abbia più pin della UNO ma meno dell'atmega perchè sono sprecati), ci unisse cose per i quadricotteri (quindi potenza, calcolo in DSP o ci mettiamo un ARM), e poi si pensasse a come migliorare il software (con contatti con alexinparis e collaboratori) tenendo attiva e in sviluppo la parte arduino 8bit come stabilizzazione e poi per chi vuole un UAV passa alla scheda nuova.

secondo me non stiamo andando fuori tema perchè credo che stia nascendo in altri progetti il problema di passare a 32 bit o comunque a MCU più potenti e credo che questa nuova scheda con l'aiuto di Massimo, Davide, e gli altri creatori della vera arduino potrebbe diventare una nuova arduino rivoluzionaria!

Massimo diceva che non era facile far migrare una community da 8 a 32bit ma se prendiamo quello che vuole la community dai 32 bit il passaggio credo sarà quasi indolore.

anche se credo che il problema maggiore di una migrazione sarebbe il convertire produzione aggiungendo una scheda ma senza togliere dalla produzione l'altra, tanti costi iniziali insomma

io direi innanziutto di costruire un tricoso volante, il codice si puo prendere il prestito e studiarlo, per chi ne ha voglia...poi si potranno sempre fare degli upgrade...

superlol: io ho sentito che hanno problemi coi bus, soprattutto I2C che in questo progetto è fondamentale.

Il "sentito dire" non è una cosa su cui fare conto :) Io ti posso dire con certezza che l'I2C su i PIC32 funziona perfettamente per un semplicissimo motivo, li uso per lavoro e oltre a conoscerli molto bene so perfettamente quali sono i punti deboli. Tenuto conto che il livello medio di conoscenza dell'elettronica di chi usa Arduino, senza offesa per nessuno, è decisamente basso mi viene da pensare che i "problemi" sono dovuti al fatto che l'I2C dei PIC32 funziona con livelli di tensione a 3.3 Volt, il che può creare non pochi problemi con i device che usano l'I2C a 5V se non si mette in mezzo un apposito traslatore di livelli.

però si potrebbe riscrivere il software da tutta la community italiana (nel senso riadattarlo) per un chip più potente "convertito" ad arduino.

Adattare un diverso micro ad Arduino non è una cosa semplice che si fa poche ore di lavoro, un conto è inserire nell'elenco dei micro supportati una mcu Atmel 8 bit della serie ATxxxx, un conto è prendere un micro totalmente diverso e adattarlo ad Arduino, è un lavoro che richiede mesi da parte di gente molto esperta.

intendo che alla fine arduino non è altro che una scheda con un microcontrollore e una serie di chip per rendere più facile la prototipazione e il caircamento, flashando da ISP un bootloader per dsPIC e facendo una schedina con le stesse caratteristice (anche i dsPic supportano il ICSP da quanto so)

Tutti i micro moderni prevedono la programmazione ISP, alcuni hanno addirittura il bootloader già integrato nel chip, il problema non è realizzare una nuova scheda, è il software. Volendo esiste già una scheda con sopra un dsPIC33 28 pin con case dil pensata apposta per lo sviluppo come Arduino, è questa ed è un mio progetto per conto di Droids, però non la puoi programmare in Wiring, devi usare MPLAB e il compilatore C30 di Microchip, da notare che ora c'è anche MPLABX, realizzato tramite Netbeans, che gira nativamente pure con Linux e MAC OS.

il problema principale è che l'utente finale non può comprarsi un programmatore ISP e quindi bisognerebbe distribuire Pic con bootloader precaricato (come con arduino).

Sulla MuIn dsPIC è precaricato un bootloader seriale, esattamente come con Arduino, e questo vale per quasi tutte le schede commerciali.

in pratica quello che vorrei è che la communiti si attivasse dicendo quello che vorrebbe da arduino (io ad esempio vorrei una scheda che abbia più pin della UNO ma meno dell'atmega perchè sono sprecati)

Guarda che la differenza di costo tra un micro con 23 gpio e lo stesso modello con 60 gpio è un paio di Euro, se devi mettere un micro che ha più gpio della UNO tanto vale montare subito un micro con moltissimi gpio, se avanzano poco male, si lasciano sconnessi, ma se poi vengono a mancare tocca riprogettare l'intera scheda.

, ci unisse cose per i quadricotteri (quindi potenza, calcolo in DSP o ci mettiamo un ARM), e poi si pensasse a come migliorare il software (con contatti con alexinparis e collaboratori) tenendo attiva e in sviluppo la parte arduino 8bit come stabilizzazione e poi per chi vuole un UAV passa alla scheda nuova.

Intenzione buona, ma il problema è "il software chi lo fa ?", un conto è scrivere un programma in wiring per Arduino, un conto è lavorare in C ANSI su un 32 bit che ha una miriade di registri macchina, DMA, etc, poi va a finire che chi ci lavora realmente sopra sono solo una, due persone e tutti gli altri fanno solo da beta tester.

riguardo agli uav, per raggiungere un punto, io avevo pensato a questo montare un gps, ed una bussola elettronica

si inseriscono le coordinate da raggiungere e in base alle coordinate date dal gps, con qualche calcolo trogonometrico si calcola l ancolo di rotazione del mezzo per raggiungere il punto richiesto, siccome il multicottero, è autostabile, e comandato con un trasmettitore, "simulare" l' invio di un comando al trasmettotore che fa ruotare di x gradi il mezzo, poi quando la sistanza tra il punto da raggiungere,e magari controllare la rotta ogni 10s è inferiore a y metri, si ferma. penso che una cosa del genere un arduino ad 8 bit sia in grado di farla..... ovviamente funzionerebbe in mancanza di ostacoli.... per l' atterraggio si potrebbe usare un sensore ad ultrasuoni, che rileva la distanza dal suolo, e gradualmente riduce la potenza dei motori.

un arduino dedicato, non dovrebbe avere problemi a fare questo

E con gli ostacoli che potrebbe incontrare come la metti ???

in campo libero potrebbe funzionare… oppure si puo salire a 100m di quota e poi riscendere…per gli ostacoli si potrebbe risolvere solo con tanti sensori…1 sotto, 2 avanti 2 dietro 2 per ogni lato, uno sopra… piu o meno… ma sarebbe molto piu compllicato

si in effetti ne servirebbe almeno uno per lato più uno che senta il terreno.... sennò è quasi sicura la distruzione del mezzo ho paura.... e a livello di codice non è cosa da poco...

se qualcosa a 100mt di quota va male oltr a fare a pezzi tutto si richia di far del male alle persone.... a meno che non si metta un paracadute.....

milvusmilvus: si inseriscono le coordinate da raggiungere e in base alle coordinate date dal gps, con qualche calcolo trogonometrico

Il problema è che non è "qualche calcolo trigonometrico", è un problema di geometria sferica con risoluzione almeno al milionesimo di grado, è molto più complicato di quello che pensi, Arduino non è in grado di fare simili calcoli in real time, anzi non ti basta proprio la matematica a 32 bit, serve la precisione double long int (64 bit).

per il gps esistono dei chip che fanno solo da FPU, tipo questa, non basterebbe? http://www.sparkfun.com/products/8129 tra l'altro se non erro buona parte dei GPS che ho visto usano l'NMEA e restituiscono già delle coordinate, quindi basta trovare l'orientamento del vettore tra il punto attuale e quello di arrivo, e con uno o più PID (magari uno specifico per l'altezza, così il problema diviene 2D) far coincedere l'orientamento del sensore con quello del multicottero. Sicuramente non si arriva precisamente nel punto, ma dubito che l'errore (escluso quello GPS) sia superiore al metro.

Non credo che astrobeed si riferisca alla insufficiente potenza di calcolo dell'Atmega solo per quanto concerne la precisione degli stessi ma anche per la velocità. Ammesso di utilizzare un coprocessore matematico, resta la "velocità" con cui l'Atmega dovrebbe trattare quei, considerando che un velivolo non sta... fermo ma è in movimento. Quindi quando l'Atmega dovrebbe calcolare di fermarsi in un punto, avrebbe già passato quel punto XD

astrobeed:

milvusmilvus: si inseriscono le coordinate da raggiungere e in base alle coordinate date dal gps, con qualche calcolo trogonometrico

Il problema è che non è "qualche calcolo trigonometrico", è un problema di geometria sferica con risoluzione almeno al milionesimo di grado, è molto più complicato di quello che pensi, Arduino non è in grado di fare simili calcoli in real time, anzi non ti basta proprio la matematica a 32 bit, serve la precisione double long int (64 bit).

per essere precisi, si serve un calcolo di geometria sferica, e 64bit di calcolo, solo che per fare un sistema homemade, si puo arrotondare con linee rette, e siccome la precisione dei gps non è assoluta (il che rende inutile anche il calcolo a 64bit) e quindi il punto di arrivo dovrebbe essere anche a 2 metri dalle coordinate immesse, l' errore non puo essere coacolato in modo assoluto, ma una volta a 2 metri dal punto da raggiungere, si puo ricalcore l' itinerario, e correggere l' errore.

ratto93: si in effetti ne servirebbe almeno uno per lato più uno che senta il terreno.... sennò è quasi sicura la distruzione del mezzo ho paura.... e a livello di codice non è cosa da poco...

se qualcosa a 100mt di quota va male oltr a fare a pezzi tutto si richia di far del male alle persone.... a meno che non si metta un paracadute.....

io dicevo 2 per lato (uno per motore) che sono le parti piu sporgenti..... ovvio che se cade da 100m si fanno danni, ma almenocche vuoi farlo volare su una folla, non dovrebbero esservi problemi, di solito i sistemi di "return to home" funzionano cosi, salgono ad una certa altezza, e impostano una rotta, facendo cosi si evitano ostacoli come alberi o muri, ma in campo libero, si puo anche impostare un altezza di 5 metri o meno. comunque l' unico problema del ritorno, e che sbagli coordinate, o atterri in altri posti, l' atterraggio è una cosa piu delicata...

leo72: Non credo che astrobeed si riferisca alla insufficiente potenza di calcolo dell'Atmega solo per quanto concerne la precisione degli stessi ma anche per la velocità. Ammesso di utilizzare un coprocessore matematico, resta la "velocità" con cui l'Atmega dovrebbe trattare quei, considerando che un velivolo non sta... fermo ma è in movimento. Quindi quando l'Atmega dovrebbe calcolare di fermarsi in un punto, avrebbe già passato quel punto XD

basta che ricalcola l' intinerario ogni 10s (credo che sia sufficente a fare il calcolo :D) poi man mano che si avvicina, potrebbe aumentare la frequesnza dei controlli, puo controllare le coordinate gps in realt ime e confrontarle con quelle del viewpoint, quando la distenza è inferiore a un tot metri si ferma