VRBRAIN by VirtualRobotix

[gionag]

Ho sbaglio?
Enrico

Tutto giusto... sbagli solo a mettere le "H"....

[gionag]

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...

a me sembra eccessivo saltare a queste conclusioni. forse la faccio più semplice di quello che è, ma... una volta bloccata la scheda, in jtag non si può andare a vedere dove si è fermato il programma e risalire al contrario a chi lo ha causato ?

Chiaro la VRB legge a 1000hz ma scrive sempre a 150/200 quindi non si ha un'incremento della velocità di risposta.. ma solo una maggior precisione da parte del controller.


A dopo, vado a testare l'ultimo firmware "DJI_NAZA.dfu". a presto

[danveal]

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.

Io ho letto questa versione contenuta in arducopter.pde versione v.3.1.2 Alpha https://code.google.com/p/vrbrain/so...de43e45ae2417f
dai cui estraggo una parte:

AP_Param param_loader(var_info, WP_START_BYTE);

/*
  scheduler table - all regular tasks apart from the fast_loop()
  should be listed here, along with how often they should be called
  (in 10ms units) and the maximum time they are expected to take (in
  microseconds)
 */
static const AP_Scheduler::Task scheduler_tasks[] PROGMEM = {
    { update_GPS,            2,     900 },
    { update_nav_mode,       1,     400 },
    { medium_loop,           2,     700 },
    { update_altitude,      10,    1000 },
    { fifty_hz_loop,         2,     950 },
    { run_nav_updates,      10,     800 },
    { slow_loop,            10,     500 },
    { gcs_check_input,       2,     700 },
    { gcs_send_heartbeat,  100,     700 },
    { gcs_data_stream_send,  2,    1500 },
    { gcs_send_deferred,     2,    1200 },
    { compass_accumulate,    2,     700 },
    { barometer_accumulate,  2,     900 },
    { super_slow_loop,     100,    1100 },
    { update_notify,         2,     100 },
    { perf_update,        1000,     500 }
};

Come si puo' vedere il gps (update gps) viene aggiornato ogni 20ms quindi 50Hz, l'altezza ogni 100ms 10Hz, un medium loop ogni 20ms e via dicendo

L'mpu 6000 viene letta a 200Hz frequenza massima perchè viene letta in modalità DMP, in pratica è la MPU che fa la data fusion di accelerometro e gyro e fornisce i dati gia elaborati, cioe' il valore degli angoli.
Un altro metodo consiste nel leggere i valori di acc + gyro in modo raw e poi calcolare il valore degli angoli usando il micro della scheda, leggendo i dati raw dalla mpu6000 è possibile fare acquisizione dati da 1Khz fino ad 8 Khz.
Secondo mie sperimentazioni che ho fatto in passato con mio codice ( armquad ) su un misero processore arm a 60Mhz e itg3200 + acc letti in modo raw a 1Khz, se il ciclo loop di calcolo e' piu' veloce rispetto all'aquisizione dati si ottiene una sorta di effetto oversampling e le performance di volo sono notevolmente migliori.
Io acquisivo i dati ad 1Khz e avevo un loop per il calcolo dell'assetto a 2Khz e anche soltanto in modo acro le differenze erano incredibili. Sempre secondo la mia esperienza velocità del genere consentono di non dover introdurre miriadi di parametri da settare ed ottimizzare e il volo e' piu' lineare in tutte le condizioni, in sostanza si puo' avere un comportamento "sportivo" e allo stesso tempo un hovering stabile senza settaggi diversi e senza compromessi.

Attenzione non sto dicendo che il codice attuale sia pessimo, al contrario, da quello che ho visto il codice attuale mi sembra assolutamente ottimo nelle prestazioni di volo, ma sto dicendo che si potrebbe avere di più utilizzando un codice scritto appositamente per il processore arm f4.

[gionag]

Io ho letto questa versione contenuta in arducopter.pde versione v.3.1.2 Alpha https://code.google.com/p/vrbrain/so...de43e45ae2417f
dai cui estraggo una parte:

AP_Param param_loader(var_info, WP_START_BYTE);

/*
  scheduler table - all regular tasks apart from the fast_loop()
  should be listed here, along with how often they should be called
  (in 10ms units) and the maximum time they are expected to take (in
  microseconds)
 */
static const AP_Scheduler::Task scheduler_tasks[] PROGMEM = {
    { update_GPS,            2,     900 },
    { update_nav_mode,       1,     400 },
    { medium_loop,           2,     700 },
    { update_altitude,      10,    1000 },
    { fifty_hz_loop,         2,     950 },
    { run_nav_updates,      10,     800 },
    { slow_loop,            10,     500 },
    { gcs_check_input,       2,     700 },
    { gcs_send_heartbeat,  100,     700 },
    { gcs_data_stream_send,  2,    1500 },
    { gcs_send_deferred,     2,    1200 },
    { compass_accumulate,    2,     700 },
    { barometer_accumulate,  2,     900 },
    { super_slow_loop,     100,    1100 },
    { update_notify,         2,     100 },
    { perf_update,        1000,     500 }
};

Come si puo' vedere il gps (update gps) viene aggiornato ogni 20ms quindi 50Hz, l'altezza ogni 100ms 10Hz, un medium loop ogni 20ms e via dicendo

L'mpu 6000 viene letta a 200Hz frequenza massima perchè viene letta in modalità DMP, in pratica è la MPU che fa la data fusion di accelerometro e gyro e fornisce i dati gia elaborati, cioe' il valore degli angoli.
Un altro metodo consiste nel leggere i valori di acc + gyro in modo raw e poi calcolare il valore degli angoli usando il micro della scheda, leggendo i dati raw dalla mpu6000 è possibile fare acquisizione dati da 1Khz fino ad 8 Khz.
Secondo mie sperimentazioni che ho fatto in passato con mio codice ( armquad ) su un misero processore arm a 60Mhz e itg3200 + acc letti in modo raw a 1Khz, se il ciclo loop di calcolo e' piu' veloce rispetto all'aquisizione dati si ottiene una sorta di effetto oversampling e le performance di volo sono notevolmente migliori.
Io acquisivo i dati ad 1Khz e avevo un loop per il calcolo dell'assetto a 2Khz e anche soltanto in modo acro le differenze erano incredibili. Sempre secondo la mia esperienza velocità del genere consentono di non dover introdurre miriadi di parametri da settare ed ottimizzare e il volo e' piu' lineare in tutte le condizioni, in sostanza si puo' avere un comportamento "sportivo" e allo stesso tempo un hovering stabile senza settaggi diversi e senza compromessi.

Attenzione non sto dicendo che il codice attuale sia pessimo, al contrario, da quello che ho visto il codice attuale mi sembra assolutamente ottimo nelle prestazioni di volo, ma sto dicendo che si potrebbe avere di più utilizzando un codice scritto appositamente per il processore arm f4.

hai mai fatto un giro con autoquad ?

[Enrico-viale]

a me sembra eccessivo saltare a queste conclusioni. forse la faccio più semplice di quello che è, ma... una volta bloccata la scheda, in jtag non si può andare a vedere dove si è fermato il programma e risalire al contrario a chi lo ha causato ?

No ... Quando va in freeze la scheda non risponde più! Il jtag e una porta di comunicazione aperta verso il processore ... Se quello si blocca non comunica più! Almeno questo e quello che ha fatto a me, non so se è lo stesso per gli altri.

Certo, sarebbe più semplice avere una scheda che si blocca di continuo come quella di Marco ...

Lancio una proposta ... Un po brutale se vogliamo ma potrebbe essere efficace:
Disabilitiamo temporaneamente il mavlink ... (O utilizziamo un altra porta) ... Poi inseriamo tutta una serie di messaggi nelle funzioni principali (un po lungo ... Da fare) che inviano una stringa che identifica quella funzione alla porta com del mavlink. Poi diamo a Marco quel firmware. Con la vrbrain collegata a un qualsiasi terminale seriale dovrebbero comparire tutte le stringhe ... Appena si blocca, e se si blocca sempre con la stessa stringa, potremmo circoscrivere la ricerca ad una serie di funzioni e non a tutto il codice.





Enrico

[Bobo67]

a me sembra eccessivo saltare a queste conclusioni. forse la faccio più semplice di quello che è, ma... una volta bloccata la scheda, in jtag non si può andare a vedere dove si è fermato il programma e risalire al contrario a chi lo ha causato ?

Purtroppo Michele questi freeze a quanto pare capitano solo a me (e purtroppo è il secondo in volo), il team di VR che ha board sotto jtag non ne ha mai avuto uno.
E lo stesso firmware con il quale oggi ho crashato al secondo volo (solo Loiter ad un metro di quota per sicurezza, ed ho fatto bene) sta girando su un'altra board da stanotte alle 2, senza alcun freeze, quella dell'ultimo video che si impallava solo a guardarla.
La board sul quad "crashato" è nuova di pacca, non l'avevo mai vista piantarsi prima d'ora, questa che uso per i test a banco è invece molto più "sensibile".
Come si fa a debuggare qualcosa di tremendamente casuale, e che quando sei li che l'aspetti a banco non capita mai?
Purtroppo non mi sento più sicuro, e se perdo la sicurezza poi è molto difficile riacquisirla, sono al limite.
Ho volato "fino a ieri" con gimbal a tre assi e cam sotto all'hexa con VR Brain, ora l'ho "saldato" all'altro hexa con Wookong che, almeno per quel che mi riguarda, non ha mai scantonato una volta, ma conosco chi ha avuto un bel "fly-away" con S800 e Z15 sotto...

[Bobo67]

Consiglio, e lo ribadisco, di stare sulla 3.0.3 per volare abbastanza tranquilli, anche se "a banco" ho avuto un feeeze pure con quella dopo circa 8 ore, ma l'aria di Ferrara è forse ostica alle VR Brain...
Siamo sempre al lavoro per cercare sta magagna da "notti insonni"...

[redfox74]

@Danilo,
in merito al tema del codice nativo per F4 vs Arducopter , su VRBrain gira a livello nativo Openpilot ... Stefan ha fatto il porting e chi vuole puo' fare test anche su quel codice . A quanto pare pero' e' piuttosto indietro rispetto a quanto mette a disposizione in questo momento Arducopter32.

@Michele,
ho sotto in jtag da giovedì una scheda in attesa di freeze , ma purtroppo non avviene nulla ... se dovesse accadere potremmo fare il debug ... purtroppo non ti puoi attaccare successivamente e guardare ... ma devi avere il sorce sul tuo pc allineato con il bin caricato a bordo .

Tema Autoquad ,
in realtà inzialmente c'eravamo visti con Francesco e Fabio Varesano e l'amico francese per supportarlo e svilupparlo assieme , ma poi per varie ragioni non se n'e' fatto piu' niente , e nemmeno quel firmware purtroppo e' esente da bug ... gli utenti sono molto contenti delle prestazioni , ma ogni tanto qualche problemino salta fuori.

Tema Sistema Operativo su F4
In questo momento a livello sperimentale ho fatto early porting su VRBrain di Nuttx , con lo stesso approccio di PX4 , dove si puo' far giare su SO sia ARducopter monoblocco che un codice piu' strutturato di PX4 ... ma su Arducopter siamo a grandi linee a livello di VRBrain forse qualcosa meno ... su PX4 nativo ... meglio lasciar perdere un casino ...

Quindi ... quello che vorrei sottolineare e' che VRBrain e' una piattaforma molto flessibile che a seconda del firmware che monta : Arducopter , Openpilot , Nuttx , PX4 o che monterà puo' essere un prodotto R&D , Didattico o in futuro anche stabile e commerciale .

Sta alla nostra community decidere in quale direzione investire piu' energie perchè si crede piu' in una direzione che in un altra.

Lavorare interamente da soli ad un progetto exnovo e' un impresa ciclopica . E non so' se poi vale cosi' la pena.

Di solito dalle esperienze che ho maturato nel mio lavoro per ottenere un prodotto stabile bisogna fermarsi ... fare test pesanti su quanto si ha in mano in questo momento e definire il perimetro entro il quale i collaudi hanno dato esito positivo .

A quel punto si puo' affermare con certezza che con quella rev. di firmware e quella configurazione di hardware di sorprese non ce ne dovrebbero essere ...
se ogni due giorni cambiamo le carte in tavola diventa pressochè impossibile fare queste valutazioni ...
Sarebbe carino mettere appunto una task force di utenti che lavori su stable e un altro gruppo su dev ...
In modo tale da censire i collaudi fatti in modo sistematico e i voli effettuati con sucesso per capire cosa ci dice la statistica in modo oggettivo.

Io lavorerei in questa direzione che ne pensate ?

@DraghettoFly,
per migliorare la tenuta al vento del quad bisogna aumentare la reattività del PID sul rate in modo che in autonomia tenti di compensare gli scompensi dovuti alle raffiche di vento.

@Marco,
in merito al test di oggi di Marco da quello che ho capito l'ha fatto con la versione con alta frequenza di lettura del giroscopio passando da 100 hz a 1000 hz per verificare eventuali vantaggi di stabilità in questa configurazione ... purtroppo dopo un primo loiter di 15 minuti senza problemi nel secondo ha avuto il freeze ... quindi stava operando su una versione dev.

@DEV
In questo momento io sto' volando ancora con la rev 3.0.2 sul drone che uso per i test di affidabilità del VR Copter X4 e con questo drone ho fatto orientativamente una 40'na di voli senza problemi particolari da segnalare oggi ho fatto un test di volo con una telecamera termica senza problemi per simulare un volo d'ispezione.

Non metto le mani sul fuoco che anche sulla v 3.0.2 ci sia qualcosa di migliorabile , ma lascio parlare la statistica che sarebbe interessante confrontare con quella di altri.

Un saluto e buona giornata a tutti
Roberto

[Draghettofly]

@Redfox
"...per migliorare la tenuta al vento del quad bisogna aumentare la reattività del PID sul rate in modo che in autonomia tenti di compensare gli scompensi dovuti alle raffiche di vento".
Grazie Roberto, è quello che mi accingo a fare. Marco mi aveva detto anche di intervenire su D, però senza aggiungere se in + o in -.
Se ho iniziato a comprendere, io lo abbasserei di un punto a 0,004.
Quindi alzo Rate P ed abbasso un pochino Rate D.
Dovrebbe essere così, no?

[Enrico-viale]

Sarebbe carino mettere appunto una task force di utenti che lavori su stable e un altro gruppo su dev ...
In modo tale da censire i collaudi fatti in modo sistematico e i voli effettuati con sucesso per capire cosa ci dice la statistica in modo oggettivo.

Ok Roberto, io sono disponibile! Sono giorni che continuo a verificare e controllare ma non trovo nulla!
In effetti ho perso un po il conto di quanti utenti hanno il freeze ... A parte Marco .
Ma non sarebbe più facile se Marco ti spedisse le schede? Magari alla fine lui ha un problema hardware ... Alla fine mi sembra l'unico ad avere un problema costante.


Enrico

[fabietto_91]

Ricapitolo qui per la seconda volta la mia esperieza di questi giorni con la 3.1.3beta_EXTGPS, installata su VRBrain 4.0, senza gps nè telemetrie, scheda alimentata dalla rastrelliera degli esc con un bec T-motor (sia in volo che nei test al banco).
Ecco il riassunto:
-più di 2ore test al banco con i motori in azione (cambiando lipo ogni 20minuti)
-decine riavvii consecutivi... accensione, spin motori, spegnimento...accensione,.. ecc
-più di 200 minuti di volo in stabilze, alt hold e sport mode.. (ogni volo di circa 5minuti)
-3 test di funzionamento in stand by con led lampeggiante,alimentata da bec esterno, no USB. 2 ore il primo, 8 ore il secondo e 10 ore il terzo, nessun freeze.

Fin ora (.....grattatina.....), nessun problema...

Mi è sembrato giusto portare un po' di buone notizie in questo thread....

[gionag]

No ... Quando va in freeze la scheda non risponde più! Il jtag e una porta di comunicazione aperta verso il processore ... Se quello si blocca non comunica più! Almeno questo e quello che ha fatto a me, non so se è lo stesso per gli altri.

Certo, sarebbe più semplice avere una scheda che si blocca di continuo come quella di Marco ...

Lancio una proposta ... Un po brutale se vogliamo ma potrebbe essere efficace:
Disabilitiamo temporaneamente il mavlink ... (O utilizziamo un altra porta) ... Poi inseriamo tutta una serie di messaggi nelle funzioni principali (un po lungo ... Da fare) che inviano una stringa che identifica quella funzione alla porta com del mavlink. Poi diamo a Marco quel firmware. Con la vrbrain collegata a un qualsiasi terminale seriale dovrebbero comparire tutte le stringhe ... Appena si blocca, e se si blocca sempre con la stessa stringa, potremmo circoscrivere la ricerca ad una serie di funzioni e non a tutto il codice.





Enrico

Enrico la tua idea mi piace un bel pò... se avessi le conoscenze necessarie, mi sarei già messo al lavoro

[redfox74]

VR Copter + Camera Termica

Ciao a tutti,
oggi ho fatto un po' di voletti con il mio VR Copter X4 con montata su una camera termica FLIR TAU 320 rev firm VRBrain 4.5 v 3.0.3

Ecco il video ...



saluti
Roberto

[Bobo67]

Ok Roberto, io sono disponibile! Sono giorni che continuo a verificare e controllare ma non trovo nulla!
In effetti ho perso un po il conto di quanti utenti hanno il freeze ... A parte Marco .
Ma non sarebbe più facile se Marco ti spedisse le schede? Magari alla fine lui ha un problema hardware ... Alla fine mi sembra l'unico ad avere un problema costante.


Enrico

Ho il debugger qui, connesso e funzionante, ora s'inizia la caccia...
E ce l'ho io e non l'ha Emile, lead programmer di Virtualrobotix, si può? Tirata d'orecchi a Roberto, ennesima, ti verranno gli orecchioni prima o poi!
I problemi non li ho solo io, diciamo che il sottoscritto ve li notifica e ci lotta, gli altri si rompono e comprano Naza/WKM/APM/PX4, ma non sono l'unico.
Enrico, quando puoi contattatami via Skype (mi trovi col nome e cognome) che ti faccio dare un'occhiata in remoto alla situazione, grazie!

[gibon]

Ho il debugger qui, connesso e funzionante, ora s'inizia la caccia...
E ce l'ho io e non l'ha Emile, lead programmer di Virtualrobotix, si può? Tirata d'orecchi a Roberto, ennesima, ti verranno gli orecchioni prima o poi!
I problemi non li ho solo io, diciamo che il sottoscritto ve li notifica e ci lotta, gli altri si rompono e comprano Naza/WKM/APM/PX4, ma non sono l'unico.
Enrico, quando puoi contattatami via Skype (mi trovi col nome e cognome) che ti faccio dare un'occhiata in remoto alla situazione, grazie!

mikrokopter?