MultiWii Quad! Alternativa ad Aeroquad/Baronpilot con sensori wii

[asimmetrico]

Per il WMP ti consiglio (dato che quello che hai elencato non si capisce bene se è originale) a questo punto di spendere 5€ in più prendendo quello originale nintendo .

Dove lo trovo a 5 euro in più?

Al

[ciskje]

ma quello è originale?!?!? intento l arduino?! è uguale al proi v3?!?!
eventualemnte prenderei dallo stesso negoziante anche la i/o shield

Quell I/O shield non va bene, il prezzo del nano è incredibile.
Occhio che se prendete l'arduino pro vi serve il "programmatore" FTDI se prendete il nano invece c'e' già l'USB (e non vi serve il programmatore).

[Elmessicano]

Dove lo trovo a 5 euro in più?

Al

Ciao

nei negozi dove vendono anche console e accessori nintendo....l'originale costa 19,90 o 19,99....non ricordo bene.

Ciao

Diego

[arnaldo]

Quell I/O shield non va bene, il prezzo del nano è incredibile.
Occhio che se prendete l'arduino pro vi serve il "programmatore" FTDI se prendete il nano invece c'e' già l'USB (e non vi serve il programmatore).

bene...allora lo prendero da li il nano...lo shield invece...mmmm

[albio]

Verifica che cosa legge dal configurator mentre i motori sono in moto...se i valori saltellano tanto il problema è lì. Come ti dicevo pare che l'adxl345 non sia molto amichevole con le vibrazioni, anche se bisogna sempre settare i filtri e il range di sensibilità (ma sembra che nessuno se ne interessi, quando mi pare la prima cosa da provare...boh :-/)



Funzionare veramente bene pare a nessuno, è ancora troppo acerba e finchè ci sarà un solo pid non si andrà da nessuna parte.... funzionicchia se sei quasi fermo ma non è affidabile. Io non mi aspetto che cambi granchè in futuro, è per questo che non mi semba abbia molto senso sbattersi per implementare nuovi sensori su arduino/multiwii...meglio pensare ad altro se si vuole modalità stabile e funzionalità avanzate.



Ci sono alcune differenze e molti lamentano comportamenti diversi e non sempre migliori tra 1.6 e versioni precedenti. Io le ho provate un po' tutte e l'ultima 1.6 è quella con cui sono riuscito ad alzare di più il P e ad avere il quad più stabile (P 9,5 I 0.20 D -30) ma alla fine sfrutto solo i vari bugfix e uso sempre le mie versioni semplificate (basate sulla 1.2) che non mi danno mai problemi...

Oh, luminare italico del Uimoscio, illumina pure le nostre menti offuscate!!!

Io mi sono letto paginate di codice, ma non ne capisco una mazza.
Che ne dici di dirci come settare per bene i filtri?

Io uso il NK, che per via di vibrazioni è peggio della principessa sul pisello...

[ciskje]

Che ne dici di dirci come settare per bene i filtri?

Purtroppo è proprio come li setta il multiwii che non va tanto bene (ad esempio l'ITG3200 viene settato con un filtro a 10hz troppo stringente).

Per l'NK non c'e' nulla da poter cambiare per quanto riguarda i filtri hardware purtroppo.

[jhoexp]

Oh, luminare italico del Uimoscio, illumina pure le nostre menti offuscate!!!

Io mi sono letto paginate di codice, ma non ne capisco una mazza.
Che ne dici di dirci come settare per bene i filtri?

Gli ultimi giroscopi invensense, i nuovi accellerometri bosh ecc... hanno la possibilità di settare alcuni parametri di funzionamento quali il range di sensibilità (2, 3, 5g ecc...) alcuni filtri di taglio in frequenza, ecc...
Tu hai mai sentito qualcuno chiedere come settare sti filtri e quali siano i parametri ideali per l'utilizzo sui nostri multirotori? Niente, pare non freghi a nessuno.
Un minimo di influenza ce l'avranno, no? magari fanno la differenza...

E' più o meno come comprarsi un Ferrari 430 e non sapere come si cambiano le marce. Sicuramente va forte anche in prima, ma magari è meglio capire cosa fanno ste strane leve dietro al volante, no?

Io uso il NK, che per via di vibrazioni è peggio della principessa sul pisello...

Guarda io non so più cosa pensare..... un po' tutti credevamo che ci fossero problemi con lo stable mode col NK perchè appena si accendevano i motori i valori degli acc andavano per i fatti loro. Si pensava quindi che fosse colpa della sua eccessiva sensibilità alle vibrazioni, e tutti a dire male del povero nunchuck.

Poi tempo fa Ziojos ha fatto un quad col NK, usando aeroquad modificato da lui, che ha uno stable mode quasi perfetto (ho postato il video tempo fa, appena lo ritrovo lo riposto). Bam, tutti morti. Lui non posta il codice e nessuno commenta... Però è evidente che qualcosa non torna...vuoi vedere che è solo questione di codice?

Poco tempo fa su rcgroups hanno fatto un po' di test e cosa è venuto fuori? Che l' NK non è poi così male, anzi è persino meglio dell'adxl345 con i filtri di default!! (cioè col cambio piantato in prima marcia)

E vabbè, io mi limito a raccogliere informazioni e a far volare i miei mezzi, quando posso contribuisco per quel poco di tempo e conoscenze che ho, ma se continuiamo così ci si metterà altri 2 anni a scoprire come si apre lo sportellino del carburante....

[ToshiroTamigi]

Guarda io non so più cosa pensare..... un po' tutti credevamo che ci fossero problemi con lo stable mode col NK perchè appena si accendevano i motori i valori degli acc andavano per i fatti loro. Si pensava quindi che fosse colpa della sua eccessiva sensibilità alle vibrazioni, e tutti a dire male del povero nunchuck.

Poi tempo fa Ziojos ha fatto un quad col NK, usando aeroquad modificato da lui, che ha uno stable mode quasi perfetto (ho postato il video tempo fa, appena lo ritrovo lo riposto). Bam, tutti morti. Lui non posta il codice e nessuno commenta... Però è evidente che qualcosa non torna...vuoi vedere che è solo questione di codice?

Poco tempo fa su rcgroups hanno fatto un po' di test e cosa è venuto fuori? Che l' NK non è poi così male, anzi è persino meglio dell'adxl345 con i filtri di default!! (cioè col cambio piantato in prima marcia)

E vabbè, io mi limito a raccogliere informazioni e a far volare i miei mezzi, quando posso contribuisco per quel poco di tempo e conoscenze che ho, ma se continuiamo così ci si metterà altri 2 anni a scoprire come si apre lo sportellino del carburante....

Ho visto proprio stasera che sul bma020 l'inizializzazione va a sovrascrivere dei registri per cui è specificato tipo 3 o 4 volte nel manuale di NON SOVRASCRIVERLI, pena la restituzione di valori dell'accelerazione non precisi.

[Paolo_56]

Gli ultimi giroscopi invensense, i nuovi accellerometri bosh ecc... hanno la possibilità di settare alcuni parametri di funzionamento quali il range di sensibilità (2, 3, 5g ecc...) alcuni filtri di taglio in frequenza, ecc...
Tu hai mai sentito qualcuno chiedere come settare sti filtri e quali siano i parametri ideali per l'utilizzo sui nostri multirotori? Niente, pare non freghi a nessuno.
Un minimo di influenza ce l'avranno, no? magari fanno la differenza...
[...]

Giusto!

Un'altra cosa che, secondo me (forse se ne è già parlato, da qualche parte), fa la differenza è il RITARDO con cui il gruppo Brushless ESC + motore brushless + elica risponde alle richieste di variazioni di velocità, sia a scendere sia a salire.

Questo ritardo, dipendente dal BESC, dal motore e dall'elica utilizzata, potrebbe non essere affatto piccolo, ed essere quindi DETERMINANTE per raggiungere un buon livello di stabilità (ossia, senza oscillazioni visibili).

Nel SW, ad es. la v. 1.6, c'è un punto in cui se ne tiene conto, ossia c'è un qualche parametro specifico da settare?


Ciao,
Paolo

[jhoexp]

Un'altra cosa che, secondo me (forse se ne è già parlato, da qualche parte), fa la differenza è il RITARDO con cui il gruppo Brushless ESC + motore brushless + elica risponde alle richieste di variazioni di velocità, sia a scendere sia a salire.

Questo ritardo, dipendente dal BESC, dal motore e dall'elica utilizzata, potrebbe non essere affatto piccolo, ed essere quindi DETERMINANTE per raggiungere un buon livello di stabilità (ossia, senza oscillazioni visibili).

Il problema è già stato affontato e se ne è parlato diffusamente: ovviamente il ritardo totale del sistema esc + elica + motore è causato dal ritardo dell'esc e dal momento d'inerzia del complesso elica/motore.
Cerchiamo sempre di minimizzare il secondo scegliendo opportunamente elica e motore, ma dobbiamo sempre cercare di ottimizzare anche spinta ed efficienza, quindi sarà per forza sempre una soluzione di compromesso.
Oltre una certa "taglia" ovviamente le cose si mettono male con momenti d'inerzia e pesi eccessivi ed è per questo che questi mezzi a passo fisso non scalano molto bene.

Per quanto riguarda il ritardo dell'esc, c'è chi ha scelto i regolatori i2c anche per questo motivo, ma il problema si è rivelato trascurabile perchè col pilotaggio ad alta frequenza ed un normale esc pwm (di quelli noti, che reggono il pwm ad alta frequenza e che non hanno funzioni di smoothing o altro) si ottengono risultati assolutamente comparabili a quelli di regolatori i2c, con una frazione della spesa e soprattutto con la possibilità di usare correnti molto maggiori.

per quanto riguarda il ritardo dell'esc
Nel SW, ad es. la v. 1.6, c'è un punto in cui se ne tiene conto, ossia c'è un qualche parametro specifico da settare?

Ci sono appunto i parametri del PID da settare, che ovviamente tiene conto del ritardo e dell'inerzia di tutto il sistema.
Il ritardo degli esc cinesi tipo hobbywing/turnigy con il pilotaggio a 490 khz è minimo, la risposta è stata misurata da alcuni test su rc groups e confrontata con il ritardo di un regolatore i2c. In pratica le differenze sono trascurabili.

[Paolo_56]

[...]
Ci sono appunto i parametri del PID da settare, che ovviamente tiene conto del ritardo e dell'inerzia di tutto il sistema.
[...]

Ok, però io mi riferivo a qualcosa di più specifico, e quindi non 'nascosto' nei parametri PID. Il ritardo di cui sto parlando può essere visto come il 'ritardo di gruppo' (o qualcosa di molto simile) di un segnale generico, nei sistemi in retroazione.

[...]
Il ritardo degli esc cinesi tipo hobbywing/turnigy con il pilotaggio a 490 khz è minimo,
[...]

Il pilotaggio è, in realtà, a 490 Hz ; comunque, può darsi che occorrano diversi periodi a 490 Hz prima che la velocità inizi a variare.

Ne approfitto per segnalare che, tramite il collegamento di GND dei segnali in ingresso ai BESC, i BESC stessi portano un mare di disturbi al GND di Arduino: secondo me, conviene utilizzare degli optoisolatori (con ingresso a LED, ed uscita digitale a 5 V ed ovviamente alimentati dai 5V del BEC del BESC). In questo modo, i due GND (power e signal) sono separati, i segnali sono MOLTO più 'puliti' ed è molto più difficile che il multirotore 'impazzisca' all'improvviso, senza apparente motivo.


Ciao,
Paolo

[ToshiroTamigi]

Sto costruendo un microquad con motori brushed grande circa 10cm da motore a motore.

Ieri sera ho finito di montare il prototipo della scheda
A bordo atmega328 + mosfet per i brushed + alimentatore(con max682) per fornire i 5v a partire da una lipo. E' grande circa 18x60 mm(al momento ho montato il tutto su una scheda per prototipazione per lqfp48 presa su Electronic components - dipmicro electronics in attesa che mi arrivi il circuito stampato che ho progettato appositamente grande 30x30mm).

Come radio al momento uso un clone di HK per dsm2.

Successivamente sostituirò la radio con una coppia di moduli bluetooth, per comandarlo con un classic controller per wii con gli stick analogici, collegato ad un atmega8l (così alimento tutto a 3.3v e lavoro con una sola lipo).

Adesso non resta che aspettare che Poste decida di sbloccarmi un pacco, fermo a roma dall'11, con le lipo e le eliche così da terminarlo.

Appena possibile posto le foto con la situazione attuale ;)

[ciskje]

Ci sono appunto i parametri del PID da settare, che ovviamente tiene conto del ritardo e dell'inerzia di tutto il sistema.

Il ritardo degli esc cinesi tipo hobbywing/turnigy con il pilotaggio a 490 khz è minimo, la risposta è stata misurata da alcuni test su rc groups e confrontata con il ritardo di un regolatore i2c. In pratica le differenze sono trascurabili.

Alcune precisazioni, i PID da soli non tengono molto conto del ritardo tra comando ed uscita (circa 300ms nel caso di esc normali a 490hz e eliche 10x4.7), appena sente l'errore impone un uscita, direttamente e senza tante complicazioni.

Per sistemi con altissima inerzia è assolutamente trascurabile il ritardo tra comando ed uscita (ad esempio si accende un riscaldatore anche in 1 secondo con un relè ma ci vogliono ore prima che l'ambiente si scaldi).

Se il comando è molto lento a reagire, è necessario anticipare il comando prima di raggiungere il setpoint. Di questo nei normali PID non si tiene conto, si suppone che il ritardo comando effettiva uscita sia trascurabile.

Tutto dipende dal rapporto che c'e' tra il ritardo tra comando e uscita e l'effettiva variazione della variabile controllata.

[jhoexp]

Scusate, ovviamente intendevo 490 Hz, ma mi sembra che su queste cose ci si è fatti già troppe seghe mentali.

E' ormai assodato che i regolatori PWM vanno benissimo, costano poco, sono più facili da reperire e più affidabili. Inoltre non incasinano il bus i2c e il ritardo che hanno misurato sugli esc buoni era di circa 88ms, 137ms per quelli scrausi cinesi comunemente usati. Forse su mezzi microscopici ci sarà differenza ma per un multirotore "medio" abbiamo visto che veramente non cambia nulla. Persino i fantomatici 8bit di risoluzione alla fine bastano e avanzano.

Ok, il PID non conosce a priori il ritardo di risposta, ma tu setti i parametri proprio per "inseguire" il comportamento del sistema ed è anche in funzione del ritardo totale del mezzo che scegli i coefficienti.
Certo ci sono modi migliori per fare il controllo ma per ora è forse meglio concentrarsi su qualcosa di un minimo più avanzato, magari un controllo di quota appena decente che ci faccia decollare e atterrare autonomamente il quad in caso di problemi?

[arnaldo]

Scusate, ovviamente intendevo 490 Hz, ma mi sembra che su queste cose ci si è fatti già troppe seghe mentali.

E' ormai assodato che i regolatori PWM vanno benissimo, costano poco, sono più facili da reperire e più affidabili. Inoltre non incasinano il bus i2c e il ritardo che hanno misurato sugli esc buoni era di circa 88ms, 137ms per quelli scrausi cinesi comunemente usati. Forse su mezzi microscopici ci sarà differenza ma per un multirotore "medio" abbiamo visto che veramente non cambia nulla. Persino i fantomatici 8bit di risoluzione alla fine bastano e avanzano.

Ok, il PID non conosce a priori il ritardo di risposta, ma tu setti i parametri proprio per "inseguire" il comportamento del sistema ed è anche in funzione del ritardo totale del mezzo che scegli i coefficienti.
Certo ci sono modi migliori per fare il controllo ma per ora è forse meglio concentrarsi su qualcosa di un minimo più avanzato, magari un controllo di quota appena decente che ci faccia decollare e atterrare autonomamente il quad in caso di problemi?

Magari...il barometro l'hanno messo...o meglio scritto tra le caratteristiche...sarebbe ora che lo facessero funzionare bene...