3DR Pixhawks

[mikronerd]

oggi pomeriggio sono riuscito a fare il collaudo ed è andato tutto bene
i pid li sentivo molto lenti, però il modello sembrava piuttosto fermo in aria
c'è ancora molto da fare perchè c'erano lente oscillazioni, soprattutto su YAW che ballava continuamente
questo il log che ho preso dalla sd card, si riesce a capire qualcosa per la coda?
forse problema del compass?
dal pulsante log analyzer esce fuori "Test: Compass = FAIL - Large change in mag_field (79.68%)"
devo fare la calibrazione compass motor?
https://www.dropbox.com/s/h9u8hec7p25nwy3/1.log

ho dato un occhio al log, non sono molto esperto ma mi piace confrontare i parametri ed i grafici, secondo me hai i pid lenti perchè hai settato il rate_pitch_roll_P troppo basso.
ma vedo che sei atterrato parecchie volte, ogni volta modificavi i pid ?
per il posto dove hai volato, mi sembra molto strano che per i primi 29 minuti hai HDOP a 2.5 e poi solo dopo il 29 minuto è sceso a 1.9
il gps è come nella foto, attaccato al frame ?
Hai fatto anche il log da telemetria ?
per lo yaw non saprei, ma con i pid default come vola ?
Visto che hai volato solo in stabilize, il magnetometro non entra in funzione e quindi non dovrebbe incidere. le vibrazioni sono perfette, non ti è venuta vollia di provare un althold ?


Ciao - Giuseppe

[-RsX-]

si eccolo, l'ho trovato
https://www.dropbox.com/s/qhsniskhqw...2018-16-58.rar
fino al 30% del log non succede niente di particolare, stavo lottando con il gas invertito che non mi faceva inizializzare la scheda e poi ho settato il THR_MIN perchè 2 motori partivano e 2 no, sono esc DJI
ho impostato il telaio V e ho iniziato da pid trovati in rete di un altro discovery
mi sono trovato male perchè erano davvero bassi e non riuscivo neanche a decollare



questi ultimi sono i pid dopo diversi tentativi, che sono tutti gli atterraggi che si vedono nel log dove andavo al portatile e cambiavo i parametri tramite telemetria
adesso noto che ho lasciato lo stabilize yaw basso e magari dipendeva da questo che non si stabilizzava se mi dici che il compass non era in funzione
comunque stavo pensando che tutti quei cavi dei motori possono dare fastidio al compass, mi sa che per la prossima prova li taglierò
da dove si vede nei log se il compass è disturbato dai motori?
pitch e roll li ho riportati più o meno ai valori default che ricordavo e già volava meglio
si il gps è attaccato al frame, la parte superiore è solo vetronite
che valori dovrebbe dare il gps?
ho volato solo in stabilize e non mi è venuta voglia di provare altro perchè non riuscivo a far stare fermo lo yaw
piccoli passi, è abbastanza complicato e già oggi ero piuttosto in confusione con tutti questi parametri

[mikronerd]

l'interferenza del compass la vedi così:
questo è il tuo grafico magfiled relazionato con throttle.


se leggi il wiki qui, che spiega molto bene l'analisi dei log
common-Diagnosing problems using Logs | ArduCopter
ti accorgi che hai un'interferenza abbastanza alta, ma non così preoccupante.
potresti risolvere mettendo l'asticella tipo DJI, e facendo il compassmot.
Per lo yaw io ti consiglio di ricominciare con i parametri default ed iniziare cambiando solo il rate_P, e poi testare il barometrico con althold, per vedere se mantiene bello cazzutto l'altitudine.

Ciao - Giuseppe

si eccolo, l'ho trovato
https://www.dropbox.com/s/qhsniskhqw...2018-16-58.rar
fino al 30% del log non succede niente di particolare, stavo lottando con il gas invertito che non mi faceva inizializzare la scheda e poi ho settato il THR_MIN perchè 2 motori partivano e 2 no, sono esc DJI
ho impostato il telaio V e ho iniziato da pid trovati in rete di un altro discovery
mi sono trovato male perchè erano davvero bassi e non riuscivo neanche a decollare



questi ultimi sono i pid dopo diversi tentativi, che sono tutti gli atterraggi che si vedono nel log dove andavo al portatile e cambiavo i parametri tramite telemetria
adesso noto che ho lasciato lo stabilize yaw basso e magari dipendeva da questo che non si stabilizzava se mi dici che il compass non era in funzione
comunque stavo pensando che tutti quei cavi dei motori possono dare fastidio al compass, mi sa che per la prossima prova li taglierò
da dove si vede nei log se il compass è disturbato dai motori?
pitch e roll li ho riportati più o meno ai valori default che ricordavo e già volava meglio
si il gps è attaccato al frame, la parte superiore è solo vetronite
che valori dovrebbe dare il gps?
ho volato solo in stabilize e non mi è venuta voglia di provare altro perchè non riuscivo a far stare fermo lo yaw
piccoli passi, è abbastanza complicato e già oggi ero piuttosto in confusione con tutti questi parametri

[mikronerd]

Dunque, è vero, la Pixhawk attualmente la abbiamo tre gatti in tutta Italia, almeno quelli che scriviamo qui e ci confrontiamo e condividiamo, io l'ho acquistata convinto di prendere il miglior sistema UAV-RC esistente in commercio, in termini di prestazioni e rapporto qualità prezzo, (stesso pensiero per la VrBrain che reputo meno plug and play per gli end user ma di pari livello).
inoltre ad oggi, dopo una trentina di voli avendola smaneggiata, e per le mie esigenze di aspirante modellista, nonostante qualche problemino, sono ancora convinto di avere tra le mani un sistema potente, versatile, che ti dà l'impressione di controllo totale quando sei in volo.

Questa è la premessa con i biscotti :
Ora il bastone :

l'altra faccia della medaglia invece è che nell'interfacciamento con "l'esterno", intendo ovviamente gli esc, sto vedendo confusione e ancora pochi elementi per risolvere i problemi, anche se sono convinto che la 3DRobotics ci sta lavorando senza fare troppa pubblicità, perchè mi rendo conto che non conviene sbandierare in giro che molti esc hanno problemi di sync se interfacciati con la Pixhawk, perchè chi non ha ancora deciso di acquistarla, leggendo di questi problemi semplicemente non l'acquisterà.
Per carità il problema è degli esc, non certamente della Pixhawk, allora ho proposto nel forum ufficiale di stilare una sorta di "compatible list", come quella creata a suo tempo per la Naza, per capire quali sono gli esc che realmente funzionano senza problemi di sync, ground, rate refresh, con la Pixhawk.
Ebbene prima mi viene risposto di usare i loro esc, (nello store hanno un unico modello a 20a alimentabile fino 4s), poi mi viene risposto che è una grande idea quella della lista del wiki, è che se voglio posso essere il primo a stilarla.
mmhhmm, io che sono un end end end user, e non posseggo neanche un oscilloscopio, appartengo a quella categoria di utenti che dovrebbero consultare la lista proprio perchè utilizzatori finali, non appartengo a quelli in grado di stilarla, quindi rispondo che la lista, (visto che è stata accolta come una grande idea) potrebbe essere iniziata proprio dai developer e tester che ogni giorno spremono l'hardware ed i firmware alla ricerca di bug. Chi meglio di loro possono dirci oggi, a noi malati di multirotorite e di egisto,, quali esc secondo i loro test non hanno mai dato problemi ?
E non è uno scarica barile, perchè basta dire "amici miei, io oggi ho fatto acro - auto - loiter - flip - sport - hibrid - con e senza payload - con questo firmware e questi motori, secondo me vanno bene,. non si sono piantati, però se poi si piantano a voi che utilizzate altre configurazioni, sono cavoli vostri - patti chiari - amicizia lunga.."
Mi rendo altresì conto che la 3drobotics non è che si mette lì a comprare 20/30 tipi di esc ed a fare analisi di laboratorio ed empiriche per vedere quali non creano problemi con la Pixhawk, però ad esempio, ad oggi non si capisce ancora se sta benedetta spinetta del negativo del segnale PWM si deve inserire o no, ci sono due linee di pensiero, quella attuale di 3drobotics (anche del wiki) che dice che non va messo per non creare pericolosi loop, e l'altra linea di pensiero ad esempio qui ESCs / Motor Controllers - PX4 Autopilot Platform
che dice che va messa obbligatoriamente per un corretto pilotaggio dei segnali pwm.
Quindi prima domanda all'unico interessato nostrano: Maaaarco, la linea ufficiale della 3drobotics è sempre quella della "non spinetta ground" ? Ci potrebbe essere un ripensamento in merito ?
Altra domanda ad altro interessato nostrano: Robeeeerto, con VrBrain come vi state orientando in questo senso ? anche se l'hardware della VrBrain è diverso dalla Pixhawk e così anche sicuramente la distribuzione dei ground sul PCB, cosa ne pensate degli esc.
Leggo nel 3d di riferimento VrBrain, ed è già qualcosa, che molti dei test li fate con gli F30 e che non vi hanno mai creato problemi. OK, invece a 6s cosa posso usare ? F40 ?
Leggevo che anche questi possono creare qualche problema con la Pixhawk, se non con il firmware "settembre 2012", che faccio, tolgo gli Afro e rimetto gli F40 ?
ma sta spinetta ground la metto o no ?
io sono un giovane utilizzatore senza esperienza, però non mi risulta di aver avuto o letto di questi dubbi con l'APM.

Mi sembra un pò, (è solo una similitudine fatta pure male) come quando due anni fa uscì la GoPro hero3 black che aveva un mare di problemi, i quali venivano sistematicamente negati dalla casa madre, poi però uscivano firmware a più non posso che piano piano hanno sistemato le cose..

Però io ora a casa c'ho 8 Afro30 e 8 F40 riflashati, che devo fà per volare sereno ?
Se mi precipita l'okto mentre volo, questo deve accadere perchè sono "bestia" ed ho fatto male le saldature oppure non ho stretto bene le eliche, non deve accadere perchè l'esc perde il sync con la PixHawk in quanto non è quello (l'unico) dello store 3drobotics.
Edit: ho anche proposto di aggiungere qualche altro esc nello store, che sia dato per certificato con la Pixhawk, per esempio un 30/40a alimentabile a 5/6s, in modo da poter accontentare tutti. Sarei il primo ad acquistarli e volare sereno.

In conclusione dico che al momento mi tengo stretta la mia "lady pixhawk", in attesa di sapere o leggere cosa fare, e volerò più sereno con le mie APM.
Non mi dite di cambiare piattaforma hardware o altro brand perchè non ho un euro da spendere.

Sono le mie riflessioni, opinabili e contestabili.

Ciao - Giuseppe

[saeli]

Ero intenzionato anche io a prenderla per sostituire la mia apm defunta ma leggendoti... aspetto ancora che sistemico le cose, Marco @bobo67 ci puoi chiarire le idee?

Inviato dal mio GT-P7500 utilizzando Tapatalk

[TermicOne]

Giuseppe, visto che ora hai un pò svolazzato con lady hawk ci dai una impressione dei vantaggi concreti che tale piattaforma garantisce OGGI rispetto alla ottima e collaudata APM della quale hai una buona esperienza? Ho capito che queste piattaforme avanzate saranno il futuro ma OGGI a tuo parere e secondo la tua esperienza che vantaggi concreti ci danno?

La mia sensazione, derivata dalla pur positiva esperienza con VRBRAIN, é che oggi, a meno che non si voglia far volare un octocopter, non mi sembra che ci siano concreti vantaggi rispetto alle piú economiche piattaforme basate su Arduino (APM con APMcopter e AIO Pro con MegapirateNG) . Certamente in futuro le nuove piattaforme a 32bit consentiranno di sviluppare nuovi algoritmi e nuove funzionalitá che il buon Arduino non supporterebbe...ma oggi?

Luciano

[redfox74]

Dunque, è vero, la Pixhawk attualmente la abbiamo tre gatti in tutta Italia, almeno quelli che scriviamo qui e ci confrontiamo e condividiamo, io l'ho acquistata convinto di prendere il miglior sistema UAV-RC esistente in commercio, in termini di prestazioni e rapporto qualità prezzo, (stesso pensiero per la VrBrain che reputo meno plug and play per gli end user ma di pari livello).
inoltre ad oggi, dopo una trentina di voli avendola smaneggiata, e per le mie esigenze di aspirante modellista, nonostante qualche problemino, sono ancora convinto di avere tra le mani un sistema potente, versatile, che ti dà l'impressione di controllo totale quando sei in volo.

Questa è la premessa con i biscotti :
Ora il bastone :

l'altra faccia della medaglia invece è che nell'interfacciamento con "l'esterno", intendo ovviamente gli esc, sto vedendo confusione e ancora pochi elementi per risolvere i problemi, anche se sono convinto che la 3DRobotics ci sta lavorando senza fare troppa pubblicità, perchè mi rendo conto che non conviene sbandierare in giro che molti esc hanno problemi di sync se interfacciati con la Pixhawk, perchè chi non ha ancora deciso di acquistarla, leggendo di questi problemi semplicemente non l'acquisterà.
Per carità il problema è degli esc, non certamente della Pixhawk, allora ho proposto nel forum ufficiale di stilare una sorta di "compatible list", come quella creata a suo tempo per la Naza, per capire quali sono gli esc che realmente funzionano senza problemi di sync, ground, rate refresh, con la Pixhawk.
Ebbene prima mi viene risposto di usare i loro esc, (nello store hanno un unico modello a 20a alimentabile fino 4s), poi mi viene risposto che è una grande idea quella della lista del wiki, è che se voglio posso essere il primo a stilarla.
mmhhmm, io che sono un end end end user, e non posseggo neanche un oscilloscopio, appartengo a quella categoria di utenti che dovrebbero consultare la lista proprio perchè utilizzatori finali, non appartengo a quelli in grado di stilarla, quindi rispondo che la lista, (visto che è stata accolta come una grande idea) potrebbe essere iniziata proprio dai developer e tester che ogni giorno spremono l'hardware ed i firmware alla ricerca di bug. Chi meglio di loro possono dirci oggi, a noi malati di multirotorite e di egisto,, quali esc secondo i loro test non hanno mai dato problemi ?
E non è uno scarica barile, perchè basta dire "amici miei, io oggi ho fatto acro - auto - loiter - flip - sport - hibrid - con e senza payload - con questo firmware e questi motori, secondo me vanno bene,. non si sono piantati, però se poi si piantano a voi che utilizzate altre configurazioni, sono cavoli vostri - patti chiari - amicizia lunga.."
Mi rendo altresì conto che la 3drobotics non è che si mette lì a comprare 20/30 tipi di esc ed a fare analisi di laboratorio ed empiriche per vedere quali non creano problemi con la Pixhawk, però ad esempio, ad oggi non si capisce ancora se sta benedetta spinetta del negativo del segnale PWM si deve inserire o no, ci sono due linee di pensiero, quella attuale di 3drobotics (anche del wiki) che dice che non va messo per non creare pericolosi loop, e l'altra linea di pensiero ad esempio qui ESCs / Motor Controllers - PX4 Autopilot Platform
che dice che va messa obbligatoriamente per un corretto pilotaggio dei segnali pwm.
Quindi prima domanda all'unico interessato nostrano: Maaaarco, la linea ufficiale della 3drobotics è sempre quella della "non spinetta ground" ? Ci potrebbe essere un ripensamento in merito ?
Altra domanda ad altro interessato nostrano: Robeeeerto, con VrBrain come vi state orientando in questo senso ? anche se l'hardware della VrBrain è diverso dalla Pixhawk e così anche sicuramente la distribuzione dei ground sul PCB, cosa ne pensate degli esc.
Leggo nel 3d di riferimento VrBrain, ed è già qualcosa, che molti dei test li fate con gli F30 e che non vi hanno mai creato problemi. OK, invece a 6s cosa posso usare ? F40 ?
Leggevo che anche questi possono creare qualche problema con la Pixhawk, se non con il firmware "settembre 2012", che faccio, tolgo gli Afro e rimetto gli F40 ?
ma sta spinetta ground la metto o no ?
io sono un giovane utilizzatore senza esperienza, però non mi risulta di aver avuto o letto di questi dubbi con l'APM.

Mi sembra un pò, (è solo una similitudine fatta pure male) come quando due anni fa uscì la GoPro hero3 black che aveva un mare di problemi, i quali venivano sistematicamente negati dalla casa madre, poi però uscivano firmware a più non posso che piano piano hanno sistemato le cose..

Però io ora a casa c'ho 8 Afro30 e 8 F40 riflashati, che devo fà per volare sereno ?
Se mi precipita l'okto mentre volo, questo deve accadere perchè sono "bestia" ed ho fatto male le saldature oppure non ho stretto bene le eliche, non deve accadere perchè l'esc perde il sync con la PixHawk in quanto non è quello (l'unico) dello store 3drobotics.
Edit: ho anche proposto di aggiungere qualche altro esc nello store, che sia dato per certificato con la Pixhawk, per esempio un 30/40a alimentabile a 5/6s, in modo da poter accontentare tutti. Sarei il primo ad acquistarli e volare sereno.

In conclusione dico che al momento mi tengo stretta la mia "lady pixhawk", in attesa di sapere o leggere cosa fare, e volerò più sereno con le mie APM.
Non mi dite di cambiare piattaforma hardware o altro brand perchè non ho un euro da spendere.

Sono le mie riflessioni, opinabili e contestabili.

Ciao - Giuseppe

Ciao Giuseppe,
comprendo la questione che ti affligge e che affligge molti rispetto agli ESC ed effettivamente sul mercato c'e' di tutto ... in merito alla nostra triennale esperienza con VRBrain e gli ESC in generale siamo sempre riusciti a trovare il problema , che in genere era piu' legato al motore - ESC - Firmware piuttosto che alla vrbrain.
Quello che consiglio e' leggere sul forum , per la VRBrain il nostro qua sul barone e utilizzare configurazioni collaudate specialmente per motori come i TMotors 3506-08 ... che hanno dato molti grattacapi in passato .
In generale e' necessario collegare il ground il 95 % dei casi per avere una massa piu' sicura e' al 100% fondamentale con gli ESC OPTO.
La storia degli esc e' una storia molto complessa e che viene dal passato ... DJI in generale consiglia di usare i suoi ultra collaudati per le loro piattaforme ancor di più Mikrokopter che sono addirittura i2c creando forti limitazioni di configurazione del drone .
In merito al discorso di Termicone che puo' essere condivisibile se quello che APM da' e' gia' piu' che sufficiente , nelle ultime versioni ci sono funzionalità che non esistono piu' su APM , come il supporto a SBUS FUTABA/SPEKTRUM (Disponibile anche nelle vecchie VRBRAIN 4.x con piu' di due anni di servizio ) Oppure EKF come nuovo algoritmo di stabilità ed assetto , doppia imu , doppio gps e doppio magnetometro cose che l'apm si scorda ... d'altronde il mondo va avanti e a noi sviluppatori piace alzare sempre di piu' l'asticella se no che gusto c'e' ....

Comunque Io sono molto scettico sulla piattaforma Pixhawke per altre ragioni in primis il sistema operativo nuttx che e' in generale un gran casino ... noi stiamo verificando ogni virgola di nuttx durante il porting su vrbrain 4 - 5 e ho sotto due persone da piu' di 3 mesi a fare solo quello ... Non e' una passeggiata avere un OS sotto APM Copter che gira e che coordinata tutte le funzionalità . VRBrain e' l'unica scheda che supporta la versione con OS e quella senza OS stile APM 2.x



Un saluto
Roberto

[danveal]

ancor di più Mikrokopter che sono addirittura i2c creando forti limitazioni di configurazione del drone .

Ciao Roberto che limitazioni? ( mikrokopter con la nuova versione FW 2.06 e il nuovo ACC potrebbe [ devo ancora provare le novità ] essere la piattaforma più performante esistente attualmente considerando il comportamento di volo e l'insieme delle sue funzioni autonome e personalizzazioni)

Piuttosto potrebbe essere interessante se il codice apm supportasse anche gli esc i2c. A livello di codice sono poche righe sempre se è disponibile una porta i2c e che le librerie i2c usate su stm32f4 siano affidabili.
Avere esc i2c taglierebbe la testa al toro ai presunti problemi di pwm lato micro anche se io ci credo poco perchè da ormai qualche anno uso i bluseries flashati simonk con segnali pwm a 3.3volt e non ho mai avuto problemi a parte i conosciuti problemi pankake.
A questo proposito segnalo che esiste un altro firmware per gli esc, il BLHELI nato sui processori silabs ma ora disponibile anche per molti esc atmel.
Non è che i casini sulla pixhawck sono dovuti alla giovinezza dell'implementazione del nuttx?
Tra l'altro mi risulta che anche la modalità di volo che usa l' EKF ogni tanto dia dei problemi strani. Forse la pixhawk è stata fatta uscire troppo presto e con troppe novità non adeguatamente testate. Per developer abituati a programmare per processori atmel non è uno scherzo cambiare architettura aldila del porting iniziale.

[mikronerd]

io ho acquistato la pixhawk esclusivamente per metterla sull'okto, dove avevo giá collaudato l'APM, ebbene la prima cosa che si nota é la possibilitá di avere tutti i log attivi, (di default), con l'APM + Okto ero sempre telemetricamente preoccupato di avere ad esempio imu e motors attivi ed usare funzionalitá waypoint, anche se dove dire che ho volato molto bene con APM + okto, avevo un bel loiter cazzuto, throttle hover al 45 %, grazie alle notti passate su ecalc, e mai un "mechanical failure", ma questo non dipende dall'APM ma dipende da me .
sostituendo l'APM con la Pixhawk, nella pratica ho avuto immediatamemte una sensazione di maggior controllo, obbedienza e stabilitá in volo, però parliamo di sensazioni, forse é un effetto placebo, anche perché il mio modo di volare é molto semplice, 90 % althold, 5 % loiter, e l'altro 5 % tutti gli altri modi di volo.
Con pixhawk si prende immediatamente confidenza con il buzzer e le sue musichette, diventano un'aspettativa quando si accende, arma disarma, e ti fanno presto dimenticare anche i led fix gps e arm disarm, anche se presto dovrebbe uscire il led rgb i2c per replicare i multicolori (praticamente invisibili al momento) del leddone pixhawk.
Ora immaginate il mio disappunto, dopo aver volato con soddisfazione con APM, cominciare a leggere di ground si ground no, problemi con quell'esc , problemi con quell'altro esc, la colpa é sempre dell'esc, questo l'abbiamo capito.
Nonostante questo ho ancora fiducia nella pixhawk, aspetto solo che qualcuno mi dica quali esc (di qualitá) usare senza problemi e se é meglio non riflasharli SimonK per usarli bene con Pixhawk, mi adeguerei e dormirei sonni tranquilli.
l'ho sempre detto che la mia scelta era tra pixhawk e vrbrain, e giá ho spiegato molti post fa i motivi (miei personali) della scelta su pixhawk, ma su quell'okto potrebbe presto salirci una VrBrain..

@danveal
leggo cose buone anche sugli esc32, che costicchiano, che ne pensate, potrebbero essere una buona scelta per l'attuale pixhawk, usati sempre in PWM, oppure la cosa rimane sempre limitativa ?

ciao - Giuseppe

[redfox74]

Ciao Roberto che limitazioni? ( mikrokopter con la nuova versione FW 2.06 e il nuovo ACC potrebbe [ devo ancora provare le novità ] essere la piattaforma più performante esistente attualmente considerando il comportamento di volo e l'insieme delle sue funzioni autonome e personalizzazioni)

Piuttosto potrebbe essere interessante se il codice apm supportasse anche gli esc i2c. A livello di codice sono poche righe sempre se è disponibile una porta i2c e che le librerie i2c usate su stm32f4 siano affidabili.
Avere esc i2c taglierebbe la testa al toro ai presunti problemi di pwm lato micro anche se io ci credo poco perchè da ormai qualche anno uso i bluseries flashati simonk con segnali pwm a 3.3volt e non ho mai avuto problemi a parte i conosciuti problemi pankake.
A questo proposito segnalo che esiste un altro firmware per gli esc, il BLHELI nato sui processori silabs ma ora disponibile anche per molti esc atmel.
Non è che i casini sulla pixhawck sono dovuti alla giovinezza dell'implementazione del nuttx?
Tra l'altro mi risulta che anche la modalità di volo che usa l' EKF ogni tanto dia dei problemi strani. Forse la pixhawk è stata fatta uscire troppo presto e con troppe novità non adeguatamente testate. Per developer abituati a programmare per processori atmel non è uno scherzo cambiare architettura aldila del porting iniziale.

Limitazioni intendevo nel senso che su mk puoi usare solo esc i2c che a grandi linee sono solo quelli mk ... oppure attraverso degli adattatori .

Anche secondo me i problemi sono nascosti nel nuttx e' per quello che prima di rilasciarlo in via definitiva su vrbrain gli stiamo facendo le pulci ... sul forum ufficiale ad esempio si parlava di un bug che faceva spegnere il firmware su uno dei due processori Pixhawke ... lasciando l'altro a pilotare gli esc con l'ultimo valore cloccato dalla cpu principale . Parlavano di ROver
Secondo me questo e' un altro grande limite usare due cpu quando te ne basta 1 sola cosi' i problemi si moltiplicano per due ... infatti ha una cpu f4 e una cpu f1 con due SO diversi ... tutti da manutenere debuggare e supportare insomma un bel casino ...
Io ho fatto la scelta di rimanere con una architettura mono processore , magari piu' potente ... pero' unico con tutto implementato su quello ... visto che di potenza di calcolo , flash e ram ne abbiamo ancora moltissima da utilizzare .
Praticamente abbiamo preso tutto il codice sulla seconda cpu e messo sulla prima e fatto girare come modulo a livello di sistema operativo e funziona tutto perfettamente anzi meglio .. di base tra le due cpu la comunicazione avviene a livello di i2c o seriale che di fatto diventa il collo di bottiglia della pixhawke , su vrbrain invece la comunicazione avviene attraverso uorb direttamente sfruttando processi in ram quindi alla massima velocità consentita dal processore ... questo approccio consente di risparmiare il 2 % della cpu rispetto a pixhawke niente di che ma sempre qualcosa in meno
un saluto
Roberto

[danveal]

Limitazioni intendevo nel senso che su mk puoi usare solo esc i2c che a grandi linee sono solo quelli mk ... oppure attraverso degli adattatori .

Gli afro esc hanno anche l'ingresso i2c con indirizzamento mikrokopter

Per il resto sono d'accordissimo con te, vrbrain nelle varie release è un hardware maturo e gli adattamenti al codice che avete fatto sono più solidi anche perchè svolti in piu tempo e gradatamente rispetto al salto fatto da 3dr.
Se guardo da fuori l'impressione è che la vrbrain batte 10 a zero la pixhawk a livello di scelte progettuali ma 3dr batte 10 a 0 virtualrobotix per il marketing ( certo con i finanziamenti che hanno... ) La storia insegna che il prodotto leader del mercato spesso non è il migliore ma quello che si è saputo vendere meglio
Dovevano approffittare della tua esperienza ( dimostrata con la vrbrain che conoscevano bene ) e farti collaborare a progettare la pixhawk

[-RsX-]

Come mi hai consigliato sto spostando il GPS più in alto
55mm bastano?
Una basetta di carbonio più ampia aiuterebbe di più schermando meglio i disturbi da sotto o sarebbe solo peso inutile?


Sent from my Nexus 5 using Tapatalk

[mikronerd]

Come mi hai consigliato sto spostando il GPS più in alto
55mm bastano?
Una basetta di carbonio più ampia aiuterebbe di più schermando meglio i disturbi da sotto o sarebbe solo peso inutile?


Sent from my Nexus 5 using Tapatalk

Ciao non credo c'è una regola, più lontano lo metti meglio è, puoi accorgertene da solo, rifai un voletto con la nuova asticella e poi vai a riguardarti il grafico magfield. La soluzione migliore alla fine è quella di fare il anche il compassmot, che in pratica adegua i parametri in base al throttle ed alle interferenze generate dai motori.
io sto aspettando da ebay due asticelle ripiegabili che dovrebbero essere alte 11cm o 15cm, per il momento utilizzo la torretta con gps in cima, ma a causa di questa che è abbastanza alta non posso usare la cappottina pertanto ho deciso di "tornare" alla soluzione "dji style"
La basetta, di carbonio e non, secondo me serve solo per attaccare il GPS con biadesivo.
Ma è telescopica ? non è mica un'antenna FM??
Ciao - Giuseppe

[-RsX-]

ok, è un distanziatore in alluminio di telaio per elicottero con le estremità già forate e filettate
montarlo è stato immediato con 2 viti, ho solo tagliato la basetta in carbonio, che nel caso fosse stata utile potevo realizzare anche più grande

[RazorCopter]

Riporto la mia esperienza, io con la mia Pix, non ho mai avuto problemi, la mia configurazione è Pix+AfroSlim 20A+ Tmotor 3506 650KV e volo senza spinetta del ground anche perchè la massa è sempre la stessa, capisco l'obbligatorietà della massa sugli opto ma li è un altro discorso avendo disaccoppiato i due circuiti sull'ESC, per tanto io sono della corrente: NO GND

Rispondendo invece RsX, io sostituirei il carbonio con un altro materiale, plastica vetronite vetroresina, insomma qualcosa che non sia un conduttore.

Gian