VRBRAIN by VirtualRobotix

[Enrico-viale]

Il 6000 viene letto sia a tempo sia su richiesta, ecco il semaforo ed ecco la race-condition, poi perchè venga letto due volte qualche volta potrebbe essere per avere un dato aggiornato per una calibrazione.

bool got = _spi_sem->take_nonblocking();

ok ... ma perche sulla gestione di quella seriale se la usa solo per il mpu6000? Non sarebbe meglio diretta?

[redfox74]

... possibile accesso ad una periferica non alimentata ho fuori clock ... stack corruption o chiamata ad una funzione con un indirizzo non valido ...

Sono pronto sul pezzo per la verifica serale della patch ... ho visto anche la nota di marco rispetto all'hard fault quando alimentato da usb ... voglio vedere da vicino le condizioni di contorno in cui capita .. se l'alimentazione non e' stabile sul micro quando si fanno partire le periferiche e' una condizione che si puo' verificare di sicuro ... i led che si accendono e il ciclo while li ce lo abbiamo messo noi , perchè quello e' un vero PANIC , servirebbe anche un testre per vedere la tensione che si ha sulla usb in quella condizione ... giusto per scrupolo .
A dopo le verifiche , nulla va lasciato al caso , visto che poi gratta gratta troviamo le magagne di tutti
Roberto

[Bobo67]

Si, dopo attente verifiche sembrerebbe un problema che si presenta in fase di boot solo se la board è alimentata dall'usb, ma attenzione perchè nel git attuale ho chiesto ad Emile di inserire la possibilità di dichiarare l'enhanced dal config con un define ma c'è un errore, aspettiamo quindi che venga sistemato prima di volarci, per ora solo prove a banco, tutto acceso e collegato, eliche ovviamente rimosse... e dopo l'ulteriore fix, ovviamente!

[redfox74]

Finiti test congiunti con Marco e Michele sui problemi segnalati qui sopra ...
allora effettivamente quando mi sono collegato ho visto gli hardfault ... come da lui descritti , poi abbiamo fatto qualche prova collegando diversamente la usb per avere piu' corrente e la scheda ha ricominciato a funzionare correttamente .
Il problema era associabile al collegamento alla usb sia del vrbrain che del jtag durante i test , in realtà appena abbiamo rimesso in pista la scheda abbiamo notato un rallentamento del led verde lampeggiante .... studiata un po' la cosa abbiamo trovato il problema nella compilazione del codice che stavamo debuggando che giustificava anche i ripetuti hardfault ...
C'e' ancora un piccolo problema sul git , nel codice attualmente online , in realtà non basta definire la modalità ENANCHED nell'APM_Config.h , ma serve farlo anche nella libreria APM_InertialSensor , perche' non sente il APM_Config.h ... Emile se riesci dacci un occhio
Appena attivato correttamente il modo anche nella libreria ora tutto a preso a funzionare ...
Aspettiamo il collaudo notturno per poter procedere domani ad un po' di voletti di collaudo al campo .. giusto per togliere la ruggine.
Per ora un saluto e buona notte a tutti

Roberto

[gionag]

Finiti test congiunti con Marco e Michele sui problemi segnalati qui sopra ...
allora effettivamente quando mi sono collegato ho visto gli hardfault ... come da lui descritti , poi abbiamo fatto qualche prova collegando diversamente la usb per avere piu' corrente e la scheda ha ricominciato a funzionare correttamente .
Il problema era associabile al collegamento alla usb sia del vrbrain che del jtag durante i test , in realtà appena abbiamo rimesso in pista la scheda abbiamo notato un rallentamento del led verde lampeggiante .... studiata un po' la cosa abbiamo trovato il problema nella compilazione del codice che stavamo debuggando che giustificava anche i ripetuti hardfault ...
C'e' ancora un piccolo problema sul git , nel codice attualmente online , in realtà non basta definire la modalità ENANCHED nell'APM_Config.h , ma serve farlo anche nella libreria APM_InertialSensor , perche' non sente il APM_Config.h ... Emile se riesci dacci un occhio
Appena attivato correttamente il modo anche nella libreria ora tutto a preso a funzionare ...
Aspettiamo il collaudo notturno per poter procedere domani ad un po' di voletti di collaudo al campo .. giusto per togliere la ruggine.
Per ora un saluto e buona notte a tutti

Roberto

attendiamo il responso di Marco sul volo "reale".... sto giro mi sento fiducioso

[Bobo67]

Eccomi, ho fatto solo due voli per stare in sicurezza ed i freeze sembrano scomparsi, le due board che ho in test sono accese (alimentate dalla rail) da ieri sera senza mai bloccarsi, credo che il problema sia stato risolto.
C'è qualcos'altro da sistemare e Roberto è già al corrente della cosa, l'usb che spesso e volentieri freeza la board, cosa da poco considerando che succederebbe immediatamente solo ad usb appena collegata, alimentando invece la board dalla rastrelliera o dalla power port l'usb viene completamente disabilitata, quindi si sta sicuri.
Siamo a caccia di un'altra piccola magagna sulle porte gps/telemetria, ma che non comporta blocchi della board se le connessioni sono state fatte correttamente, swappando gps e telemetria tra loro qualche freeze può intercorrere ma ci sta, del resto sarebbe un nostro errore, stiamo comunque cercando di isolare pure questo.
Per ora per me è GO, domani lo dirò con più convinzione, ma tutt'ora sono molto fiducioso.

[redfox74]

Quasi 11 ore di volo a terra , simulato senza eliche e 20 minuti in volo reale

Eccomi...
tra poco devo iniziare una call piuttosto lunga , ma faccio una sintesi della giornata di kick off della vers 3.1.4beta .
Dopo le modifiche di ieri sera e i test con Marco oggi ho mantenuto il mio VR Copter X4 attivo tutto il giorno simulando una missione iniziata alle 8.30 di mattina e finita alle 19.00 . Insomma potevo virtualmente arrivare da Bergamo a Roma ....
La versione che ho testato e' stata con
Versione Quad a X .
Enanched , quindi con il gyro aggiornato a 1 khz e non a 100 hz come nella versione standard.
Ho usato un alimentatore da tavolo da 10 amp , ovviamente i test li ho effettuati tutti senza eliche.
Sono decollato alla mattina alle 8.30 e atterrato alle 19.00
Durante il volo virtuale ho fatto un po' di tutto , loiter , rtl , auto .... in condizioni di gps pessime ... i gligth erano frequenti perchè ero sotto una tettoia così ho potuto osservare il comportamento del failsafe del GPS che attiva in automatico la funzione di land. Da valutare quanto sia intuitiva questa cosa a volte puo' prendere alla sprovvista.
Finita la sessione di test una volta rientrato a casa in giardino mi sono divertito a fare un po' di otto ... ho apprezzato la qualità sia delle elighe Graupner , sostituite alle mie affidabilissime apc per fare qualche test.
Direi che il volo in enanched e' molto smooth , non so se fosse anche merito delle nuove eliche ma mi sono divertito un sacco a fare otto in poco metri di spazio , sembrava di far volare una chiocciolina da allenamento , pur avendo sotto il drone anche un bel carrello ... Tutto perfetto , ho fatto anche qualche test di altitude hold e loiter anche li tutto perfetto ....

Passiamo invece ad alcune nuove cosette emerse oggi spulciando il codice ufficiale di arducopter , pensiamo di aver trovato un nuvo bachetto , già corretto nella nostra versione e disponibile sul git , che in realtà rischia di generare una quantità enorme di call di interrupt con il rischio di non far passare piu' per il main il codice.

Di questa cosa me ne sono accorto facendo test cattivi , invertendo gps e telemetria sulla rastrelliera per simulare cosa potrebbe combinare un utente inesperto che sbaglia ad installare il software dal repository.

In quel caso avevo notato alcune condizioni che sembravano dei freeze , idagando e indagando ancora ho scoperto anche questa piccola magagna .

https://code.google.com/p/vrbrain/so.../Scheduler.cpp

Questa e' la patch

Quindi mi raccomando non volate assolutamente con gps e telemetria invertite, perchè ho osservato che il gps di 3dr e gli ublox in generale potrebbero anche perdere la loro configurazione corretta richiedendo un restore della configurazione da parte dell'ublox center .. l'init che viene fatto in automatico potrebbe non essere sufficiente.

Proseguiamo nella revisione del codice per aumentare l'affidabilità complessiva del codice , ma penso che in questi giorni abbiamo fatto un lavoro veramente enorme a cui i primi risultati sperimentali iniziano a dare ragione.

Durante le varie chiacchierate fatte con utenti e sviluppatori del gruppo quello che e' emerso e' che sarebbe bello poter avere una versione ritagliata di codice , ultra stabile che possa anche avere solo un sotto insieme di funzioni , ma che garantisca il massimo di affidabilità complessiva del sistema.

Ci abbiamo iniziato a lavorare seriamente da diverso tempo e i primi risultati arriveranno a breve con il rilascio di una serie di hardware che siano in grado di garantire maggiore affidabilità delle nostre piattaforme volanti anche attraverso la messa a dispsoizione di una seconda imu esterna o di una distribution board con alimentatori professionali e con circuiti di sicurezza e controllo in corrente di elevata qualità .
Attualmente e' in fase di assemblaggio la distribution board del VR Copter X4 che per prima abbraccia proprio questo approccio.


Sul Git ho visto che Emile ha appena rilasciato la rev 3.1.5 con tutte le modifiche patch e miglioramenti apportati al codice tra ieri e oggi.

Domani tempo permettendo continuero' i test di oggi ... con questa nuova revisione.

Un saluto a tutti
e buona serata
Roberto

[redfox74]

Eccomi, ho fatto solo due voli per stare in sicurezza ed i freeze sembrano scomparsi, le due board che ho in test sono accese (alimentate dalla rail) da ieri sera senza mai bloccarsi, credo che il problema sia stato risolto.
C'è qualcos'altro da sistemare e Roberto è già al corrente della cosa, l'usb che spesso e volentieri freeza la board, cosa da poco considerando che succederebbe immediatamente solo ad usb appena collegata, alimentando invece la board dalla rastrelliera o dalla power port l'usb viene completamente disabilitata, quindi si sta sicuri.
Siamo a caccia di un'altra piccola magagna sulle porte gps/telemetria, ma che non comporta blocchi della board se le connessioni sono state fatte correttamente, swappando gps e telemetria tra loro qualche freeze può intercorrere ma ci sta, del resto sarebbe un nostro errore, stiamo comunque cercando di isolare pure questo.
Per ora per me è GO, domani lo dirò con più convinzione, ma tutt'ora sono molto fiducioso.

Ottimo Marco , grazie per il lavoro immenso che stai facendo per la nostra community ;) Anche domani continuiamo nella revisione e verifica cosi se deve saltar fuori qualcosa d'altro lo si fa' saltar fuori ... speriamo che ora si chiuda la vers 3.1 ufficialmente in modo tale da blindarla !!!
Se becco Tridge gli segnalo anche il problemino scoperto oggi ...
saluti
Roberto

[REfuso]

ciao
ho quasi terminato l' assemblaggio dell' AndreX e sarei in procinto di farlo svolazzare, mancano acora le 3 zampe momentaneamente ho montato un carrello alto e i motormount sono ancora su disegno.. ma può tranquillamente spiccare il volo
ora mi sono letto in queste giornate delle avventure di Marco e degli sforzi comunitari nel risolvere alcuni problemi, ora nella scheda ho il famigerato v.3.1-dev che a me x ora non ha dato problemi, ma sarà 2 sett. che non volo..e di cose ne sono successe nel frattempo..e la mia memoria fa cilecca..mi tengo questo fw ho ne metto uno + "sicuro" o me ne sto buonino a terra..dai devo solo rodare i motori e vederlo appeso in aria invece che al chiodo sulla parete..

qualche foto della bestiola quasi ultimata..

[rino2]

Domandina da nubbio che è appena rientrato e si è perso molti passaggi... se io.. ad oggi 24/09 ore 21.35... scarico dal GIT il Master e lo compilo.... Cosa ottengo????

Mi sembra di aver capito la 3.1.5 beta... ma configurata come? Quad a X? GPS a 1K o 100Hz? GPS interno o esterno?

Anche io per vari motivi non volo da tempo e ho ancora la 3.1DEV.... anche qui... mi par proprio di capire che è bene non usarla anche se a me restava accesa per giornate.....

Grazie a tutti voi!!!

Rino

[Bobo67]

Metti l'ultimo Alex, Emile deve ancora fixare la storia "dell'enhanced o meno" (gliel'ho appena fatto notare) ma è più sicuro di qualsiasi altro vecchio, la conferma arriva dal fatto che il bug che abbiamo trovato è anche stato prontamente rimosso anche dal codice nativo APM Copter, qui il link.
@Rino: se la compili così com'è ottieni una "QUAD GPS INTERNO NON ENHANCED".
Imho lasciate perdere qualsiasi altra versione più vecchia della 3.1.5 attuale, chi sa leggere il codice sa bene il perchè...

[REfuso]

Grazie Marco, vado con l' ultimo..

[Bobo67]

Grazie Marco, vado con l' ultimo..

Se poi vuoi proprio stare più sicuro non inserire "l'enhanced mode", anche se dai miei test regge tranquillamente, io oggi ho volato così.
Sarà anche importante allinearsi alla versione APM Copter RC3 perchè è stata inserita una protezione "anti gps glitch", qui i commint recenti di Randy, è comunque da testare.
L'obbiettivo d'ora innanzi sarà quello di marcare una versione cosidetta "stabile", un gruppo di testers di Virtualrobotix la bollerà tale dopo un bel pò di test in volo.

[redfox74]

Metti l'ultimo Alex, Emile deve ancora fixare la storia "dell'enhanced o meno" (gliel'ho appena fatto notare) ma è più sicuro di qualsiasi altro vecchio, la conferma arriva dal fatto che il bug che abbiamo trovato è anche stato prontamente rimosso anche dal codice nativo APM Copter, qui il link.
@Rino: se la compili così com'è ottieni una "QUAD GPS INTERNO NON ENHANCED".
Imho lasciate perdere qualsiasi altra versione più vecchia della 3.1.5 attuale, chi sa leggere il codice sa bene il perchè...

Quello che intende Marco rispetto alla storia dell'enhanced e' che per attivare l'enanched e' da attivare sia in APM_Config.h , ma anche internamente alla AP_InertialSensor per il sensore MPU6000 nel .h va attivato anche li perchè in questo momento non viene sentito il define in APM_Config.h

[Draghettofly]

Questioni di ... codice...

Sono settimane che, appropriatamente, ci si occupa solo di programmazione, a causa della possibilità di crash. Ottimo e lodevole l'impegno di molti che si stanno spendendo tanto per tutti. Leggo con piacere che si è arrivati a qualcosa di stabile. Fantastico.
A questo punto, solo per curiosità (non è il mio settore), sono andato a curiosare sul codice e mi sono posto alcuni interrogativi.
Il programma completo di librerie occupa quasi venti Mb di "spazio" sull'HD. Mi pare si tratti di programmazione che somiglia al linguaggio C.
Sono in grado di riconoscere qualche operazione, cicli ed iterazioni. ma non vado oltre.
Tuttavia mi chiedo come sia possibile tirar fuori da 20 Mb un dfu di poco più di 400k. E le librerie?
Qualche programmatore mi ha detto che il firmw è in grado di inglobare quei settori di lib che possono servire, tralasciando gli altri.
Funziona veramente così? E che cavolo è il MK6000? E l'ENHANCED?
Forse qualche esperto sorriderà un pò , ma sono curiosità legittime che servono a far comprendere meglio le cose anche a chi non è dentro queste problematiche.
Avete tutti un linguaggio spesso incomprensibile a molti e, quelli poco pratici, come me, visto che ormai sono diventati "trasparenti", mi pare che stiano abbandonando la scena. La qual cosa, a me, farebbe riflettere un pochino.
Speriamo che almeno queste curiosità, relative alla programmazione, vengano prese in considerazione da qualcuno e che si ricominci a trovare il tempo per tutto il resto. Mi sono mancati molto i vostri consigli.
Grazie. Cordiali saluti.
Carlo