BaronPilot - Autostabilizzatore Molto Economico

[Perryosio]

Ciao a tutti, bentornati dalle ferie!

Dovrei aver trovato il motivo dei miei problemi, avevano costretto il mezzo a terra dopo l'ultimo schianto.

Siccome non trovavo confronti con mezzi baronpilot, ho trovato l'identico problema su hardware uguale ma software diverso, mi riferisco al TriWiiCopter.

TriWiiCopter - Page 8 - RC Groups post 109

"This is one of the bad fake WM+ (there maybe others).
It seems to work fine at the beginning, but suddenly I2C stops working and it freezes everything, and the motors continues to spin."

Ha risolto il problema con l'ultima relase la 3.1 dove in caso di freeze riavvia WMP+NK in 33ms, usabilissimo questo sistema anche in volo...

Siccome non è possibile determinare in anticipo se ci sono buone o cattive copie di WMP+NK (potrebbe essere che pure gli originali abbiano questo problema, ma si presenta molto più raramente...), sarebbe opportuno (necessario) integrare questa feature anche in baronpilot.

Ciao a tutti, allora, è stato possibile testare il tricottero baronpilot 2 giorni fa in giardino; tutto andava per il meglio, sempre in modalità acro, si poteva cominciare a ragionare con il discorso del PID per perfezionare la stabilità, una bella soddisfazione insomma, un volo tranquillo in giardino senza sorprese.
Ah, una cosa , devo le scuse a Ciskje, rispetto all'ultimo post di prima delle ferie, aveva ragione Ciskje, non vi erano problemi di ricezione della radio causati da altro hardware o dal software ma semplicemente la radio difettosa, molto scarsa in ricezione (la Corona RP8D1 appena arrivata, quella nuova a 9 canali, vedremo se è riparabile). Quindi cambiata la radio risolti i problemi di ricezione.
Poi purtroppo il fatto.
Prima era già successo che si sentisse il o i motori andar su di giri ma solo per un attimo, diciamo 0,1-0,2 secondi, e questo non aveva causato alcun problema reale.
Poi ad un certo punto durante il volo tranquillissimo ecco che improvvisamente i motori vanno a palla per quasi 1 secondo, il baronpilot che sale, si capovolge e lì ovviamente non c'è stato molto da fare, essendo già quasi a terra è caduto con qualche danno, un braccio rotto e l'asse di 1 motore stortato.
Adesso è già tutto riparato e pronto per nuove prove ma davvero, sarebbe meglio ripartire solo con il problema dell'"impazzimento" in qualche modo affrontato.
Grazie, ciao.

[leonking]

Ciao a tutti, allora, è stato possibile testare il tricottero baronpilot 2 giorni fa in giardino; tutto andava per il meglio, sempre in modalità acro, si poteva cominciare a ragionare con il discorso del PID per perfezionare la stabilità, una bella soddisfazione insomma, un volo tranquillo in giardino senza sorprese.
Ah, una cosa , devo le scuse a Ciskje, rispetto all'ultimo post di prima delle ferie, aveva ragione Ciskje, non vi erano problemi di ricezione della radio causati da altro hardware o dal software ma semplicemente la radio difettosa, molto scarsa in ricezione (la Corona RP8D1 appena arrivata, quella nuova a 9 canali, vedremo se è riparabile). Quindi cambiata la radio risolti i problemi di ricezione.
Poi purtroppo il fatto.
Prima era già successo che si sentisse il o i motori andar su di giri ma solo per un attimo, diciamo 0,1-0,2 secondi, e questo non aveva causato alcun problema reale.
Poi ad un certo punto durante il volo tranquillissimo ecco che improvvisamente i motori vanno a palla per quasi 1 secondo, il baronpilot che sale, si capovolge e lì ovviamente non c'è stato molto da fare, essendo già quasi a terra è caduto con qualche danno, un braccio rotto e l'asse di 1 motore stortato.
Adesso è già tutto riparato e pronto per nuove prove ma davvero, sarebbe meglio ripartire solo con il problema dell'"impazzimento" in qualche modo affrontato.
Grazie, ciao.

ciao, una info...
hai sia VM+ che Nunchuk?

grazie.

[Perryosio]

ciao, una info...
hai sia VM+ che Nunchuk?

grazie.

Ciao, si uso sia WM+ che NNChk originali nintendo.
Altre prove fatte poi in seguito però son da tenere in conto:

quando è successo il fattaccio poteva essere stata inserita la modalità stabile; ricordo che erano in corso delle brevi prove.
Ripetendo le prove senza le eliche in casa oggi pomeriggio si è potuto notare che mentre la modalità acro non da nessun tipo di problema non appena si inserisce la modalità stabile, nonostante la convinzione di aver fatto le impostazioni (comando VS), subito mentre qualche motore (non sempre lo stesso) comincia a salire di giri, qualche altro (non sempre lo stesso), tende a rallentare e fermarsi, come in una specie di deriva incontrollabile. Quindi la perdita di controllo avuta potrebbe essere dovuta al fatto che era stata inserita (cioè avevo inserito) con troppa fiducia la modalità stabile che invece non è ancora "pronta" all'uso.
D'altronde il bello è proprio quello di disporre di una modalità stabile, no?
Il ticottero con i tre giroscopi c'è già e funge molto bene, a parte il fatto del casino nell'accenderlo (è necessario prima escludere i giroscopi poi accendere tutto poi inserire i giroscopi fra esc e radio, poi staccare e riattaccare il gyro dello yaw alla radio fino a quando non risponde a dovere); questo casino ovviamente non c'è con il baronpilot.
Sarebbe bello che Ciskje riuscisse a completare la V50 "universale", dato che dovrebbe contenere anche la soluzione di questo problema, se non erro.
Ciao, grazie.

[blinking]

Il ticottero con i tre giroscopi c'è già e funge molto bene, a parte il fatto del casino nell'accenderlo (è necessario prima escludere i giroscopi poi accendere tutto poi inserire i giroscopi fra esc e radio, poi staccare e riattaccare il gyro dello yaw alla radio fino a quando non risponde a dovere); questo casino ovviamente non c'è con il baronpilot.

eh? io accendo la rx con i giro attaccati, aspetto che si azzerino (smettono di lampeggiare) quindi collego gli esc, che si armano correttamente.

[mikenet76]

eh? io accendo la rx con i giro attaccati, aspetto che si azzerino (smettono di lampeggiare) quindi collego gli esc, che si armano correttamente.

idem.

[leonking]

Ciao, si uso sia WM+ che NNChk originali nintendo.
Altre prove fatte poi in seguito però son da tenere in conto:

quando è successo il fattaccio poteva essere stata inserita la modalità stabile; ricordo che erano in corso delle brevi prove.
Ripetendo le prove senza le eliche in casa oggi pomeriggio si è potuto notare che mentre la modalità acro non da nessun tipo di problema non appena si inserisce la modalità stabile, nonostante la convinzione di aver fatto le impostazioni (comando VS), subito mentre qualche motore (non sempre lo stesso) comincia a salire di giri, qualche altro (non sempre lo stesso), tende a rallentare e fermarsi, come in una specie di deriva incontrollabile. Quindi la perdita di controllo avuta potrebbe essere dovuta al fatto che era stata inserita (cioè avevo inserito) con troppa fiducia la modalità stabile che invece non è ancora "pronta" all'uso.
D'altronde il bello è proprio quello di disporre di una modalità stabile, no?
Il ticottero con i tre giroscopi c'è già e funge molto bene, a parte il fatto del casino nell'accenderlo (è necessario prima escludere i giroscopi poi accendere tutto poi inserire i giroscopi fra esc e radio, poi staccare e riattaccare il gyro dello yaw alla radio fino a quando non risponde a dovere); questo casino ovviamente non c'è con il baronpilot.
Sarebbe bello che Ciskje riuscisse a completare la V50 "universale", dato che dovrebbe contenere anche la soluzione di questo problema, se non erro.
Ciao, grazie.

ciao,
mi passi i tui valori di:

PRR
PRP
VRR
VRP
SRR
SRP
A
AR
VR

vorrei fare un confonto.
hai mai volato solo con VM+?
se si dopo aver collegato in NNCHK, cosa hai notato? o settato?

grazie.

[Perryosio]

ciao,
mi passi i tui valori di:

PRR
PRP
VRR
VRP
SRR
SRP
A
AR
VR

vorrei fare un confonto.
hai mai volato solo con VM+?
se si dopo aver collegato in NNCHK, cosa hai notato? o settato?

grazie.

Ciao, ecco i valori

Calibrating...
7953.20
7818.98
8013.12
BaronPilot

PRR 0.90;0.28;0.00;0.00

PRP 0.90;0.28;0.00;0.00

VRR 498.00;516.00;514.00

VRP 498.00;516.00;514.00

SRR 1.20;2.00;0.00;0.00

SRP 1.20;2.00;0.00;0.00

A -36.85;38.00;-36.79;38.38

AR -36.85;38.00;-36.86;38.39

VR 498.00;516.00;514.00

tuttavia la cosa interessante che nelle varie prove si è potuto notare è che il valore letto dagli accellerometri appare valido a motori fermi mentre fa casino non appena si passa da stand-by ad acro. Forse il sistema NNCK/Arduino subisce interferenze a causa della posizione proprio sopra Arduino (praticamente appoggiato sopra).
Adesso occorre fare altre prove separando meglio i tre circuiti stampati ovvero le tre schedine elettroniche (Arduino, WM+ e NNCK).
Grazie, ciao.

[leonking]

test senza NNCHK

Oggi nonostante il vento di mare abbastanza sostenuto ho fatto delle prove.....
Sono sicuro che il sistema funziona bene e che io non sia in grado di settare l'accelerometro... Il risultato è che solamente con il WM+ il quad è molto stabile, corregge bene ed è abbastanza reattivo. Al contrario appena collegato in NNCHK tutto sembrava incontrollabile e nel tentativo di correggere ti scappa do tutti i lati costringendoti a star lì a correggere in modo esagerato. Ripeto è possibile che il mio setup non sia per niente esatto, però solo con il WM+ va molto bene.
Infatti in altri progetti hanno solo il WM+.
Ho lasciato nel firmare incluso l'accelerometro, e mi chiedevo se era possibile, tenendolo fisicamente collegato, escluderlo dal sistema di correzione....

Penso che a questa domanda potrà rispondermi solo il mitico Francesco a cui mando un saluto in attesa del parto della v.5.0.

[ciskje]

Dovrei spiegare un milione di cose, ma ho il tempo contingentato, riassumo con:

1) il nunchuck è fondamentale per l'FPV, tiene parallelo al terreno anche se non tocchiamo i comandi
2) il nunchuck fornisce 3 valori, x,y,z che rappresentano l'accelerazione "sentita"
3) non c'e' un modo perfetto per settarlo come per i giroscopi (che basta tararli da fermo).
4) x rappresenta l'accelerazione sentita in avanti
5) y rappresenta l'accelerazione sentita a destra
6) z rappresenta l'accelerazione sentita in basso
7) normalmente non si conosce lo zero del nunchuk, i valori letti per x e y si suppongono 0 in piano, ma z ? Ad esempio leggendo 512,512,700 il centro di x,y è sicuramente 512.
8) l'algoritmo implementato attualmente si suppone che per z lo zero sia la media di x e y.
9) il meglio sarebbe fare lo zero in tre fasi, tenendo in piano, a 90 gradi in avanti e poi 90 gradi a destra il velivolo (un po' scomodo).
10) anche se abbiamo fatto la taratura in piano, il velivolo scivolerà comunque (basta che un motore sia montato leggermente inclinato), e sarà comunque necessario trimmarlo con la radio
11) il nucleo stesso di BaronPilot è l'autolivellamento, altrimenti a chi non interessa ed è più "elettronico" è molto meglio la scheda di KaptainKUK
12) comprare da robot-italy un ADXL335 al posto del Nunchuck non è affatto una brutta idea (è già utilizzabile in baronpilot). Il nunchuck rallenta le letture del WM+ e conseguentemente la stabilità.
13) Sono al lavoro sulla V50, ma sarò costretto ad introdurre numerosi altri parametri da settare nel sorgente per l'orientamento
14) Devo trovare un modo per semplificare il setup dell'autolivellamento, e l'abilitazione dei motori, a quel punto rilascerò la V50.
15) Mi piacerebbe poter passare da acro ad autolivellamento in aria, in modo che se in una manovra pericolosa ci troviamo in difficoltà è possibile passare al modo autostabile.

[leonking]

Dovrei spiegare un milione di cose, ma ho il tempo contingentato, riassumo con:

1) il nunchuck è fondamentale per l'FPV, tiene parallelo al terreno anche se non tocchiamo i comandi
2) il nunchuck fornisce 3 valori, x,y,z che rappresentano l'accelerazione "sentita"
3) non c'e' un modo perfetto per settarlo come per i giroscopi (che basta tararli da fermo).
4) x rappresenta l'accelerazione sentita in avanti
5) y rappresenta l'accelerazione sentita a destra
6) z rappresenta l'accelerazione sentita in basso
7) normalmente non si conosce lo zero del nunchuk, i valori letti per x e y si suppongono 0 in piano, ma z ? Ad esempio leggendo 512,512,700 il centro di x,y è sicuramente 512.
8) l'algoritmo implementato attualmente si suppone che per z lo zero sia la media di x e y.
9) il meglio sarebbe fare lo zero in tre fasi, tenendo in piano, a 90 gradi in avanti e poi 90 gradi a destra il velivolo (un po' scomodo).
10) anche se abbiamo fatto la taratura in piano, il velivolo scivolerà comunque (basta che un motore sia montato leggermente inclinato), e sarà comunque necessario trimmarlo con la radio
11) il nucleo stesso di BaronPilot è l'autolivellamento, altrimenti a chi non interessa ed è più "elettronico" è molto meglio la scheda di KaptainKUK
12) comprare da robot-italy un ADXL335 al posto del Nunchuck non è affatto una brutta idea (è già utilizzabile in baronpilot). Il nunchuck rallenta le letture del WM+ e conseguentemente la stabilità.
13) Sono al lavoro sulla V50, ma sarò costretto ad introdurre numerosi altri parametri da settare nel sorgente per l'orientamento
14) Devo trovare un modo per semplificare il setup dell'autolivellamento, e l'abilitazione dei motori, a quel punto rilascerò la V50.
15) Mi piacerebbe poter passare da acro ad autolivellamento in aria, in modo che se in una manovra pericolosa ci troviamo in difficoltà è possibile passare al modo autostabile.

mi piacerebbe continuare a leggere altre tue spiegazioni, ma capisco che sei abbastanza pieno di lavoro e hai poco tempo.
Ti sarei grato se quantomeno mi daresti una info se il mio modo di tarare il NNCHK è giusto.

Posizionato perfettamente su piano orizzontale dò "VR", a questo punto mi restituisce i tre valori. 514.00 530.00 510.
Poi do "VS", e mi restituisce altri tre valori,
infine con "A" controllo, dopo averlo posizionato in verticale e girato antiorario di 90°, mi deve restituire valori che si avvicinano a 0.00;90.00.
E se così non fosse? se non riuscissi ad avere quei valori? dove intervengo?
Scusami ma voglio capire.... Grazie.

[Perryosio]

Problemi risolti!

Ciao a tutti, nelle (mie) mail precedenti ci sono state espressioni inesatte, ad esempio parlando di modalità stand-by, acro e stabile in realtà erano da intendere le tre posizioni legate al channel5, cioè DISABLE, READY TO TAKE OFF E NORMAL (chiedo scusa ).
Invece sono stati risolti i problemi di deriva!!!!!! E' stato facile verificarlo con i comandi del CLI, una volta capito meglio il significato.
In pratica come era prima, avendo appoggiato la basetta del NNCK direttamente sul processore di Arduino ehm...., c'era qualche interferenza, che tuttavia si manifestava solamente all'accensione dei motori; in pratica a motori fermi (DISABLE) il nnck forniva valori adeguati mentre appena si accendevano i motori (READY TO TAKE OFF) impazziva; incredibile che nonostante ciò si riusciva a volare, come con un tricottero a 4 gyro, però poi pian piano il tutto andava in deriva ed il vessel tendeva ad andare in coma, con motori che si fermavano ed altri che salivano di giri ed obbligo di atterrare, se non peggio, quando improvvisamente partiva a razzo.
Adesso le schedine sono state separate con circa 2 cm di polistirolo; inoltre qualche filo malamente inserito nelle prese di Arduino duemilanove è stato sistemato con spinette da servocomando.... e.......stasera tutte le prove fatte danno il baronpilot pefettamente funzionante (in casa). C'è un filmatino di un brevissimo volo, vediamo se entro domani sera compare su youtube.
Speriamo di poter fare qualche bella prova in esterno domani.
Grazie a tutti, grazie Ciskje!


ps.: a Leonking: ricordati che dopo aver trovato le impostazioni migliori, es. con VS oppure valori migliori di PID, è necessario e fondamentale scriverle sulla EPROM con il comando EW, per cortesia Ciskje correggi se non è vero.

[Perryosio]

Dovrei spiegare un milione di cose, ma ho il tempo contingentato, riassumo con:

1) il nunchuck è fondamentale per l'FPV, tiene parallelo al terreno anche se non tocchiamo i comandi
2) il nunchuck fornisce 3 valori, x,y,z che rappresentano l'accelerazione "sentita"
3) non c'e' un modo perfetto per settarlo come per i giroscopi (che basta tararli da fermo).
4) x rappresenta l'accelerazione sentita in avanti
5) y rappresenta l'accelerazione sentita a destra
6) z rappresenta l'accelerazione sentita in basso
7) normalmente non si conosce lo zero del nunchuk, i valori letti per x e y si suppongono 0 in piano, ma z ? Ad esempio leggendo 512,512,700 il centro di x,y è sicuramente 512.
8) l'algoritmo implementato attualmente si suppone che per z lo zero sia la media di x e y.
9) il meglio sarebbe fare lo zero in tre fasi, tenendo in piano, a 90 gradi in avanti e poi 90 gradi a destra il velivolo (un po' scomodo).
10) anche se abbiamo fatto la taratura in piano, il velivolo scivolerà comunque (basta che un motore sia montato leggermente inclinato), e sarà comunque necessario trimmarlo con la radio
11) il nucleo stesso di BaronPilot è l'autolivellamento, altrimenti a chi non interessa ed è più "elettronico" è molto meglio la scheda di KaptainKUK
12) comprare da robot-italy un ADXL335 al posto del Nunchuck non è affatto una brutta idea (è già utilizzabile in baronpilot). Il nunchuck rallenta le letture del WM+ e conseguentemente la stabilità.
13) Sono al lavoro sulla V50, ma sarò costretto ad introdurre numerosi altri parametri da settare nel sorgente per l'orientamento
14) Devo trovare un modo per semplificare il setup dell'autolivellamento, e l'abilitazione dei motori, a quel punto rilascerò la V50.
15) Mi piacerebbe poter passare da acro ad autolivellamento in aria, in modo che se in una manovra pericolosa ci troviamo in difficoltà è possibile passare al modo autostabile.

Ciao, in attesa della V50, Francesco, per i poveri mortali molto digiuni di programmazione, potresti magari dare qualche info sul significato dei diversi tipi di lampeggio del led su D13 e di quando è necessario usare il comando EW?
Grazie 1000, ciao

[leonking]

Ciao, in attesa della V50, Francesco, per i poveri mortali molto digiuni di programmazione, potresti magari dare qualche info sul significato dei diversi tipi di lampeggio del led su D13 e di quando è necessario usare il comando EW?
Grazie 1000, ciao

Il comando EW "eprom write" fa la stessa cosa di quando tu esegui sul PC:
"Salva" ossia scrivi tutti i parametri che hai appena modificato sull' HDD di Arduino.
Ricorda pure che se esci dal "Serial Monitor" e poi rientri hai perso i dati appena modificati.

ciao

[elettro]

ciao, sto guardando il tuo codice per capire come stabilizzi l'uscita del giroscopio. In Mixing.pde mi pare capire che butti direttamente i valori in PID, anche se non capisco dove leggi acroPitch, acroRoll e acroYaw, e anche dove setti g (ma le stai usando globali? e dove le inizializzi? mannaggia in java non ci son 'sti bordelli).
Oppure ti fidi del valore in uscita dal gyro e lo sbatti direttamente nel PID? io ho capito che è pressoché impossibile cercare di cavar fuori un angolo assoluto dal gyro, ma almeno il più vicino possibile!

[ciskje]

ciao, sto guardando il tuo codice per capire come stabilizzi l'uscita del giroscopio. In Mixing.pde mi pare capire che butti direttamente i valori in PID, anche se non capisco dove leggi acroPitch, acroRoll e acroYaw, e anche dove setti g (ma le stai usando globali? e dove le inizializzi? mannaggia in java non ci son 'sti bordelli).
Oppure ti fidi del valore in uscita dal gyro e lo sbatti direttamente nel PID? io ho capito che è pressoché impossibile cercare di cavar fuori un angolo assoluto dal gyro, ma almeno il più vicino possibile!

al PID è passata la struttura dati con dentro acroPitch etc. (è un po' come passare l'oggetto nel 1980).

Un angolo assoluto dal gyro viene calcolato dalla routine di stabilizzazione attraverso quello che viene chiamato un filtro passa alto per il gyro e un filtro passa basso per l'accelerometro. (è dentro stabilization.pde).

L'accelerometro segna costantemente l'angolo corretto ma soffre durante le manovre veloci della forza centrifuga, i gyro invece segnano l'angolo corretto nelle manovre rapide ma alla lunga derivano.