x ufo

[gibon]

Ninja 1.10

Buongiorno Dommy e buongiorno agli altri mattinieri.
Ecco la foto del Ninja 1.10
Dopo la foto ho rimontato l'antenna per i 40mHz.
La spektrum non funziona.
Adesso vado a fare un volo, dopo guardo con l'oscilloscopio, così guardo anche il segnale al servo della cam.

CIao a tutti

[dommy]

filtro

Ciao,:

P.S. @Jijuja non ho capito (naturalmente) come fare a risolvere il problema del servo con una MCU aggiuntiva. Se per te fosse un lavoretto semplice ti guadagneresti la gratitudine di molti utenti...
Dopotutto è male dedicarsi ad un'amante sola... poi avanza pretese ecc...

Direi che un sistema buono per risolvere tale problema senza micro sarebbe quello di tradurre il segnale in analogico poi trattarlo con un filtro "fisico"
per poi convertirlo nuovamente in digitale...( ad occhio serve un servo vecchio,un pò di resistenze,condensatori ed un Ne555 )
questo naturalmente in modo casalingo ma a questo punto costa meno un micro,il problema ad occhio
( ho l'MK ma ci ho fatto solo qualche voletto per verifiche ed aspetto tempi migliori per lavorarci quindi ho solo le vostre descrizioni del problema )
dovrebbe essere che qualche impulso arriva "fuori" il che potrebbe essere spiegabile perchè viene generato non da un modulo PWM
ma via Software e sappiamo benissimo che le priorità sono altre...
Per pilotare un servo normalmente viene impiegato un segnale con periodo di 20mS e impulso che dura da circa 1mS a 2mS ( centro 1.5mS )
per dargli la posizione. Il micro dovrebbe occuparsi di leggere la lunghezza dell'impulso e "filtrarlo" con un algoritmo ( es. filtro Kalman )
per poi riprodurlo verso il servo. ( + difficile da capire che da fare ) Certo sarebbe utile "vedere" questo segnale quindi registrarlo
per un certo tempo...Qualcuno di voi ha voglia di farlo? così possiamo andare a fondo...
Per farlo non servono strumenti esagerati ma c'è esempio un software gratuito sviluppato quì in Italia che "trasforma"
il PC con scheda audio in un oscilloscopio ottimo direi per lavorare su queste frequenze,i limiti sarebbero che non è fatto
per lavorare con segnali in "continua" ma in questo caso non è un problema. ( così partecipiamo tutti )
Approposito con il Micro non ci sarebbe nessun ritardo in quanto si lavorerebbe sulla previsione.

Ciao!

Questa secondo me è la soluzione migliore, parecchi anni fà avevo usato una pic 12C508 per fare un servo reverse, poi mi resi conto che era facile farci di tutto, e allora ci feci prima un servo slow down e poi un sequenziatore per aprire gli sportelli dei carrelli del mio rafale, però in questo caso usai una 16f84a.
Non saprei però come implementare un filtro di kalman su una pic di questo tipo, ma sono sicuro che si possa fare perchè a ben vedere si tratta "solo" di fare quanto già fanno tutti i vari ricevitorini cinesi e non che usano il concetto "berg" o per dirla alla Multiplex" il sistema IPD, qualcuno poi, come corona, lo chiamano RX con tecnologia dsp, ma insomma è una PIC che analizza l'impulso e se è anomalo, diverso da come ci si aspetterebbe lo scarta e continua a mandare quello di prima, siccome questo si fà con un tempo di 20 ms e cioè 50 hertz e cioè 50 volte al secondo, anche se scartiamo la metà degli impulsi arrivati per quello che deve fare è sempre troppo.
Forza Jijuja, io sono troppo fuori dal discorso PIC da tanto, non mi ricordo più nulla ma tu dopo l'amante uno potresti passare alla due poi alla tre etc.etc. scherzo dai, ma se ci metti le mani forse potresti aiutare tutto il team, però siccome le cose facili di sicuro non ti piacciono, io direi una cosa, facciamolo subito per due canali, perchè bene o male alla fine si dovrà usare sia per il nick che per il roll.
Ciao e
buona Domenica a tutti
Dommy

[dommy]

ninja

Buongiorno Dommy e buongiorno agli altri mattinieri.
Ecco la foto del Ninja 1.10
Dopo la foto ho rimontato l'antenna per i 40mHz.
La spektrum non funziona.
Adesso vado a fare un volo, dopo guardo con l'oscilloscopio, così guardo anche il segnale al servo della cam.

CIao a tutti

forte.... ha un che di agressivo, cattivo, sembra un insettone volante.....

[gibon]

karma

Grazie Dommy.
Karman non so chi è. Invidio il vostro approccio matematico ai problemi, io al massimo so cos'è il Karma, grazie alle mie letture sulle filosofie orientali, ma temo che non c'entri nulla. Il kamasutra invece forse (viste le attività di jijuja) qualcosa c'entra.
Dico la mia:
Se il problema viene da una micro-interruzione del segnale positivo, che come giustamente dicevate dura da 1mS a 2mS, avevo pensato (per risolvere velocemente il problema) di fare questo:
Teniamo sotto controllo l'impulso positivo, e quando va a zero, prima di portare a zero anche l'uscita, vediamo che stia a zero almeno per un tempo più lungo di quelle che sono le interruzioni. Se ritorna positivo (in quei 0,1-0,3ms) L'uscita non la commutiamo a zero, se invece il segnale resta a zero per un tempo superiore, commutiamo l'uscita.
Questo porta ad un allungamento del segnale, tanto quanto è il tempo di attesa che applichiamo, ma probabilmente nessun ritardo nel controllo. La lungezza in più si traduce in un diverso posizionamento del servo che può essere corretto anche meccanicamente.
Questo sempre che il problema siano micro interruzioni, come penso.
Una cosa così, nei circuiti dei macchinari, si fa con un temporizzatore programmato per la funzione:" ritardo alla diseccitazione".
Spè che disegno un grafico...

[gibon]

filtro

Eqqueqqà...

Dommy, il circuito con il PIC mi attizza.. dovrò ricominciare a fare i C.S.

Un mio amico dice che li stampa sull'acetato con la getto d'inchiostro e poi impressiona, con una lampada UV, le piastre pre-sensibilizzate. Funzionerà?

Il pic un po' l'ho usato quando ho realizzato il Monty della De Agostini. Ho anche la scheda dimostrativa, con zoccoli per i vari modelli display.. A frequentare gente come voi dovrò tirar fuori dall'armadio tutto quanto..

Ma lo programmate con il PICBASIC proton ??

Grazie ciao!!

[gibon]

durata

Se invece il problema non è di micro-interruzioni, ma di errori nella lunghezza, con questo sistema, il problema non si risolve..

Dai.. ci do' un'okkiata..
Prima però vado a volare ancora un po'..

Ciaoooo!!!

[jijuja]

Ciao,è dalle 8.00 che stò scrivendo codice nel quore dell'amante...

gibon
durata
Se invece il problema non è di micro-interruzioni, ma di errori nella lunghezza, con questo sistema, il problema non si risolve..

Dai.. ci do' un'okkiata..
Prima però vado a volare ancora un po'..

Ciaoooo!!!

Grande,se riesci a registrare uno spezzone di traccia sarebbe la cosa migliore per "vedere"

Le vostre considerazioni mi spingono ad interessarmi al problema
( già promesso )
Allego una traccia disegnata di "fuori range"
ma è la cosa che mi preoccupa meno,
i 20mS non sono un tempo critico e nemmeno devono essere stabili mentre
la parte "alta" deve essere corretta.
Il filtro si baserebbe su questi principi:
intanto i fuori range vengono scartati a priori
ma il grosso del lavoro è : (ora cerco di spiegarmi)
se ho un "1" lungo 1mS ( stick tutto esempio DX )
il successivo "1" non potrà essere lungo 1.5mS ne tantomeno 2 mS
in quanto vorrebbe dire muovere lo stick da DX a SX in 2 centesimi di secondo ?!?!?!?
quindi questi non possono essere segnali corretti mentre
dopo l' "1" di 1mS potrà essere corretto un "1" di 1.05 mS
il che vuol dire muovere lo stick alla velocità di 150°/sec. ( plausibile )
( calcoli fatti a mente su supposizioni di corsa stick quindi non prendetegli in considerazione ) quello che volevo è rendere l'idea...
Poi possiamo esempio considerare che se stò muovendo lo stick
a DX regolarmente difficilmente darò uno scatto a SX anche se nel limite
della velocità di movimento che impostiamo come massima ammissibile
e potrebbe essere considerato scorretta anche questa situazione...
Pensiamoci...
Questo non è il filtro di cui parlavo ma una supposizione di filtro ad ok,
entrambe i codici si possono implementare e vedere quello che và meglio...

per dommy : ok per 2 servi,le velocità in gioco sono talmente ridicole per una MCU che non è assolutamente un problema...

Ciao,buona Domenica!
( io torno a scivere un pò di codice,oggi niente volo per mè,
mi riscatto Domenica prossima... )

[dommy]

glitch filter & other

Eqqueqqà...

Dommy, il circuito con il PIC mi attizza.. dovrò ricominciare a fare i C.S.

Un mio amico dice che li stampa sull'acetato con la getto d'inchiostro e poi impressiona, con una lampada UV, le piastre pre-sensibilizzate. Funzionerà?

si funziona, lo uso anche io, ma trovo piu semplice usare quei fogli a4 blu, non mi ricordo come si chiamano, li stampo con la laser, taglio il pezzetto e lo infilo nell'acido, tutto quà.

Il pic un po' l'ho usato quando ho realizzato il Monty della De Agostini. Ho anche la scheda dimostrativa, con zoccoli per i vari modelli display.. A frequentare gente come voi dovrò tirar fuori dall'armadio tutto quanto..

Ma lo programmate con il PICBASIC proton ??

io per le PIC uso il Pic Start PLUS con l'ultimo upgrade con la flash programmabile, lo comperai insieme al sistema di sviluppo della MicroChip, molti anni fà, e devo dire che fù un ottimo acquisto, valido e semplice e poi mai obsoleto.
Per gli AVR invece AvrStudio 4 con SK500 + addons, ma in realtà lo uso veramente poco, si fà tutto con i bootloader e varie interfacce ISP.

Grazie ciao!!

per il filtro guarda che quello che hai disegnato tu è la soluzione del problema, solo che il tuo è un approccio elettromeccanico invece che elettronico. Con una pic non fai altro che leggere questi impulsi e siccome ne conosci la temporizzazione, per esempio sai che dovrebbero essere da 1 a 2 ms e che il tempo di ciclo è di 20 ms, se qualcosa è diverso da quello che dovrebbe significa che è sbagliato per cui non lo usi ed usi il vecchio impulso.
Tieni conto che, semplificando i concetti, questo è quello che fà il PCM (salvo che nel pcm il segnale contiene la sua codifica) o che fanno tutti i sistemi cosidetti DSP, come appunto Multiplex IPD.
Cmq poco fà, in una pausa, mi sono messo a rovistare nel disco del PC dedicato al settore Micro per Aereomodellismo ed ho trovato quello che cerchiamo, mi sono ricordato che qualcosa dovevo avere da qualche parte perchè mi era servito nel Rafale biturbina, ed in effetti ho trovato parecchi progetti, i più interessanti sono solo tre, di cui uno fatto da RC-Cam, tutta roba degli anni 2000/2005 che usano PIC per filtrare i segnali, pulirli e rigenerarli, e, se necessario fare anche una specie di fail safe, che però a noi non serve.
A chi interessa posso mandare i zip con tutto il necessario, è roba molto ma molto semplice, facile e poco costosa, roba di pochissimi euro.
Le foto allegate sono un esempio di quello per singolo canale di RC-Cam che è poi forse il più evoluto come codice perche scritto tutto in codice macchina, ma c'è un progetto Francese che fà direttamente quattro canali.
Il progetto di Bruce Abbott è veramente carino e ben fatto, ma usa come ingresso il treno PWM intero e non il singolo canale.
Vabbe a chi serve PM con la mail a cui mandare.
Ciao Ciao
Dommy
p.s per tua info considera che il cosidetto "Kalman Filter" non è altro che un algoritmo matematico (piuttosto sofisticato ed indigesto) che non fà altro che predire cosa e come dovrebbe essere qualcosa sulla base di quello che è successo prima. Nel codice MK è usato intensamente così come la cosidetta "data fusion" che viene usata per processare il PID

[dommy]

Ciao,

Ciao,è dalle 8.00 che stò scrivendo codice nel quore dell'amante...

gibon
durata
Se invece il problema non è di micro-interruzioni, ma di errori nella lunghezza, con questo sistema, il problema non si risolve..

Dai.. ci do' un'okkiata..
Prima però vado a volare ancora un po'..

Ciaoooo!!!

Grande,se riesci a registrare uno spezzone di traccia sarebbe la cosa migliore per "vedere"

Le vostre considerazioni mi spingono ad interessarmi al problema
( già promesso )
Allego una traccia disegnata di "fuori range"
ma è la cosa che mi preoccupa meno,
i 20mS non sono un tempo critico e nemmeno devono essere stabili mentre
la parte "alta" deve essere corretta.
Il filtro si baserebbe su questi principi:
intanto i fuori range vengono scartati a priori
ma il grosso del lavoro è : (ora cerco di spiegarmi)
se ho un "1" lungo 1mS ( stick tutto esempio DX )
il successivo "1" non potrà essere lungo 1.5mS ne tantomeno 2 mS
in quanto vorrebbe dire muovere lo stick da DX a SX in 2 centesimi di secondo ?!?!?!?
quindi questi non possono essere segnali corretti mentre
dopo l' "1" di 1mS potrà essere corretto un "1" di 1.05 mS
il che vuol dire muovere lo stick alla velocità di 150°/sec. ( plausibile )
( calcoli fatti a mente su supposizioni di corsa stick quindi non prendetegli in considerazione ) quello che volevo è rendere l'idea...
Poi possiamo esempio considerare che se stò muovendo lo stick
a DX regolarmente difficilmente darò uno scatto a SX anche se nel limite
della velocità di movimento che impostiamo come massima ammissibile
e potrebbe essere considerato scorretta anche questa situazione...
Pensiamoci...
Questo non è il filtro di cui parlavo ma una supposizione di filtro ad ok,
entrambe i codici si possono implementare e vedere quello che và meglio...

per dommy : ok per 2 servi,le velocità in gioco sono talmente ridicole per una MCU che non è assolutamente un problema...

Ciao,buona Domenica!
( io torno a scivere un pò di codice,oggi niente volo per mè,
mi riscatto Domenica prossima... )

Vediamo se posso darti una mano con la roba tirata fuori dai meandri dei miei dischi, magari puoi partire da questi progetti e rielaborare così il tempo per andare a volare sarà incrementato, considera che per il codice del progetto RC-Cam purtroppo non ho i source perchè il tizio dice che usa delle librerire sue proprietarie che non vuole divulgare e poi molto è scritto in codice macchina.
Lui fà proprio quello che dici tu, sulla base di quello che ho ricevuto sò se il successivo può essere valido oppure nò, questo non è un kalman filter, ma rende l'idea, ovviamente i segnali fuori range, quindi affetti da disturbi di sicuro, vengo gettati subito.
Anche l'algo del progetto Francese è più o meno simile.
Ciao
Dommy

[biv2533]

ok.. alle prodezze del MK mi ero abituato... ma questo mi ha lasciato a bocca aperta...

Pazzesco!
Quel "crucco" amichevolmente parlando e' un vulcano di ideee oltre ad essere anche un bravo pilota.

Sono senza parole

Ora che i commenti sono in inglese e spero continui cosi, e' ancora piu' un piacere vedere l'evoluzione sul campo del progetto MK

[gibon]

oscilloscopio

Ecco le tracce dell'oscilloscopio con applicato il segnale per il servo della cam (J7)

Non si notano imperfezioni, infatti il mio servo è stabile e si muove con l'inclinazione sul nik.

Ho provato con un servo che era in kit con la MX12 graupner, ed uno che era con la DX7 Spektrum (digitale) e funzionano bene tutti e due.

Avevo anche un microservo della e-sky ma sul momento non lo trovo.

Strano però che il problema non si presenti.. non so che dire.. Mi diceva ddrake che lo fa anche a motori spenti come ho provato io.

Boh..

Nella terza immagine, ho avvicinato moltissimo la trasmittente, e il segnale radio si sovrappone a quello del servo che comunque non oscillava ugualmente..

riboh!

[gibon]

cam

Ho associato il canale della cam ad uno stick, e sembra funzionare bene.

Forse i difetti si notano solo con la cam montata.. Drake, spiegaci meglio.

Dommy il tuo MK come si comporta?

..oggi pomeriggio non c'è scampo: passeggiata in campagna.

Ciao a tutti.... vado alla pappa.

[ddrake]

Ciao a tutti.
Ach! il team degli scienziati pazzi è al lavoro!?

Ok, i problemi rilevati dalla community sul controllo del servo camera sono sostanzialmente due:

1- quello dei movimenti casuali del servo. E' più accentuato con alcuni servi che con altri.
Non sono continue ma, appunto, casuali.
Avvengono anche con motori spenti e MK fermo.
Ad esempio con dei micro servi DSY le oscillazioni arrivano ad essere sui +/- 5°.
Con servi standard DSY le oscillazioni diminuiscono in ampiezza ma sono comunque presenti.
Con il servo che utilizzo in questo momento (Graupner C577) si sente il servo ronzare ma senza che ci sia alcun movimento, quindi da questo punto di vista è abbastanza ok.
Ipotizzo che alcuni componenti nei servi facciano la differenza (i DSY sono cineserie economiche, comprati solo per fare delle prove).

2- i movimenti a scatto della camera.
Anziché avere un movimento fluido della camera in risposta al comando dato il movimento è 'a piccoli scatti'. Ovviamente si sente questo problema quando si cerca di effettuare una rotazione lenta della camera.
In MKTool c'è la sezione camera che permette di impostare i parametri di lavoro, quindi le variabili che influiscono su questo aspetto sono diverse.
Inoltre da radiocomando si può impostare la corsa del servo..
Quindi i parametri in gioco sono diversi.
Personalmente non sento molto questo secondo problema. Specialmente in compensazione non trovo che i movimenti della mia camera siano a 'scatti'.
Un video di prova che ho fatto:
Mikrokopter - 1st wireless downlink on Vimeo

Quello che sarebbe bene capire è se questi piccoli glitch nei movimenti sono dati da un refresh rate del firmware troppo basso (in questo caso la compensazione sul roll peggiorerebbe le cose) oppure se si tratta di 'disturbi' filtrabili in qualche modo.

Per quanto riguarda il firmware pensavo di fare una prova aggiungendo la funzione di compensazione e portando il segnale su uno dei canali liberi.
Ho visto come la effettuano sul Nick e dovrei solo fare lo stesso ma prendendo il segnale dal giro di Roll.
Ce la farà l'ATMEGA a gestire anche questo? Non lo so. Però come complessità computazionale dell'algoritmo è lineare, non siamo certo nel campo dei problemi NP
Vedremo, purtroppo il tempo è poco. Anche oggi mi devo dedicare al lavoro. Devo ancora riparare l'antenna del MK, figuratevi...

Ciao

[ddrake]

@Gibon:
Allora è tutto ok con il Ninja?
Ma 'sotto' il cofano' l'hai modificato con l'hub centrale più lungo o è ancora con le basette centrali del negozio MK?

ciao

[gibon]

cofanatura

@Gibon:
Allora è tutto ok con il Ninja?
Ma 'sotto' il cofano' l'hai modificato con l'hub centrale più lungo o è ancora con le basette centrali del negozio MK?

ciao

Il cofano (leggerissimo e rigido) è solo una protezione per l'elettronica, infatti ho rimontato la radio a 2,4 ch senza protezione non mi fidavo ad usare.

Sotto ci sono i centerplate dello shop.

In realtà sono un po' seccato dal fatto che la radio dx7 non funziona. Il MK diventa incontrollabile. Eppure con MKtool i canali sono OK, e con l'oscilloscopio l'uscita dell'interfaccia è perfetta!! Ho provato a cambiare disposizione ma niente da fare..

Con la radio a 40mHz funziona alla perfezione, infatti stamattina ho volato con quella e faceva un hoovering very-ok.. (senza altimetro).

Alla fine non ho avuto tempo di montare la bussola, ne il trasmettitore video.

Ho rotto alcune eliche perchè hanno toccato sul cemento quando provavo con la DX7. Si sono rotte in modo diverso: si è aperto il mozzo.

Secondo me vuol dire che il mozzo forato fino a 5 mm è più debole dell'attacco dell'elica (altrimenti si sarebbe rotto quello) e quindi la modifica non è conveniente. Una è addirittura "esplosa" cioè il mozzo si è aperto mentre ruotava, ma devo dire che non sono sicuro se ha toccato nella protezione dell'interfaccia, ma anche in quest eventualità si è ugualmente dimostrata troppo debole. Le ogive poi si allentano facilmente, se si mette un bloccante forte non si svitano + neanche quando vuoi smontarle, quindi... i propellemittner però non sono perfettamente diritti, e allora.. non so come fare per fare bene ..

Quindi con il foro di 3 mm si rompono perchè l'attacco al mozzo non è abbastanza robusto (dovrebbe essere fatto con un raccordo stondato e non a 90° così si formano cricche) se si porta il foro a 5mm il mozzo diventa ancora più debole dell'attacco dell'ala.
ciao..