Official topic: multicotteri con arduino!

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

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

astrobeed:

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)

lesto:
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 :slight_smile:
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.

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.

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

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

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.

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.

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 :wink:

Altra cosuccia.. se il veicolo è in modalità autonoma... servono sensori per rilevare ostacoli e quant'altro ?

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): Kinect Flies Quad Helicoptor - Boys Toys - YouTube

edit: comunque prima facciamolo volare, poi ci pensiamo al resto

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

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.

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

ratto93:
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 :wink:

Sono anni che non mi metto più a combattere con i master, gli acidi e il trapano per fori, i pcb me li faccio fare da un service così ho piste perfette e fori metallizzati, se poi voglio spendere di più posso avere anche il solder e le serigrafie.

WMP e ADXL335.
Sembra corretto? (A muoverlo quello che vedevo a schermo era realistico) Intorno al secondo 45 si vede lo "scatto" strano che fa di cui parlavo qualche post fa. Stasera proseguo i test...

astrobeed:

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

Ah ok, in effetti il kallman è un filtro.. con la DCM io prendo i dati, e li "sbatto" nell'algoritmo senza troppi complimenti.

per come la vedo io la banda influenza il tempo di aggiornamento della IMU, che influenza il tempo di aggiornamento del pid. Nel senso che è inutile dare in pasto al kallmann (o alla DCM) dati non aggiornati, e quindi senza output è inutile (se non controproducente, causa I e forse anche D)aggiornare il pid

astrobeed:

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.

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

per la board lo so, ma lo stesso vale per una board senza sensori no? voglio dire, non è certo il costo dei sensori a rendere alto il costo, quanto il PBC stesso.

per il resto ti seguo, volevo approfondire qualche punto ma devo uscire di fretta. va bene il C, però con le define cambierei il file.h importato, e ogni .h è un sensore diverso, un pò come vorrei fare con le classi nel codice che ho scritto finora. molto più pulito, no?

Per il PCB cosa vuoi che costi... Se ne fai 10 gia' il costo scende, se te lo fai in casa costa praticamente solo lo sbattimento di farlo.

io vorrei dire che a mio parere 100 schede si venderebbero senza troppi problemi.

avendo 200€ di fisso più 1.50€ a scheda (serigrafata e tutto) sono 350€ solo le schede, poi bisognerebbe vedere i componenti, però se la imu viene sui 100€ e un arduino viene sui 25€ si avrebbero schede in vendita da 150€ che in questo campo sinceramente sono pochi.

poi la parte col GPS sarebbe la più costosa però (modulo GPS da circa 60€?) anche perchè necessita di una MCU più potente e costosa

ma voi state contando solo i PBC o anche i costi di assemblaggio degli SMD? Perché a questo punto arduino, i sensori e tutto il resto li fai in SMD (che dovrebbero costare anche meno). Però se pensi di assemblarli in casa, inizia a pensare anche al numero di resi... magari si possono fare due versioni, una totalmente SMD per il commercio, e una con il minimo assoluto di pezzi SMD (solo i sensori?) che non viene venduta, ma uno si scarica il file e se la fa da solo..

Però non so un bromografo da casa che precisione ha, credo che dipenda solo fino ad un certo punto dalla qualità della stampa.

Oppure si può pensare di fare fare il PCB ed anche montare i componenti da Seeedstudio.... sono cinesi ma fanno a dovere il loro lavoro... ho un paio di loro oggettini e vanno alla perfazione e la fattura è davvero buona....

ratto93:
Oppure si può pensare di fare fare il PCB ed anche montare i componenti da Seeedstudio.... sono cinesi ma fanno a dovere il loro lavoro... ho un paio di loro oggettini e vanno alla perfazione e la fattura è davvero buona....

la commercializzazione è l'ultimo dei problemi, prima direi che ci serve un hardware e un software prima di produrre una scheda :wink:

quindi attendiamo astrobeed che metta giù i primi sistemi di equazioni che poi provvederemo a risolvere :stuck_out_tongue:

L'eventuale realizzazione di una scheda dedicata all inclusive è da prendere in considerazione solo dopo aver realizzato almeno una beta funzionante del software provata su hardware normale, adesso è prematuro parlarne.
Non scordatevi che tutti i sensori sono in case qfn, praticamente impossibili da saldare in da soli senza disporre almeno di un forno preriscaldante e una stazione ad aria, e tocca pure saperlo fare altrimenti fate una bella frittura mista da qualche decina di Euro.

superlol:

ratto93:
Oppure si può pensare di fare fare il PCB ed anche montare i componenti da Seeedstudio.... sono cinesi ma fanno a dovere il loro lavoro... ho un paio di loro oggettini e vanno alla perfazione e la fattura è davvero buona....

la commercializzazione è l'ultimo dei problemi, prima direi che ci serve un hardware e un software prima di produrre una scheda :wink:

quindi attendiamo astrobeed che metta giù i primi sistemi di equazioni che poi provvederemo a risolvere :stuck_out_tongue:

Non volevo insinuare che si potrebbero commercializzare... ma solo che se ci servono a noi che li andremo a testare dei prototipi a basso costo andrebbe preso in considerazione seeedstudio tutto la... proprio per il fatto che questi micro sono in formati inutilizzabili a livello hobbistico...