Official topic: multicotteri con arduino!

[milvusmilvus]

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

[astrobeed]

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.

[milvusmilvus]

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

[ratto93]

E con gli ostacoli che potrebbe incontrare come la metti

[milvusmilvus]

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

[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.....

[astrobeed]

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).

[lestofante]

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.

[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

[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.

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

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 ) 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

[astrobeed]

per il gps esistono dei chip che fanno solo da FPU, tipo questa, non basterebbe? http://www.sparkfun.com/products/8129

Questo in specifico non lo conoscevo, ho dato un'occhiata al data sheet e si tratta sicuramente di un dsPIC30F3012 programmato per fare da FPU, il pin out corrisponde perfettamente, solo i dsPIC30 funzionano anche a 5V e il set di calcoli è quello del set matematico del C30 con aggiunte le funzioni della libreria matematica estesa per i dsPIC, insomma niente di strano, per il GPS si limita a verificare la validità delle sentenze nmea.
Come ho già detto servono calcoli a 64 bit per tracciare un percorso partendo da coordinate gps, per rendersene conto basta pensare che mediamente un secondo d'arco sulla latitudine vale circa 300 metri, ed è una frazione pari a 1/(360*3600), per rendersi conto che con solo 32 bit non vai da nessuna parte, sulla longitudine è pure peggio perché la distanza varia in funzione della latitudine, sono identiche solo all'equatore.

tra l'altro se non erro buona parte dei GPS che ho visto usano l'NMEA e restituiscono già delle coordinate,

Tutti i gps commerciali forniscono le coordinate tramite sentenze NMEA, è uno standard de facto.

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)

Il pid non serve a nulla in questo caso, devi tracciare una rotta tra due coordinate cartesiane trasformandole in polari, e fin qui sarebbe pure semplice da fare, però la terra non è piatta ed ecco perché diventa un problema di geometria sferica.
Anche se su distanze molto brevi, poche decine di metri, puoi approssimare il tutto in 2D rimane sempre il problema che i calcoli vanno fatti a 64 bit visto che il GPS ti ritorna una cosa del tipo 32* 18' 14,128" sia per la latitudine che per la longitudine ovvero un bel numero composto da +/- 2 cifre e 10 decimali e i way point vanno espressi con la stessa risoluzione
La terra è grossa e per poter specificare un punto con precisione, diciamo +/- 1 metro, serve molta risoluzione  

[astrobeed]

e siccome la precisione dei gps non è assoluta (il che rende inutile anche il calcolo a 64bit)

Un GPS decente di ultima generazione, con EGNOS disponibile, garantisce un circolo di confusione di circa 3 metri, la precisione/risoluzione ti serve sempre e comunque perché i conti li devi fare con i giusti valori, se cominci ad arrotondare pure quelli puoi dire addio alla precisione della rotta.

basta che ricalcola l' intinerario ogni 10s (credo che sia sufficente a fare il calcolo ) 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

La rotta deve essere calcolata, e corretta, istante per istante, diciamo almeno una volta al secondo, ed è pure poco, sia perché il mezzo non vola mai perfettamente allineato con la rotta preimpostata, vuoi per le tolleranze meccaniche, vuoi per il vento, le turbolenze, le termiche, sia perché tocca fare i conti con il drift della IMU che non è assolutamente trascurabile.
Altro dettaglio, un quadricottero può tranquillamente volare a oltre 50 km/h, in 10 secondi percorre oltre 130 metri, penso di non dover dire altro 

[milvusmilvus]

ma su 100m calcolare una itinerario relttilineo invece che curvilineo cosa comporta??? chredo che su una distanza cosi piccola, crei piu problemi l' erba che cresce sul terreno che la circonferenza terrestre, salvo che si voglia far volare un uav sul campo di calcio di holly e benjy , al limite si puo calcolare un itinerario rettilineo, e impostare la distanza da terra (con un sensore, un telemetro, o qulasuasi cosa calcoli la distanza) e dire di mantenerla costante, ovviamente la velocità del mezzo non deve essere alta senno si possono avere problemi. a che velocità viaggia un uav, ovviamente quelli da 1000-2000 euro, come il mikrocopter, e non un predator

[superlol]

beh può volare a varie velocità ma dipende come imposti il software, se voglio che rispetti una certa velocità un vero UAV dovrebbe farlo, intendo che io nel waypoint gli metto la velocità, altitudine, eventuali configurazione (POI o stable mode attivo o alt hold od altro) e magari anche l'ora in cui deve essere in quel punto

poi per semplificare le cose il software su pc potrebbe creare più waypoint invece che solo 2 per rendere tutto più preciso.
ad esempio se voglio che il quadri faccia 250 metri a 50 orari gli metto 1 waypoint di mezzo a 135 metri in modo che abbia un altro riferimento di rotta (con GPS 10Hz)

[astrobeed]

ma su 100m calcolare una itinerario relttilineo invece che curvilineo cosa comporta???

Vallo a dire a quelli che devono georefenziare le piantine per il GPS 
Il problema è molto complesso e non si può affrontare su un forum, ti consiglio di scaricarti un po di documentazione su come funziona il gps, i sistemi geodeteci, in particolare il WGS 84, e la matematica necessaria per convertire le coordinate GPS in una rotta, così ti rendi conto da solo che la cosa non è semplice da gestire.
Giusto come curiosità, usando due gps i dentici di buona qualità, uno posto sul quadri e fisso a terra, è possibile ridurre l'errore a meno di 50 cm, è una specie di gps differenziale semplificato, è indispensabile un data link bidirezionale tra la postazione gps a terra e il velivolo.