VRBRAIN by VirtualRobotix

[emile.c]

Questo è quello che ho capito io sbattendoci la testa per un po', poi potrei sbagliarmi, ma fino ad ora ha funzionato...

La MPU6000 ha due modi per essere letta: con o senza DMP.
Senza DMP è quella che tu definisci RAW, con DMP è quella che tu chiami con angoli.
La prima non fa nessuna elaborazione del dato che viene servito così com'è "alla velocità" che imposti tramite il registro SMPLRT_DIV. L'unica manipolazione viene fatta con il filtro che imposti tramite DLPF_CFG.
Se il filtro è 0, i dati vengono resi disponibili a 8KHz (1KHz per gli acc), altrimenti acc e gyro sono resi disponibili con la seguente formula:

Sample Rate = Gyroscope Output Rate / (1 + SMPLRT_DIV)

Quindi se imposto il filtro a 0 (DLPF_CFG) e il SMPLRT_DIV a 0 avrò i gyro a 8KHz e gli acc a 1KHz.
Se invece metto il filtro ad un valore diverso da 0 i gyro saranno disponibili ad 1KHz così come gli acc.
Quindi la formula tiene conto del valore Output Rate.

Quindi se voglio i dati a 200Hz, mi basta impostare il valore SMPLRT_DIV a 4 (e questo è quello che avviene su APM)
Ogni volta che la MPU ha un dato nuovo, genera un interrupt che può (e lo è in VRBRAIN) essere collegato alla MCU per avere il dato nell'istante esatto in cui viene generato.
Prima dello scheduler usavamo questa modalità.

Caso completamente diverso è il DMP, che in pratica ti fornisce i valori in quaternion di roll pitch e yaw già ruotati e manipolati. In pratica sostituisce in toto la DCM dando più respiro alla MCU.
Questa versione io personlamente non l'ho mai testata, ma non sembra sia stata molto apprezzata da chi l'ha provata.

E.

La MPU 6000 puo' essere letta in 2 modi,
in modo raw con frequenza da 1Khz ad 8 Khz,
e in modo DMP, con gli angoli, frequenza massima 200Hz.
Ora se mi dici che è settata a 200Hz non puo' che essere letta in DMP perchè in modo raw e il filtro DLPF attivo la frequenza settabile da registri è di 1Khz, 200Hz non esiste come possibilità.
Per quanto riguarda 1000 vs 2000 g/s per il gyro è vero che viene aumentata la sensibilità ma è anchè piu' sensibile al rumore.
Inoltre andrebbe verificato anche il DLPF sull' ACC e il suo range.

[emile.c]

Guarda per un EKF pagherei.... ma non so proprio da dove si comincia, quindi ogni proposta non può che essere pienamente supportata.



Per quanto riguarda i motori che partono, verifico che non sia per caso impostato un valore di PWM iniziale che possa far muovere i motori anche se non armati.

E.

perdonami ma sono entrato nella discussione da poco, e, mea culpa non mi son letto tutto l'ambaradan di roba precendete.
lieto di sentirtelo dire... almeno non sarò il solito pazzo che grida al lupo al lupo

abbiamo fatto passi avanti, ma siamo ancora ben lontani da avere un Fw definibile STABILE.

@emile.c
Consiglio, che da come ho capito non è condiviso qua... prima di fare altre modifiche, io userei tutta quella cpu-power del arm per implementare un bel UKF o EKF.... un ca**o di kalman non sono un fisico, ma da quello che ho visto, nelle mie prove sperimentali con altre Fc che lo implementano (vedi Autoquad, vedi WKM) aiuta non poco nella stabilità generale del sistema e nella reiezione ai disturbi. ovvio, tutto il merito non è e non sarà di questo filtro, ma la sua implementazione su autoquad ha fatto fare il vero salto di qualità... (insieme alle varie compensazioni della sensoristica, ma mi pare che su questo si stia già lavorando).

[gionag]

Guarda per un EKF pagherei.... ma non so proprio da dove si comincia, quindi ogni proposta non può che essere pienamente supportata.



Per quanto riguarda i motori che partono, verifico che non sia per caso impostato un valore di PWM iniziale che possa far muovere i motori anche se non armati.

E.

comincio a darci un occhio, forse guardando come viene implementata su autoquad potremo accelerare un pò la cosa. mi pare che aq usi l'unscented...

[emile.c]

Che gira bene su ATMEL?!!?
HAHAHA...
leggetevi questo post e poi ne riparliamo:

https://groups.google.com/forum/#!to...ss/xhJAD9SEO2w

L'idea di base è che non vale la pena (almeno fnio ad ora) staccarsi completamente da APM.
I progressi ci sono e il codice va avanti, inoltre nessuno ci vieta di aggiungere funzionalità che su AVR non possono essere usate.
La politica di Tridge (fortuna che c'è lui) è implementare cose nuove mantenendo il codice di alto livello compatibile con diverse piattaforme e la cosa secondo me ha futuro.
Il lavoro svolto fino ad ora sulla VRBRAIN conta poche persone, quindi non avrebbe avuto senso staccarsi se poi non c'è una community che con costanza mantiene il codice.

Noi siamo pronti per entrare nella repository ufficiale di APM, manca solo che qualcuno mi auiti :hint :hint con un po' di lavoro sul toolchain (ARMGCC) e la configurazione via Make. Io lì non mi addentro...

E.

se ti riferisci alla pixhawk dubito seriamente che cambi qualcosa...
quella scheda, usa un sistema molto diverso, con sensori totalmente diversi dai "nostri" e dubito che possa apportare modifiche significative. o meglio, se lo farà lo farà per se stessa e non per la vrbrain in particolare

credo che il problema è che la vrbrain si voglia mantenere allineata al codice originale apm, quindi staccarsi per implementare cose sarebbe un passo verso una direzione senza via di ritorno. bisogna fare una scelta. o fare un "semplice" porting di un software 8bit su una piattaforma 32... oppure sviluppare, magari usando come punto di partenza roba già esistente, una soluzione cucita ad hoc per le potenzialità di questa scheda.
ripeto, il mio è un desiderio più che una lucida analisi tecnica, ma mi sembra sprecato tutto quel ben di dio per mandare avanti un software che gira già... a mio avviso, benissmo su atmel.

è come se avessimo un dragster e lo facessimo andare con il freno a mano (... paracadute) tirato...

ovvio, son scelte...

[QuercusPetraea]

Con il download dei log mi ritrovo nella solita (per me) situazione per cui lo scaricamento dei log, principalmente l'ultimo, si pianta senza proseguire. Questo comporta pure che la seriale resta impegnata da qualche istanza di MP e per riaverla devo fare un logoff dal PC per fargli sganciare le risorse.

Attualmente ho solo due log di questa fattispecie:
log 10, start 2398, end 3717
log 11, start 3718, end 2397

Il numero 11 sembra arrotolarsi sul 10 e si. blocca durante il download.
In più il log 10 non inizia con le solite informazioni seguite da PARM per poi arrivare alle registrazioni dei dati ma parte subito con:
Colonna Valore
1 10
2
3 ArduCopter 3.1.5
4 Free RAM 4096
5 VRBRAIN
6 IMU ecc.
7 IMU ecc.

I log li ho scaricati dopo aver aggiornato alla 3.1.5 odierna.

Prima di volare ho fatto un log erase e mi sarei aspettato che la numerazione ripartisse da 1 ma così non è, neppure su APM 3.0.1 con Arduflyer.

[danveal]

Se il filtro è 0, i dati vengono resi disponibili a 8KHz (1KHz per gli acc), altrimenti acc e gyro sono resi disponibili con la seguente formula:

Sample Rate = Gyroscope Output Rate / (1 + SMPLRT_DIV)

Quindi se imposto il filtro a 0 (DLPF_CFG) e il SMPLRT_DIV a 0 avrò i gyro a 8KHz e gli acc a 1KHz.
Se invece metto il filtro ad un valore diverso da 0 i gyro saranno disponibili ad 1KHz così come gli acc.
Quindi la formula tiene conto del valore Output Rate.

Quindi se voglio i dati a 200Hz, mi basta impostare il valore SMPLRT_DIV a 4 (e questo è quello che avviene su APM)
Ogni volta che la MPU ha un dato nuovo, genera un interrupt che può (e lo è in VRBRAIN) essere collegato alla MCU per avere il dato nell'istante esatto in cui viene generato.
Prima dello scheduler usavamo questa modalità.

E.

Si hai ragione se viene usato lo smplrt_div si puo' acquisire a frequenze inferiori.
Ma allora se è come dici, invece di fare tutto questo giro con l'enhanced sarebbe stato meglio settare il smplrt_div in modo da avere 1 Khz perchè attualmente

i dati vengono resi a 200Hz quindi solo ogni 5ms hai un nuovo dato che va a formare un buffer di 7 valori, con la versione a 100hz vai a leggere questo array (che per riempirsi di 7 valori nuovi richiede 35ms ) ogni 10ms, quindi 1volta sola mediando ottenendo una media di 7valori
Con la versione a 1000Hz vai a leggere ogni 1ms un array formato di 7 valori che varia solo ogni 5ms ( i 200hz della mpu) per 4 volte leggerai sempre lo stesso valore alla 5 avrai un nuovo valore, e alla 10ma un altro ancora.
Alla fine con la versione attuale a 200hz mpu, avrai solo 2 valori di array validi con la versione a 1000hz mentre ne avrai 1 con la 100hz.
E 2 valori contro 1 non e' che siano chissa che differenza...

Sarebbe stato molto meglio far girare la mpu ad 1Khz da registro interno e acquisire a 1000hz anche da software in questo modo hai 10 valori reali con il loop a 100Hz.
loop a 100Hz che appunto inficia un po tutto, pensato per l'8 bit.

Se si avesse un loop principale da 500hz si avrebbero 2 letture utili molto piu' vicine al realtime e non bufferizzate (in sostanza le bufferizzate sono letture vecchie) la sincronizzazione con i 400-500Hz inviati algi esc, e il comportamento di volo sarebbe nettamente migliore perche' l'assetto sarebbe determinato in modo piu' veloce avvicinandosi al reale assetto e il "comando" verso i motori del nuovo assetto da ottenere è più puntuale.
E tutto questo a parita di codice di calcolo dell'attitude

Se poi come detto da gionag si implementassero filtri come ekf, e sfruttando la potenza del processore le cose migliorerebbero ancora, sopratutto nel mantenimento della precisione a seguito di manovre e del tempo di volo trascorso, ma per come e' strutturato il codice attuale sarebbe quasi tutto da riscrivere a parte le librerie e i driver.

[gionag]

Che gira bene su ATMEL?!!?
HAHAHA...
leggetevi questo post e poi ne riparliamo:

https://groups.google.com/forum/#!to...ss/xhJAD9SEO2w

L'idea di base è che non vale la pena (almeno fnio ad ora) staccarsi completamente da APM.
I progressi ci sono e il codice va avanti, inoltre nessuno ci vieta di aggiungere funzionalità che su AVR non possono essere usate.
La politica di Tridge (fortuna che c'è lui) è implementare cose nuove mantenendo il codice di alto livello compatibile con diverse piattaforme e la cosa secondo me ha futuro.
Il lavoro svolto fino ad ora sulla VRBRAIN conta poche persone, quindi non avrebbe avuto senso staccarsi se poi non c'è una community che con costanza mantiene il codice.

Noi siamo pronti per entrare nella repository ufficiale di APM, manca solo che qualcuno mi auiti :hint :hint con un po' di lavoro sul toolchain (ARMGCC) e la configurazione via Make. Io lì non mi addentro...

E.

va bhe, almeno non si spegne per aria ... era quello il senso

[ciskje]

EKF DCM, sono discorsi affrontati un sacco di volte, in sostanza trovo che il mitico Seb. Magdwick abbia riassunto molto bene la situazione:

The Kalman filter [14] has become the accepted basis for the majority of orientation filter algorithms [4, 15, 16, 17] and commercial inertial orientation sensors; xsens [18], micro-strain [19], VectorNav [20], Intersense [21], PNI [22] and Crossbow [23] all produce systems founded on its use. The widespread use of Kalman-based solutions are a testament to their accuracy and effectiveness, however, they have a number of disadvantages. They can be complicated to implement which is reflected by the numerous solutions seen in the subject literature [3, 4, 15, 16, 17, 24, 25, 26, 27, 28, 29, 30, 31, 32]. The linear regression iterations, fundamental to the Kalman process, demand sampling rates far exceeding the subject bandwidth; for example, a sampling rate between 512 Hz [18] and 30 kHz [19] may be used for a human motion caption application. The state relationships describing rotational kinematics in three-dimensions typically require large state vectors and an extended Kalman filter implementation [4, 17, 24] to linearise the problem.
These challenges demand a large computational load for implementation of Kalman- based solutions and provide a clear motivation for alternative approaches.

Ad oggi credo uno dei maggiori esperti mondiali della ricerca scientifica per soluzioni inerziali.
In sostanza Kalman ha una regressione lineare per trovare la soluzione euleriana è quindi molto lento nel convergere (da qui l'uso dell'EKF) e richiede quindi sampling e cicli enormemente superiori di quelli che usiamo oggi (si parla di decine di khz!).
E' dispendioso sia come memoria che come processore.

Madgwick ha trovato la rappresentazione a quaternioni con l'ottimizzazione dell'uso del magnetometro (lo usa non come bussola ma come riferimento inerziale) che trovo semplicemente geniale. Converge molto rapidamente con campionamenti relativamente lenti.

L'intero algoritmo è una manciata di linee di codice, ben spiegato nel suo sito:

Open source IMU and AHRS algorithms | x-io Technologies

In sostanza si mette giro acc e magnetometro dentro la formula e con poche iterazioni si ottiene l'orientamento dello spazio (come quaternione, e da qui ai 3 angoli di eulero).

In sostanza questo:

[Bobo67]

Si hai ragione se viene usato lo smplrt_div si puo' acquisire a frequenze inferiori.
Ma allora se è come dici, invece di fare tutto questo giro con l'enhanced sarebbe stato meglio settare il smplrt_div in modo da avere 1 Khz perchè attualmente

i dati vengono resi a 200Hz quindi solo ogni 5ms hai un nuovo dato che va a formare un buffer di 7 valori, con la versione a 100hz vai a leggere questo array (che per riempirsi di 7 valori nuovi richiede 35ms ) ogni 10ms, quindi 1volta sola mediando ottenendo una media di 7valori
Con la versione a 1000Hz vai a leggere ogni 1ms un array formato di 7 valori che varia solo ogni 5ms ( i 200hz della mpu) per 4 volte leggerai sempre lo stesso valore alla 5 avrai un nuovo valore, e alla 10ma un altro ancora.
Alla fine con la versione attuale a 200hz mpu, avrai solo 2 valori di array validi con la versione a 1000hz mentre ne avrai 1 con la 100hz.
E 2 valori contro 1 non e' che siano chissa che differenza...

Sarebbe stato molto meglio far girare la mpu ad 1Khz da registro interno e acquisire a 1000hz anche da software in questo modo hai 10 valori reali con il loop a 100Hz.
loop a 100Hz che appunto inficia un po tutto, pensato per l'8 bit.

Se si avesse un loop principale da 500hz si avrebbero 2 letture utili molto piu' vicine al realtime e non bufferizzate (in sostanza le bufferizzate sono letture vecchie) la sincronizzazione con i 400-500Hz inviati algi esc, e il comportamento di volo sarebbe nettamente migliore perche' l'assetto sarebbe determinato in modo piu' veloce avvicinandosi al reale assetto e il "comando" verso i motori del nuovo assetto da ottenere è più puntuale.
E tutto questo a parita di codice di calcolo dell'attitude

Se poi come detto da gionag si implementassero filtri come ekf, e sfruttando la potenza del processore le cose migliorerebbero ancora, sopratutto nel mantenimento della precisione a seguito di manovre e del tempo di volo trascorso, ma per come e' strutturato il codice attuale sarebbe quasi tutto da riscrivere a parte le librerie e i driver.

Ma perchè Danilo non ti metti nel team ed inizi a fare qualcosa di serio con noi?
Le idee le hai, le doti pure... cosa manca?

[Bobo67]

@Francesco: i quaternioni sono stati già implementati da circa un anno, ma poi non sono stati fatti test approfonditi sulla cosa, credo d'esser stato uno dei pochi a provare il codice in volo, e per com'era fatto non ho visto gran risultati.
PS: il gimbalino mi pare ok, è della board annessa che si sa ben poco...

Tridge sta "rilassando il collo all'APM" a quanto pare, modifiche allo scheduler, LOL:

https://github.com/diydrones/ardupil...c774743d2d00de

[ciskje]

@Francesco: i quaternioni sono stati già implementati da circa un anno

I quaternioni sono solo una comodità ma il vero trucco è l'algoritmo con l'aiuto inerziale del magnetometro (almeno questo ho capito dalla lunga e pallosissima pubblicazione universitaria).

Non ho ben capito la storia della media, in sostanza si ha un nuovo dato (che sia anche una media degli ultimi 10) ogni 1khz ?

[danveal]

Ma perchè Danilo non ti metti nel team ed inizi a fare qualcosa di serio con noi?
Le idee le hai, le doti pure... cosa manca?

Il fatto è che sono un "attimo" impegnato con phoenixpilot e la stm32F3 discoveryboard, siamo vicini ad ottenere gpshold e altitude hold.
Una volta ottenuti posso pensare di passare alla vrbrain, o collaborando sul codice attuale oppure se soddisfatto dei risultati cercando di fare il porting del codice taulabs sulla vrbrain cosa che in parte è gia stata fatta ma poi lasciata morire con codice di 6-7mesi fa, che non era ai livelli attuali.
Devo dire che pero' lavorare sul codice apm/vrbrain è molto piu' semplice rispetto a lavorare sul codice taulabs.
Per la cronaca sul taulabs per l'INSoutdor cioe' il codice della navigzione sono implementati ekf e mi pare anche premerlani /magdwick
Vedremo dai, in un modo o nell'altro convergerò sulla vrbrain nel frattempo vi osservo con interesse.

Già che ci sono volevo fare i complimenti a Roberto e VirtualRobotix tutta per le iniziative a cui stanno collaborando per divulgare il "mondo dei droni" anche nelle scuole, iniziative come questa Quadricottero.com: Robotica aerea e droni all’I.I.S. Majorana di Avezzano.
Secondo me in Italia abbiamo tutte le competenze e l'inventiva per fare bene, forse manca una visione comune, un unione delle forze che all'estero è più presente, noi italiani tendiamo ad essere più individualisti a parte alcune eccezioni, come quella di Roberto, se qualche anno fa non avesse preso questa strada ora tante cose non ci sarebbero la strada ormai e' tracciata quindi non puo' che procedere al meglio

[REfuso]

olà..
ieri sera ho caricato sull' andreX il fw 3.1.5, quello "liscio", l' enhanced pensavo di caricarlo sul muletto, fatto le varie calibr. radio\accel\baro e importato i param. salvati dalla V. 3.1-dev.
Visto che il settaggio accurato della bestia è relativamente "delicato", considerando che uso motori da 360kw e eliche da 17 i param. di default sono vicini al limite e per avere delle risposte pulite dal mezzo si deve lavorare di tuning con le mani di una fata.. mi domandavo: ci possono essere dei problemi con il caricamento dei param. dal fw 3.1-dev.. o posso stare tranquillo?
Nel pome se riesco a trovare un momento libero lo vado a provare...

[emile.c]

Nessuna incompatibilità accertata, quindi puoi caricare il FW senza perdere I dati precedentemente salvati.
Se devi caricarli da file fai un doppio check esportando il file appena caricato e facendo un a comparazione.
E.

olà..
ieri sera ho caricato sull' andreX il fw 3.1.5, quello "liscio", l' enhanced pensavo di caricarlo sul muletto, fatto le varie calibr. radio\accel\baro e importato i param. salvati dalla V. 3.1-dev.
Visto che il settaggio accurato della bestia è relativamente "delicato", considerando che uso motori da 360kw e eliche da 17 i param. di default sono vicini al limite e per avere delle risposte pulite dal mezzo si deve lavorare di tuning con le mani di una fata.. mi domandavo: ci possono essere dei problemi con il caricamento dei param. dal fw 3.1-dev.. o posso stare tranquillo?
Nel pome se riesco a trovare un momento libero lo vado a provare...

[REfuso]

ottimo, grazie Emile