MultiWii Quad! Alternativa ad Aeroquad/Baronpilot con sensori wii

[danveal]

La modalita' stabile puo' essere fatta anche senza accelerometri, se i gyroscopi sono di buona qualita', se hanno pochissima deriva, se il loop e' molto veloce in modo che il tempo di calcolo influenzi poco l' integrazione, lo stable mode funziona lo stesso. Basta decollare con il quad in piano.

Se l'acro mode e' fatto bene quando si lasciano gli stick il quad sta nell'angolo in cui si trova, quindi se si lasciano gli stick a quad fermo egli stara' fermo e grazie al calcolo dell'integrale correggerà eventuali variazioni d'angolo, esattamente come nello stable mode.
Quando invece si e' lontani / fpv, se il quad si sta muovendo e siamo in stable e portiamo gli stick al centro, il quad si portera' si orrizzontale ma manterrà la velocita' di spostamento precedente quindi continuera' a spostarsi, per farlo fermare sara' necessario un contromovimento di stick esattamente come nella modalita' acro.
L'unica differenza e' che nella stable siamo sicuri che se portiamo lo stick al centro il quad avra' angolo zero mentre nell'acro non possiamo sapere a che angolo si trova, sapremo solo che con lo stick al centro il quad manterra' l'angolo di quel momento.
Tuttavia io con armquad ho sperimentato configurazioni acro che fanno in modo che con lo stick al centro il quad tende a portarsi nelle vicinanze dell'angolo zero, in definitiva non e' che ci sia molta differenza.
Il vantaggio e' togliersi dai piedi l'acc con tutti i problemi di drift / imprevisti (causati dalle vibrazioni o picchi di vibrazioni) e trimming che comporta, infatti io con la acro non devo mai trimmare nulla ( e ho volato anche con eliche sbilanciate, bracci storti etc) e non ho mai avuto 1 solo episodio di comportamento strano.

L'acc e' piu' per il volo autonomo, il volo a vista puo farne anche a meno.
Ricordo poi che per avere il gps hold bisogna avere anche un magnetometro e un barometro, dubito che tutte queste cose siano alla portata di un solo micro come l'atmega328 o similari, sia per lo spazio di memoria sia per la velocita' complessiva, per questi progetti "arduinici" ci vorra' per forza una sorta di naviboard.

[elettro]

La modalita' stabile puo' essere fatta anche senza accelerometri, se i gyroscopi sono di buona qualita', se hanno pochissima deriva, se il loop e' molto veloce in modo che il tempo di calcolo influenzi poco l' integrazione, lo stable mode funziona lo stesso. Basta decollare con il quad in piano.

Umm no, a lungo adare l'errore si accumula, magari dopo 10 ore di volo, ma comunque avresti un'imprecisione che aumenta. Con gli accelerometri invece, finchè la gravità resta 1G non hai problemi di crescita dell'errore, o almeno verranno automaticamente azzerati grazie all'accelerometro. C'è da precisare che durante accelerazioni & decelerazioni bisogna prendere i valori dell'accelerometro con le pinze

L'acc e' piu' per il volo autonomo, il volo a vista puo farne anche a meno.

concordo, finchè rimane a vista potresti pure volarlo senza nulla (se hai ottimi pollici)

Ricordo poi che per avere il gps hold bisogna avere anche un magnetometro e un barometro, dubito che tutte queste cose siano alla portata di un solo micro come l'atmega328 o similari, sia per lo spazio di memoria sia per la velocita' complessiva, per questi progetti "arduinici" ci vorra' per forza una sorta di naviboard.

Tranne per il gps (che non sono sicuro) il resto è fattibile e già implementabile con l'atmega328. Per il GPS in aeroquad usano l'atmega1280 che ha più memoria, ma non so se è indispensabile..
Al massimo usi 2 arduino, così hai pure il parallelismo
Uno gestisce i segnali (accelerometro, GPS, magnetometro, ricevente, giroscopi, barometro) l'altro prende i dati elaborati, esegue i vari filtri e comanda i motori.

[danveal]

Umm no, a lungo adare l'errore si accumula, magari dopo 10 ore di volo, ma comunque avresti un'imprecisione che aumenta. Con gli accelerometri invece, finchè la gravità resta 1G non hai problemi di crescita dell'errore, o almeno verranno automaticamente azzerati grazie all'accelerometro. C'è da precisare che durante accelerazioni & decelerazioni bisogna prendere i valori dell'accelerometro con le pinze


concordo, finchè rimane a vista potresti pure volarlo senza nulla (se hai ottimi pollici)


Tranne per il gps (che non sono sicuro) il resto è fattibile e già implementabile con l'atmega328. Per il GPS in aeroquad usano l'atmega1280 che ha più memoria, ma non so se è indispensabile..
Al massimo usi 2 arduino, così hai pure il parallelismo
Uno gestisce i segnali (accelerometro, GPS, magnetometro, ricevente, giroscopi, barometro) l'altro prende i dati elaborati, esegue i vari filtri e comanda i motori.

Per 20-30 minuti si puo avere la modalita' stabile anche senza acc.
Non lo dico tanto per dire ma per esperienza reale, uavp che si basa su un pic ma ha ottimi gyro quali gli adxrs610 puo' volare in stable anche senza acc.
Armquad con solo gyro l' itg3200 puo' volare in stable senza acc.
Certo con il tempo come dici tu l'errore si accumula ma visto che le lipo non consentono autonomie elevate il problema non esiste, una volta che atterri si riparte da zero.
Per discorso multiwii, con il nunchuk ha gia 6ms di loop se aggiungi il resto senza l'appoggio di scheda esterna non oso pensare a quanto si arrivi.
Penso che intorno ai 10ms si inizi ad avere un quad parecchio instabile e comunque lento nel reagire.

[ciskje]

Umm no, a lungo adare l'errore si accumula, magari dopo 10 ore di volo

A parte l'accumulo dell'errore, basta partire da una leggera pendenza per rendere inutili i gyro (dato che non sanno dov'e' il vettore verticale).
Confermo quel che hai espresso in modo perfetto.
Chiunque abbia un minimo di esperienza sa benissimo che headtracker o gyro HH che appunto "simulano" i gradi assoluti (anche quelli costosi), perdono il riferimento dopo pochi movimenti (non è solo una questione di tempo).

Per quanto riguarda l'arduino in effetti 2k non sono molti per i calcoli GPS, ma un teensy o uno qualunque delle decine di cloni con ATMega con un po' di RAM bastano e avanzano.

[elettro]

Certo con il tempo come dici tu l'errore si accumula ma visto che le lipo non consentono autonomie elevate il problema non esiste, una volta che atterri si riparte da zero.

Se avessi provato a visualizzare un grafico 3d con l'angolo simulato, vedresti che è tutto un trucco... l'errore è notabile fin dalle prime 2 o 3 rotazioni. Un trucco molto usato è di fare la media tra le ultime letture per sapere lo zero del gyro, questo oltre che evitare il drift fa in modo che dopo qualche attimo il giroscopio inizia a pensare di essere dritto di nuovo, anche se effettivamente non lo è (algoritmo HH degli hk401b, molto consigliati tra gli elicotteristi..)

Per discorso multiwii, con il nunchuk ha gia 6ms di loop se aggiungi il resto senza l'appoggio di scheda esterna non oso pensare a quanto si arrivi.

Se hai strutturato bene il codice non stai ad aspettare 6ms che arrivi il messaggio del nunchuk, vai avanti con le sole letture giro, al limite assumendo per buona l'ultima lettura accelerometro.
Forse intendi che in 6ms fa tutto il loop... però considera che usa un kallmann filter, molto dispendioso in termini di risorse rispetto alla DCM, che è nata apposta per unire le rilevazioni di tanti sensori usando meno risorse (e si son ritrovati con un algoritmo che a quanto pare è migliore)

ah proposito, per il fatto che dicevo che sarebbe bene dividere il nunckuc dal motion plus, molti di voi si chiederanno(non credo ma va bè), ma come fai a collegare 2 dispositivi i2c se l'at-mega ha solo una coppia di pin i2c? così: Arduino Blog » Blog Archive » SoftI2CMaster Library Lets You Add I2C To Any Arduino Pin

[danveal]

Se avessi provato a visualizzare un grafico 3d con l'angolo simulato, vedresti che è tutto un trucco... l'errore è notabile fin dalle prime 2 o 3 rotazioni. Un trucco molto usato è di fare la media tra le ultime letture per sapere lo zero del gyro, questo oltre che evitare il drift fa in modo che dopo qualche attimo il giroscopio inizia a pensare di essere dritto di nuovo, anche se effettivamente non lo è (algoritmo HH degli hk401b, molto consigliati tra gli elicotteristi..)


Se hai strutturato bene il codice non stai ad aspettare 6ms che arrivi il messaggio del nunchuk, vai avanti con le sole letture giro, al limite assumendo per buona l'ultima lettura accelerometro.
Forse intendi che in 6ms fa tutto il loop... però considera che usa un kallmann filter, molto dispendioso in termini di risorse rispetto alla DCM, che è nata apposta per unire le rilevazioni di tanti sensori usando meno risorse (e si son ritrovati con un algoritmo che a quanto pare è migliore)

ah proposito, per il fatto che dicevo che sarebbe bene dividere il nunckuc dal motion plus, molti di voi si chiederanno(non credo ma va bè), ma come fai a collegare 2 dispositivi i2c se l'at-mega ha solo una coppia di pin i2c? così: Arduino Blog » Blog Archive » SoftI2CMaster Library Lets You Add I2C To Any Arduino Pin

Io non uso nessun trucco, semplicemente calcolo l'angolo integrando i valori del gyroscopio, e uso detto angolo per lo stable mode, fine.
Certo che se vengono usati gyro poco performanti, che derivano, che sono usati con poco gain, resi ciechi ai piccoli movimenti perche altrimenti oscilla tutto, e' chiaro che l'angolo sara' impreciso dopo pochissimo.
La chiave e' basarsi sui gyroscopi di qualita', avere un buon algoritmo e usare l'acc solo come riferimento sporadico per "ricalibrare" il tutto, in sostanza l'acc deve avere poco peso.
Quindi in primis ci vuole un codice che gira veloce per integrare i valori dei gyro con il minor errore di integrazione possibile, piu' veloce e' il loop e minore sara' l'errore che si accumula nel tempo, i gyro devono essere adeguati e validi, non devono derivare dopo poco come i murata dentro gli HK, devono essere compensati in temperatura, devono essere resi sensibili anche ai piccoli movimenti, devono essere filtrati.
Tutti i migliori progetti usano l'acc in questo modo.
Shrediquette usa una piccola componente dell' acc, solo l' 1% che somma ai gyro
UAVX confronta l'angolo calcolato dai gyro con quello dell' acc e soltanto quando vi e' un certo delta di differenza inserisce una piccola parte dell'acc per correggere l'angolo derivato dai gyro.
Mikrokopter usa anche lui una piccola parte dell'acc

Il kalman del multiwii e' una versione semplificata, i 6 ms o i 3ms di loop con il solo wiimotion derivano dalle pause e dalle medie mostruose che usa.
La DCM sui quadricotteri e' piu imprecisa del kalman e a dirla tutta, la mia opinione e' che sui quadricotteri non funzionera mai bene, discorso diverso se impiegata sugli aerei.

Buon divertimento coi vostri progetti e le vostre idee acc centriche e DCM

[redfox74]

Per 20-30 minuti si puo avere la modalita' stabile anche senza acc.
Non lo dico tanto per dire ma per esperienza reale, uavp che si basa su un pic ma ha ottimi gyro quali gli adxrs610 puo' volare in stable anche senza acc.
Armquad con solo gyro l' itg3200 puo' volare in stable senza acc.
Certo con il tempo come dici tu l'errore si accumula ma visto che le lipo non consentono autonomie elevate il problema non esiste, una volta che atterri si riparte da zero.
Per discorso multiwii, con il nunchuk ha gia 6ms di loop se aggiungi il resto senza l'appoggio di scheda esterna non oso pensare a quanto si arrivi.
Penso che intorno ai 10ms si inizi ad avere un quad parecchio instabile e comunque lento nel reagire.

Mi dispiace contraddirti ma è praticamente impossiible usando giroscopi mems mantenere un corretto angolo d'assetto partendo da zero , non diciamo cose non vere alla gente che ci legge .... le derive dei giroscopi mems sono talmente alte che basta pochissimo per andare ad inficiarne le letture ... per far quel che dici tu dovresti usare gyro laser che hanno un livello 10 volte inferiore di deriva ... ma cmq quelli che funzionerebbero ancora meglio sono quelli meccanici che si usano ancor oggi su aerei da caccia , ne ho visto uno di un f104 .. una figata davvero.
I mems in particolare se non vengono caratterizzati a livello termico già dopo 10 secondi iniziano a derivare .. sono state fatte diverse tesi e simulazioni in merito a questa cosa ... L'unico modo serio per avere uno stable mode affidabile è affiancare accelerometri e magnetometro che ti danno dati con valenza assoluta e non relativa , questo ti consente già a velocità di integrazione piuttosto basse di avere ottimi risultati ...
con gli ultimi sviluppi fatti su Multipilot e Arducopter usando DCM e un algoritmo di stabilizzazione a due livelli quindi non usa solo gli accelerometri per calcolare l'angolo assoluto di assetto , ma usa anche i giroscopi per integrare eventuali variazioni in tempo reale dovute ad esempio a folate di vento improvvise , senza questi accorgimenti lo stable mode sarebbe sempre in ritardo ad intervenire ... lo stick a questo punto informa l'olgoritmo di stabilizzazione quale deve essere l'angolo da mantenere durante ul volo ... questa modalità quindi consente anche di evitare la perdita di controllo in modo stabile durante le translazioni .. passare da un controllo stabile ad un controllo acrobatico in modo automatico potrebbe essere un grosso problema per chi non riesce ancora a governare l'assetto di un quad a distanza .... potrebbe capovolgersi e un neofita magari non avrebbe prontezza di riflessi per uscire dal problema .
Un saluto
Roberto

[redfox74]

Umm no, a lungo adare l'errore si accumula, magari dopo 10 ore di volo, ma comunque avresti un'imprecisione che aumenta. Con gli accelerometri invece, finchè la gravità resta 1G non hai problemi di crescita dell'errore, o almeno verranno automaticamente azzerati grazie all'accelerometro. C'è da precisare che durante accelerazioni & decelerazioni bisogna prendere i valori dell'accelerometro con le pinze


concordo, finchè rimane a vista potresti pure volarlo senza nulla (se hai ottimi pollici)


Tranne per il gps (che non sono sicuro) il resto è fattibile e già implementabile con l'atmega328. Per il GPS in aeroquad usano l'atmega1280 che ha più memoria, ma non so se è indispensabile..
Al massimo usi 2 arduino, così hai pure il parallelismo
Uno gestisce i segnali (accelerometro, GPS, magnetometro, ricevente, giroscopi, barometro) l'altro prende i dati elaborati, esegue i vari filtri e comanda i motori.

Sullla Multipilot uso un 644P 64 Kbyte flash e 4 kbyte ram e 20 mhz di clock contro i 16 della versione standard di arduino. Attualmente con il firmware Hexafox e Multisensor , usando due di questi micro ho già tutto a disposizione ... Acc , Gyroscopi , Magnetometro , GPS , sonar , sensore ir anti collisione. Tutto opensource e disponibile sul repository ...
Nelle validazioni attualmente fatte sul codice in volo ho già testato e tutto funziona :

• volo acro.
• volo stabile .
• uso del magnetometro per tenere una direzione voluta del velivolo ... Heading hold per intenderci o comunque conoscienza della prua .. e compensazione in base all'assetto del velivolo.
• GPS il software è pronto e già testato ... ancora in fase pre alfa ma già inizia a funzionare .
• Il sonar ha tutto implementato a livello di librerie di gestione ed un timido accenno di implementazione per l'altitude hold a bassa quota sotto i 6 metri.
• i sensori anti collisione già sono disponibili come librerie fino a 1.5 metri .

Il codice è già tutto scritto .. hexafox v2 e multisensor ci sono schemi disponibili ed eventualmente schede Multipilot - Multisensor già pronte all'uso ..
lnmultipilot10 - Project Hosting on Google Code

fare il porting su altre piattaforme hardware non è un problema ...
sto' lavorando anche su di una versione di firmwrare che sarà la QuadFox v3 che cercherà di utilizzare anche magnetometro e gps su di un'unica scheda.
Qui sto' cercando di fare anche delle prove sull'uscita PWM direttamente dal micro senza usare il bus i2c per il controllo dei motori ... ma non è una cosa prioritaria ... anche perchè ho visto che anche i cugini di arducopter stanno lavorando allo sviluppo di un controller brushles i2c visti i limiti di affidabilità e precisione che hanno trovato sugli ESC standard
Un saluto
Roberto

[danveal]

Mi dispiace contraddirti ma è praticamente impossiible usando giroscopi mems mantenere un corretto angolo d'assetto partendo da zero , non diciamo cose non vere alla gente che ci legge .... le derive dei giroscopi mems sono talmente alte che basta pochissimo per andare ad inficiarne le letture ... per far quel che dici tu dovresti usare gyro laser che hanno un livello 10 volte inferiore di deriva ... ma cmq quelli che funzionerebbero ancora meglio sono quelli meccanici che si usano ancor oggi su aerei da caccia , ne ho visto uno di un f104 .. una figata davvero.
I mems in particolare se non vengono caratterizzati a livello termico già dopo 10 secondi iniziano a derivare .. sono state fatte diverse tesi e simulazioni in merito a questa cosa ... L'unico modo serio per avere uno stable mode affidabile è affiancare accelerometri e magnetometro che ti danno dati con valenza assoluta e non relativa , questo ti consente già a velocità di integrazione piuttosto basse di avere ottimi risultati ...
con gli ultimi sviluppi fatti su Multipilot e Arducopter usando DCM e un algoritmo di stabilizzazione a due livelli quindi non usa solo gli accelerometri per calcolare l'angolo assoluto di assetto , ma usa anche i giroscopi per integrare eventuali variazioni in tempo reale dovute ad esempio a folate di vento improvvise , senza questi accorgimenti lo stable mode sarebbe sempre in ritardo ad intervenire ... lo stick a questo punto informa l'olgoritmo di stabilizzazione quale deve essere l'angolo da mantenere durante ul volo ... questa modalità quindi consente anche di evitare la perdita di controllo in modo stabile durante le translazioni .. passare da un controllo stabile ad un controllo acrobatico in modo automatico potrebbe essere un grosso problema per chi non riesce ancora a governare l'assetto di un quad a distanza .... potrebbe capovolgersi e un neofita magari non avrebbe prontezza di riflessi per uscire dal problema .
Un saluto
Roberto

Roberto i forum sono fatti per discutere e' normale avere diversi punti di vista.
Io semplicemente dico che e' possibile volare in stable senza acc, ovviamente non sara' mai come con acc ma e' possibile volarci.
Chiedi al ragazzo del TT-COPTER lui e' allergico all'acc e fa tutto senza.
Leggi cosa scritto nel manuale UAVP (2007) i tedeschi sono sempre stati avanti, cmq. se ci fosse tutto quel drift che dici allora anche io sull'armquad dovrei averlo quando non uso l'acc e invece posso lasciare le mani dagli stick e l'angolo si mantiene per un tempo discreto. Forse dipende dall'algoritmo implementato.

Integral flight mode without ACC-sensor
You can fly in integral mode without an ACC sensor. However, since the “zero” setting is not resetted by the
sensor, it will “drift away”. In this case, you will need to apply stick in that axis just to hold the UAVP level. To reset, just land, switch off the motors, and start again.
Notice:
Make sure to start from a horizontal place!
Registers 24 and 25 in this mode are used as trim registers. If your UAVP always drifts away in the same
direction, you can trim it with these parameters. Try with steps of 8.
As for the flight controller-integral-parameters – the above mentioned rules apply!

Edit: ho letto anche la parte dove dici dei controller i2c, l'esperienza MK mi diche che il bus i2c e' il vero punto debole, inoltre con alte correnti per le configurazioni pensanti il bus e' sempre piu disturbato fino a portare a possibili blocchi.
Al contrario l'esperienza PWM mi dice che e' molto molto affidabile, ma come detto prima sono solo opinioni, niente di scientifico

[biv2533]

Stiamo parlando di MultiWii, rimanimo in tema grazie ?!?

[leonking]

provata oggi la 1.3..... ottima come le altre.....

ho sempre lo YAW lento...... che faccio?
e se diminuisco la P?
al momento è come da default 8.0

grazie.

[Elmessicano]

@leonking

potresti indicarmi dove hai trovato la 1.3?

Grazie

[biv2533]

La 1.3 e' ancora in beta test e non e' stata pubblicata ufficilamte sul sito dell'autore che la ha distribuita solo a qualche pilota.

Io stesso avevo trovato il link e lo avevo pubblicato, ma dopo aver ricevuto specifiche comunicazioni ho cancellato il messaggio.

Fatta questa e doverosa precisazione oggi sono riuscito a collaudare il tricottero con MultiWii e Wii motion, senza nunchuck.

Avevo con me il portatile per modificare o cambiare eventualmente qualche parametro, ma con quelli di default sono andato molto bene.

In un paio di occasioni, nei quali ho effettuato virate molto inclinate richiamandolo improvvisamente, non ho notato nessun tipo di problema, come invece avveniva con i normali cloni dei 401 montati sul tricotter, che avevavo un ritardo di risposta.

Direi ampiamente soddisfatto per ora, prossima step; montare il tutto su un quadri piccoletto tipo quello di Johexp


@leonking
Yaw lento su un quadricottero?
Domanda stupida e forse scontata: il senso di rotazione delle eliche e' corretto e sono montate al posto giusto?

[Elmessicano]

O.K.,Grazie,attendo l'uscita ufficiale.

[albo86]

@biv2533

non vorrei andare molto fuori topic, ma il MultiWiiV1_2_CP che sarebbe?