MultiWii Quad! Alternativa ad Aeroquad/Baronpilot con sensori wii

[jhoexp]

Bella notizia il video

Seguo quel topic quasi ogni giorno ma si direbbe che quei risultati alla fine li raggiunge solo lo sviluppatore e pochi altri (cioe', io di tutti questi setup funzionanti e utenti entusiasti non ho notizia, a leggere quelle pagine).

Veramente lo sviluppatore non è quello del video, e comunque fin dall'inizio del progetto gli utenti attivi e intraprendenti hanno avuto risultati migliori.
Il position hold non è ancora perfetto ma sta iniziando a funzionare decentemente dalla dev precedente grazie ad eosbandi.
Ci sono mille configurazioni supportate come al solito e tenere traccia di tutto è un pasticcio, i mei multiwii con atmega256 e gps seriale (mtk3329 e 3339) funzionano, anche se la versione i2c per ora sembra una soluzione migliore...

[Sergei]

A mio parere EosBandi stà facendo un grosso lavoro, da parte mia ho preso il Navigatron V2 che ha a bordo l'atmega 328 e che comunica in I2C scaricando così l'Arduino principale da tutte le incombenze di calcolo necessarie al Gps.
In questi progetti bisogna seguire e quando possibile aiutare e i risultati verranno.
Personalmente seguo Multiwii poichè apprezzo il lavoro di questi sviluppatori, anche se auspicherei un maggior coordinamento, e poi io sono uno di quelli che preferiscono creare i propri modelli e magari scassarsi le p...e per farli funzionare e non ricorrere a prodotti preconfezionati.

[silfox70]

A mio parere EosBandi stà facendo un grosso lavoro, da parte mia ho preso il Navigatron V2 che ha a bordo l'atmega 328 e che comunica in I2C scaricando così l'Arduino principale da tutte le incombenze di calcolo necessarie al Gps.
In questi progetti bisogna seguire e quando possibile aiutare e i risultati verranno.
Personalmente seguo Multiwii poichè apprezzo il lavoro di questi sviluppatori, anche se auspicherei un maggior coordinamento, e poi io sono uno di quelli che preferiscono creare i propri modelli e magari scassarsi le p...e per farli funzionare e non ricorrere a prodotti preconfezionati.

ciao Sergei tu nell'integrazione a che punto sei? Hai già montato il tutto e fatto qualche prova di volo?

Grazie

[Sergei]

ciao Sergei tu nell'integrazione a che punto sei? Hai già montato il tutto e fatto qualche prova di volo?

Grazie

No, sono ancora in attesa di materiale per finire la costruzione del mio quinto quadri che sarà
principalmente dedicato alla navigazione Gps.
Seguo però con grande interesse il forum Multiwii riguardante l'integrazione del Gps da parte di Eosbandi.

[blackfede]

Ciao, noto che il mio quadri (mwii 2.0 con leggera MM e pid di default) quando effettuo una discesa un po' decisa (ovvero, quando tolgo gas per venire giu' dritto) tende a traballare un po'. E' risolvibile questa cosa? Non mi crea problemi ma non mi piace molto...
Fede

[enrycorser]

Oggi per la prima volta ho sperimentato involontariamente l'entrata in funzione del "fail-safe", con conseguenti attimi di "movimenti intestinali convulsi".

Volo in una piazza deserta ma molto ampia, usata un giorno la settimana per il mercato rionale. Quello che sto cercando di mettere in pratica ultimamente è il volo "contro". Ore di simulatore ed esperienza live quando possibile.

Multiwii 2.0 M.M attive su Flyduino. Alla seconda lipo di hovering (o quasi...motori un pelo sotto il 50%) sento 3 bip dalla turnigy 9x, non faccio in tempo a guardare il display e mi accorgo che il quadri non risponde più ai comandi. Spengo e riaccendo la radio....ma non si riaccende!!! Non ho potuto far altro che guardare come veniva giù ed iniziava a saltellare come un canguro appena toccava terra.

La radio era calda (ma ero sotto il sole a picco e quì in siculonia fa caldo) e si è riaccesa solo dopo 10 minuti all'ombra.

Scusate ma volevo solo condividere....mi metto alla ricerca del possibile problema...

[Sergei]

Ciao, noto che il mio quadri (mwii 2.0 con leggera MM e pid di default) quando effettuo una discesa un po' decisa (ovvero, quando tolgo gas per venire giu' dritto) tende a traballare un po'. E' risolvibile questa cosa? Non mi crea problemi ma non mi piace molto...
Fede

Quando "vieni giu dritto" come dici tu scendi nelle turbolenze create dalle tue stesse eliche che spingono l'aria verso il basso, pertanto quello che riscontri è perfettamente normale.
Quando scendi dovresti mantenere anche un minimo avanzamento.

[magnetron1]

Ciao, noto che il mio quadri (mwii 2.0 con leggera MM e pid di default) quando effettuo una discesa un po' decisa (ovvero, quando tolgo gas per venire giu' dritto) tende a traballare un po'. E' risolvibile questa cosa? Non mi crea problemi ma non mi piace molto...
Fede

Pensa che senza MM quel traballamento sarebbe pure peggio!
E' normale. Devi traslare leggermente di lato o diminuire la velocità di discesa.

[redfox74]

A mio parere EosBandi stà facendo un grosso lavoro, da parte mia ho preso il Navigatron V2 che ha a bordo l'atmega 328 e che comunica in I2C scaricando così l'Arduino principale da tutte le incombenze di calcolo necessarie al Gps.
In questi progetti bisogna seguire e quando possibile aiutare e i risultati verranno.
Personalmente seguo Multiwii poichè apprezzo il lavoro di questi sviluppatori, anche se auspicherei un maggior coordinamento, e poi io sono uno di quelli che preferiscono creare i propri modelli e magari scassarsi le p...e per farli funzionare e non ricorrere a prodotti preconfezionati.

Ciao a tutti ,
ora do' un occhio anche io a quanto sta' facendo EOSBANDI sono curiso di capire che strada sta' prendendo visto che anche con i nostri sviluppi stiamo facendo passi avanti enormi. Comunque sarebbe carino che anziche' continuare con AVR che ormai e' destinato a breve tempo a lasciare spazio a soluzioni ARM si iniziasse a prendere in mano il bel lavoro fatto da Timecop su Multiwii e si portasse li sopra il gps.
Un sacco di risorse in piu' e non c'e' la necessita' di mettere piu' AVR in cascata per evitare di intaccare le prestazioni.
Io ci sto' facendo una pensata al porting anche di multiwii sulla VR BRAIN che arrivera' tra qualche settimana ed e' allineata con la soluzione NAZE32 come architettura hardware.
Chi fosse interessato alla cosa mi faccia sapere.
In merito alla complessita' di setup delle funzioni automatiche l'esperienza dice che servirebbe a bordo anche una dataflash per salvare log da poter sbobinare e capire esattamente cosa succede a bordo durante i test.
Solo in quel modo si riesce a livello sistematico a capire cosa va nella direzione giusta dello sviluppo e cosa no.
Io in futuro auspicherei una convergenza dei progetti opensource proprio perche' in quanto tali sarebbe meglio lavorare tutti assieme su qualcosa di molto efficace piuttosto che rimetterci tutti a reinventare la ruota
Saluti
Roberto

[redfox74]

Eosbandi Usa Il Nostro Stesso Approccio

Ciao a tutti,
ho appena guardato lo sviluppo di EOSBANDI e mi sono letto il suo doc r33 che si trova a questo link ... Downloads - i2c-gps-nav - Arduino based GPS and NAV co-proc for I2C protocol - Google Project Hosting
assieme al codice.
Allora il codice che usa e' il nostro a cui stiamo lavorando parlo del DEVTEAM di Arducopter di cui faccio parte assieme a tanti altri italiani come Emile , Marco Robustini ecc.
Quindi doppio PID annidato con POS HOLD e POS_RATE.
In realta' ci sono gia' diversi miglioramenti apportati da Angel a questo codice per rendere piu' efficiente e dinamico il comportamento nel caso in cui ci siano variazioni di velocità del vento intervenendo sul KI in modo automatico.
Sono contento che quello che ho detto nel post precedente in realta' sta' gia' avvenendo a livello di opensource e' meglio unire le forze e trovare spunti comuni in modo da raggiungere presto risultati eccellenti
Questo e' il video del mio Loiter con quell'algoritmo , mettendo pero' a zero la P del HOLD perche' con valori piu' alti oscilla sul punto senza vento .
Quindi direi che ci siamo circa 3 metri di errore.
VIDEO:
MP32F4 + NAVY 2012 Loiter and Altitude Hold test 2 - FOXTEAM UAV CLAN
FOTO del LOG di volo 3 metri di errore.
Primi Test Loiter F4 - FOXTEAM UAV CLAN

Il fatto di usare un micro dedicato anziche' lo stesso che si usa per l'assetto e' un vantaggio anche se la comunicazione in i2c a me non piace infatti cerco di eliminarla da qualsiasi device che interfaccio e preferisco SPI .
Il mio test ovviamente e' fatto su arm

Saluti
Roberto

[blackfede]

Grazie per la spiegazione a proposito delle vibrazioni, mi ero accorto che scendendo lentamente o traslando queste non c'erano.

@redfox sicuramente la piattaforma arm e' il futuro, ma come ben sai lo zoccolo duro dello sviluppo di multiwii non ci sente :huh

Ma quali vantaggi si potrebbero avere dalla vrbrain e multiwii assieme? A quel punto non sarebbe decisamente piu' conveniente comunque la vostra piattaforma software?

[ziojos]

Ciao a tutti,
ho appena guardato lo sviluppo di EOSBANDI e mi sono letto il suo doc r33 che si trova a questo link ... Downloads - i2c-gps-nav - Arduino based GPS and NAV co-proc for I2C protocol - Google Project Hosting
assieme al codice.
Allora il codice che usa e' il nostro a cui stiamo lavorando parlo del DEVTEAM di Arducopter di cui faccio parte assieme a tanti altri italiani come Emile , Marco Robustini ecc.
Quindi doppio PID annidato con POS HOLD e POS_RATE.
In realta' ci sono gia' diversi miglioramenti apportati da Angel a questo codice per rendere piu' efficiente e dinamico il comportamento nel caso in cui ci siano variazioni di velocità del vento intervenendo sul KI in modo automatico.

Non per puntualizzare, ma hai scoperto quello che ho scritto nella pagina precedente di questo tread e che EOSBandi dichiara esplicitamente , Avevo pure invitato a vedere le Tue dimostrazioni e quelli di Bobo67 su Arducopter ( Marco è collaudatore ufficiale di arducopter) per farsi un' idea.


Ciao

[redfox74]

Non per puntualizzare, ma hai scoperto quello che ho scritto nella pagina precedente di questo tread e che EOSBandi dichiara esplicitamente , Avevo pure invitato a vedere le Tue dimostrazioni e quelli di Bobo67 su Arducopter ( Marco è collaudatore ufficiale di arducopter) per farsi un' idea.


Ciao

Scusa ZioJos , sei arrivato prima tu di me Non avevo letto le pagine precedenti
Comunque bello dai avanti tutta sul GPS Ero troppo curioso di vedere cosa bolleva in pentola . Bene Bene ... allora ora possiamo mettere a fattor comune le esperienze e i setup

[redfox74]

Grazie per la spiegazione a proposito delle vibrazioni, mi ero accorto che scendendo lentamente o traslando queste non c'erano.

@redfox sicuramente la piattaforma arm e' il futuro, ma come ben sai lo zoccolo duro dello sviluppo di multiwii non ci sente :huh

Ma quali vantaggi si potrebbero avere dalla vrbrain e multiwii assieme? A quel punto non sarebbe decisamente piu' conveniente comunque la vostra piattaforma software?

E' questione di gestione del volo e di quanto le persone siano appassionate a piattaforme software che hanno visto crescere. C'e' chi preferisce di gran lunga la multiwii per l'assetto , almeno in modalità acro che la arducopter supporta male.
E chi invece preferisce arducopter e tutto cio' che sta' attorno a quella piattaforma. Io ai tempi avevo sposato arducopter. Quando e' nata da una costola di Aeroquad su cui stavo gia' lavorando con TED prima dello sviluppo della mia piattaforma arm anch'io usavo AVR il 644p quello che chiamano sanguino . Il motivo era perche' era compatibile anche con Mikrokopter. Poi ho rivoluzionato tutto e sono andato su qualcosa di totalmente nuovo.
Ora fare un confronto multiwii vs arducopter potrebbe scaturire un putiferio per la gioia dei moderatori . Quindi non butto benzina sul fuoco ... ma in futuro magari potremmo fare qualche parallelo magari piu' cattivo ... contro il Naza ... ;)
Comunque su multiwii in realta' tutta la parte di gps e' ancora in fase molto embrionale e non la vedo ben supportata ne dalla sua gui ne dal protocollo di comunicazione ne dagli strumenti di debug.
Io posso dare una mano al porting di multiwii 2.0 su ST magari partendo dal lavoro di timecopt ma servirebbe un project leader appassionato a multiwii fino ai budelli per potare avanti con passione questo porting.
Riscrivendo tutto per una piattaforma piu' potente bisogna vedere come si e' bravi a fare il lavoro Pero' sicuramente il risultato potrebbe essere veramente FIKO !!
Io gia' sto' impazzando per mantenere allineato Arducopter con la piattaforma MP32F4 e di tempo per fare le cose bene non ne avrei molto , poi e' una questione di continuita' non puoi mollare una settimana .. perche' se guardi il repo gia' ci sono mille cose ... poi sapendo leggere il codice e' importante anche tirar dentro nel tuo branch le cose che hanno senso invece di quelle che introducono bachi micidiali
Saluti
Roberto

[redfox74]

Continuando a scuriosare nel codice mi sono accorto che si e' preso proprio le nostre lib di base sul PID , AC_PID e anche i registri nella struct sono proprio le nostre , non ho capito bene come fa la parametrizzazione remota tramite il tools della multiwii ... Okkio pero' che questa versione e' vecchia di quasi un mesetto.
Andrebbe riallineata ...
La cosa bella e' quando ti citano in un progetto che nemmeno sai che esiste


/************************************************** ************************************************** ***************************
* I2CGPS - Inteligent GPS and NAV module for MultiWii by EOSBandi
* V2.0
*
* This program implements position hold and navigational functions for MultiWii by offloading caclulations and gps parsing
* into a secondary arduino processor connected to the MultiWii via i2c.
* Once activated it outputs desired banking in a lat/lon coordinate system, which can be easily rotated into the copter's frame of reference.
* Need an updated version of Wire library, since current one does not handle repeated start in slave mode.
* also uses PI and PID libraries from the Arduplane team
*
* Navigation and Position hold routines and PI/PID libraries are based on code and ideas from the Arducopter team:
* Jason Short,Randy Mackay, Pat Hickey, Jose Julio, Jani Hirvinen
* Andrew Tridgell, Justin Beech, Adam Rivera, Jean-Louis Naudin, Roberto Navoni

Il bello dell'opensource.
Saluti a tutti
Roberto Navoni