VRBRAIN by VirtualRobotix

[redfox74]

Oggi pomeriggio riprovata VRBRAIN con GPS Ublox V2
u-Blox CN-06 GPS Receiver V2.0 (suit MultiWii, APM, etc) - Flight Control - RCTimer RC Plane Car MultiRotor APM and MultiWii Carbon Fiber Propeller Hobby Store

Il volo in Stabilize è bello fluido e anche l'Alt HOLD nonostante le vibrazioni sembra funzionare...anche se non è perfetto (penso per le vibrazioni). Ho provato per diverse volte ad attivare LOITER ma dopo un secondo il quad prende una direzione e spedito si allontana e occorre fermarlo prima che scompaia dalla vista.

Smontato il GPS e rimesso sul quad MegaPirateNG. Nuovamente tutto funziona perfettamente (LOITER, RTL, GUIDED, ecc.)....quindi i GPS sono OK.

Allego alcuni log per chi è in grado di leggerli...ma a questo punto, senza la funzionalità GPS, con la VRBRAIN sono praticamente fermo.

Ciao Termic
come stai facendo i test con la telemetria attiva ?
Hai fatto la taratura della radio per settare in modo corretto il center degli stick ?
Altra cosa molto importante la taratura del magnetometro , deve essere fatta per riuscire ad avere un ottimo risultato nel loiter.
La prima taratura se non la fai potrebbe inserirsi overrite del gps hold , quindi praticamente se lui non vede gli stick al centro continua ad aggiornare la posizione.
Mentre il magnetometro se non e' tarato correttamente potrebbe pensare di avere il nord in posizione diversa rispetto a quella in cui e' realmente e quindi sbagliare la correzzione .
Di solito i problemi o sono sul primo o sul secondo step ... anziche' fare la taratura manuale potresti attivare l'auto calibrazione del magnetometro in volo inserendo soltanto la tua declinazione.

In merito al gps ublox non so' cosa usino gli altri come protocollo e come sia configurato quel gps ma noi usiamo ublox in binario a 38400 , mi pare di capire pero' che la posizione sul planner la vedi corretta .... anche il nord e' al posto giusto ?

Altra cosa se hai la telemetria attiva il numerello che ti definisce la distanza dal punto di loiter che fa' quando inserisci il loiter aumenta o rimane basso come valore ?

Ora non ho sottomano il mio pc con il planner sono fuori ... piu' tardi guardo il log e cerco di capire dove sia l'inghippo ...

un saluto
Roberto

[pragamichele]

termicone
non hai ancora capito?
le schede sono configurate per tornare a casa di chi te le ha vendute
così la stessa scheda la possono vendere più volte e ci guadagnano anche motori, regolatori, ecc..
sto scherzando ovviamente

[TermicOne]

Magnetometro!

RedFox: 1 - TermicOne: 0

Senza grosse speranze ho rifatto la taratura manuale del magnetometro con la declinazione magnetica di Milano e la simpatica danza del quad. Ora con il GPS V1 con antenna piccola il Loiter funziona!!! Stasera per celebrare l'avvenimento posterò un piccolissimo video.

C'è ancora parecchio da fare:
- sistemare un pochino i PID (per limitare i traballamenti)
- togliere le vibrazioni (ancora importanti)

...ma ora possiamo iniziare veramente a giocare!

Grazie ancora a Emile e Roberto per il loro costante supporto!

Luciano

[TermicOne]

VRBRAIN - Maiden flight

Primo volo con GPS nel giardino davanti a casa.
Il quad è un vecchio muletto APMQ dedicato ai test.
Motorelli cinesi da 8 dollari e ESC Turnigy Plush rigorosamente NON flashati.
PID di default. Tenuta della posizione e della quota direi buona nonostante un pochino di brezza e vibrazioni sulla scheda ancora da sistemare.

Luciano

NB
Sono tutti buoni a far volare bene quad o esa con motori da 50 dollari l'uno ed eliche in carbonio superlusso. Il vero test è far volare bene questo quadricoso APMQ (A Poor Man's Quad) ...

[TermicOne]

Configurazione GPS

Piccola segnalazione sulla configurazione automatica del GPS da parte di Arducopter32 su VRBRAIN

Durante il boot MegaPirateNG configura automaticamente il GPS impostando la velocità della porta seriale (default 38.400), il protocollo (normalmente UBLOX) e il rate (5Hz).

Arducopter32 su VRBRAIN invece mi sembra di capire che configuri il GPS solo per la velocità della seriale a 38.400 e protocollo (UBLOX) mentre non configura il rate. Se quindi si connette un GPS impostato in fabbrica a 1 Hz esso continua a lavorare a 1 Hz ....e a 1 Hz la posizione non viene tenuta assolutamente.

Il problema non è grave perchè i nuovi GPS arrivano settati a 5 Hz ma lo segnalo ugualmente perchè ci sono in giro ancora dei GPS UBLOX che, come il mio, sono di default a 1 Hz e soprattutto non hanno una eeprom e non mantengono la configurazione (vecchio problema già rilevato su MultiWii). Dopo un po' di ore tutto si resetta alla configurazione di default (9600, NMEA, 1 Hz). Nel mio caso il vecchio GPS ieri funzionava perfettamente perchè nei vari tentativi (prima della ricalibrazione del magnetometro) lo avevo forzato a 5 Hz con Ucenter. Oggi il GPS non teneva più la posizione e anche in Mission Planner nel test GPS si poteva rilevare che il colloquio era lentissimo (circa 1 frame al secondo). Riconfigurato con Ucenter il colloquio è a 5 Hz (come con MegaPirate) Ora metto il vecchio GPS su MegaPirateNG e il nuovo (che ha la eeprom) su VRBRAIN in modo da continuare le prove.

Luciano

[redfox74]

Piccola segnalazione sulla configurazione automatica del GPS da parte di Arducopter32 su VRBRAIN

Durante il boot MegaPirateNG configura automaticamente il GPS impostando la velocità della porta seriale (default 38.400), il protocollo (normalmente UBLOX) e il rate (5Hz).

Arducopter32 su VRBRAIN invece mi sembra di capire che configuri il GPS solo per la velocità della seriale a 38.400 e protocollo (UBLOX) mentre non configura il rate. Se quindi si connette un GPS impostato in fabbrica a 1 Hz esso continua a lavorare a 1 Hz ....e a 1 Hz la posizione non viene tenuta assolutamente.

Il problema non è grave perchè i nuovi GPS arrivano settati a 5 Hz ma lo segnalo ugualmente perchè ci sono in giro ancora dei GPS UBLOX che, come il mio, sono di default a 1 Hz e soprattutto non hanno una eeprom e non mantengono la configurazione (vecchio problema già rilevato su MultiWii). Dopo un po' di ore tutto si resetta alla configurazione di default (9600, NMEA, 1 Hz). Nel mio caso il vecchio GPS ieri funzionava perfettamente perchè nei vari tentativi (prima della ricalibrazione del magnetometro) lo avevo forzato a 5 Hz con Ucenter. Oggi il GPS non teneva più la posizione e anche in Mission Planner nel test GPS si poteva rilevare che il colloquio era lentissimo (circa 1 frame al secondo). Riconfigurato con Ucenter il colloquio è a 5 Hz (come con MegaPirate) Ora metto il vecchio GPS su MegaPirateNG e il nuovo (che ha la eeprom) su VRBRAIN in modo da continuare le prove.

Luciano

Ciao Luciano,
mi sembra una valutazione interessante , in realtà sei uno dei pochi che non usa il gps standard che noi utilizziamo di solito che e' il 3dr ublox 6h . In quel caso i gps sono gia' inizializzati di fabbrica , comunque e' interessante verificare con le diverse opzioni disponibili sul mercato cinese cosa succede e mi pare che sia gia' un bel passo avanti che con la corretta configurazione seppur manuale tutto funge come da attese.
Sarebbe interessante nella documentazione indicare in modo chiaro che tipo di configurazioni sono necessarie e se sono salvate in eeprom oppure no' ... nel secondo caso penso serva fare una modifica al driver per forzare ad ogni accensione la corretta configurazione ...

AP_GPS_UBLOX::_configure_gps(void)
{
struct ubx_cfg_nav_rate msg;
const unsigned baudrates[4] = {9600U, 19200U, 38400U, 57600U};
FastSerial *_fs = (FastSerial *)_port;

// the GPS may be setup for a different baud rate. This ensures
// it gets configured correctly
for (uint8_t i=0; i<4; i++) {
_fs->begin(baudrates[i]);
_write_progstr_block(_fs, _ublox_set_binary, _ublox_set_binary_size);
//while (_fs->tx_pending()) delay(1);
}
_fs->begin(38400U);

// ask for navigation solutions every 200ms
msg.measure_rate_ms = 200;
msg.nav_rate = 1;
msg.timeref = 0; // UTC time
_send_message(CLASS_CFG, MSG_CFG_RATE, &msg, sizeof(msg));

// ask for the messages we parse to be sent on every navigation solution
_configure_message_rate(CLASS_NAV, MSG_POSLLH, 1);
_configure_message_rate(CLASS_NAV, MSG_STATUS, 1);
_configure_message_rate(CLASS_NAV, MSG_SOL, 1);
_configure_message_rate(CLASS_NAV, MSG_VELNED, 1);

// ask for the current navigation settings
Debug("Asking for engine setting\n");
_send_message(CLASS_CFG, MSG_CFG_NAV_SETTINGS, NULL, 0);
}

Questa e' l'attuale routine di configurazione bisogna capire se venga accettata oppure no da tutte le tipologie di gps ublox testati ... l'invio del messaggio ogni 200 ms dovrebbe corrispondere ai 5 hz cosi' a prima vista almeno ...

Questo e' il link nel codice master :
AP_GPS_UBLOX.cpp - vrbrain - VitualRobotix VRBrain repository - Google Project Hosting


Saluti
Roberto

[QuercusPetraea]

Ciao Luciano,
mi sembra una valutazione interessante , in realtà sei uno dei pochi che non usa il gps standard che noi utilizziamo di solito che e' il 3dr ublox 6h . In quel caso i gps sono gia' inizializzati di fabbrica , comunque e' interessante verificare con le diverse opzioni disponibili sul mercato cinese cosa succede e mi pare che sia gia' un bel passo avanti che con la corretta configurazione seppur manuale tutto funge come da attese.
Sarebbe interessante nella documentazione indicare in modo chiaro che tipo di configurazioni sono necessarie e se sono salvate in eeprom oppure no' ... nel secondo caso penso serva fare una modifica al driver per forzare ad ogni accensione la corretta configurazione ...

AP_GPS_UBLOX::_configure_gps(void)
{
struct ubx_cfg_nav_rate msg;
const unsigned baudrates[4] = {9600U, 19200U, 38400U, 57600U};
FastSerial *_fs = (FastSerial *)_port;

// the GPS may be setup for a different baud rate. This ensures
// it gets configured correctly
for (uint8_t i=0; i<4; i++) {
_fs->begin(baudrates[i]);
_write_progstr_block(_fs, _ublox_set_binary, _ublox_set_binary_size);
//while (_fs->tx_pending()) delay(1);
} // _ublox_set_binary
_fs->begin(38400U);

// ask for navigation solutions every 200ms
msg.measure_rate_ms = 200;
msg.nav_rate = 1;
msg.timeref = 0; // UTC time
_send_message(CLASS_CFG, MSG_CFG_RATE, &msg, sizeof(msg));

// ask for the messages we parse to be sent on every navigation solution
_configure_message_rate(CLASS_NAV, MSG_POSLLH, 1);
_configure_message_rate(CLASS_NAV, MSG_STATUS, 1);
_configure_message_rate(CLASS_NAV, MSG_SOL, 1);
_configure_message_rate(CLASS_NAV, MSG_VELNED, 1);

// ask for the current navigation settings
Debug("Asking for engine setting\n");
_send_message(CLASS_CFG, MSG_CFG_NAV_SETTINGS, NULL, 0);
}

Questa e' l'attuale routine di configurazione bisogna capire se venga accettata oppure no da tutte le tipologie di gps ublox testati ... l'invio del messaggio ogni 200 ms dovrebbe corrispondere ai 5 hz cosi' a prima vista almeno ...

Questo e' il link nel codice master :
AP_GPS_UBLOX.cpp - vrbrain - VitualRobotix VRBrain repository - Google Project Hosting


Saluti
Roberto

I moduli GPS ublox lea-6 e neo-6 sono sostanzialmente identici come funzionalità e sensibilità, tant'è che il manuale con le specifiche del protocollo è lo stesso per entrambi. L'unica differenza sostanziale tra i due è che il lea-6h è "Galileo ready" con un aggiornamento specifico del firmware.

Ho dato un'occhiata al codice e sembrerebbe che il GPS, all'accensione della FCB, venga inizializzato per lavorare a 38400 baud inviando un messaggio a varie velocità per intercettare quella corretta.
Nel codice AP_GPS_UBLOX::init(enum GPS_Engine_Setting nav_setting) viene chiamata la funzione _configure_gps():

void
AP_GPS_UBLOX::_configure_gps(void)
..
..
..
    struct ubx_cfg_nav_rate msg;
     //possibili baudrate
    const unsigned baudrates[4] = {9600U, 19200U, 38400U, 57600U};
    FastSerial *_fs = (FastSerial *)_port;

    // the GPS may be setup for a different baud rate. This ensures
    // it gets configured correctly
    for (uint8_t i=0; i<4; i++) {
// invia il messagio di set per ogni baudrate indicato in baudrates[4]
        _fs->begin(baudrates[i]);
/* il messaggio forza il modulo a lavorare a 38400 e la definizione è in AP_GPS_UBLOX.h
#define UBLOX_SET_BINARY "$PUBX,41,1,0003,0001,38400,0*26\n\265\142\006\001\003\000\001\006\001\022\117" */
         _write_progstr_block(_fs, _ublox_set_binary, _ublox_set_binary_size);
        //while (_fs->tx_pending()) delay(1);
    } 
// inizializzato il modulo, si procede con il set definitivo  della seriale a 38400
    _fs->begin(38400U);

Subito dopo il codice imposta il rate a 200ms inviando il relativo messaggio di configurazione:

   // ask for navigation solutions every 200ms
    msg.measure_rate_ms = 200;
    msg.nav_rate        = 1;
    msg.timeref         = 0;     // UTC time
    _send_message(CLASS_CFG, MSG_CFG_RATE, &msg, sizeof(msg));

Quindi, se ciò che ho capito è corretto, il GPS dovrebbe essere inizializzato ad ogni avvio di AC32.
Perchè poi non funzioni a Luciano resta un quesito aperto.

[TermicOne]

Grazie a tutti del supporto. Il problema è relativo solo al GPS CN-06 Ublox V1 con il V2 tutto OK. Non penso che valga la pena perderci del tempo. Scriveremo nella documentazione che non bisogna usare quel GPS. Lo userò solo su MegaPirateNg dove invece viene configurato correttamente.

I test procedono: per avere una situazione calma e senza vento sono andato un'oretta al campetto stamattina.

Ho provato brevemente le varie funzioni di volo automatico che ho utilizzato con successo con MegaPirateNg sul medesimo quad:
- auto take off
- auto mode con piccole missioni
- auto land al termine della missione
- RTL con loiter a 2 m
- RTL con auto land
- guided mode con invio target e comandi da android via radio modem
- follow me con android

Direi che funziona tutto. Non ho guardato tanto la precisione della posizione e della quota perchè per ora mi interessava verificare solo la funzionalità.

Solo tre temi da approfondire mi sono saltati all'occhio:

- l'auto take off funziona solo se attivo i motori al minimo in stabilize. Partendo con i motori fermi si ribalta

- durante il volo automatico (auto, guided, rtl, follow me) il quad non gira la prua verso il prossimo waypoint ma rimane orientato sempre nella posizione di decollo (da capire se c'è qualche parametro o se occorre fare qualche define nel codice)

- nel volo automatico, anche in assenza di vento, spesso il modello non rimane sulla linea retta per raggiungere direttamente l'obiettivo ma compie un'ampia curva e a volte in RTL fa un giretto intorno alla home prima di atterrare.

Magari oggi vedo se riesco a rifare le prove con calma e a registrare qualche log.

Forse il problema più significativo è il secondo perchè non è bello vedere il modello che va a spasso senza girare la faccia verso l'obiettivo.

Grazie ancora a tutti!

Luciano

[QuercusPetraea]

Aggiunta rispetto a quanto detto prima.
Visto che con MPNG il neo-6m funziona, ho verificato il codice relativo (anche in arducopter-mega) ed ho rilevato questa differenza che non mi sembra da poco

Arducopter-mega:

// the GPS may be setup for a different baud rate. This ensures
    // it gets configured correctly
    for (uint8_t i=0; i<4; i++) {
        _port->begin(baudrates[i]);
        _write_progstr_block(_port, _ublox_set_binary, _ublox_set_binary_size);
        while (_port->tx_pending()) {
          hal.scheduler->delay(1);
        }

AC32:

 // the GPS may be setup for a different baud rate. This ensures
    // it gets configured correctly
    for (uint8_t i=0; i<4; i++) {
        _fs->begin(baudrates[i]);
        _write_progstr_block(_fs, _ublox_set_binary, _ublox_set_binary_size);
 //La linea successiva è invece commentata nel codice
        //while (_fs->tx_pending()) delay(1);

Nel codice AC-mega si attende che il dato venga trasmesso e si fa un delay di 1(ms?), in AC32 no.
Ci sono differenze nella gestione delle seriali tra STM32 e 2560?

[QuercusPetraea]

Grazie a tutti del supporto. Il problema è relativo solo al GPS CN-06 Ublox V1 con il V2 tutto OK. Non penso che valga la pena perderci del tempo. Scriveremo nella documentazione che non bisogna usare quel GPS. Lo userò solo su MegaPirateNg dove invece viene configurato correttamente.

[snip]

Luciano

Questo confermerebbe le mie osservazioni sul codice, magari Roberto od Emile possono confermarlo o meno, che essendo il V2 già impostato su eeprom a 38400/5Hz questi funziona a prescindere dalle inizializzazioni, mentre il V1 ha necessità di essere inizializzato.

Passato il mal di schiena, ho messo insieme un frame Arducopter originale ed ho montato la VRBRAIN in sospensione su moongel (anzi, spacegel) e fissata con elastici. Al banco sembra funzionare tutto, GPS, telemetria, magnetometro ecc.
Se questo fine settimana il tempo fa il bravo si vedrà come si comporta.

[REfuso]

ciao Luciano, ti rispondo velocemente xè sto correndo al trabako..
sulla questione della prua nel volo auto, con l' ultima versione fw il multi mantiene la prua nella direzione impostata prima di passare in una modalità di volo auto. Nella ver. 2.9.1.1 invece la prua seguiva la direzione del multi.

[redfox74]

Grazie a tutti del supporto. Il problema è relativo solo al GPS CN-06 Ublox V1 con il V2 tutto OK. Non penso che valga la pena perderci del tempo. Scriveremo nella documentazione che non bisogna usare quel GPS. Lo userò solo su MegaPirateNg dove invece viene configurato correttamente.

I test procedono: per avere una situazione calma e senza vento sono andato un'oretta al campetto stamattina.

Ho provato brevemente le varie funzioni di volo automatico che ho utilizzato con successo con MegaPirateNg sul medesimo quad:
- auto take off
- auto mode con piccole missioni
- auto land al termine della missione
- RTL con loiter a 2 m
- RTL con auto land
- guided mode con invio target e comandi da android via radio modem
- follow me con android

Direi che funziona tutto. Non ho guardato tanto la precisione della posizione e della quota perchè per ora mi interessava verificare solo la funzionalità.

Solo tre temi da approfondire mi sono saltati all'occhio:

- l'auto take off funziona solo se attivo i motori al minimo in stabilize. Partendo con i motori fermi si ribalta

- durante il volo automatico (auto, guided, rtl, follow me) il quad non gira la prua verso il prossimo waypoint ma rimane orientato sempre nella posizione di decollo (da capire se c'è qualche parametro o se occorre fare qualche define nel codice)

- nel volo automatico, anche in assenza di vento, spesso il modello non rimane sulla linea retta per raggiungere direttamente l'obiettivo ma compie un'ampia curva e a volte in RTL fa un giretto intorno alla home prima di atterrare.

Magari oggi vedo se riesco a rifare le prove con calma e a registrare qualche log.

Forse il problema più significativo è il secondo perchè non è bello vedere il modello che va a spasso senza girare la faccia verso l'obiettivo.

Grazie ancora a tutti!

Luciano

Ciao Luciano,
il tema di da che parte giri il muso il drone durante le funzioni automatiche e' configurabile nel config.h ... forse sarebbe meglio inserirlo come parametro nel mission planner , ma nell'attuale versione di codice "ufficiale" e' cablato nel config e va riconfigurato .
Anche a me piace di piu' con il muso che ruota , mi da' l'idea di comprendere molto meglio quello che sta' facendo ... in realtà su richiesta di robustini abbiamo attivato la funzione di blocco della prua ... perche' dai test che ha effettuato specialmente in applicazioni di fotogrammetria e' migliore come approccio generale , si riesce ad essere piu' precisi .

Per quanto concerne le altre impostazioni , per migliorare la qualità del crosstrack puoi cambiare il PID oppure devi litigare ancora un attimo con la taratura del magnetometro.
Ti consiglio di attivare la funzione di calibrazione automatica ... farti un voletto e riprovare per vedere se con quel tipo di calibrazione va meglio.

In merito ai PID sono diversi da quelli di MegaPirate o APM perche' il nostro ciclo di loop e' molto piu' veloce ... quindi hanno significati diversi.

Fondamentalmente il vantaggio di avere una cpu piu' capiente e piu' veloce e' che da un lato non ci sono situazioni in cui il drone sovraccaricato da operazioni a comportamenti anomali e diversi da quelli attesi ... cioe' nel ciclo di vita la cpu riesce a servire tutti i task andando a 168 mhz anziche' a 16 cosa che in realta' non avviene ne in mega pirates ne in apm.
E dall'altro canto c'e' molto spazio per evoluzioni future attualmente dal punto di vista della cpu stiamo impiegando il 25 % delle risorse di memoria ... 250 kbyte su 1 mega e molto meno sulla ram 16 kbyte su 192 kbyte .
La cpu in questo momento e' impiegata solamente al 20 % contro il 95 % di un apm .

Attualmente stai testando la versione 2.9.2 che e' la versione basata sulle prime librerie di compatibilità che abbiamo realizzato negli ultimi 2 anni di lavoro .

Nella versione 3.0 che e' ormai allineata alla rc5 c'e' invece tutta la nuova implementazione che si basa sulle AP_HAL che e' la libreria dedicata allo sviluppo multi processore che ti consente di rendere indipendente l'applicazione dall'hardare .

Changes - vrbrain - VitualRobotix VRBrain repository - Google Project Hosting

Questa versione e' allineata alla versione 3.0rc5 di apm con gli ovvi vantaggi del 32 bit e della velocità di calcolo .
I test inizieranno a breve ... quindi preparati li ci sarà un po' piu' di attività di beta testing di quelle "CAZZUTE" come si dice in gergo essendo un po' tutto nuovo ...

Cmq i principali vantaggi dei driver implementati su ap_hal saranno :

Un nuovo driver di gestione della radio in input che ci dovrebbe permettere di utilizzare anche le riceventi HS o frsky senza andare a ricompilare codici ad hoc .... inoltre il driver supporta la configurazione PPM - PPMSUM attraverso l'applicazione di un jumper live senza bisogno di ricompilare il codice o montare un firmware ad hoc.

L'uso diffuso del DMA nella comunicazione di tipo i2c.

L'uso diffuso del interrupt sulla seriale in tx che ci evita latenze inutili.

Il supporto della usb contemporanamente alla seriale per la comunicazione mavlink .

il supporto degli ingressi analogici e sulla versione 4.5 sia la lettura della vbatt ( gia' disponibile sulla v 4.0 ) che della corrente ( solo sulla 4.5) .

A livello di driver non ricordo altro per ora se Emile vuole integrare benvenga.

Per il resto nella revisione 3.0 ci sono tante novità specialmente per il controllo inerziale del dorne sui 3 assi ... a cui dedicheremo presto un blog post specifico.

Tema molto importante con la versione 3.0 e le AP_HAL , supportiamo anche il software arduplane per il controllo di aerei con la VR Brain e il software ArduRover e Boat.

Un saluto
Roberto

[TermicOne]

Grazie Roberto. ..ottime notizie!

...non vedo l'ora di vedere tutte queste novità!

Per sistemare l'orientamento dovrei modificare il config.h e ricompilare ...ma occorrerebbe avere il source con la modifica frsky ...oppure attendiamo la prossima versione dove il problema frsky dovrebbe essere risolto!

Grazie ancora per il supporto!

Luciano

NB
Con l'attuale versione è già disponibile la rilevazione della tensione batterie e la trasmissione in telemetria? Se fosse disponibile dove si collega la tensione da rilevare?

[redfox74]

Grazie Roberto. ..ottime notizie!

...non vedo l'ora di vedere tutte queste novità!

Per sistemare l'orientamento dovrei modificare il config.h e ricompilare ...ma occorrerebbe avere il source con la modifica frsky ...oppure attendiamo la prossima versione dove il problema frsky dovrebbe essere risolto!

Grazie ancora per il supporto!

Luciano

NB
Con l'attuale versione è già disponibile la rilevazione della tensione batterie e la trasmissione in telemetria? Se fosse disponibile dove si collega la tensione da rilevare?

http://vrbrain.files.wordpress.com/2013/01/vrbrain.png

Si e' gia' disponibile vedi i pin sulla sinistra dove vedi 10 11 12 il pin centrale e' l'input del voltage lipo che uln2003 usa assieme alla massa per poi accendere buzzer e led.

Basta che colleghi la lipo li e attivi da mission planner , nella telemetria poi ti ritrovi tutto.

Saluti
Roberto

[TermicOne]

Battery Monitor

Collegata tensione batteria all'input "Lipo Voltage" del piedino 12 e fatta la calibrazione da Mission Planner ora abbiamo anche la tensione batteria in telemetria senza necessità di sensore AttoPilot come in MegaPirateNG (non mi interessa il sensore di corrente).

Ottimo!

Aggiornata immagine del pin out: