VRBRAIN by VirtualRobotix

[REfuso]

..nuove ma vecchie new..
ho rifatto la sospensione della vr, questa volta usando 2 strati di biadesivo forte della tesa, usato anche x la kk2 con ottime risultati a livello di smorzamento delle vibra. Provato abusivamente al campo di calcio sotto casa mia..non c'era nessuno..
stabilità discreta, in loiter tende a salire e scendere + che trovare una sua quota fissa nel complesso è abbastanza buono, almeno non va giu di testa mettendosi a fare cerchi sempre + larghi.
Ho guardato il log del volo e l' asse X è rimasto al limite, peggiorato pure l' asse z, quello che ha meno problemi è l' asse y..
ritorno a casa e inserisco un terzo strato di tesa e ritorno a provare..questa volta nel mio cortile 3x3mt..quindi solo hovering e un paio di attivazioni in loiter. Mi collego al pc x leggere il nuovo log ma con mia sorpresa mi dice che non ci sono logs....non so bene cosa pensare..dal terminal imposto di nuovo enable log e enable imu, e la risposta oltre ai vari dati che caricherà nei log è "no logs"..non so se nelle precedenti volte fosse venuto fuori questa scritta ..ne so se vuol dire che non ha trovato logs, visto che ultimamente ogni volta che scarico i logs alla fine faccio pulizia..
ripeto l' operazione, torno in cortile, faccio un po di hovering in stabilize poi torno in casa a controllare e quando apro la finestra download logs..fa tutta la solita manfrina e alla fine scrive no log..
ripeto la cosa altre 3\4 volte fino a sentirmi abbastanza deficiente ma i risultati rimangono invariati..no logs..no logs..li mortacci..
...ogni giorno c'è ne una nuova...sono vicino a un punto di non ritorno...

edit: dimenticavo ..dall' ultimo log , quello fatto dopo le modifiche sul sistam d' appoggio della vr il gps è peggiorato tantissimo nel parametro Hdop che prima aveva già vicino al limite a 1.9, ora nell' ultimo log è a 3.71.., ho alzato di 5cm il gps e l'ho messo sopra la vr..mo faccio 2 foto e le posto..

[REfuso]

allego 3 foto della disposizione degli elementi sul frame.
nelle modifiche di oggi ho aumentato la distanza nella verticale tra power board e vr, tolto anche gli ultimi 4 buolloni in metallo che tenevano il coperchio, ora la vr è sopsesa solo su colonnine e bulloni m3 in nylon..

[rino2]

Tieni presente che il GPS per funzionare bene e avere un HDOP buono DEVE essere in campo aperto..... se lo attivi sotto un quadratino di cielo e 4 mura intorno avrai magari anche 8 satelliti ma un HDOP pessimo.....
Facendo una sintesi della sintesi della sintesi... Immagina i satelliti in cielo, se il GPS ne aggancia 8 ma tutti su una stessa linea .... NOTA... trattandosi di volta stellata, la parola LINEA è assolutamente impropria ma rende l'idea.. comunque si dovrebbe parlare di arco di cielo....
Dicevo.... se li becca tutti in linea la sovrapposizione dei dati crea un campo di incertezza molto grande e quindi un HDOP grande (scarsa precisione)... se invece di satelliti il GPS ne prende anche solo 4 ma sui 4 punti cardinali... il campo di incertezza diventa piccolo e quindi DHOP piccolo con maggiore precisione.....
Mi perdonino gli esperti ma ho voluto condensare in poche parole il concetto e spero che così sia capibile....

Inoltre aggiungi che il segnale del satellite può essere fatto rimbalzare da muri, piante, costruzioni.....

Poi naturalmente ci sta anche che il tuo GPS sia farlocco.....

[REfuso]

ciao rino,sempre premuroso, grazie x il supporto,hai frainteso, l' ultimo log di cui parli( dopo non ne ha + fatti) era quello relativo al volo nel campo di calcio che ho sottocasa...100x50mt senza niente sopra e attorno mura di 4mt, il 3x3 mt è il mio cortile..ma come scrivevo dopo quel volo non ho avuto + traccia di logs..
dici che anche queste condizioni (campo di calcio ) possano compromettere in questo modo l Hdop?

Il gps, acquistato da un utente del forum che l' aveva acquistato precedentemente da Roberto con la vr è un 3dr lea6 V 1.1... che non dovrebbe essere farlocco

[REfuso]

allego il log della discussione così si può confrontare con quelli precedenti, poi andando a guardare nella cartella apm\logs ho trovato dopo il log in questione solo tlog che dovrebbero essere relativi ai voli effettuati in cortile..ma xè non ha fatto i log ma solo logs telemetrici.. x me rimane un mistero..

[emile.c]

Forse siamo venuti a capo dei problemi di DraghettoFly... sto apsettando una sua conferma, ma ho trovato nei suoi parametri uno che mi ha lasciato un po' perplesso.
In pratica aveva una declinazione magnetica di 4,1 RADIANTI che in gradi corrisponde a 240°....
in pratica nel planner lui inseriva come valore di declinazione 2.40 (con il punto) il planner però il punto lo interpreta come separatore di migliaia e quindi lo ignora trasformando quindi 240° in radianti -> 4.18

Quindi prestate bene attenzione al parametro inserito e ri-verificate passando da un tab all'altro. Secondo me questo ha generato diversi problemi mai risolti. Non ci credo che tutti hanno messo una virgola quando il planner stesso come esempio usa il punto... oltretuttop non c'è nessun modo per "salvare" il parametro inserito e per farlo salvare bisogna uscire dalla schermatae rientrare...
molto poco furbo come sistema.


Mah, io intanto ho aperto una issue sul sito del MP sperndo che qualche anima pia se ne accorga...

Immaginate la povera VRBRAIN di draghetto che ogni volta che si meteva in loiter aveva il compass girato di 240°... ci credo che gli andava a funghi il quad

Notte!
E.

[emile.c]

Refuso, prova da terminal a fare tet-->eedump e dimmi cosa esce.
Se sono quasi tutti 0 o caratteri alfanumerici va bene. Se sono tutte FE o FF allora potresti avere un problema con la EEPROM.
Tu avevi già avuto un problema con la bussola giusto?
Considera che bussola ed eeprom stanno sullo stesso bus di comuncazione.
Per ora non faccio supposizioni.
Fammi sapere.

E.

allego il log della discussione così si può confrontare con quelli precedenti, poi andando a guardare nella cartella apm\logs ho trovato dopo il log in questione solo tlog che dovrebbero essere relativi ai voli effettuati in cortile..ma xè non ha fatto i log ma solo logs telemetrici.. x me rimane un mistero..

[xian06]

VR Brain will be compatible with : "The flexible PX4 middleware running on the NuttX Real-Time Operating System brings multithreading and the convenience of a Unix / Linux like programming environment to the open source autopilot domain"

[execcr]

VR Brain will be compatible with : "The flexible PX4 middleware running on the NuttX Real-Time Operating System brings multithreading and the convenience of a Unix / Linux like programming environment to the open source autopilot domain"

The processor is almost the same, only few more program space and ram.
Maybe yes.

[execcr]

Volevo usare la funzione relay della VRB (per far andare lo shutter).
Nel codice AP_Relay.cpp ho visto che è mappato al pin 200. A quale pin corrisponde sulla VRB? E' una delle uscite dell'ULN?

Ciao fede

[rino2]

Forse siamo venuti a capo dei problemi di DraghettoFly... sto apsettando una sua conferma, ma ho trovato nei suoi parametri uno che mi ha lasciato un po' perplesso.
In pratica aveva una declinazione magnetica di 4,1 RADIANTI che in gradi corrisponde a 240°....
in pratica nel planner lui inseriva come valore di declinazione 2.40 (con il punto) il planner però il punto lo interpreta come separatore di migliaia e quindi lo ignora trasformando quindi 240° in radianti -> 4.18

Quindi prestate bene attenzione al parametro inserito e ri-verificate passando da un tab all'altro. Secondo me questo ha generato diversi problemi mai risolti. Non ci credo che tutti hanno messo una virgola quando il planner stesso come esempio usa il punto... oltretuttop non c'è nessun modo per "salvare" il parametro inserito e per farlo salvare bisogna uscire dalla schermatae rientrare...
molto poco furbo come sistema.


Mah, io intanto ho aperto una issue sul sito del MP sperndo che qualche anima pia se ne accorga...

Immaginate la povera VRBRAIN di draghetto che ogni volta che si meteva in loiter aveva il compass girato di 240°... ci credo che gli andava a funghi il quad

Notte!
E.

ahahhahahahah... A prescindere che quanto scoperto sia vero o meno.... ritorna valido quanto avevo detto in precedenza... se ricordo bene proprio a Draghetto ma che vale per tutti...... Molto spesso sono le banalita' le cose da controllare e verificare.... Quindi se a una domanda di aiuto chi vi risponde chiede cose che SEMBRANO banali o che avete gia' detto... rispondete... non e'che non vi crede e non mette in dubbio la vostra buona fede.....a volte un punto al posto della virgola fa la differenza...

Rino

[emile.c]

No il pin 200 è un pin che non esiste e il codice skippa la sua inizializzazione.
Purtroppo le uscite non s ono molte, quindi devi sacrificare qualcosa (magari l'ingresso Sonar o un pin dei led).
Se mi contatti via Skype possiamo farci una ragionata.
Penso che la cosa possa servire anche ad altri, quindi mi piacerebbe implementarla.

Emile (manlio su skype)

Volevo usare la funzione relay della VRB (per far andare lo shutter).
Nel codice AP_Relay.cpp ho visto che è mappato al pin 200. A quale pin corrisponde sulla VRB? E' una delle uscite dell'ULN?

Ciao fede

[execcr]

Ok, guardando meglio il codice forse comincio a comprenderlo un pochino di piu (sono comunque un po limitato sotto questo punto di vista...)

Allora mi è venuto in mente ora che in effetti il package del STM32F40x al massimo arriva 176pin...quindi presumo che il 200 sia fittizio o virtuale.

Ergo, la funzione ora è "disattivata".

Per riattivarla, e qua prego qualcuno che me lo confermi, procedo con.

in config.h del codice arducopter libero il pin del led COPTER_LED_1 sull'uln

#elif CONFIG_HAL_BOARD == HAL_BOARD_VRBRAIN
 #define COPTER_LED_1 200  // Motor or Aux LED
 #define COPTER_LED_2 200       // Motor LED or Beeper
 #define COPTER_LED_3 65        // Motor or GPS LED
 #define COPTER_LED_4 200       // Motor or GPS LED
 #define COPTER_LED_5 200       // Motor or GPS LED
 #define COPTER_LED_6 200       // Motor or GPS LED
 #define COPTER_LED_7 200       // Motor or GPS LED
 #define COPTER_LED_8 200       // Motor or GPS LED

In relay.cpp invece inserisco il 102 liberato precedentemente

#if CONFIG_HAL_BOARD == HAL_BOARD_APM1
#define RELAY_PIN 47
#elif CONFIG_HAL_BOARD == HAL_BOARD_APM2 || CONFIG_HAL_BOARD == HAL_BOARD_AVR_SITL
#define RELAY_PIN 13
#elif CONFIG_HAL_BOARD == HAL_BOARD_PX4
#define RELAY_PIN 111
#elif CONFIG_HAL_BOARD == HAL_BOARD_VRBRAIN
#define RELAY_PIN 102
#else
// no relay for this board
#define RELAY_PIN -1
#endif

mmh corretto?

[execcr]

No il pin 200 è un pin che non esiste e il codice skippa la sua inizializzazione.
Purtroppo le uscite non s ono molte, quindi devi sacrificare qualcosa (magari l'ingresso Sonar o un pin dei led).
Se mi contatti via Skype possiamo farci una ragionata.
Penso che la cosa possa servire anche ad altri, quindi mi piacerebbe implementarla.

Emile (manlio su skype)

Post mancato per cinque minuti
Si in effetti si è un po sacrificati, ma rimappando le porte secondo me si possono coprire molti scenari.

Magari una bella expansion board, roberto?

Anche secondo me comunque potrebbe essere molto utile. Ok stasera ti aggiungo su skype (fedecr mi pare. non lo uso da una vita)

ciao

[emile.c]

Bravo, tutto corretto.
Ricorda che però il pin del LED è in realtà una massa pilotata, non è un segnale.
Non sono un esperto ma probabilemte dovrai prendere il positivo dal +5V, ma non sotto il pin del LED che è a 12V.

E.

Ok, guardando meglio il codice forse comincio a comprenderlo un pochino di piu (sono comunque un po limitato sotto questo punto di vista...)

Allora mi è venuto in mente ora che in effetti il package del STM32F40x al massimo arriva 176pin...quindi presumo che il 200 sia fittizio o virtuale.

Ergo, la funzione ora è "disattivata".

Per riattivarla, e qua prego qualcuno che me lo confermi, procedo con.

in config.h del codice arducopter libero il pin del led COPTER_LED_1 sull'uln

#elif CONFIG_HAL_BOARD == HAL_BOARD_VRBRAIN
 #define COPTER_LED_1 200  // Motor or Aux LED
 #define COPTER_LED_2 200       // Motor LED or Beeper
 #define COPTER_LED_3 65        // Motor or GPS LED
 #define COPTER_LED_4 200       // Motor or GPS LED
 #define COPTER_LED_5 200       // Motor or GPS LED
 #define COPTER_LED_6 200       // Motor or GPS LED
 #define COPTER_LED_7 200       // Motor or GPS LED
 #define COPTER_LED_8 200       // Motor or GPS LED

In relay.cpp invece inserisco il 102 liberato precedentemente

#if CONFIG_HAL_BOARD == HAL_BOARD_APM1
#define RELAY_PIN 47
#elif CONFIG_HAL_BOARD == HAL_BOARD_APM2 || CONFIG_HAL_BOARD == HAL_BOARD_AVR_SITL
#define RELAY_PIN 13
#elif CONFIG_HAL_BOARD == HAL_BOARD_PX4
#define RELAY_PIN 111
#elif CONFIG_HAL_BOARD == HAL_BOARD_VRBRAIN
#define RELAY_PIN 102
#else
// no relay for this board
#define RELAY_PIN -1
#endif

mmh corretto?