Official topic: multicotteri con arduino!

lesto:
io uso la DCM, leggera veloce e abbastanza semplice.

Per come la vedo io con la DCM ti sei solo complicato la vita senza trarre nessun reale beneficio, non ho dati per la combinata PID e Kalman su un ATmega, li uso per altre cose, in compenso ho dati molto precisi su i PIC serie 18, per un ciclo completo mi bastano meno di 200 us (pid e kalman ottimizzati sull’applicazione), dovrebbe essere lo stesso anche su ATmega 328.
Si può sempre prendere in considerazione di portare il clock del micro a 20 MHz, avevo già postato la cosa diverso tempo fa con tanto di bootloader modificato per tale frequenza, il 25% di velocità nei calcoli fa sicuramente comodo in questa applicazione.

ad occhio la DCM è più semplice da implementare, almeno per me che qualcosina di algebra lineare la so. Il codice che ho usato non l'ho scritto io, ho solo risolto un problemino quando l'accelerometro legge 0,0,0 (caso quasi impossibile, ma prevenire...)

io per tutto il ciclo (compresa lettura RX tramite interrupt, che probabilmente rallenta un pò tutto) trasformazioni e tutto mi pare che arrivassi a 1ms per loop

però è difficile trovare un paragone, bisognerebbe vedere anche la qualità dei dati in uscita

per i 20MHz mi sa che diventa un pò un casino per ci usa la board arduino, sarebbe obbligatorio usare un chip stand alone

ps. ho controllato l'idea del collegamento analogico... il chip è uno ADXL335B (perchè è un fake nunchuck) foglio dati: http://docs.google.com/viewer?a=v&q=cache:VtX3g1Lcf4wJ:www.sparkfun.com/datasheets/Components/SMD/adxl335.pdf+adxl335b+accelerometer&hl=en&pid=bl&srcid=ADGEESipeGlTX4n5OKnMEdGa4brKTPdTzKchHCT-2C0wRhDYJAKQJbdMyPC8xYrTH8104HBRChs5oNgoB8En7lcaWaQIftwDIIBmuRylYziVLbH9W4MViJDPDLD6qPlvR-l8qWc-8W20&sig=AHIEtbTugPuomcYswsiC2j8iBBhZFsvlTw l'oversampling se ho capito bene è leggere più volte il dato prima che il sensore lo aggiorni, e fare la media di queste letture, giusto? Quindi in questo caso facendo 3200 letture analogiche al secondo avrei un oversampling di 2 dati per x e y(1600Hz), e di ~6 dati per l'asse z(550Hz), giusto?

data la disposizione dei pin, credo che volendo riuscirei pure a saldarci sopra dei cavi volanti... è indubbio che fare una board apposita sia la soluzione migliore però.. rischio di rovinare il chip, magari "strappando" le piste?

io sono disposto a rischiare il mio quadricottero per gente come voi basta non mi facciate scherzi ;)

per di più tra poco credo ordinerò la freeIMU di Fabio Varesano ]:D (questo volta definitivamente :~)

riguardo la clock vero che il 25% di velocità in più sarebbe davvero comoda ma come è stato detto renderebbe il tutto più complicato per chi si avvicina per la prima volta.

io direi intanto di dire: che parti salviamo di multiwii? quali eliminiamo?

visto che è stato riscritta la parte riguardante l'I2C che non rallenti il software (almeno è quello che ho capito) si potrebbe tenere, così il sistema di leggere i segnali dalla ricevente sempre che non usi un misero pulsein :roll_eyes:

inoltre prevederei uno switch per abilitare oppure non la comunicazione seriale che porta via un sacco di tempo, se uno vuole poi collegarlo alla GUI si mette su ON lo switch e così in volo non si rallenta il programma sbaglio forse?

Appena ho i pezzi monto il mio lo testo con multiwii e poi anche io posso usarlo per testare il codice.... per programmare viste la mia modesta preparazione non so qunto sarò utile ma ce la metterò tutta ;) buona l'idea di spegnere la seriale... ed anche quella di overcloccare il micro... ora non vorrei dire una baggianata ma ne ho visti alcuni che sono addirittura oltre i 20Mhz... che sia controproducente spingersi così oltre ? http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1266309691 a 32Mhz magari con un bel dissipatorino... però se cresha finchè è su son cavoli amari...

lesto: per i 20MHz mi sa che diventa un pò un casino per ci usa la board arduino, sarebbe obbligatorio usare un chip stand alone

Basta cambiare il quarzo e mettere il bootloader modificato.

ps. ho controllato l'idea del collegamento analogico... il chip è uno ADXL335B

Che è pure meglio del 330 montato sull'originale.

l'oversampling se ho capito bene è leggere più volte il dato prima che il sensore lo aggiorni, e fare la media di queste letture, giusto?

Se fai la media esatta ottieni un filtro che aiuta molto ad eliminare il rumore, per ottenere i bit in più devi shiftare a destra di uno per ogni potenza di 4 dei samples, ovvero :

per ottenere 11 bit somma di 4 samples diviso 2 (>>1) per ottenere 12 bit somma di 16 samples diviso 4 (>>2) per ottenere 13 bit somma di 64 samples diviso 8 (>>3)

Quindi in questo caso facendo 3200 letture analogiche al secondo avrei un oversampling di 2 dati per x e y(1600Hz), e di ~6 dati per l'asse >z(550Hz), giusto?

Non scordati che la banda reale di quei sensori è circa 100 Hz, ci vuole un filtro passa basso tra l'out del ADXL e l'input del ADC, è già presente sulla schedina del Nunchuk. In pratica è inutile leggerli troppo velocemente, basta fare la lettura dei tre ingressi ADC ad ogni ciclo di 1 ms, quando ne hai 4 fai il conto ed hai i valori a 11 bit con un refresh di circa 250 Hz.

data la disposizione dei pin, credo che volendo riuscirei pure a saldarci sopra dei cavi volanti... è indubbio che fare una board apposita sia la soluzione migliore però.. rischio di rovinare il chip, magari "strappando" le piste?

Non devi collegarti sui pin, ci sono i tre condensatori che fanno da filtro passa basso, sfruttano l'impedenza d'uscita del sensore, su i quali è molto più semplice saldare tre fili senza fare danni. Li trovi facilmente con un multimetro, su un lato sono collegati a GND mentre sull'altro c'è una tensione pari a 1/2 Vcc, circa 1.65 v, quando l'accelerometro è in bolla per gli assi X e Y e una tensione minore, circa 1.1 v, per l'asse Z.

ratto93:
ed anche quella di overcloccare il micro…

20 MHz non è un oveclock, è la massima frequenza prevista dal data sheet.
Sono assolutamente contrario a qualunque forma di overclock perché è una emerita tavanata galattica a meno che non si parli di leggerissimi overclock, tipo mandare il micro a 21 MHz invece di 20 MHz, ed è comunque rischioso perché possono saltare fuori problemi strani come istruzioni non eseguite o errori di calcolo, quello del calore è l’ultimo dei problemi.

Come non detto :drooling_face:

@lesto: se guardi le foto che ho postato negli ultimi messaggi noterai che sto utilizzando un ADXL335 montato sulla sua scheda gia' preparata, utilizzando l'analogico. Questa e' la mia scheda: http://www.adafruit.com/products/163 e ho pensato di utilizzarla al posto del nunchuck visto che la possedevo gia' precedentemente. Se collegherai anche il tuo in analogico possiamo collaborare al codice. A me, PARREBBE gia' funzionante anche senza oversampling, ma vanno sistemati gli assi per esserne sicuro... Stasera dopo cena ci lavorero' un po'.

Comunque portare a 20mhz se il progetto lo richiedera' mi pare la specifica minore, penso che tutti quelli che partecipano a questo thread possano cavarsela con un atmega standalone o nel risaldare un quarzetto...

Federico: A me, PARREBBE gia' funzionante anche senza oversampling, ma vanno sistemati gli assi per esserne sicuro... Stasera dopo cena ci lavorero' un

Infatti l'oversampling per aumentare la risoluzione è una finezza non streattamente necessaria, semmai è meglio usarlo con la media esatta per ripulire dal rumore, usare sempre un numero di campioni che sia una potenza di due in modo da poter fare la divisione tramite bit shift, molto meno tempo CPU e molte meno istruzioni assembly che significa meno impegno di flash/ram.

superlol: per di più tra poco credo ordinerò la freeIMU di Fabio Varesano ]:D (questo volta definitivamente :~)

Ma è già disponibile la 0.4 ?

io direi intanto di dire: che parti salviamo di multiwii? quali eliminiamo?

Tutto e nulla :D In pratica si fa prima a scrivere un programma ex novo usando come riferimento il multiwii, contiene molte idee buone, ma spesso messe in pratica in modo "dilettantesco" o sotto forma di copia e incolla senza ottimizzare nulla, p.e. il Kalman.

visto che è stato riscritta la parte riguardante l'I2C che non rallenti il software (almeno è quello che ho capito

E' stata riscritta perché la libreria originale di Arduino in caso di problemi sulla I2C si blocca, se succede in volo il botto è una certezza, però va migliorata perché anche questa del MultiWii in certe situazioni blocca l'esecuzione del programma, me sono accorto per caso mentre facevo le prove sul banco.

si potrebbe tenere, così il sistema di leggere i segnali dalla ricevente sempre che non usi un misero pulsein :roll_eyes:

Se ti dico che usa la pulsein che fai non utilizzi più il MultiWii ? :grin:

inoltre prevederei uno switch per abilitare oppure non la comunicazione seriale che porta via un sacco di tempo,

La comunicazione seriale non porta via nulla per due motivi, primo è su richiesta dell'Host, cioè Arduino non trasmette nulla senza prima ricevere una richiesta, secondo la seriale è gestita in hardware e basta che invii un byte ad ogni ciclo del loop, prendendolo da un buffer, ed ecco che il tempo impegnato è circa 1 uS per ogni ciclo main. Solo se utlizzi la modalità display lcd, e la devi attivare con un ben precisa sequenza sugli stick, la seriale spara dati in continuazione, ma avviene solo a terra. Comunque è indispensabile aggiungere la telemetria in volo che MultiWii non ha per il momento.

superlol: inoltre prevederei uno switch per abilitare oppure non la comunicazione seriale che porta via un sacco di tempo, se uno vuole poi collegarlo alla GUI si mette su ON lo switch e così in volo non si rallenta il programma sbaglio forse?

io farei che la comunicazione seriale è sempre attiva, magari una volta al secondo controlla se ci sono dati da PC. In base al dato da PC richiesto, risponde. (magari all'inizio usiamo un solo valore che significa "debug all"). Un byte dovrebbe bastare, son 255 richieste diverse!

ecco, astrobeed mi ha preceduto come al solito, quindi:

E' stata riscritta perché la libreria originale di Arduino in caso di problemi sulla I2C si blocca, se succede in volo il botto è una certezza, però va migliorata perché anche questa del MultiWii in certe situazioni blocca l'esecuzione del programma, me sono accorto per caso mentre facevo le prove sul banco.

proponi di riscrivere la libreria o è possibile modificare la twi/wire in modo da non essere "bloccante" in caso di errore?

Se ti dico che usa la pulsein che fai non utilizzi più il MultiWii ?  smiley-mr-green

io uso una classe che usa interrupt sul timer, modificata dal baronpilot... se volete la posto

Se collegherai anche il tuo in analogico possiamo collaborare al codice.

ehhh ma se mi dici così io ci provo... magari la lascio collegata alla board e metto dei cavi volanti, poi vediamo come sistemare l'accrocchio

astrobeed:
Ma è già disponibile la 0.4 ?

no ma ai miei scopi basta una 0.3.5_MS :wink:

tutto e nulla :smiley:
In pratica si fa prima a scrivere un programma ex novo usando come riferimento il multiwii, contiene molte idee buone, ma spesso messe in pratica in modo “dilettantesco” o sotto forma di copia e incolla senza ottimizzare nulla, p.e. il Kalman.

quindi alla fine vale prendere spunto su quali equazioni usare e come usarle ma riscrivendole ho ben capito?

E’ stata riscritta perché la libreria originale di Arduino in caso di problemi sulla I2C si blocca, se succede in volo il botto è una certezza, però va migliorata perché anche questa del MultiWii in certe situazioni blocca l’esecuzione del programma, me sono accorto per caso mentre facevo le prove sul banco.

qui riporto lesto allora, conviene riprendere la libreria o questo codice e modificarlo?

Se ti dico che usa la pulsein che fai non utilizzi più il MultiWii ? :grin:

penso che non lo usi per un fatto di perdere troppo tempo:
un segnale è lungo 20ms giusto? vanno letti 5 canali minimo che sono 0.1s, troppi direi, come dice lesto è meglio un sistema su interrupt od addirittura verifica ogni millisecondo dello stato del pin così verrà generato ovviamente uno stato motori ogni 0.1ms ma non si ferma il codice

La comunicazione seriale non porta via nulla per due motivi, primo è su richiesta dell’Host, cioè Arduino non trasmette nulla senza prima ricevere una richiesta, secondo la seriale è gestita in hardware e basta che invii un byte ad ogni ciclo del loop, prendendolo da un buffer, ed ecco che il tempo impegnato è circa 1 uS per ogni ciclo main.
Solo se utlizzi la modalità display lcd, e la devi attivare con un ben precisa sequenza sugli stick, la seriale spara dati in continuazione, ma avviene solo a terra.
Comunque è indispensabile aggiungere la telemetria in volo che MultiWii non ha per il momento.

questo non lo sapevo, per la telemetria proporrei xbee pro, facilmente reperibili, c’è chi li ha già e si interfacciano col proprio software al pc, non disturbano le trasmittenti (almeno non ho trovato casi di disturbo e poi tanto io sono sulle 40MHz :P) inceve credo sia ormai indispensabile oltre che un’iterfaccia per laptop una per tablet per la comodità (non ho un tablet ma a fine estate lo compro appena entrano soldi :sweat_smile:) il problema degli xbee è che sono 100€ di telemetria e preferirei fosse opzionale.

questo non lo sapevo, per la telemetria proporrei xbee pro, facilmente reperibili, c'è chi li ha già e si interfacciano col proprio software al pc, non disturbano le trasmittenti (almeno non ho trovato casi di disturbo e poi tanto io sono sulle 40MHz smiley-razz) inceve credo sia ormai indispensabile oltre che un'iterfaccia per laptop una per tablet per la comodità (non ho un tablet ma a fine estate lo compro appena entrano soldi smiley-sweat) il problema degli xbee è che sono 100€ di telemetria e preferirei fosse opzionale.

su questo punto non sono pienamente d'accordo. Se usi una trasmittente 2.4GHz, come lo xbee, allora ti ritrovi un disturbo. Credo che la tx/rx scelga un canale non congestionato, oppure salta spesso di frequenza, ma queste sono proprietà delle trasmittenti, perciò, sopratutto sui modelli di bassa fascia, non si può essere totalmente sicuri. Se si usa uno xbee, tutto dovrebbe passare per xbee per non avere problemi.

Ma sinceramente se dovessimo avere un sistema senza fili, io proporrei il wimax, raggio molto esteso e possibilità di uplink video, sempre se si trova un sistema per far convivere il video sul mezzo. NON so se la tecnologia è realmente applicabile però, non i sono mai informato.

oppure si usano delle ricetrasmittenti da 433Mhz onde evitare i disturbi con i telecomandi…
sennò resta la via dei 900Mhz anche se non sono molto in regola… però sinceramente se anche vengono usati per mezzoretta non credo siano già li a far storie…

lesto: su questo punto non sono pienamente d'accordo. Se usi una trasmittente 2.4GHz, come lo xbee, allora ti ritrovi un disturbo.

Ecco perché esistono leggi che regolamentano in modo rigido le varie bande/canali, proprio per evitare che due sistemi operanti sulla stessa banda, ma in porzioni diverse, si diano fastidio a vicenda. Se usi un radiocomando a 2.4 GHz regolarmente omologato, quindi niente spazzatura cinese, sei automaticamente certo che lavora esclusivamente sui canali riservati ai radiocomandi, gli Xbee, o altri sistemi dati sulla banda dei 2.4 GHz come il BlueTooth o il WiFi, lavorano su canali diversi da quelli dei radiocomandi e non si danno fastidio tra di loro.

Ma sinceramente se dovessimo avere un sistema senza fili, io proporrei il wimax, raggio molto esteso e possibilità di uplink video, sempre se si trova un sistema per far convivere il video sul mezzo. NON so se la tecnologia è realmente applicabile però, non i sono mai informato.

Per quanto riguarda la telemetria e l'eventuale sistema di controllo remoto per le funzionalità UAV vere e proprie il progetto si ferma alla porta seriale, da li in poi sarà a discrezione delle singole persone cosa collegare per il wireless. In volo la porta seriale sarà utilizzata per inviare e ricevere informazioni, ma anche per fare la messa a punto e calibrazione a terra, poi cosa gli si collega dipende da cosa uno ha disponibile o preferisce usare, dal punto di vista dell'informazione non cambia nulla se viaggiano tramite Xbee o Wiqualcosa.

lesto: proponi di riscrivere la libreria o è possibile modificare la twi/wire in modo da non essere "bloccante" in caso di errore?

Sicuramente le funzioni I2C sono da riscrivere totalmente, sia per evitare qualunque causa di blocco che per migliorarne l'efficienza.

io uso una classe che usa interrupt sul timer, modificata dal baronpilot... se volete la posto

Ovviamente il MultiWii non usa la pulsein per rilevare il PPM dalla ricevente per il semplice motivo che è bloccante come istruzione ed è pure molto imprecisa, usa un timer e gli interrupt. La funzione che gestisce la ricevente si può recuperare al 100% salvo qualche piccolo ritocco, tra l'altro prevede sia la modalità con un pin per ogni canale out oppure immettere direttamente il segnale PPM complessivo di tutti i servi, alcune riceventi lo prevedono, su un solo pin, l'ho provata e funziona bene.

superlol: no ma ai miei scopi basta una 0.3.5_MS ;)

Bene, allora farai da beta tester per la freeimu :)

quindi alla fine vale prendere spunto su quali equazioni usare e come usarle ma riscrivendole ho ben capito?

Il punto è che nel MultiWii non c'è nessuna equazione, come ho già detto il pid non è un vero pid, è un quasi pid poco efficiente, il Kalman è uno generico copia incollato, questo vuol dire che tocca fare tutto da 0 per quanto riguarda la parte matematica. Insomma c'è molto lavoro da fare se si vuole sfornare un nuovo progetto fatto come si deve, per par condicio ho dato uno sguardo anche ai concorrenti come Aeroquad e Ardupilot, sotto certi versi sono fatti meglio, però anche questi sono approssimativi per quanto riguarda la parte matematica e di controllo.

astrobeed:

superlol: no ma ai miei scopi basta una 0.3.5_MS ;)

Bene, allora farai da beta tester per la freeimu :)

quindi alla fine vale prendere spunto su quali equazioni usare e come usarle ma riscrivendole ho ben capito?

Il punto è che nel MultiWii non c'è nessuna equazione, come ho già detto il pid non è un vero pid, è un quasi pid poco efficiente, il Kalman è uno generico copia incollato, questo vuol dire che tocca fare tutto da 0 per quanto riguarda la parte matematica. Insomma c'è molto lavoro da fare se si vuole sfornare un nuovo progetto fatto come si deve, per par condicio ho dato uno sguardo anche ai concorrenti come Aeroquad e Ardupilot, sotto certi versi sono fatti meglio, però anche questi sono approssimativi per quanto riguarda la parte matematica e di controllo.

mi sta bene da fare da beta tester e se riesco magari anche a scrivere qualche riga di codice perchè avrò molto da imparare scommetto, anzi moltissimo :D

appunto quello che intendevo, l'equazione può andare bene intesa come che tipo ma è da rifare. dici che ottimizzando al massimo queste equazioni si avrà un sistema più veloce o arriveranno calcoli più complessi che andranno a rallentare tutto? :~

Sicuramente le funzioni I2C sono da riscrivere totalmente, sia per evitare qualunque causa di blocco che per migliorarne l’efficienza.

http://code.google.com/p/simplo/source/browse/trunk/libraries/fastwire/Fastwire.cpp