Go Down

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

astrobeed


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.
Scientia potentia est

ratto93

Se corri veloce come un fulmine, ti schianterai come un tuono.

FEDERICO

@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'.
Federico - Sideralis
Arduino &C: http://www.sideralis.org
Foto: http://blackman.amicofigo.com

FEDERICO

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 - Sideralis
Arduino &C: http://www.sideralis.org
Foto: http://blackman.amicofigo.com

astrobeed


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.
Scientia potentia est

astrobeed

#470
Aug 02, 2011, 05:50 pm Last Edit: Aug 02, 2011, 05:51 pm by astrobeed Reason: 1

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


Ma è già disponibile la 0.4 ?

Quote

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.

Quote

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.

Quote

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


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

Quote

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.
Scientia potentia est

lestofante


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:

Code: [Select]

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?

Code: [Select]
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

Quote
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
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

superlol



Ma è già disponibile la 0.4 ?

no ma ai miei scopi basta una 0.3.5_MS  ;)

Quote

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.

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

Quote


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?

Quote


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

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

Quote


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  :smiley-sweat:) il problema degli xbee è che sono 100€ di telemetria e preferirei fosse opzionale.
http://www.aug-altogarda.it/ <- Il nuovo AUG per basso trentino e dintorni!

lestofante

Quote
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.
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

ratto93

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....
Se corri veloce come un fulmine, ti schianterai come un tuono.

astrobeed


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.

Quote

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.

Scientia potentia est

astrobeed


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.

Quote

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.
Scientia potentia est

astrobeed


no ma ai miei scopi basta una 0.3.5_MS  ;)


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

Quote

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.

Scientia potentia est

superlol



no ma ai miei scopi basta una 0.3.5_MS  ;)


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

Quote

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?  :~
http://www.aug-altogarda.it/ <- Il nuovo AUG per basso trentino e dintorni!

fax8

Quote
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

Go Up