annuncio

**fvaresano** · 28 gennaio 11, 19:48

lascia che siano gli utenti a proporre i componenti da montare

**twobladez** · 28 gennaio 11, 20:03

Pensiamo prima alle funzionalità/caratteristiche/modularità etc un pò più nel dettagli, prendendo spunto da quello che c'è già in giro e che ci sembra buono e....non reinventiamoci la ruota se qualcosa che è stato già fatto risulta utile al progetto

..mettiamo da parte al momento l'hw e facciamo un pò di brainstorming su tutto il resto...

P.S.: sulle funzionalità etc (non sull'hw/sw) sarebbe il caso di ascoltare un pò tutti...

/Gianni

**ToshiroTamigi** · 28 gennaio 11, 20:14

Che ne pensate di spostarsi su una qualsiasi piattaforma cortex?
Tra le varie in giro ho visto queste(che penso prenderò per fare qualche prova):
Embedded Artists > Products > LPCXpresso & mbed > LPC1769 LPCXpresso
Embedded Artists > Products > QuickStart Boards > LPC1343 QuickStart Board

o alternativamente qualche modello di STM32.

Sono estremamente più economiche e potenti ma comunque supportate da GCC.

**areis81** · 28 gennaio 11, 22:33

da nubbio di informatica l'unica cosa che mi ha bloccato dall'intraprendere l'avventura del multiwiiquad è la programmazione. please rendetemelo semplice!

**elettro** · 29 gennaio 11, 01:50

secondo me l'IDE in base ai componenti scelti dovrebbe linkare solo i moduli necessari.
Ciò è fattibile costruendo le varie classi per i sensori come astratte, con i metodi pubblici (costruttore, update() e leggi(), per esempio ) e poi per ogni modello di sensore la specifica sottoclasse.
Nel momento in cui si scelgono i propri modelli di sensori dall'IDE, viene generato un .pde apposito. In questo modo può venirsi a creare una libreria di sensori, oltre che stimare la durata del ciclo di aggiornamento del programma (dato molto utile)
Addirittura facendo le cose per bene, diverrebbe possibile settare Teensy++, arduino classico o mega, perché ogni sensore avrebbe le sue sottoclassi per inizializzare correttamente anche il micro.
Per sensore intendo sia input che output...

Come algoritmo di stabilizzazione propongo la DCM, l'algoritmo che ho usato impiega meno di 1 millisecondo (dai 940 ai 970 microsecondi) sull'atmega328 a 16mhz...

**Triky81** · 29 gennaio 11, 02:24

ciao
sono daccordo e contrario un po con tutti.
l'hardware è in costante sviluppo, davvero non gli si riesce a stare dietro.
se si vuole fare una cosa molto economica io non userei un ITG3200 che costa solo lui 60.
con tutte le evoluzioni dei progetti ormai tutti gli investimenti in idg500, adxl335 e tanti altri che ho comprato nell'ultimo anno li butterei via, è un peccato perchè per costruire una cosa con un minimo di stabilità vanno benissimo, ricordiamoci che sul primo x-ufo c'erano giroscopi meccanici, eppure volava.
mi baserei su giroscopi analogi "rimediati" tipo da giro di elicotteri come fecero con la kk.
se poi la lettura analogica rallenta, mettiamo un micro dedicato alla sola conversione I2C dei sensori che manda tutto ad un'altro micro sempre economico che fa solo miscelazione rx e sensori, anche le due schede che ha indicato Tashiro per me andrebbero bene, apparentemente economiche e funzionali.
io su uno dei miei quad ho usato multiwii ho iniziato con mp, nk, 4 cf2822, 4esc pwm 18A, chip arduino e shield autocostruito e telaio tubi Leroy merlin. totale spesa appena 100.
questa per me è una cosa economica, naturalmente radio a parte e batteria, quelle sono cose che uno bene o male già possiede.

@ Ciskye: non prenderla come offesa ma la foto del telaio sembra un dolce millefoglie

**fvaresano** · 29 gennaio 11, 03:30

se si vuole fare una cosa molto economica io non userei un ITG3200 che costa solo lui 60.

In realta' quel chip costa circa 10 euro a comprarlo grezzo.. pero' devi poi saldarlo e farti una PCB da solo. (cosa che io ho fatto)

Nel mio ultimo ordine di PCB (http://www.varesano.net/files/IMG_0946.JPG) ho diverse breakout board .. tra cui una per l'ITG3200, se ne vuoi una (pronta per l'uso o da saldare) fatti sentire.

**danveal** · 29 gennaio 11, 09:02

Originariamente inviato da Triky81 Visualizza il messaggio

ciao
mi baserei su giroscopi analogi "rimediati" tipo da giro di elicotteri come fecero con la kk.
se poi la lettura analogica rallenta, mettiamo un micro dedicato alla sola conversione I2C dei sensori

Se si vogliono usare gyro analogici io consiglio di usare sempre il wiimotion ma in analogico. I gyro dei cloni sono gli idg650 e sono equivalenti all' itg3200 come "core".
Il vantaggio dell' itg3200 e' il condizionamento del segnale e la conversione in i2c fatta al suo interno cosa che elimina parecchio rumore.
Una lettura analogica poi puo' essere ancora piu' veloce perche l'itg3200 genera 1000 letture al secondo se settato con filtri sotto 256Hz o 8000 letture se settato con filtro a 256Hz.
Io il wiimotion in analogico l'ho usato ( la versione originale ) nei miei primi esperimenti e funziona bene, molto meglio dei murata che sono dentro i gyro degli elicotteri che soffrono di deriva termica, richiede un minimo di capacità di saldatura, nel link sotto lo schema di collegamento
http://www.baronerosso.it/forum/mode...crobatico.html

Un saluto di Benvenuto a Fabio

**biv2533** · 29 gennaio 11, 12:17

Appoggio la proposta di Danilo, anche da un punto di vista economico, tre giroscopi anche cloni e non di marca costano sicuramente di piu' che non la WiimotionPlus

**AleBS** · 29 gennaio 11, 13:56

Chiedo agli esperti se una soluzione del genere possa soddisfare un buon risultato in base a cosa monta il WMP nel link e considerando il prezzo. A breve dovrei riceverlo, l'arduino è operativo, se volete che faccia qualche prova in particolare chiedete pure (per avere una conferma del funzionamento) e appena pronto potrei dire come gira

(mi mancano però ancora una tonnellata di pollici per il volato neh

)

Ciao

**redfox74** · 29 gennaio 11, 14:31

Ciao a tutti,
penso che reinventare l'acqua calda non serva proprio a nessuno , nel senso che i progetti che gia' esistono coprono il 100 % delle esigenze degli utenti entry level.
Secondo me vanno definite prima le esigenze per capire che cosa vogliano gli utenti , e poi semplicemente li si reindirizza sul progetto piu' adeguato.
Prova a schematizzare rapidamente :

Multiwii / Baronpilot , KK (Piattaforma Arduino 8 bit) - Dev Core Team 1-2 persone
entry level ... buon supporto acro model e supporto iniziale a stable mode ... supportano inoltre gestione sensori ultra low cost .... progetto DIY. (wire e parecchio codice nativo) Supporto di base 4 + x inizio supporto esa okto (Ci sono ancora problemi sulla loro matrixtable un po' troppo entry level e cablata nel codice)

Hardware a parte KK Multiwii e BaronPilot richiedono arduino e un po' di sensori recuperati da device commerciali.

Aeroquad (Piattaforma Arduino 8 bit) - Dev Core Team 10 persone circa
entry level ... buon supporto acro ,stable inizio supporto barometro , gps e magnetometro progetto ( stabilizzazione gps e di quota in corso di test ) da cui e' derivato Arducopter linguaggio di programmazione wire C++ Supporto Multicotteri 4-12
Hardware : Arduino + carrier board ad hock e sensori sparkfun oltre che sensori entry level.

Arducopter - Ardupilot - Arduhely (Piattaforma Arduino 8-32 bit) Dev Core Team 30 persone circa
Supporto Ala Fissa , Multicotteri , Elicotteri . Funzioni supportate : volo acrobatico , volo stabile , sonar per atterraggio automatico , sensore video per position hold indoor e a bassa quota. GPS hold , stabilizzazione di quota con barometro , return to home e navigazione waypoint in versione ardupilot 2.7 , ardupilot mega e arducopter mega.
Hardware : proprietario , sviluppato ad hoc per applicazioni amatoriali , particolarita' sensori compensati in temperatura. ( tante funzioni avanzate sono nuove e non sono ancora sufficientemente debuggate).
Nel progetto arducopter in questo momento mi sto' occupando del porting a 32 bit di tutto il software gia' disponibile , la piattaforma hardware su cui sto' lavorando e' la Multipilot32 anche detta ArduPilot32
Multipilot 2.0 - AP32 Building Log realtime update. The next gen cpu for your Arducopter. - FOXTEAM UAV CLAN

Tutti i progetti qua sopra sono completamente opensource , quindi e' previsto fork e uso commerciale dei progetti .

Mikrokopter:
Piattaforma amatoriale piu' antica , ottime qualita' di volo stabile e acrobatico , position hold gps navigazione waypoint stabilizzazione telecamera per riprese amatoriali e non , molto usata da chi fa' lavoro aereo con quad ... punto di riferimento per molti nuovi sviluppi unica pecca progetto closed source per la parte navi.

Nella mia descrizione sommaria dei progetti sopracitati non vedo alcuna necessita' di inventarcene un'altro . La cosa che invece potrebbe essere molto utile e' unirsi a una di queste community gia' esistenti e migliorare quanto di buono e molto buono e' stato gia' fatto.

Un saluto a tutti
Roberto

**redfox74** · 29 gennaio 11, 14:40

Originariamente inviato da ToshiroTamigi Visualizza il messaggio

Che ne pensate di spostarsi su una qualsiasi piattaforma cortex?
Tra le varie in giro ho visto queste(che penso prenderò per fare qualche prova):
Embedded Artists > Products > LPCXpresso & mbed > LPC1769 LPCXpresso
Embedded Artists > Products > QuickStart Boards > LPC1343 QuickStart Board

o alternativamente qualche modello di STM32.

Sono estremamente più economiche e potenti ma comunque supportate da GCC.

Ciao Toshiro,
se ancora non hai visto questo Multipilot 2.0 - AP32 Building Log realtime update. The next gen cpu for your Arducopter. - FOXTEAM UAV CLAN dai un occhio .
Saluti
Roberto

**blinking** · 29 gennaio 11, 14:50

Originariamente inviato da redfox74 Visualizza il messaggio

Nella mia descrizione sommaria dei progetti sopracitati non vedo alcuna necessita' di inventarcene un'altro . La cosa che invece potrebbe essere molto utile e' unirsi a una di queste community gia' esistenti e migliorare quanto di buono e molto buono e' stato gia' fatto.

Un saluto a tutti
Roberto

dal punto di vista logico condivido pienamente la tua idea.

dal punto di vista pratico, è bene non dimenticare che siamo modellisti, fondamentalmente un ibrido tra artigiani e artisti.
il fatto che ci siano in commercio 50 (ipotesi) modelli di Extra300 non ci impedisce di farcene uno da noi, magari con soluzioni tecniche ispirate a quello o quell'altro progetto. Utilita' pratica nessuna, ma la soddisfazione di farselo da se' è parte integrante dell'hobby.

per cui in definitiva, se Ciskje, Danveal, e tutti gli altri (non fatemi fare la lista!) non si sentono di riversare le loro capacità in un progetto iniziato da altri per le loro buone ragioni, non vedo perchè non dovrebbero poter fare qualcosa di diverso.

**redfox74** · 29 gennaio 11, 15:21

Originariamente inviato da blinking Visualizza il messaggio

dal punto di vista logico condivido pienamente la tua idea.

dal punto di vista pratico, è bene non dimenticare che siamo modellisti, fondamentalmente un ibrido tra artigiani e artisti.
il fatto che ci siano in commercio 50 (ipotesi) modelli di Extra300 non ci impedisce di farcene uno da noi, magari con soluzioni tecniche ispirate a quello o quell'altro progetto. Utilita' pratica nessuna, ma la soddisfazione di farselo da se' è parte integrante dell'hobby.

per cui in definitiva, se Ciskje, Danveal, e tutti gli altri (non fatemi fare la lista!) non si sentono di riversare le loro capacità in un progetto iniziato da altri per le loro buone ragioni, non vedo perchè non dovrebbero poter fare qualcosa di diverso.

Ciao blinking ,
non fraintendere non voglio proprio obligare nessuno ... io l'ho semplicemente pensata cosi' da sempre ... nei progetti opensource di solito ci sono due filoni di sviluppo , quella che viene chiamata trunk e quella che viene chiamata branch.
Io ho lavorato a diversi branch nel tempo sia per Aeroquad che per Arducopter, i branch contengono funzioni sperimentali , sviluppate su idee piu' o meno originali che poi quando sufficientemente stabili possono essere importate nel progetto originale trunk , questo modo di procedere lascia spazio all'estro creativo e all'individualismo che ci vuole sempre in queste cose. Pero' sempre in un ottica di lavoro di squadra.
Un'altra cosa che puoi fare se no e' un fork di un progetto come Arducopter come avevano fatto i pirati dove tu dici , io parto di qua ma faccio una cosa totalmente diversa dal progetto originale. Per far comunque una cosa di questo genere bisogna avere massa critica se no non ha alcun senso ...
Il problema di aprire nuovi progetti o fork e' che se poi non hai massa critica spendi un sacco di tempo e sforzi che si spengono come una fiamma di cerino al vento ... quindi quel poco tempo che si ha tutti noi a disposizione e' meglio spenderlo nel modo piu' produttivo possibile

Quindi se parliamo di un nuovo progetto decidiamo da che parte si vuol partire potrebbe essere un fork di baron pilot e dove si vuol arrivare ..

Cmq dopo multipilot32 il prossimo progetto a cui mi dedichero' e' AtomKopter un evoluzione di multipilot32 con un cooprocessore atom x86 da 1.3 giga.
Saluti
Roberto

File allegati

annuncio

Simplo - Progetto open source semplice ed economica piattaforma stabilizzante

Simplo - Progetto open source semplice ed economica piattaforma stabilizzante

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta