VRBRAIN by VirtualRobotix

[gionag]

San jtag e san Marco e tutti del team... adesso... mi tocchetà ri-smontare arduflyer e ributtare su vrb.

Clap clap clap a tutti !

Sent from my GT-I9100P using Tapatalk 2

[redfox74]

BUG on AP_HAL Problem on APM PX4 AND VRBRain " Porca Vacca " !!!

Testo originale appena postato sulla DEV - LIST ufficiale di arducopter

Dear Friend,
after two weeks of strange problem that affect last revision of our ys code 3.1.3 we decide to going in deep and try to found the problem that was on our drone.

So the old revision of our porting on VRbrain don't use AP_HAL and don't use scheduler and semaphore , in last revision we adopt AP_Hal and so we are using this two library.

We found this problem because some user and Marco , too told us that our board freeze after some seconds , minutes , hour randomly ...

We test some boards in our labs but nothing ... the problem happen every time only if we try to use an high rate of mpu6000 data instead of 100 hz work at 1000 hz .

So after a lot evaluation of our native driver .... i2c .. spi .. ecc ecc

We decide to use JTAG on Marco Board to understand what happen ... because on that boad connected on USB HUB this problem happen every time .
that was great idea ... after configure the pc of Marco With ST-LINK 2 debugger and start the code we saw after 10 seconds what happen the result was incredible .......

appear that the code was blocked here :

void VRBRAINScheduler::panic(const prog_char_t* errormsg) {
hal.console->println_P(errormsg);
for(;;); <---------------------------------------------- !!!!!!!!!
}


Whe check why this happen and we found here the problem :

void AP_InertialSensor_MPU6000::_read_data_from_timerpr ocess()
{
static uint8_t semfail_ctr = 0;
bool got = _spi_sem->take_nonblocking();
if (!got) {
semfail_ctr++;
if (semfail_ctr > 100) {
hal.scheduler->panic(PSTR("PANIC: failed to take SPI semaphore "
"100 times in AP_InertialSensor_MPU6000::"
"_read_data_from_timerprocess"));
}
return;
} else {
semfail_ctr = 0;
}

_last_sample_time_micros = hal.scheduler->micros();
_read_data_transaction();

_spi_sem->give();
}


So after i remove the for (;;); the code work fine without problem and only in some situation i see with a break point that happen this condition ...

I have two question
Why
for(;;);
and not only a log in a flash about the problem ....

The other question is what kind of problem could produce this panic sentence ?

So i think that for affordable code we need to re write this kind of managment to have more safe approach.

In VRBrain we don't implent watchdog because we prefer to see the problem instead to restart the board without any kind of managment .

IN APM2 i see that is activated the watchdog so when you have this error the apm restart if this a Plane ok could reload ... if that is a copter the board cannot restart in air because you cannot doing a gyro calibration during fly . And you need to rearm the quad to try to restart it.

In PX4 i see that there is an Exit Sentence ....

So i think that could be better for all the project put our hand here to solve this bugs

Thanks to Marco Robustini for his help in debug and Emile for support in development and in porting of AP_HAL

Thanks for your atention
Roberto Navoni

[xian06]

[Bobo67]

La board che si blocava a guardarla è li che va da questa notte, attaccata sempre a quell'hub usb... nice shot ragazzi, si ricomincia a volare!
Qualcuno dirà "io non mi sono mai fermato"... beh, ti è andata bene, amico mio!
Quando intercorrono questi problemi bisognerebbe sempre aspettare risposte certe dal team di sviluppo, non pensando "mah, chissà quello la cosa combina, le mie schede vanno bene", e ve l'ho ribadito più volte, non per i vostri quad ma per una questione di sicurezza!
Ora sono curioso di vedere cosa scriveranno Tridge o Pat in merito alla cosa.
Forse qualcosa del tipo "abbiamo fatto una cacata?"...
Leggo ora la risposta, dicono che c'è un bug sulla gestione del "semaphore" sul nostro porting, verifichiamo se è così.

[ciskje]

Ok, meno male che c'era un loop infinito, il vero problema non è levare il for(;;) (che lascerei, si tratta di una situazione che non deve capitare mai!), ma piuttosto capire come mai si arriva a 100 cicli senza poter accedere alla SPI, se si mette 1000 funziona?

[blurex]

Qualcuno dirà "io non mi sono mai fermato"... beh, ti è andata bene, amico mio!

VERO!!!!!!!!!!!!!!!!!!!!!!!!!

[ciskje]

Farei cosi', nel panic blocco tutto e faccio lampeggiare qualcosa con un codice che indica dove si è fermato (il panic è usato parecchio nel codice ma sempre per casi disperati).

[Bobo67]

E' corretto Francesco, quella situazione non dovrebbe intercorrere, ma purtroppo salta fuori randomicamente, bisogna sicuramente trovare il perchè ma come dice Roberto perchè fermare l'esecuzione del codice? Schianto sicuro se sei in volo.
Non è meglio reindirizzare un output sulla seriale o sulla flashlog per vedere in caso cosa succede?
Ho già crashato due volte per questa cosa, ed a voi tutti è andata bene.

[ciskje]

E' corretto Francesco, quella situazione non dovrebbe intercorrere, ma purtroppo salta fuori randomicamente, bisogna sicuramente trovare il perchè ma come dice Roberto perchè fermare l'esecuzione del codice? Schianto sicuro se sei in volo.
Non è meglio reindirizzare un output sulla seriale o sulla flashlog per vedere in caso cosa succede?
Ho già crashato due volte per questa cosa, ed a voi tutti è andata bene.

Farei 2 prove, metterei 1000 e lascerei il blocco (anche perchè se non hai la SPI disponibile il codice non ho idea in che guai si va a cacciare).

[danveal]

E' corretto Francesco, quella situazione non dovrebbe intercorrere, ma purtroppo salta fuori randomicamente, bisogna sicuramente trovare il perchè ma come dice Roberto perchè fermare l'esecuzione del codice? Schianto sicuro se sei in volo.
Non è meglio reindirizzare un output sulla seriale o sulla flashlog per vedere in caso cosa succede?
Ho già crashato due volte per questa cosa, ed a voi tutti è andata bene.

Marco ho visto vari tuoi video... il tuo modo di volare stressa gyro e acc che inviano più dati e mandano in crisi il codice, ecco perchè succedeva solo a te devi volare più tranquillo
Scherzo ovviamente, se si toglie quella parte di codice non si risolve nulla perche il problema sull'spi rimane, e il sistema potrebbe ricevere dati corrotti dall' mpu6000 o non riceverli e crashare ugualmente ma con effetti imprevisti tipo fly away

[emile.c]

Buongiorno a tutti.

Ciskje et al., se vi fa piacere scambiare quattro chiacchere su skype mi potete aggiungere.
Mi trovate sotto manlio (emile).

tornando al nostro problema, sono d'accordo che il "panic" non dovrebbe succedere, e dobbiamo capire come mai il codice non è in grado di prendere il semaforo per l'SPI.
Ma dobbiamo anche considerare che stiamo parlando di oggetti volanti, quindi il panic è l'ultima delle risorse e dovrebbe accadere solo quando c'è un effettivo problema hardware.

Io non mi farei venire giù il coso per un semaforo sulla mpu6000, al limite resetterei la SPI o i semafori, e ricomincio.

Solo quando ci sono situazioni non gestite devo andare in panic (hard fault, bus fault etc) ma anche qui sono convinto che ci possono essere strategie per il corretto ripristino.
Le mie esperienze con ARM e la programmazione dei MC è pari a quella di un bambino delle elementari che va all'università senza passare dal liceo...

Sto imparando e una collaborazione con qualcuno che come me vuole imparare o mettere a disposizione la propria esperienze è solo ben accetta!

Quindi oggi cerco di capire come uscire da un panic senza creare panico, e vediamo cosa succede.

Cmq, un grazie a Marco che ha messo a disposizione tempo, eliche, telai e il suo PC che ieri notte è stato assalito da me e Roberto...

[emile.c]

Tornando al discorso MPU600, posso confermare quanto detto che con il rate a 1000Hz e il filtro a 98Hz il mezzo vola mooolto meglio.
A patto però di aver tolto le vibrazioni inutili.

Nella versione 2.9 si volava con i full rate dei gyro e acc a 1KHz, il loop principale a 200/250Hz quindi con un sampling di 4/5 dati per ogni ciclo di calcolo dell'attitude.

Nelle mie varie implementazioni avevo anche testato il rate a 8Khz della MPU ed ero arrivato ad un loop principale di 4KHz, dopo di che si cominciava a sentire un po' di scircchiolii.

Purtroppo il porting delle ap_hal è stato un parto (ancora da finire per bene), per cui per evitare di trovarm in situazioni in cui non sapevo se era la mia implementazione o il codice loro a non funzionare mi sono tenuto 1:1 con la versione di APM, con l'obiettivo, una volta consolidato di iniziare a spingere sull'acecleratore.

Per il momento con il loop a 100Hz l'utilizzo (approsimativo) delle risorse è stimato tra il 7 e il 14%, direi che di birra cen n'è.

sarebbe bello anche poter implementare un filtro un po' più serio (tipo EKF) per il controllo della posizione inerziale in modo da sfruttare tutte le doti dell'ARM.

E.

[Claudiopapi]

.... e il suo PC che ieri notte è stato assalito da me e Roberto...

...tag: nerds,fetish,gangbang.

[ElNonino]

Da programmatore di PLC e microembedded devo dare ragione a Cjskye, per applicazioni complesse e che richiedono il massimo dell'affidabilità preferisco un RTOS a schedulazione che un multitasking, inoltre prediligo i sistemi multiprocessore: trovo più semplice ottimizzare e debuggare applicazioni specifiche anzichè 1000 funzioni impaccate tutte in un unico micro.

Una struttura hw e fw modulare consente poi di aggiornare facilmente i singoli blocchi man mano che aumentano le richieste o vengono disponibili nuovi prodotti ed anche rendere il sistema ridondante; da anni adotto questa filosofia progettuale e mi son sempre trovato bene, però son gusti personali: ad esempio io preferisco il "C" classico al C++ per i micro e Delphi per le applicazioni di interfaccia su PC.

IMHO.

[QuercusPetraea]

Che dire. Gran bel lavoro di spulciamento per capire le magagne.
Nel frattempo, come consigliato, non ho osato volare con VRBrain 3.1-DEV per sicurezza, sebbene abbia fatto prima dello stop una decina di voli senza problemi.

Oggi o domani mi arriva il JTAG per cui se posso dare una mano ci sono, ma servirebbe anche a me una immersion nel codice HAL; per quello che riguarda ARM non ho ancora sufficiente conoscenza di queste MCU ed ho bisogno di colmare le lacune. Ma se migliora la comprensione del codice affiancato all'uso del manuale di STM32F4, dovrei riuscire agevolmente a colmare le lacune attuali.