VRBRAIN by VirtualRobotix

[Bobo67]

... Led verde fisso! Non è che entra in terminale?

No, per due motivi, il primo è che a volte si blocca col led spento (quindi è casuale), il secondo perchè se l'interroghi su qualsiasi porta, usb o seriale, non ti risponde, bloccata forse in qualche loop.

[redfox74]

No, per due motivi, il primo è che a volte si blocca col led spento (quindi è casuale), il secondo perchè se l'interroghi su qualsiasi porta, usb o seriale, non ti risponde, bloccata forse in qualche loop.

Ciao Marco,
Le mie due schede ... sono attive da giovedì senza presentare inconvenienti di sorta .. oggi ci ho volato con quel firmware con una termocamera per fare alcuni esperimenti senza alcun tipo di problema poi magari posto un piccolo video .
In merito al problema che si presenta se lasci fallire la taratura dei giroscopi ci stiamo indagando sia io che Emile ... l'ipotesi piu' accreditata e' una funzione di delay che anziche fare un ciclo di attesa e basta fa un ciclo che richiama funzioni in multi tasking introdotta dalla rev 3.1.3 di firmware ... ora stiamo preparando una versione modificata in modo da fare la contro prova e vedere se l'inghippo sta li ... ti confermo comunque che anche a me facendo i test con la gimbal a 3 assi , visto che in fase iniziale tende a oscillare il drone con la 3 assi qualcosa di poco chiaro l'avevo visto succedere ... tant'e' che abbiamo deciso di fare una funzione che sullla VR Gimbal puo' disattivarti i motori in fase di iniziale del volo in modo da non dare fastidio alla procedura di arming dei motori.
Spero che gia' domani una versione per fare il contro test sia pronta magari ci si becca online ... un saluto e buona notte
Roberto

[Bobo67]

Freeze immediati nella versione "enhanced"

Non mi spiego come non possiate replicare come me la cosa, eccovi il video che ho appena fatto dei freeze immediati della versione "enhanced" del firmware 3.1.3-beta, precisamente ho flashato questa, board solo alimentata via usb, spero che si senta l'audio di quando Windows trova la periferica.
Non passano oltre 5 secondi ed il blocco è costante, ogni volta che tolgo e rimetto l'usb, board resettata al default.
La cosa che mi fa specie è che Emile ci stia volando con questa versione e che molti non trovino questo problema.
Il biglietto per Lourdes l'ho già comprato... guardate che roba...

[gionag]

Non mi spiego come non possiate replicare come me la cosa, eccovi il video che ho appena fatto dei freeze immediati della versione "enhanced" del firmware 3.1.3-beta, precisamente ho flashato questa, board solo alimentata via usb, spero che si senta l'audio di quando Windows trova la periferica.
Non passano oltre 5 secondi ed il blocco è costante, ogni volta che tolgo e rimetto l'usb, board resettata al default.
La cosa che mi fa specie è che Emile ci stia volando con questa versione e che molti non trovino questo problema.
Il biglietto per Lourdes l'ho già comprato... guardate che roba...

procedura replicata
nessun problema al momento, non freeza... almeno non subito come fà a te..

ma... non è che... hai una versione dei driver usb strana ?

[gionag]

procedura replicata
nessun problema al momento, non freeza... almeno non subito come fà a te..

ma... non è che... hai una versione dei driver usb strana ?

occhio... mi correggo subito... messo usb, avviata la scheda, mezzo secondo dopo il flash, led Verde / Rosso / Giallo accesi tutti insieme.. FISSI
resettata e adesso è tornata a funzionare

[redfox74]

Eccoci qua ,ho appena finito una call con Marco e abbiamo verificato un po' di cosette ... allora la prima e relativa hai freeze dei video.
Non sono inputabili solo a problematiche hardware o firmware ma ad un insieme di fattori che siamo riusciti a circoscrivere .
Prima di tutto Marco sta usando un usb host e non la porta diretta dell'usb del pc , e sta usando un usb hub 2.0
La usb della vrbrain non è sofisticata come una usb di un pc windows o linux , ma e' gestita da un semplice codice cdc per supportare la seriale su usb.
Con in mezzo un hub specialmente se 2.0 sembra che in certe condizioni la cosa gli piaccia molto poco.
Quando la cosa gli piace molto poco , quando e' passato troppo poco tempo da quando la vrbrain si e' svegliata e la usb del pc negozia il protocollo.
Collegando la vrbrain direttamente al pc rispetto all'hub abbiamo visto che il probblema succede con minor frequenza.
Quindi cosa ho fatto , con il codice sorgente allineato sul pc di Marco abbiamo rifatto un dfu che non usa la versione di qualche giorno fa' di Emile pubblicata sul repo , ma l'ultima di 24 ore fa con alcune piccole modifiche al timer e altri aggiustamenti alla usb .
Inoltre ho voluto tornare indietro ad una modifica fatta al delay il giorno 8 settembre che consente l'esecuzione di codice mavlink e lampeggio led anche quando la scheda e' in una funzione delay.
In particolare questa patch
https://code.google.com/p/vrbrain/so...de43e45ae2417f
Tornando indietro alla versioine precedente non dovremmo annidare troppe funzioni rendendo la vita un po' piu' semplice allo stack e cercando di mantenere un po' di linearità nelle funzioni da eseguire .
A me non piaciono per nulla troppe chiamate interrupt contemporanee durante l'esecuzione del codice specialmente in un so senza sistema operativo in grado di fare i lock delle variabili condivise.
Per ora e tutto ... speriamo di aver risolto anche questa cosa .. dopo questo approfondimento notturno.
un saluto
Roberto

[Bobo67]

Versioni "anti-freeze"

Non sto a spiegarvi molte cose nel dettaglio perchè vado al campo a testare questa versione adesso, teoricamente il problema dovrebbe esser stato isolato "definitivamente" (speriamo), o almeno ora la board del mio precedente video, quelal che si bloccava immediatamente, ora gira sempre in versione "enhanced" senza un blocco, almeno da 6 ore è così!
"Spostare la board durante l'inizializzazione" accelerava i freeze per un problema di delay mancante, poi vi spieghiamo bene il perchè.
In questa versione non vedrete i led verde/rosso blinkare velocemente durante la fase di startup, è normale, non preoccupatevi, questa deve fare così
Vi prego di far prove, magari a banco se non volete rischiare nulla, con questi due DFU che ho appena compilato e vi allego, per quad ed hexa con gps esterno, in versione enhanced.
Fateci sapere, grazie!

Marco

[ciskje]

Alcune domande per emile non ho idea di quale metodo preferisce per farsi contattare.

Nei dfu preparati vedo che INT EXT GPS, per ottenere le due versioni scambi i riferimenti _usart in uartA B C ? 0 telemetria con serigrafia gps, 1 porta interna, 2 porta esterna serigrafia telem?

jtag producurata per gentile concessione in arrivo.

Per la versione con e senza MTK quali define vengono usati?

E' possibile parlare direttamente con emile?

Perchè sono state scambiate TELEM e GPS, dato che sarebbe bastato scambiare di nuovo i numeri delle seriali con le uartB e uartC usate da ap?

[redfox74]

Alcune domande per emile non ho idea di quale metodo preferisce per farsi contattare.

Nei dfu preparati vedo che INT EXT GPS, per ottenere le due versioni scambi i riferimenti _usart in uartA B C ? 0 telemetria con serigrafia gps, 1 porta interna, 2 porta esterna serigrafia telem?

jtag producurata per gentile concessione in arrivo.

Per la versione con e senza MTK quali define vengono usati?

E' possibile parlare direttamente con emile?

Perchè sono state scambiate TELEM e GPS, dato che sarebbe bastato scambiare di nuovo i numeri delle seriali con le uartB e uartC usate da ap?

Ciao Francesco,
ti rispondo al volo io :
per fare le due versioni ti confermo che vanno invertiti i due uartB e C .
Il risultato e' che quando selezioni in sequenza a b c ti trovi :
gps sulla porta interna .
telemetria sulla porta telemetria.
sull'altra seriale c'e' attivo il secondo canale mavlink.

nel secondo caso con b e c invertiti avrai :

GPS da inserire sulla porta telemetria.
Telemetria da inserire sulla porta SER.
Il secondo canale mavlink e' spostato sulla seriale del gps interno.

Quando si attiva la porta usb invece si disattiva la porta telemetria standard ma rimane la seconda per poter testare modem di telemetria e usb contemporaneamente.

In merito al gps viene riconosciuto in automatico dalla libreria gps non richiede di attivare alcun define . Il protocollo ublox o mediaterk 3dr vengono riconosciuti e selezionati all'accensione.

Per parlare con Emile scivi qua o come ti ho detto in skype puoi contattartci
saluti
Roberto

[Draghettofly]

Buongiorno a tutti,
stamattina sono andato a volare. C'era vento, tanto, ed arrivava a folate. Il buon senso mi avrebbe suggerito di "passare" ma volevo mettere alla prova il multijet (sic!) in condizioni difficili. Ho visto tanti (troppi) traballamenti molto evidenti nel traslato, in questa situazione. La missione l'ha portata a compimento ma tra mille difficoltà. Si notava che arrancava...traballando.
Questi sono i miei pid attuali (senza vento tutto ok):
RATE_PIT_I,0,18
RATE_PIT_P,0,15
RATE_RLL_D,0.005
RATE_RLL_I,0.18
RATE_RLL_P,0,15

STB_PIT_P,4,0
STB_RLL_P,4,0
STB_YAW_P,4,25
Dove intervenire subito?
Siamo tutti presi dai freeze, d'accordo, e le ultime questioni che ho posto sono state ignorate completamente. Posso capire. Però insomma... spero che non ci si dimentichi, pur con dovute priorità, lo scopo e lo spirito del forum.
Marco mi ha dato dei suggerimenti che ho seguito e seguirò ancora ma in questo frangente un punto di partenza risulterebbe sempre utile. Se c'è vento dove mi conviene intervenire per evitare questi traballamenti nel traslato? Ho aggiustato qualcosa ma ne ho peggiorate altre...evidentemente (F-450 con 10x45 mot Dji 2212 920kv). Quali pid ed, indicativamente, a quali valori cominciare a provare? Le reazioni del multicoso erano "torpide", non veloci.

Grazie. Cordiali saluti.
Carlo

[Bobo67]

Freeze purtroppo in Loiter ad un metro da terra, 3 eliche 15x5 carbon andate e nessun altro danno... siamo ancora in alto mare!
Si si, metto su un altro WKM...

[danveal]

unica cosa che mi sento di suggerire... l'INS_FILTER di DEFAULT su apm è già settato a 20hz... praticamente indichiamo all'MPU dopo aver letto i dati di applicare un passa basso con frequenza di taglio a 20. ora, io non conosco come lavora il sistema di stabilizzazione dell'apm nel dettaglio. ma a mio modesto parere già 20hz sono bassini. sul mio drone, dato che ho appurato tramite log che il livello di vibrazioni è molto basso ho ALZATO l'INS_FILTER a 42hz guadagnando non poco in reattività alle perturbazioni esterne.

quindi l'INS_FILTER è un "bel parametro" ma và usato con cautela, abbassarlo troppo è controproducente, in quanto rallenta eccessivamente la piattaforma inerziale. così' come potrebbe essere un problema alzarlo eccessivamente, rendendo "ipersensibili" il sensore.

Detto questo, in bocca al lupo.

Questo post, scritto alcuni giorni fa passato inosservato andrebbe evidenziato, perchè si tratta di un fattore fondamentale. Su altre piattaforme la frequenza di taglio viene settata da 40 ai 60 Hz, chi ha un filtro hardware,come mikrokopter, e chi software.
Averlo troppo basso è funzionale in quanto è un metodo veloce per risolvere il problema indotto dalle vibrazioni ma potrebbe causare effetti imprevisti, oltre a rendere un bradipo il multirotore nelle reazioni
Ho letto anche alcune parti del codice, praticamente la MPU 6000 viene letta a 200hz ma poi lo scheduler fa girare la routine di calcolo assetto a 100-150hz e a quanto scrivi viene aggiunto di default il filtro a 20Hz
Insomma prestazioni da 8 bit, io da un ARM F4 mi aspetterei molto ma molto di più. Avendo a disposizione una scheda di controllo basata su ARM bisognerebbe abbandonare il codice nativo 8 bit e scriverlo per l' ARM

[gionag]

Questo post, scritto alcuni giorni fa passato inosservato andrebbe evidenziato, perchè si tratta di un fattore fondamentale. Su altre piattaforme la frequenza di taglio viene settata da 40 ai 60 Hz, chi ha un filtro hardware,come mikrokopter, e chi software.
Averlo troppo basso è funzionale in quanto è un metodo veloce per risolvere il problema indotto dalle vibrazioni ma potrebbe causare effetti imprevisti, oltre a rendere un bradipo il multirotore nelle reazioni
Ho letto anche alcune parti del codice, praticamente la MPU 6000 viene letta a 200hz ma poi lo scheduler fa girare la routine di calcolo assetto a 100-150hz e a quanto scrivi viene aggiunto di default il filtro a 20Hz
Insomma prestazioni da 8 bit, io da un ARM F4 mi aspetterei molto ma molto di più. Avendo a disposizione una scheda di controllo basata su ARM bisognerebbe abbandonare il codice nativo 8 bit e scriverlo per l' ARM

Hanno fatto la versionona a 1000hz (quella con scritto enhanced) di lettura sul 6000, ma onestamente andrebbe indagato poi ogni quanto scrive... e se effettivamente su vrb il filtro a 20hz "hardware" è applicato.
Da quello che ho visto cambia registro dentro al sensore, quindi non usa algoritmi software.

[Enrico-viale]

Sicuramente sarebbe la cosa migliore ... Ma il problema credo sia poi mantenere l'allineamento con arducopter ... Che risulterebbe più lungo ad ogni modifica. A dirla tutta allora sarebbe meglio avere un S.O. Che gestisca un vero multithread ... È non uno scheduler ... Diventa difficile così capire quando le variabili vengono aggiornate e da chi ... ...

Comunque un conto e la frequenza di lettura del sensore ... È quindi il calcolo della media delle letture ... È un conto e la frequenza con cui quella variabile "media" viene usata ... Il risultato di una lettura più frequente e semplicemente un dato più attendibile perché la media viene fatta su un più alto numero di campioni. Ho sbaglio?
Enrico

[Bobo67]

Avendo a disposizione una scheda di controllo basata su ARM bisognerebbe abbandonare il codice nativo 8 bit e scriverlo per l' ARM

Se deve continuare a bloccarsi in questo modo, random, direi che si dovrebbe perseguire questa strada.
Roberto, siamo rimasti alzati fino a tardi per il nulla...