VRBRAIN by VirtualRobotix

[xian06]

Ciao Gionag,
ecco i nuovi file per i test della rev 3.1.3 , se vuoi fare un test anche tu .
Un saluto
Roberto

3.1.3_MPU6000.dfu Led switch off after 10 mins.

[Bobo67]

3.1.3_MPU6000.dfu Led switch off after 10 mins.

Damn, here the same version no freeze after 12 hours, now i'm in test for this night with the MPU6000_SCHED...
Remember to power the VR Brain for this test with a stabilized power supply, not with USB!

[Enrico-viale]

Qualcuno a provato a lasciare la scheda in freeze ? Ho idea che si riprenda da sola.
Marco ... Riusciresti a provare ... Visto che a te si blocca subito?

Enrico

[Enrico-viale]

Guardate questo video ... http://m.youtube.com/watch?feature=c...&v=TzrswyLw770 ... Scusate il buio ma ero assorto e concentrato e non ho visto che era ormai sera inoltrata ... Fuori sul balcone al freddo!

Comunque si vedono meglio i led. Guardate il famoso led verde della vr ... Strano vero?

Finito il video ho continuato il mio debug ... ... Vedete anche la Lucina del debugger ... Quello è il tx rx del debugger sulla scheda ... La vrbrain Non è in freeze ... È rallentata ... È con il tempo e peggiorata.

Comunque ho visto che entrava di continuo in scrittura sulla porta usb ... (Non era collegata a nulla) ovvero l'usb era inserita nel pc che alimentava la scheda ma nessun programma (mp) che la usasse ... In questo modo se non altro avevo i flag di usb presente attivi ... Mandava il suo hartbeat ... Per capire se qualcuno rispondeva alle sue chiamate

In più e uscita fuori tempo ... ... In pratica i contatori dei tick ( correggimi Emile se sbaglio) vengono confrontati da una serie di funzioni che verificano il tempo di ciclo del main loop ... In pratica se la vrbrain ci mette troppo tempo a fare il giro entra in failsafe ... ... Ed in fatti entrava sempre li!

Continuò gli esperimenti

Chiaramente firmware 3.1.3


Enrico

[Draghettofly]

Ho la 3.1 dev con Gps LEA 6H ext.

[redfox74]

Buonaserata a tutti,
siete una squadra fantastica Stiamo riuscendo a validare un firmware grazie all'aiuto di tutti , penso una cosa del genere non sia mai successa Almeno non mi ricordo altri thread dove si lasciavano accese schede per giorni per capire il livello di affidabilità delle varie versioni di firmware.
In realtà è un test limitato pero' gia' ci sa' dare qualche info in piu' rispetto ai normali voli che non durano piu' di 20 minuti , in previsione dell'uso della scheda su aerei ad esempio poter essere tranquilli per diverse ore di voli e' molto importante ... e magari perchè no per quando avremo anche a disposizione anche batterie che consentiranno di far volare diverse ore i nostri droni
Comunque riepilogando , Marco è passato da pochi secondi con la scheda in freeeze a 12 ore di funzionamento continuativo senza problemi , utilizzando un alimentatore stabilizzato . Quindi simulando un bec.
Xian06 invece ci segnala che la sua scheda ancora dopo 10 min si rallenta ... bisognerebbe capire se sta' alimentando con un bec o ancora da usb.
Faccio una breve parentesi per spiegare alcuni aspetti progettuali della vrbrain che magari ad alcuni non sono poi cosi' chiari.
Volevo sottolineare un aspetto progettuale molto importante :
L'alimentazione della scheda deve avvenire sulla rastrelliera del radiocomando e non su quella degli esc. Infatti lato ESC di solito si usa un altro bec totolmente disaccopiato per alimentare eventuali servi o led per segnalazioni visive ad alta potenza.
In questo caso il jumper che porta l'alimentazione da davanti , dove ci sono i canali rc a dietro dove ci sono gli esc va tolto.
Infatti le schede devono avere un bec dedicato e l'alimentazione della cpu non deve essere influenzato da disturbi esterni che arrivino , ne dalla radio , ne dalla telemetria , tantomeno dai servo.
Quindi parola d'ordine prima di tutto pulizia della alimentazione in ingresso alla cpu.
Altre schede con costi piu' elevati come la DJI Wookong per esempio ha una PMU dedicata che ha proprio questa funzione stabilizzare al meglio l'alimentazione e iniettarla nella scheda stabilizzata. Noi anche se non abbiamo una PMU dedicata almeno su questa scheda entry level , facciamo tesoro di queste semplici regole in modo tale da dare sempre alla cpu un'alimentazione pulita.
Vi faccio un esempio molto semplice di quello che mi accade in passato , avevo dei servo collegati direttamente alla stessa alimentazione della cpu e un servo arrivato in fondo corsa si e' fuso ... e mi mise in corto l'alimentazione della scheda di controllo ... a quel punto il drone casco , semplicemente per un servo che si era cotto .... da allora inparai la lezione e quando riprogettai la vrbrain inserii questo piccolo stratagemma , semplice ma efficace.
La stessa cosa puo' succedere in arduplane o anche in ardurover dove per il controllo delle ali o dello sterzo un servo puo' richiedere molta corrente e quindi mandare sul bus di alimentazione della vrbrain dei glitch che possono far intervenire i circuiti di reset interni al micro ... spero che queste piccole note possano essere utili per fare un cablaggio sempre piu' affidabile sui vostri droni.

[redfox74]

Problematiche USB

Sappiamo che alimentando la vrbrain da usb , la scheda va in stdby , o come dice Enrico si rallenta è sicuramente un bug antipatico , ma non dovrebbe incidere in configurazione di volo . Infatti la usb dovrebbe essere usata sempre e solo senza lipo collegata per fare le prime impostazioni di sistema , poi in tutti gli altri casi , sopratutto nel fare la taratura del magnetometro con i motori piuttosto che la calibrazione del magnetometro o degli esc , va sempre fatto tutto da telemetria o da seriale ttl.
Quindi che si blocchi la scheda dopo 10 min - 20 min che e' collegato via usb come dice Enrico ... è un problema di driver usb che sta' cercando di sistemare , ma non bloccante in configurazione di volo ... azzzz ho appena ricevuto da Enrico un Bingoooooo vuoi vedere che ha scovato l'arcano ;)

....... to be continued ;)

[redfox74]

Problematiche USB , il bello del JTAG ... Grande Enrico

Vi allego un interessante screenshot appena ricevuto ...


Enrico e' uno dei pochi che come prima cosa ha sistemato sul suo sdk il Jtag e a riprova che puo' essere molto utile in fase di debug guardate cosa ha scovato ?
Praticamente quando la scheda andava in freeze ed era collegata in usb ci andava perche' il buffer di tx continuava ad aumentare , ma non veniva fatto il flush del tx perchè con la usb scollegata non riusciva a mandare l'heartbeat al mission planner.

Facendo un break e analizzando con il jtag il valore delle variabili del processore ora e' chiaro dove andare a mettere la pezza per risolvere il problema ...
basta fare in modo che se la usb non e' collegata il buffer in tx venga tenuto svuotato in automatico.
La potenza dell'opensource e del Jtag un'opzione che ho voluto mettere a disposizione fin da subito sulla VRBRAIN .


Grande lavoro Enrico

un saluto
Roberto

[xian06]

I tried with usb powered. Old board, 4.0.
But with 3.1.3 do not freezed when serial connect worked.
I see mavlink on putty terminal and after mQ(maybe radio status? m=109) sequence wait 30 sec but led still blinking and continue mavlink.
Without serial connect freezed after 10 mins.

[Bobo67]

Vi allego un interessante screenshot appena ricevuto ...


Enrico e' uno dei pochi che come prima cosa ha sistemato sul suo sdk il Jtag e a riprova che puo' essere molto utile in fase di debug guardate cosa ha scovato ?
Praticamente quando la scheda andava in freeze ed era collegata in usb ci andava perche' il buffer di tx continuava ad aumentare , ma non veniva fatto il flush del tx perchè con la usb scollegata non riusciva a mandare l'heartbeat al mission planner.

Facendo un break e analizzando con il jtag il valore delle variabili del processore ora e' chiaro dove andare a mettere la pezza per risolvere il problema ...
basta fare in modo che se la usb non e' collegata il buffer in tx venga tenuto svuotato in automatico.
La potenza dell'opensource e del Jtag un'opzione che ho voluto mettere a disposizione fin da subito sulla VRBRAIN .


Grande lavoro Enrico

un saluto
Roberto

Bel colpo Enrico, a questo punto potrebbe esser la stessa cosa quando la board non trova la telemetria a terra collegata, forse anche li il buffer di tx continua ad aumentare, si blocca più spesso infatti in quello stato, verificare please!
Bella cosa il debugger sul jtag... dai che ci siamo quasi e voglio tornare in volo!
Dopo 3 ore di test anche la "MPU6000_SCHED" sta ancora girando...

[redfox74]

Questa notte attorno alle 3.00 am io Emile ed Enrico abbiamo testato una patch al codice di gestione della selezione della ubs o della seriale per la telemetria , questa semplice patch consente in modo molto facile e sicuro di passare dalla telemetria da usb a quella via seriale semplicemente attivando o disattivando il canale seriale appoggiato sul driver usb.
Praticamente prima nel codice il driver controllava solo la presenza fisica del connettore usb e re direzionava tutto il traffico di telemetria sul canale usb , senza controllare in modo accurato se il canale seriale verso mavlink fosse aperto o chiuso , la cosa piu' antipatica di questa modalità era che praticamente era impossibile quando si era switchati su usb usare il radio modem per fare dei test di comunicazione.
ora invece semplicemente chiudendo la seriale usb si switcha su quella ttl dove e' collegato il modem .
Questa patch oltre a rendere molto piu' comada la gestione del canale di telemetria in realtà dovrebbe anche evitare che in modo erroneo si cerchi di trasmettere dati sulla usb con il canale virtualmente scollegato.
Evitando quindi la messa in stdby della scheda quando si disattiva il canale usb , problema che prima si vedere accadere in modo sistematico.
Ora appena la patch sarà disponibile potremo verificare il nuovo comportamento e verificare se e' migliorativo.
Questa mattina ho parlato con Emile che e' stato con noi per decidere come implementare anche nella ultima alpha questa modifica , per quanto riguarda il codice girato a Marco sembra non abbiamo avuto piu' segnalazioni di instabilità particolare andiamo avanti con i test e approfittiamo del brutto tempo per continuare i test di affidabilià al banco simulando condizioni reali di volo
un saluto
Roberto

[Draghettofly]

Volo migliorabile?

Per Marco (ma non solo).
Buonasera.
Allego i video del mio volo in Auto di stamattina, cielo coperto e poco vento.
https://www.youtube.com/watch?v=KEdwxyTJxEQ
https://www.youtube.com/watch?v=T8ifeK3O1g8
Chiedo scusa per le riprese che sono piene di "buchi di visibilità" poichè il telefono era fissato ad un piccolo treppiedi sul cofano della macchina.... Non riuscivo a vedere nemmeno quanto campo di volo avevo, cioè l'angolo di copertura dell'immagine. Appena avrò immagini migliori le sostituirò a queste, ovviamente, ma adesso andiamo verso la brutta stagione....
Tuttavia, se avrete un pochino di pazienza, non sfuggiranno all'occhio esperto di Marco (o di altri) eventuali limiti e carenze di settaggio (intendo pid).
Ho il pollice nervosetto, lo so ma talvolta le reazioni del multicoso sembrano ancora un pochino rapide, nonostante sia intervenuto e le abbia certamente migliorate. Può anche essere che vada bene così...fatemi sapere.In pratica vi chiedo una mano per la messa a punto.
Sui wp in Auto sono, cmq, abbastanza soddifatto...e non è poco se ricordo gli sbattimenti di questa estate...
Questi i miei attuali rate (firmw 3.1dev, sistemati con i consigli di Marco):
RATE_PIT_D,0,003
RATE_PIT_I,0,1
RATE_PIT_IMAX,500
RATE_PIT_P,0,14
RATE_RLL_D,0.003
RATE_RLL_I,0.1
RATE_RLL_IMAX,500
RATE_RLL_P,0,14
RATE_YAW_D,0
RATE_YAW_I,0,02
RATE_YAW_IMAX,800
RATE_YAW_P,0,2

STB_PIT_I,0
STB_PIT_IMAX,800
STB_PIT_P,4.25
STB_RLL_I,0
STB_RLL_IMAX,800
STB_RLL_P,4.25
STB_YAW_I,0
STB_YAW_IMAX,800
STB_YAW_P,4.25

Come posso migliorare? Quali mi consigliate di cambiare, in relazione al comportamento del mio multicoso? P mi sembra buono è sui D ed I il problema?
Lo so che non è facile così ma almeno un consiglio me lo potete dare. Poi le decisioni sono sempre personali...
Inoltre sul log del volo alla riga 317 compare un ERR 7 (subsys) e 1 (Ecode) che poi sparisce andando avanti...cos'é?
Qui da me non c'è nessuno che possa aiutarmi. Il lavoro non mi consente deroghe per raggiungere qualche campo di volo, da voi, adesso.
Negli ultimi giorni i problemi di software l'hanno fatta, giustamente, da padroni (sforzi fantastici da parte di molti) ma non dimentichiamoci del volo, che è il fine di tutto...

Attendo con interesse le vostre opinioni.
Grazie. Cordiali saluti.
Carlo

[xian06]

I looking for DJI F550 stock pid settings.
I think F550 a good frame but I have horrible results. Oscillate and instable and FC have problems too. Im very frustrated because I spent 2500$ but not working.



Thanks

[Frame_0]

Inoltre sul log del volo alla riga 317 compare un ERR 7 (subsys) e 1 (Ecode) che poi sparisce andando avanti...cos'é?

ERR 7: GPS failsafe

ECode 1: segnale GPS perso per almeno 5 secondi

[Draghettofly]

@Xian
I'm sorry I can not help Xian. Also I have problems setting. I can read but my English is not enough. Read the post in 1378 by Marco (Bobo67) to set the best drone.
Best regards.

Grazie Frame 0.
Adesso aspetto Marco per eventuali sui pid.
Saluti a tutti.
Carlo