MikroKopter

[con air]

[QUOTE=Bobo67;3194918]Ecco il video del collaudo del mio nuovo hexino con esc RC-Timer 30A riflashati con "SimonK" firmware, oscillatore a 16 KHz e PWM a 500 Hz (AfroI2C).
..... devo andar su di motor smooth Marco....

qualcuno sa spiegarmi cosa è motor smooth e quando si regola??

[Bobo67]

E' ottimo il volo, anche la tua prova è ottima, su rcgroups nel th relativo ho sempre visto non piu' di qualche hovering e mi interessava il comportamento proprio nelle situazioni che hai fatto vedere.
Ad un certo punto mi e' sembrato di vedere un pesce rosso dentro la boccia
Ciao

Grazie a tutti per i commenti positivi!
Danilo, tu che ne sai di lettere fammi una cappottina migliore invece che far battute, anche perchè sto finendo il mangime per i pesci!

[AleBS]

Senza togliere di merito a nessuno, ma ce ne fosse di gente come Marco che condivide, studia, prova (ogni tanto con qualche contrattempo... ) e rende disponibile per gli altri quanto ha provato e testato, solo tanti complimenti !!!

[Mayer]

ottimo Marco complimenti bel lavoro

[Mayer]

Ciao a tutti,
volevo riportare l'odierna e forse ennesima esperienza quotidiana.
Da qualche tempo con i regolatori BL v2.0 abbiamo qualche problemuccio di temperatura.
Abbiamo quindi risolto montando opportune alette di raffreddamento e in effetti sino a 4/5 giorni fa il problema pareva risolto.
Oggi con 28/30 gradi di temperatura esterna ci siamo ritrovati con questo simpatico scherzetto: a circa 30 metri di quota in hovering, l'esa dopo circa 2 minuti ha iniziato a roteare su se stesso, come per un calo di potenza di un motore e ha avuto forti difficolta' a rimanere in aria.
Con una discesa controllata e' fortunatamente finito sulle fronde di un albero e poi si accasciato al suolo.
Immediate le prime verifiche, e mi sono ritrovato con alcuni regolatori sui 60° circa e gli altri decisamente ben oltre.
Stessa cosa per i motori associati ai suddetti regolatori.
I motori sono i classici AXI 28xx roba da 140watt, il consumo per singolo motore e' di circa 5 ah in hovering e 8 a tutta canna.
L'alimentazione e' a 5s.
Il peso dell'esa e' circa 4,5Kg

Quello che non capisco, leggendo anche le varie discussioni qui sul forum e' come mai questi regolatori che sulla carta dovrebbero tenere sino 35/40ah di picco scaldino cosi' tanto anche con pochi ampere e vadano in protezione.

Qualcuno ha qualche idea/soluzione?

per ritornare al discorso, questa mattina ho messo l'okto al banco ben ancorato per vedere le temperature , il mezzo dopo 3 minuti 70% di gas temperature tra i 70 e 95 gradi all'ombra con cappottina su senza aria i bl hanno staccato e sono andati in protezione, calo di potenza ovviamente , consumi di media 8A a motore
le lipo avevano ancora un buon 60% di autonomia, fase successiva montaggio dissipatori , alzamento della cappottina in modo da far arieggiare maggiormente i bl e foratura della stessa per ricircolo aria. seguiranno altri test a modifiche effettuate.

[danveal]

Grazie a tutti per i commenti positivi!
Danilo, tu che ne sai di lettere fammi una cappottina migliore invece che far battute, anche perchè sto finendo il mangime per i pesci!

Non ti conviene che te la faccia io, tieniti la tua fidati
Volevo chiederti una cosa ( se non ti sei offeso )
Il firmware SimonK ha un range PWM da 1060us a 1860us.
Sull'afro converter che range hai settato?

Comunque flasharò dei blueseries e li proverò intensivamente sul mio armaquad prima di installarli su MK, non vorrei infatti che mentre sto sorvolando delle tipe in topless sulla spiaggia accada qualche inconveniente

[Bobo67]

Ho lasciato il default Danilo, quindi credo 1000-2000, credi che sia meglio affinare il range dandogli direttamente i valori che riporti?
Forse è per quello che al minimo alcuni motori dopo che atterro si fermano, anche se il minimo è settato bene da MKTools.
Sicuro sul "1060/1860"?
Ho visto altri usare l'AfroI2C e lasciare le impostazioni del range al default, ma ci metto un attimo a cambiarle.

[danveal]

Ho lasciato il default Danilo, quindi credo 1000-2000, credi che sia meglio affinare il range dandogli direttamente i valori che riporti?
Forse è per quello che al minimo alcuni motori dopo che atterro si fermano, anche se il minimo è settato bene da MKTools.
Sicuro sul "1060/1860"?
Ho visto altri usare l'AfroI2C e lasciare le impostazioni del range al default, ma ci metto un attimo a cambiarle.

E' riportato qua https://github.com/sim-/tgy leggi "Throttle Calibration and Programming"
Come sai il converter non fa altro che convertire i valori mk 0-255 in valori pwm.
Da 1000-2000 hai 1000us che diventano step da 3.90us
Con il range giusto hai 860us che diventano step da 3.35us, insomma aumenta la risoluzione e la precisione.

Ciao

[Bobo67]

Mi era sfuggito, grazie Dan, domani lo imposto e rifaccio la calibrazione del throttle range agli esc.
Ecco forse perchè avevo problemi quando mettevo al minimo i motori senza disarmarli, alcuni si fermavano.
Dico una fesseria, ma con un range più ampio dato che la calibrazione degli esc comunque si adegua all'AfroI2c alla fine non è la stessa cosa?
Cambia solo il range degli step, ma sono sempre 256...

[danveal]

Mi era sfuggito, grazie Dan, domani lo imposto e rifaccio la calibrazione del throttle range agli esc.
Ecco forse perchè avevo problemi quando mettevo al minimo i motori senza disarmarli, alcuni si fermavano.
Dico una fesseria, ma con un range più ampio dato che la calibrazione degli esc comunque si adegua all'AfroI2c alla fine non è la stessa cosa?
Cambia solo il range degli step, ma sono sempre 256...

Ma è proprio perche aumenta il range degli step che non hai piu' 256, o meglio ne hai 256 ma oltre 1860 l'esc non accetta. In pratica con range 1000-2000 raggiungi il massimo (1860) a 220 Mentre il minimo (1060) lo raggiungi a 15, il range diventa 15-220 e perdi 51 step. Se invece calibri gli esc tramite l'afro che in calibrazione gli invia il suo range allora si ne hai 256 anche se con step piu' grossi.

[Bobo67]

Giusto, ho detto una caxxata.
Ho mandato un messaggio a Timecop, vediamo cosa risponde, ma mi confermerà la tua corretta tesi.
Quindi ora mi trovo con il throttle al massimo "ridotto", infatti mi sembrava che "quasi a canna" non tirasse come mi aspettavo.

[lanzo]

Finalmente buone notizie, oggi ho sostituito l'esc difettoso dell'Octo con uno dell'Hexa (quello con il problema del magnetometro) ed ha funzionato tutto, non ho testato il magnetometro in casa, ho montato tutto come da manuale e sono andato al campo, la prua è ben ferma anche variando il gas, dovrò testare con il peso finale ma sono ottimista.

Piuttosto alte le temperature dei BL oggi, con un peso di 3640g consumava circa 35A in hovering e il Bl più caldo ha raggiunto i 70°, il più freddo 51° senza capottina, firmware 0.88.

[dommy]

E' riportato qua https://github.com/sim-/tgy leggi "Throttle Calibration and Programming"
Come sai il converter non fa altro che convertire i valori mk 0-255 in valori pwm.
Da 1000-2000 hai 1000us che diventano step da 3.90us
Con il range giusto hai 860us che diventano step da 3.35us, insomma aumenta la risoluzione e la precisione.

Ciao

Buon giorno a tutti e buona Domenica,
Mi allaccio alla discusiione per fare qualche considerazione, premetto che ho appena ordinato 8 esc già flashati Simonok direttamente da TC insieme ad un converter per fare delle prove vista la curiosità che mi avete fatto venire...... però volevo comunque fare qualche considerazione, anzi, se non mi sbaglio e non ricordo male, queste considerazioni furono già fatte tempo fà nel vecchio 3D.
Pensavo questo: da quello che leggo, ed anche dai commenti di Marco ma anche da altri commenti su RCGroups, sembrerebbe che la soluzione convertitore I2C<-->PWM, assieme a degli ESC veloci, migliori la stabilità e la rapidità di correzione di un MK grazie alla guadagnata velocità di elaborazione dei dati verso i motori.
Quà c'è qulcosa che non mi torna, provo ad esplicitare il mio pensiero, noi usiamo sempre la stessa fonte di correzione dell'assetto, e cioè i dati I2C che arrivano dalla FC, poi, invece di mandarli direttamente ad un ESC che grazie ad un micro ATMega, li interpreta direttamente ed agisce conseguentemente su dei mosfet e quindi in pratica sul motore, li mandiamo ad un convertitore che, grazie ad un ulteriore micro li converte da dati I2C in PWM e poi mandiamo questi dati PWM ad un altro ATMega che comanda i mosfet e quindi il motore.
E quà qualcosa mi sfugge, facciamo qualche considerazione:

- con questa configurazione di sicuro introduciamo un ritardo dovuto alla conversione I2C<->PWM, ritardo tra l'altro dipendente dal tipo di micro usato, dal suo clock e dalla bontà del codice e quindi non sempre uguale
- di sicuro introduciamo degli errori dovuti anche ad una doppia conversione di dati digitali, quindi arrotondamenti etc.etc.
- di sicuro è importante fare un buon lavoro di settaggio per allineare quello che tira fuori il converter e quello che si aspettano gli ESC.
- di sicuro abbiamo aumentato la possibilità di guasti dato che abbiamo aggiunto altri dispositivi elettronici, ricordiamoci che c'è un micro e quindi un quarzo.
- di sicuro tutti i datii I2C vanno su un unico dispositivo e nel caso di una sua rottura, o di un problema sui cablaggi, leggi rottura fili, perderemmo TUTTI i motori nello stesso momento, cosa che nel caso dell' I2C avviene solo nel caso di guasto del bus, ma il guasto di un ESC si ripercuote solo su un motore e non su tutti.
- di sicuro abbiamo aumentato la complessità del sistema ed il numero di componenti quindi abbiamo aumentato i punti di possibile guasto, l'assorbimento, la generazione di rumore di dovuta ai clock ed ai micro.
- di sicuro abbiamo mancato ad una missione, fare dispositivi KISS (keep it simple, stupid!), come sapete quello che non c'è non si rompe
Insomma cosa mi sfugge? perchè dovrebbe essere meglio?
Ma non è per caso che il problema sia semplicemente la bassa qualità del codice degli ESC MK?
Se dovessi affrontare questa situazione come una attività lavorativa, come un progetto, la scelta del convertitore non la prenderei neanche in considerazione, l'unica scelta corretta e razionale sarebbe quella di pensare ad un BL veloce e comandato in I2C.
E comunque, tolto il discorso economico che ha un suo peso e per cui di sicuro la scelta di ESC commerciali è vincente, non posso credere che la soluzione con convertitore introduca dei vantaggi, la scelta convertitore introduce un vantaggio economico ma non perdiamo di vista la realtà che per mè signiica:
accetto un peggioramento del quadro globale a vantaggio dell'aspetto economico anche perchè le qualità di volo non sono degradate significativamente, ma non posso dire che ho ottenuto un miglioramento della catena di comando o della sicurezza.
Quale è la Vs. Opinione?
Saluti
Dommy

[danveal]

non perdiamo di vista la realtà che per mè signiica:
accetto un peggioramento del quadro globale a vantaggio dell'aspetto economico anche perchè le qualità di volo non sono degradate significativamente, ma non posso dire che ho ottenuto un miglioramento della catena di comando o della sicurezza.
Quale è la Vs. Opinione?
Saluti
Dommy

Ciao e Buona Domenica,
io la penso esattamente come te, il firmware simonK aumenta la velocita' di risposta dell' esc rispetto al firmware di serie, elimina il filtro in ingresso e lo ottimizza per i nostri usi.
Quindi usare un esc fw simonK su una fc che esce in pwm migliora le prestazioni rispetto all' esc standard e le rende molto simili ad una fc che esce in i2c e usa esc i2c.
Diverso il discorso sull'aggiunta del convertitore in un sistema i2c, come nel caso MK, come fai notare introduce inevitabili ritardi, piu' motori ci sono e piu' ritardo introduce, per questo motivo ero un po dubbioso sull'effettive prestazioni su MK nel volato che va oltre l'hovering, ma il video di Marco ha dimostrato che nonostante tutto le prestazioni sono ottime.

[Bobo67]

Quoto assolutamente il vostro pensiero, sono tutte considerazioni che avevo già fatto.
E' ovvio che viene introdotto un ritardo, con i BL ed il bus I2C diretto si "ragiona a 2 KHz" e bidirezionalmente, quindi è impossibile che il sistema col converter sia a pari prestazioni.
Riguardo alla questione "se si rompe il converter" è inevitabile, o il quad schizza con i motori a palla oppure si spengono tutti di botto.
Non tralasciamo però i vantaggi:

1) spesa per gli esc irrisoria, anche in caso di rottura rimpiazzarli è roba da poco
2) fine dei problemi sul bus I2C (l'isolatore i2c non è necessario), se un esc va in palla non manda in tilt tutti gli altri, sempre che non metta in corto il suo ingresso pwm e massa, praticamente impossibile
3) differenza (sul mio setup) non tangibile rispetto ai BL, nessun degrado prestazionale
4) possibilità di utilizzare motori molto più potenti
5) firmware degli esc in continua evoluzione

Ricordiamoci che Wookong è "piantato" ed utilizza esc normali, manco riflashati.
Questo dimostra che ragionare a "500" o a "2000" non serve a molto se poi i motori non hanno abbastanza reattività sulle microcorrezioni.
A mio avviso i BL sono ottimi esc se opportunamente alettati e collegati "a filo" senza utilizzare le "DB cacca" di MK.
Il vero trucco è il saper centrare un buon setup e non far caxxate nel cablaggio, compromessi a parte.