MultiWii Quad! Alternativa ad Aeroquad/Baronpilot con sensori wii

[jhoexp]

Ragazzi ho un problema,

dopo questo fantastico approfondimento sulle telecomunicazione vorrei chiedervi un consiglio.

Beh, sempre meglio che un calcio nelle palle, no?

EDIT: a parte il mio epic fail: non avevo premuto start...comqunque sia nonostante premo start i valori oscillano da in modo assurdo! quasi come se riproducessero un onda quadra. a breve carico una foto

10k di pullup non sono un po' troppi? Prova con 1.5 - 2 - 3.3k e vedrai che andrà meglio.
Alla prima accensione devi calibrare gli accellerometri (motore al massimo - jaw tutto a sx, pitch tutto cabra)

[kamikazeta]

Ragazzi ho un problema,

dopo questo fantastico approfondimento sulle telecomunicazione vorrei chiedervi un consiglio.

Ho montato su breadboard un accelerometro ADXL345 (grazie Fabio!) e un giroscopio L3G4200D, per l'alimentazione mi sono attaccato direttamente ai 3,3V di arduino e ho connesso come sempre i due fili dell'I2C con gli appositi resistori di pull-up (da 10k).

Le connessioni sono corrette perchè le ho usate e riusate con altri SW.

Apro con il software di Arduino il codice del Multiwii 1.7 e imposto come segue:
/*******************************/
/****CONFIGURABLE PARAMETERS****/
/*******************************/

/* The type of multicopter */
//#define GIMBAL
//#define BI
//#define TRI
//#define QUADP
#define QUADX
//#define Y4
//#define Y6
//#define HEX6
//#define HEX6X
//#define FLYING_WING //experimental

//#define I2C_SPEED 100000L //100kHz normal mode, this value must be used for a genuine WMP
#define I2C_SPEED 400000L //400kHz fast mode, it works only with some WMP clones

#define PROMINI //Arduino type
//#define MEGA

//enable internal I2C pull ups
//#define INTERNAL_I2C_PULLUPS

/* I2C gyroscope */
//#define ITG3200
#define L3G4200D

/* I2C accelerometer */
#define ADXL345
//#define BMA020
//#define BMA180
//#define NUNCHACK // if you want to use the nunckuk as a standalone I2C ACC without WMP


/**************************************/
/****END OF CONFIGURABLE PARAMETERS****/
/**************************************/

Non vi spaventate, non ho segato via parti di codice ma ho solo riportato le parti che ho modificato.

Fattostà che lo carico sull'arduino, una volta finito dopo qualche blinkata di led come a mostrarmi che sta caricando il SW inizia a lampeggiare periodicamente... e non fa altro...
se apro la GUI e imposto la porta COM corretta non da neppure segni, non legge nulla... e tutto con ancora quel simpatico LED lampeggiare...

Non so, ditemi voi che avete più esperienza.

Ahh, mi sono dimenticato di dire che ho caricato il software su un arduino UNO, monta sempre ATMEGA 328p e ho visto già che altre persone lo hanno utilizzato.

Vi prego aiutatemi!


EDIT: a parte il mio epic fail: non avevo premuto start...comqunque sia nonostante premo start i valori oscillano da in modo assurdo! quasi come se riproducessero un onda quadra.
In allegato ho meso una foto di ciò che vedo.

alimentazione USB troppo bassa? hai provato a dare alimentazione da batteria e USB (senza eliche ovviamente)?

[kamikazeta]

P.S: ci sei il 18, vero?!?!?

mhaa.... albio dice che passa alle 7.15, pronto o non pronto mi porta via di peso ....(seee lo voglio vedere 107 kg da alzare x1.90 di altezza), quindi...

[Pela_91]

Allora, ho riprovato con dei pull-up da 2,2k ma la cosa non cambia...
Comunque per la precisione ora come ora non ho attaccato ne batteria ne ricevitore... sono solo con arduino e bredboard, ho collegato tutto giusto per vedere se ci fosse qualche risposta umana
Su un blog, mi sembra si chiamasse Robodroid, ho visto che quel ragazzo ha fatto la mia stessa cosa ma con sensori wii e l'esito è stato però positivo.

EDIT: preciso che il problema c'è sia con lo standard mode che con il fast mode.

più che altro quello che mi spiazza è la forma d'onda letta... l'ho allegata al post prima

[kamikazeta]

@Pela_91
io quei valori di 400 -400 li ho quando alimento solo con USB. sia con wiimotion, sia con freeimu alimentato a 5V (disabilitando i pullup per la freeimu).

[Pela_91]

@Pela_91
io quei valori di 400 -400 li ho quando alimento solo con USB. sia con wiimotion, sia con freeimu alimentato a 5V (disabilitando i pullup per la freeimu).

Dici che con la batteria cambia? comunque i sensori sono collegati al 3,3V quindi le loro letture non penso siano influenzate più di tanto.

ahh un'altra curiosità, è normale che non mi segnali la presenza del giroscopio? sulla GUI c'è solo segnato in rosso Nunchuck, non c'è niente relativo ad altri giroscopi?

ripeto, quello che più mi spiazza resta comunque la forma dell'onda... è davvero strana!

[marchino65]

no ho provato con corse al 100% ma nulla, nessun nuovo modello, sempre modalità elicottero sulla mia cockpit sx. ho cambiato da mode 1 a mode 3 (si scambiano yaw e pitch) ma con qualsiasi stick in qualsiasi posizione nulla da fare

ciao
lol21

Ciao,
scusa ma forse mi sono spiegato male. Devi mettere la corsa al 120% sull stick che ti arma i motori.

Saluti

[hurricane01]

secondo i guru perchè il mio quadri nell'hovering è stabilissimo mentre nel volato traballa un pò? Su che valori devo intervenire? grazie

[Jonny-Paletta]

Ho letto/capito male io o con la FreeIMU ci son più problemi che con il WM+&BMA020?

Mi pare che nel volato vada bene ma nello STABLE ancora non troppo, in più lo stesso Fabio consiglia di lasciare disattivato il barometro...

[servo]

Ciao ragazzi oggi sono andato a provare il QUADROX anche
se ne esce un pezzo dal bauletto della moto
sono riuscito ad arrivare al campo sportivo
va tutto bene ma il vizio di scendere di quota da solo non se lo toglie.

Sensori attivi itg3200,bma02o,bussola
da subito o notato che la bussola lavora bene in fatti se la disattivavo
il quad iniziava a ruotare su se stesso, la busssola lo tiene fermo

O.T-jonny,Ommini a che punto siete fatevi vivi

Ciao,servo

[Jonny-Paletta]

Servo, io sono sempre allo stesso punto

[ziojos]

Mi spiace, cerco di evitare a prescindere queste cose, ma anch'io arrivo e trovo scritto che bluetooth e 2.4 non vanno insieme. Come esempio un clamoroso piantamento in aria con tanto di ricevente che non recupera il failsafe.... Beh, insomma, dai... non son proprio riuscito a stare zitto...

Per altro un po' più lungo io ce l'ho sempre... IL NASO!!!


Per quanto riguarda il mahoni/ magdwick ne abbiamo molto bisogno... molti si accontentano di quello che c'è adesso, ma diciamo la verità... non è cambiato quasi niente. Abbiamo tutte ste belle imu complete, piccole ed economiche, made in varesano/jussi, i due nuovi amiconi torindanesi ma così sono pressochè inutili se non si usa un algoritmo evoluto e i quaternioni sembrano la risposta giusta...

Si stanno perdendo sull'altitude holding ma se ci voli 2 minuti sul serio, il magnetometro dopo un po' lo stacchi e se accendi il level mode è meglio che ti prepari ad andare a prendere il mezzo con un sacco della spazzatura...

Sarò felice di vedervi finalmente a Bologna... anche se di manifestazioni nella mia zona ce ne sono state...

Johnny, come sai sono su AQ, sulle ultime versioni vengono usati in alternativa DCM e Quaternioni, Tra l'altro i guru di AQ hanno anche coretto qualche bug sulla Magdwick. hanno integrato il magnetometro e come risultato ... stanno impazzendo sullo stesso problema segnalato da Roberto su DCM che di la chiamano "leans". Questo problema di fatto rende inutilizzabile il modo stabile per un volato affidabile e se ben capisco da quello che dice Roberto lo stesso problema affligge la Megapirates e i suoi derivati.

La MARG se utilizza le differenze di campo magnetico può essere di un certo aiuto, comunque su AQ non da nessun risulato probabilmente meglio il GPS , anche se non privo di problemi, per correggere gli effetti delle accelerazioni centripete ed evitare i drift di assetto.
Le due soluzioni sembrano apparentemente molto diverse ma il risultato è praticamente lo stesso e pure le prestazioni in termini di carico CPU sono simili a parità di funzionalità. Ovviamente se si considerano soluzioni ottimizzate (lo dice lo stesso Magdwick ;) ).
Resta una questione di gusti o di specifiche esigenze. Ho studiato la questione già tanti anni () fa in un settore completamente diverso, quello delle immagini riprese da Satelliti Stereoscopici alla fine scelsi le trasformazioni coseno che mi sembravano più pratiche.

Quindi ben venga la soluzione proposta da ciskje ma non la considererei alternativa a DCM, in pratica danno gli stessi risultati e gli stessi problemi.

A quanto ho capito ciskje ha modificato o almeno ben tarato l'algoritmo originale di Magdwick , analogamente a quanto ho fatto per correggere questi difetti ed ottenere risultati aggiuntivi quali una migliore qualità del volo autolivellato e l'annullamento del Drift sui GYRO con la DCM e con le Routine di Controllo.
Nel mio caso ho ottenuto risultati soddisfacenti con un'opportuna taratuta della DCM, con un significativo controllo delle accelerazioni e con l'adozione di Unbised Gyro senza dover ricorrere al GPS.


Ciao

[redfox74]

Johnny, come sai sono su AQ, sulle ultime versioni vengono usati in alternativa DCM e Quaternioni, Tra l'altro i guru di AQ hanno anche coretto qualche bug sulla Magdwick. hanno integrato il magnetometro e come risultato ... stanno impazzendo sullo stesso problema segnalato da Roberto su DCM che di la chiamano "leans". Questo problema di fatto rende inutilizzabile il modo stabile per un volato affidabile e se ben capisco da quello che dice Roberto lo stesso problema affligge la Megapirates e i suoi derivati.

La MARG se utilizza le differenze di campo magnetico può essere di un certo aiuto, comunque su AQ non da nessun risulato probabilmente meglio il GPS , anche se non privo di problemi, per correggere gli effetti delle accelerazioni centripete ed evitare i drift di assetto.
Le due soluzioni sembrano apparentemente molto diverse ma il risultato è praticamente lo stesso e pure le prestazioni in termini di carico CPU sono simili a parità di funzionalità. Ovviamente se si considerano soluzioni ottimizzate (lo dice lo stesso Magdwick ;) ).
Resta una questione di gusti o di specifiche esigenze. Ho studiato la questione già tanti anni () fa in un settore completamente diverso, quello delle immagini riprese da Satelliti Stereoscopici alla fine scelsi le trasformazioni coseno che mi sembravano più pratiche.

Quindi ben venga la soluzione proposta da ciskje ma non la considererei alternativa a DCM, in pratica danno gli stessi risultati e gli stessi problemi.

A quanto ho capito ciskje ha modificato o almeno ben tarato l'algoritmo originale di Magdwick , analogamente a quanto ho fatto per correggere questi difetti ed ottenere risultati aggiuntivi quali una migliore qualità del volo autolivellato e l'annullamento del Drift sui GYRO con la DCM e con le Routine di Controllo.
Nel mio caso ho ottenuto risultati soddisfacenti con un'opportuna taratuta della DCM, con un significativo controllo delle accelerazioni e con l'adozione di Unbised Gyro senza dover ricorrere al GPS.


Ciao

Ciao ZioJoe,
ho discusso con Doug il coordinatore dello sviluppo di ArdupilotMega . Sugli aerei il problema e' in parte risolto nel senso che viene sfruttata la dinamica di volo del velivolo stesso per contenere gli errori generati dalle accelerazioni in volo .
Per quanto riguarda il problema specifico si puo' attenuare diminuendo il gain degli accelerometri ed impiegando maggiormente i giroscopi. Potrebbe funzionare un algoritmo adattivo , in realta' il problema e 'come fare il debug di questo problema durante il volo , l'unica idea plausibile e' quella di usare un braccio robotico e generare un percorso noto e fare le verifiche di congruenza sull'assetto del braccio robotico e l'attitude ritornato dalla piattaforma , oppure usare un sistema ottico che puo' valutare in tempo reale l'assetto reale rispetto a quello rilevato dalla imu di bordo.
A quanto pare il problema e' generalizzato a tutte le piattaforme imu che usano sensori mems . Il problema in realta' non si pone su piattaforme che volano in modo tranquillo e prevedibile come quelle impiegate per riprese aeree , ma sopratutto su quad che fanno volo acrobatico e' quindi sconsigliabile l'impiego della modalita' stabile per fare acrobazie . Con lo switch e' abbastanza semplice passare da una modalita' all'altra molto rapidamente. I gyro da soli non hanno ovviamente questo problema , pero' non sono in grado di mantenere informazioni di assetto impiegabili per un volo stabile. Doug mi ha detto che se avete idee in merito di come poter risolvere il problema di girarle pure anche a lui che e' molto interessato ad approfondire l'argomento ad oggi sembra un problema arginabile , ma non totalmente risolvibile.
Sul discorso del marg penso che la dipendenza dell'algoritmo dal magnetometro e' la maggior fragilita' che vedo , in presenza di masse magnetiche o metalliche l'assetto verrebbe completamente alterato ... penso anche i campi magnetici dei motori potrebbero dare fastidio , non so' perche' non ho esperienza sull'algoritmo specifico.
Io mi sono reso conto del problema in modo molto chiaro grazie all'impiego del log che abbiamo appena finito di iimplementare su AC32 dove si vede chiaramente il problema e l'entita' stessa della cosa ...
Magari nei prossimi giorni posto un file kml dove si vede chiaramente il problema.
saluti
Roberto

[ziojos]

Ciao ZioJoe,
ho discusso con Doug il coordinatore dello sviluppo di ArdupilotMega . Sugli aerei il problema e' in parte risolto nel senso che viene sfruttata la dinamica di volo del velivolo stesso per contenere gli errori generati dalle accelerazioni in volo .
Per quanto riguarda il problema specifico si puo' attenuare diminuendo il gain degli accelerometri ed impiegando maggiormente i giroscopi. Potrebbe funzionare un algoritmo adattivo , in realta' il problema e 'come fare il debug di questo problema durante il volo , l'unica idea plausibile e' quella di usare un braccio robotico e generare un percorso noto e fare le verifiche di congruenza sull'assetto del braccio robotico e l'attitude ritornato dalla piattaforma , oppure usare un sistema ottico che puo' valutare in tempo reale l'assetto reale rispetto a quello rilevato dalla imu di bordo.
A quanto pare il problema e' generalizzato a tutte le piattaforme imu che usano sensori mems . Il problema in realta' non si pone su piattaforme che volano in modo tranquillo e prevedibile come quelle impiegate per riprese aeree , ma sopratutto su quad che fanno volo acrobatico e' quindi sconsigliabile l'impiego della modalita' stabile per fare acrobazie . Con lo switch e' abbastanza semplice passare da una modalita' all'altra molto rapidamente. I gyro da soli non hanno ovviamente questo problema , pero' non sono in grado di mantenere informazioni di assetto impiegabili per un volo stabile. Doug mi ha detto che se avete idee in merito di come poter risolvere il problema di girarle pure anche a lui che e' molto interessato ad approfondire l'argomento ad oggi sembra un problema arginabile , ma non totalmente risolvibile.
Sul discorso del marg penso che la dipendenza dell'algoritmo dal magnetometro e' la maggior fragilita' che vedo , in presenza di masse magnetiche o metalliche l'assetto verrebbe completamente alterato ... penso anche i campi magnetici dei motori potrebbero dare fastidio , non so' perche' non ho esperienza sull'algoritmo specifico.
Io mi sono reso conto del problema in modo molto chiaro grazie all'impiego del log che abbiamo appena finito di iimplementare su AC32 dove si vede chiaramente il problema e l'entita' stessa della cosa ...
Magari nei prossimi giorni posto un file kml dove si vede chiaramente il problema.
saluti
Roberto

Ciao Roberto:

Non so se Doug è competente, credo che ne sappiano di più Premerlani o Cris o lo stesso Magdwick
Come ho accennato il problema l'ho risolto su DCM come descritto, e credo che ciskje abbia fatto lo stesso su MARG.

Per simulare questo inconveniente a terra, una tecnica che usano dalle parti di AQ è quella di dare una decina di scossoni laterali oppure fronte retro abbastanza ampi , questo genera accumulo sull' angolo di assetto (roll o pitch) a seconda della direzione degli scossoni. Se questo avviene in volo comporta brusche reazioni in volo, alcuni quad sono caduti. In genere questa situazione è aggravata dalla presenza di vibrazioni. (ho visto la presenza di Jello su alcuni tuoi filmati segno evidente di forti vibrazioni sul frame che se non accuratamente filtrate meccanicamente possono aggravare il problema.

Quindi, oltre a quanto ho suggerito nel post precedenti è pertanto opportuno lavorare sulle vibrazioni e sulle filtrature dei sensori, in questo caso dell' accelerometro che potrebbe generare dei BIAS.

Quindi in conclusione inserisco la soluzione che ho postato tempo a dietro sul forum AQ

1) costruire un frame ragionevolmente solido
2) isolare opportunamente le vibrazioni dalla IMU e filtrare opportunamente i sensori per non avere aliasing
3)scegliere le eliche giuste e bilanciarle (e se si ritiene opportuno bilanciare anche i motori

I primi tre punti sono soltanto buone practices che tutti conoscono, sono necessari a non aggravare il problema ma non lo risolvono

4) fare il tuning della DCM perchè sia veloce a sufficienza ma non troppo
5) settare e regolare l' accel_weight per cancellare gli effetti indesiderati dell' accelerazione
6) utilizzare gli Unbiased Gyros anche in modo acro, (se gli unbiased gyro non dovessero funzionare c'è un problema nei punti precedenti )

potrebbe darsi anche che serva un punto 7

7) Utilizzare sensori Wii magari con WMP mezzo rotto e palle blu ed arancioni di Decathlon sui bracci

Con gli accorgimenti su indicati ed in più con una routine di controllo dello Stable Mode che tiene conto della posizione del baricentro, volo esclusivamente in modo stabile e senza necessità di fare calibrazioni (calibro gli accelerometri una tantum e i giro solo in presenza di fortissimi sbalzi termici tipo 20 gradi in casa e 0 fuori più per scrupolo che per necessità.


ciao

[kamikazeta]

Se utilizzo la 1.7 con GuI 1.7 la calibrazione del magnetometro come viene gestita? sulla GUI rispetto alla versione 8 non è presente che si fa?