VRBRAIN by VirtualRobotix

[REfuso]

grazie rino, ripetuta l' operazione ha fatto tutto in un lampo e ha chiuso la finestra senza darmi avvisi di errori..
bene ..speriamo.....oggi vado in campagna a verifcare in volo se ho risolto il problema

[Bobo67]

Per l'incontro di persona, se vuoi venire a Ferrara io dalle 15 in poi sono al campo per prove: 3381060074.
Ciao!

[REfuso]

volentieri faccio un salto, ti chiamo cosi mi dai le indicazioni x raggiungerti..

[cusna]

Problemi di freeze con 3.x.x

Ciao.
sono riuscito a compilare la versione 3.1, gli errori in Eclipse sono solo in fase di verifica del sorgente da parte di Eclipse, ma quando si compila genera il file corretto, grazie Emile per le delucidazioni.
Purtroppo con inserita questa versione di FW (> 2.9) ho continui freeze, magari appena accesa, magari dopo 10 minuti magari rimane armata con i motori al max e non si ferma!
(Fortuna che sto provando senza eliche).
Pensavo fosse un problema di GPS, ho aggiornato la configurazione, ma nulla sempre uguale, si freeza, smette di comunicare con il MP.
Ovviamente ho provato a resettare tutti i parametri, con un erase e anche con un reset da cli, ho ricalibrato, ma spesso si blocca anche durante la calibrazione, smette di comunicare con il cli e si freeza.
Non presentando problemi con la 2.9.2 penso siano da scartare problemi hardware.
Cosa posso fare?
Grazie

[Enrico-viale]

Sicuro che non siano problemi hardware ? ... Hai verificato la memoria? Appena entri nel terminale quali sono le scritte che ti compaiono? Puoi postale qui?

[Enrico-viale]

... Pardon ... Non avevo letto bene ... Con la 2.9 tutto ok ... Quindi si è strano. Ma hai provato a caricare il firmware scaricato direttamente senza compilar telo? Magari e qualche cosa che manca in eclipse.

[Enrico-viale]

Vorrei lanciare un idea che non ho visto implementata da nessuna parte e che mi sembra alla portata della vrbrain.

Non sono sicuro della fattibilitá perché sugli schemi della vrbrain non trovo il pin e non so se è già occupato da un altra periferica.

Espongo:
Leggendo il datasheet del processore della vrbrain vedo che internamente ha un sensore di temperatura connesso in condivisione sul adc1_in16.
Sarebbe carino, visto la delicatezza del fattore temperatura tra l'accensione e il volo, memorizzare la temperatura nel momento di calibrazione per poterla costantemente confrontare durante il volo.
Al di la che si potrebbe tenere una traccia sui log, si potrebbe anche intervenire con un failsafe nel caso venga ad un certo punto riscontrata una differenza notevole.

Roberto, Emile, si può fare?


Enrico

[cusna]

... Pardon ... Non avevo letto bene ... Con la 2.9 tutto ok ... Quindi si è strano. Ma hai provato a caricare il firmware scaricato direttamente senza compilar telo? Magari e qualche cosa che manca in eclipse.

Ciao, grazie della risposta,
stiamo facendo delle prove con Emile, si' ho provato con un DFU già pronto ma freeza lo stesso, domani provo con un' altra VRbrain proprio per non avere nessun dubbio sull' HW.
A domani
Ciao

[xian06]

Ciao.
sono riuscito a compilare la versione 3.1, gli errori in Eclipse sono solo in fase di verifica del sorgente da parte di Eclipse, ma quando si compila genera il file corretto, grazie Emile per le delucidazioni.
Purtroppo con inserita questa versione di FW (> 2.9) ho continui freeze, magari appena accesa, magari dopo 10 minuti magari rimane armata con i motori al max e non si ferma!
(Fortuna che sto provando senza eliche).
Pensavo fosse un problema di GPS, ho aggiornato la configurazione, ma nulla sempre uguale, si freeza, smette di comunicare con il MP.
Ovviamente ho provato a resettare tutti i parametri, con un erase e anche con un reset da cli, ho ricalibrato, ma spesso si blocca anche durante la calibrazione, smette di comunicare con il cli e si freeza.
Non presentando problemi con la 2.9.2 penso siano da scartare problemi hardware.
Cosa posso fare?
Grazie

Same problem here.

[Enrico-viale]

Sto continuando i test sul sonar ... Dopo un oretta buona di debug sulla funzione RangeFinder::read la lettura (returne distance) non ha mai restituito valori superiori ai 10 cm di lettura. (Non so max letto ... Il breakpoint era condizionale e si sarebbe fermato se superava i 10 cm)

Ciò è in conflitto con quanto scritto nel log in cui avevo letture superiori ai 10 metri ... Per cui c'è qualcosa che non va nella funzione di correzione con il beccheggio e rollio ... La funzione sonar funziona bene ...

Continuerò


Enrico

[Draghettofly]

Non sono la persona più adatta per dare consigli. Tuttavia poichè sono il più vicino alle problematicha di Cusna e Xian (credo di aver avuto anch'io un freeze, in volo con la 3.1) qualcosina la dirò lo stesso.
Casomai non porta a nulla, però...hai visto mai.
Credo di aver risolto rifacendo bene le calibrazioni. Niente altro.
Anch'io ho dovuto ripetere tre volte l'acceleromero perchè MP mi dava, ripetutamente, errore. Ho insistito.
Provate, durante le calibrazioni, a staccare tutti i contatti elettrici non indispensabili (esc, led, radio-non se fai la sua calibrazione, ovvio). A volte qualche ritorno o giro di corrente strano...per esempio per qualche cattivo contatto interno che non vedi.
Casomai è una sciocchezza ma provare non costa nulla... e verificate/togliete eventuali fonti elettromagnetiche o magnetiche nelle vicinanze.

A proposito, oggi ho fatto anche RTL. Uno spasso ... funziona. Evviva!
Ciao, Carlo

Enrico ti sto seguendo con interesse. Il sonar mi servirà...poi te ne parlerò.
Ciao

[Enrico-viale]

Meno male che c'è qualcuno a cui interessa! Comunque mi sto avvicinando.
Ho copiato le funzioni di arducopter su un arduino ethernet e ho fatto delle prove ... Con il mio sonar un xl, le letture restituivano un errore massimo di +- un cm ... Ottimo. Lo stesso hardware con la stessa configurazione sulla vrbrain non può restituire dei valori fasulli identici ogni tot tempo ... A cadenze regolari ... Non è un disturbo e inpossibile!

È sicuramente un problema software e piano piano ci arrivo.
Il sonar ha una funzione di lettura che restituisce il valore letto trasformando il voltaggio in ingresso all Adc e scalandolo per convertirlo ai cm reali.

Fino a li ho provato e ci siamo ... I valori sono identici come affidabilità al arduino con cui ho fatto la prova.

Dopo di che il codice prosegue con un po di trigonometria ... Perché se il drone e "piegato" in beccheggio o rollio chiaramente il sonar leggera una distanza più grande perché non punterà perpendicolarmente al terreno ... ... Ok ?

Bene, li c'è qualcosa che non va ... ... Probabilmente, visto che ci devono essere almeno tre letture buone prima di definire una lettura sonar come buona, nei vari "task" ci deve essere un accavallamento o una qualche variabile che si trova con un valore non corretto.

Sto approfondendo ma mi ci vuole un po!
Tra l'altro ho ancora un problema con il debugger ... È qui chiedo aiuto a Roberto, su alcuni file non mi fa mettere i breakpoint dandomeli come irrisolti ... Come se quei file non venissero compilati in versione "debug" . È possibile? Ce qualcosa da cambiare nel linker o nel makefile? Hai idee?


Enrico

[REfuso]

pomeriggio solare a Ferrara...
giornata dove a ho potuto a mani piene assorbire un po ( un po xè i miei neuroni tendono a volatizzare dopo un po le nozioni assorbite) dell' esperienza notevole di Marco , che sento d' obbligo ringraziarlo anche pubblicamente,un grazie x la grande disponibilità e simpatia con cui mi ha accolto e su\sopportato in questo lungo pomeriggio di test al mio AndreX.
Devo dire che il campo volo è proprio bello e super allestito. Vedendo dal vivo il mezzo di Marco mi sono un po sentito con il mio modello sottobraccio, come l' emigrante con la valigia di cartone approdato in america..
Vengo ai problemi del mio quadri..come aveva ipotizzato iniazialmente Marco vedendo il video che avevo postato del volo di ieri in loiter, lo sbalonzolamento era dovuto dal gps non configurato correttamente. Oltre questa causa avevo i pid un po troppo alti x la configurazione del mio quad che ne peggioravano ulteriormente le prestazioni, già che si era li si è messo l' ultimo fw, avevo in questo frame ancora il 3.03rc con cui avevo un buon feeling.
Riconfigurato il gps e abbassato i valori del rate, la prestazione in loiter è prossima alla perfezione.
E' rimasto ancora un problema da risolvere sulla scheda che non mi permette di usarla a pieno regime,dovendo rinunciare per ora a tutte le modalità auto, il magne non ne vuole di essere in linea con la scheda, le abbiamo provate di tutte( sarebbe + corretto ..le ha provate ..) fatto anche il compassmount, ma non c' è stato verso di arrivare a capirne le cause, o meglio si è ipotizzato due possibili cause, un campo magnetico che non si è capito da dove possa scaturire sul frame, l' altra, che ci sia un problema del magne montato sulla scheda. Dopo innumerevoli calibrazioni e modifiche sui valori del magne ci siamo alla fine ritrovati sempre con l' errore iniziale d' angolo del magne che oscillava dai 75 ai 95°..
ho da fare un po di compiti a casa suggeriti da Marco...stanotte si lambicca fino ad ora tarda.. e uno di questi e per verificare se il problema al magne è un problema hw oppure derivante da un campo magnetico " ostile".
La cosa assurda è che in cli il test del magne risultavano perfetti, nessuna divergenza, perfettamente allineato con il nord, appena si usciva dal terminal per verificare sulla mappa del planner e voilà..discrepanze nell' ordine di 75\95°..




.

[redfox74]

Sto continuando i test sul sonar ... Dopo un oretta buona di debug sulla funzione RangeFinder::read la lettura (returne distance) non ha mai restituito valori superiori ai 10 cm di lettura. (Non so max letto ... Il breakpoint era condizionale e si sarebbe fermato se superava i 10 cm)

Ciò è in conflitto con quanto scritto nel log in cui avevo letture superiori ai 10 metri ... Per cui c'è qualcosa che non va nella funzione di correzione con il beccheggio e rollio ... La funzione sonar funziona bene ...

Continuerò


Enrico

Mi pare molto interessante il lavoro che stai facendo ... per quanto riguarda la compensazione termica dei sensori ... io ho gia' fatto un paio di sessioni in camera termica , registrando valori da -20 a + 80 gradi e guardando come si muovono i vari sensori ... se ti interessa ti mando i log.

Attualmente abbiamo fatto una utlity che usa le imu esterne con la vrgimbal e registra tutti i dati sulla sua gui ... ci siamo costruiti un datalogger per calibrare le eeprom che saranno presenti nelle imu gold con tutti i parametri letti in camera termica , poi attraverso l'uso di questi dati le vrbrain non avranno piu' bisogno di fare lo zero ad ogni arm dei motori ... e quindi saranno molto piu' precise in voli prolungati ... con dt termici molto diversi .

[execcr]

Complimenti per tutte le prove e tutti i voli che fate

Io sono da due settimane ancora a terra, cercando di risolvere 1) il problema alla vibrazioni con delle nuove soluzioni (5° iterazione del prototipo, me la prendo comoda causa pochissimo tempo fisico essendo spesso in giro per lavoro,ma sempre al computer)

2) volevo cercare di implementare il comando relay tramite l'uln2003, usando il primo led (LED12 o L2). Ma forse è sopra le mie capacità ehm

Veloce riassunto:
in arducopter/config.h

#define COPTER_LED_1 200 //era 102
 # define CONFIG_RELAY      ENABLED

in libraries/AP_Relay/AP_Relay.cpp

#elif CONFIG_HAL_BOARD == HAL_BOARD_VRBRAIN
#define RELAY_PIN 102

Nessun segno, nel MP non mi tiene nemmeno il valore Relays nella pagina del gimbal, sezione shutter. Cioè se esco e vado per esempio sui PID e torno nella pagina del gimbal, il menu a tendina è vuoto.
Controllo però in advance param list e mi da correttamente il pin del relay (102)

Allora penso che la libreria del relay abbia qualcosa che non va e prendo in prestito il codice di gestione dei led dal main.cpp, per gestire l'uln

#include <AP_HAL.h>
#include <AP_HAL_VRBRAIN.h>
#include "compat.h"
#include "AP_Relay.h"

#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

#define RELAYON           HIGH
#define RELAYOFF          LOW
const AP_Param::GroupInfo AP_Relay::var_info[] PROGMEM = {
    // @Param: PIN
    // @DisplayName: Relay Pin
    // @Description: Digital pin number for relay control. This is normally 47 for the APM1 relay, 13 for the A9 pin on APM2 and 111 for the high power relay pin on the PX4.
    // @User: Standard
    AP_GROUPINFO("PIN",  0, AP_Relay, _pin, RELAY_PIN),

    AP_GROUPEND
};


extern const AP_HAL::HAL& hal;

void digitalWrite(uint8_t pin, uint8_t out) ;
uint8_t digitalRead(uint8_t pin) ;
void pinMode(uint8_t pin, uint8_t output) ;

AP_Relay::AP_Relay(void)
{
    AP_Param::setup_object_defaults(this, var_info);
}


void AP_Relay::init() 
{
//    if (_pin != -1) {
//        hal.gpio->pinMode(_pin, GPIO_OUTPUT);
//        off();
//    }
 if (_pin != -1)   {
     pinMode(_pin, OUTPUT);
     off();
 }
}

void AP_Relay::on() 
{    
//    if (_pin != -1) {
//        hal.gpio->write(_pin, 1);
//    }
    if (_pin != -1){
	digitalWrite(_pin, RELAYON);
    }
}


void AP_Relay::off() 
{
//    if (_pin != -1) {
//        hal.gpio->write(_pin, 0);
//    }

    if (_pin != -1) {
	digitalWrite(_pin, RELAYOFF);
        }
}


void AP_Relay::toggle() 
{
//    if (_pin != -1) {
//        bool ison = hal.gpio->read(_pin);
//        if (ison)
//            off();
//        else
//            on();


    if (_pin != -1) {
            bool ison = digitalRead(_pin);
            if (ison)
                off();
            else
                on();
        }
}

Per compilare, compila (miracolo). Ma comunque non va.

Definizione di "non va": Tester in modalità di misurazione della continuità, 1 polo sul pin l'altro sulla cassa dell'usb, da sempre come valore ~500 (e niente beep).

Ora richiudo il mio povero discovery (per fare le prove dovevo tenerlo smontato) e prego qualche dio riuscire a volare per vedere se ho risolto con le vibrazioni.

(e se no, largo al prototipo 6 )

ciao a tutti!