ESC i2 vs ESC PWM

[redfox74]

Ciao a tutti,
in questi giorni sto' studiando nel dettaglio il problema relativo agli ESC PWM , premetto che avendo da sempre impiegato a ragion veduta solo ESC I2c per ovvie ragioni di risoluzione e di ottimizazione del cablaggio grazie all'utilizzo di una sola coppia di cavi per far transitare fino a 12 canali ora mi trovo a litigare quotidianamente per cercare di far funzionare ESC PWM di diverse marche e con diverse caratteristiche di setup taratura ecc ecc.

Premesso tutto questo veniamo a noi :
Nel forum la maggior parte degli utenti impiega micro arduino che tipicamente usano PWM a 8 bit per comunicare con gli ESC da qui la prima osservazione , per far funzionare questi ESC e' fondamentale alzare gli Hz di pilotaggio 400 e rotti e non piu' di 400 . Mi sono chiesto il perche' di tutto cio' e ho trovato una spiegazione , almeno penso . Piu si alza la frequenza di clock piu' il dutycicle corrisponde a grandi linee a 3 millisecondi quindi impieghi tutti e 254 punti di risoluzioni sul timer in una finestra piu' stretta , se vai oltre e ti porti a 700 hz per esempio non hai piu' lo spazio per arrivare a pilotare fino a 2 millisecondi. arrivi al massimo a 1.6 - 1.7 Avendo il codice del regolatore si potrebbe modificare il range in ingresso per guadagnare in risoluzione.
Ovviamente tutto questo cambia se usi un pwm che lavora a 16 bit anziche' a 8 Bit . Il micro piu' diffuso che ha questa caratteristica e' l'arduino mega che a quanto pare non ha problemi di gestione dei pwm a 16 bit anzi si puo' usare anche la configurazione FAST PWM.
Altra possibilità e' usare un PWM anzichè totalmente hardware gestito dagli interrupt timer ... cosi' si potrebbe sfruttare il timer1 di arduino che ha una risoluzione di 16 Bit.
Questa soluzione è impiegata ampiamente sulla multiwii per gestire i due canali aggiuntivi nella configurazione hexa e per gestire il servo di coda ...
L'unica cosa che non mi piace molto di questo approccio e' dover impiegare tempo macchina per fare una cosa che un pwm hardware risolve da solo senza appesantire il processore.

Io conosco queste librerie :
- Servo
- Analogwrite
- TimerPWM
- ServoTimer2
- TimerOne

Qualche altro consiglio ... mi sembra pero' che al massimo si arrivi a 120 punti di risoluzione nel range 1000 - 2000 micro secondi con 460 hz di periodo . Purtroppo usando un micro a 20 Mhz anziche' a 16 io vado a 700 hz e non riesco ad usare l'analogwrite .. qualche consiglio su come abbassare il periodo usando i prescaler ..? Per ora non sono ancora riuscito a venirne a capo .. anzi diciamo che su timer0 e timer2 potrei andare a 240 (16) che per me sono 300 e rotti hz meglio che i 150 a cui mi sono dovuto fermare ora .. andare a toccare il prescaler di timer0 pero' vuol dire cambiare la base dei tempi di arduino .. delle funzioni micros , delay ecc ecc .. un gran casino insomma ...
Un saluto a tutti e spero che qualcuno che ci ha gia' sbattuto il naso mi possa dare qualche buona dritta.

Un saluto
Roberto

[danveal]

Ciao a tutti,
in questi giorni sto' studiando nel dettaglio il problema relativo agli ESC PWM , premetto che avendo da sempre impiegato a ragion veduta solo ESC I2c per ovvie ragioni di risoluzione e di ottimizazione del cablaggio grazie all'utilizzo di una sola coppia di cavi per far transitare fino a 12 canali ora mi trovo a litigare quotidianamente per cercare di far funzionare ESC PWM di diverse marche e con diverse caratteristiche di setup taratura ecc ecc.

Premesso tutto questo veniamo a noi :
Nel forum la maggior parte degli utenti impiega micro arduino che tipicamente usano PWM a 8 bit per comunicare con gli ESC da qui la prima osservazione , per far funzionare questi ESC e' fondamentale alzare gli Hz di pilotaggio 400 e rotti e non piu' di 400 . Mi sono chiesto il perche' di tutto cio' e ho trovato una spiegazione , almeno penso . Piu si alza la frequenza di clock piu' il dutycicle corrisponde a grandi linee a 3 millisecondi quindi impieghi tutti e 254 punti di risoluzioni sul timer in una finestra piu' stretta , se vai oltre e ti porti a 700 hz per esempio non hai piu' lo spazio per arrivare a pilotare fino a 2 millisecondi. arrivi al massimo a 1.6 - 1.7 Avendo il codice del regolatore si potrebbe modificare il range in ingresso per guadagnare in risoluzione.
Ovviamente tutto questo cambia se usi un pwm che lavora a 16 bit anziche' a 8 Bit . Il micro piu' diffuso che ha questa caratteristica e' l'arduino mega che a quanto pare non ha problemi di gestione dei pwm a 16 bit anzi si puo' usare anche la configurazione FAST PWM.
Altra possibilità e' usare un PWM anzichè totalmente hardware gestito dagli interrupt timer ... cosi' si potrebbe sfruttare il timer1 di arduino che ha una risoluzione di 16 Bit.
Questa soluzione è impiegata ampiamente sulla multiwii per gestire i due canali aggiuntivi nella configurazione hexa e per gestire il servo di coda ...
L'unica cosa che non mi piace molto di questo approccio e' dover impiegare tempo macchina per fare una cosa che un pwm hardware risolve da solo senza appesantire il processore.

Io conosco queste librerie :
- Servo
- Analogwrite
- TimerPWM
- ServoTimer2
- TimerOne

Qualche altro consiglio ... mi sembra pero' che al massimo si arrivi a 120 punti di risoluzione nel range 1000 - 2000 micro secondi con 460 hz di periodo . Purtroppo usando un micro a 20 Mhz anziche' a 16 io vado a 700 hz e non riesco ad usare l'analogwrite .. qualche consiglio su come abbassare il periodo usando i prescaler ..? Per ora non sono ancora riuscito a venirne a capo .. anzi diciamo che su timer0 e timer2 potrei andare a 240 (16) che per me sono 300 e rotti hz meglio che i 150 a cui mi sono dovuto fermare ora .. andare a toccare il prescaler di timer0 pero' vuol dire cambiare la base dei tempi di arduino .. delle funzioni micros , delay ecc ecc .. un gran casino insomma ...
Un saluto a tutti e spero che qualcuno che ci ha gia' sbattuto il naso mi possa dare qualche buona dritta.

Un saluto
Roberto

Io utilizzo esc che hanno un range di ingresso 1100uS-1900uS e li piloto tranquillamente a 500hz (500hz come ben sai corrispondono a 2000uS )
A dire il vero sono salito fino a 525Hz (1905uS) e funzionavano ancora.
Molti dicono che 300hz o 400hz non fa differenza, nel mio caso una volta settato il pid a 500hz se scendo anche solo a 450Hz inizia ad oscillare leggermente tutto e devo ritarare il pid.
Io pero' utilizzo PWM hardware che hanno risoluzione di 1uS quindi 1000step anche se poi l'esc ha uno step ogni circa 3-4uS quindi circa200- 256 step.
Dico circa perchè ho fatto le misurazioni a vista, per farle bene andrebbe messo un sensore di velocita di rotazione.

[jhoexp]

Sapete che c'è anche un convertitore I2C -> PPM che sembra funzionare decentemente con alcuni regolatori economici:
Achetez votre convertisseur i2c -> ppm 4/6/8 voies sur Flash RC spécialiste du modélisme RC

[ElNonino]

Come ho anche scritto sul mio sito, per deformazione professionale sono un sostenitore del calcolo/processi paralleli e/o distribuiti; preferisco usare più microprocessori dedicati, acquisizione dati e comunicazione, calcolo, generazione PWM Out tutti che dialogano fra loro ad alta velocità (SPI).

In tale ottica per generare i PWM utilizzo i micro Cypress che sono dotati di svariati timers a 8/16/32 bit e di blocchi PWM dedicati e sincroni fra loro.

Cercare di far stare tutti i processi in un unico micro piccoletto come l' Arduino mi pare una forzatura.

Il mio progetto prevede, in futuro, la realizzazione di ESC pilotati da PWM ad alta velocità, spero in pochi giorni di poter fare i primi balzi a 'pollicioni' con il mio 'coso volante' (è quasi ultimato) così avrò riscontri oggettivi e potrò dare pareri più credibili.

[danveal]

Tra l'altro c'è anche la questione velocità, se si hanno 6-8 esc i2c che scambiano qualche decina di byte ognuno alla volta per ricevere il dato da inviare al motore, oltre ad eventuali byte di ritorno se si vogliono usare le info dagli esc, anche se il bus viaggia a 400Khz si arriva ad un refresh di 500hz o anche meno. Se poi nello stesso bus viaggiano i dati dei sensori si rallenta ulteriormente.
Preferisco di gran lunga il pwm anche alla luce della delicatezza del bus i2c riguardo i disturbi quando nei cavi di potenza che viaggiano vicino, circolano alte correnti ma sopratutto nel caso che un esc si bruci, il bus viene giù se non viene optoisolato.

Saluti a tutti.

[redfox74]

Terminato i test

Ciao a tutti,
ho terminato i test sui regolatori pwm mi sono fatto una cultura Riassumo brevemente quanto ho capito grazie al mio fido oscilloscopio
Premetto che Multipilot usa una versione piu' veloce di arduino che anziche' andare a 16 mhz puo' andare anche a 20 mhz . Sul mio micro 644p ho come in arduino 2 timer a 8 bit e 1 a 16 bit. I timer a 16 e a 8 possono collegare dei pin e pilotare pwm a livello hardware . Cosi' facendo il processore non viene impegnato nella scrittura del pwm sulle porte in uscita.
Con i timer a 8 bit si possono avere solo 256 punti di risoluzione , se piloti a 16 puoi avere fino a 65000 punti di risoluzione piu' o meno ..
Se si usa il pwm hardware pero' il duty cicle e' calcolato su tutto il periodo e quindi il periodo per esempio di 400 hz corrisponde esattaente a 2000 microsecondi e quindi visto che gli esc funzionano in un range compreso tra 1000 e 2000 micro avremo a disposizione solo 127 punti di risoluzione in realtà meno ... siamo comunque alla meta di un controller i2c.
Questo vuol dire che comunque qualsiasi applicazione che usi i pwm hardware di arduino non mega avrà al massimo 127 punti di regolazione per gli ESC da questo ne deriva che la risoluzione non sarà mai paragonabile ad un i2c con tutti i problemi di controllo che ne derivano .
Studiandomi il codice della multiwii ho visto che viene usato un metodo diverso dall'impiego di pwm hardware per i canali aggiuntivi ad esempio per le configurazioni hexa. Questo approccio al pwm è piu' flessibile perchè non associa a pin specifici il pwm , ma si puo' definire una qualsiasi uscita .
Il problema di questa libreria è pero' che i pin vengono gestiti in modo sequenziale e no parallelo come i pwm hardware quindi in realta' si introduce un ritardo tra un controllo ed un altro questo degrada di molto la qualità del volo perchè il periodo non è sincronizzato perfettamente specialmente se si superano i 50 hz e si hanno piu' di 2 servo a 400 hz ho osservato che il periodo variava tra i 400 hz e i 200 hz.
Questa variazione è dovuta ll'origine software di gestione dell'uscita. La risoluzione è decisamente piu' alta 1024 punti ma il periodo non è costante ...

Detto tutto cio' giungo alla conclusione che per avere un buon pwm o si ricorre all'i2c o si usa Arduino mega che supporta un numero piu' alto di pwm hardware a 16 bit .

Un saluto a tutti e se nelle mie valutazioni ci sono delle imprecisioni fatemelo sapere .
P.S.
ora devo prendere dei regolatori seri a basso costo PWM per provare Quadfox PWM in volo con qualcosa di standard cosa mi consigliate ?
Un saluto
Roberto

[jhoexp]

ora devo prendere dei regolatori seri a basso costo PWM per provare Quadfox PWM in volo con qualcosa di standard cosa mi consigliate ?
Un saluto
Roberto

Ciao Roberto, i regolatori PWM "seri" (Kontronik, Jeti, YGE, Castle) non sono sempre pensati per il pilotaggio in alta frequenza: hanno altre caratteristiche e funzioni (impostazioni di smothing, freno, soft start, governor, ecc...) nate per l'utilizzo su elicotteri o per particolari categorie di aeromodelli che ne fanno lievitare il prezzo, ma sono pressochè inutili (quando non dannose) per i nostri multirotori.

Ho costruito diversi multirotori con regolatori pwm da quattro lire che funzionano benissimo. Ho assemblato e piloto anche altri mezzi con regolatori I2C e la differenza nel volo mi sembra minima, nonstante sulla carta la risoluzione di comando sia nettamente inferiore.

Alla fine credo che molti si siano ormai convinti che serve a poco avere alte risoluzioni di comando, quando il pilotaggio avviene già ad alta frequenza e soprattutto il complesso motore/elica ha un' inerzia non trascurabile, che vanifica controlli estremamente precisi e veloci.

Io ho ormai diversi regolatori economici marchiati SP Strong Power (da 10, 18, 20, 30 e 40), tutti presi da giantcod e tutti funzionanti perfettamente a 490Hz. Secondo me sono un ottima scelta per iniziare. Non altrettanto adatti ai nostri scopi sono invece i turnigy o i towerpro, che hanno bisogno di modifiche al firmware per funzionare correttamente.

[danveal]

Ciao a tutti,

Se si usa il pwm hardware pero' il duty cicle e' calcolato su tutto il periodo e quindi il periodo per esempio di 400 hz corrisponde esattaente a 2000 microsecondi e

Mi suona strano, 400Hz ha il periodo di 2500uS

Per gli esc io uso i blackmantis a 495hz, settati a 16Khz per i motori medio piccoli e ad 8 Khz per i grandi.
Settandoli senza soft start, con timing automatico, no governor, no freno etc, e no controllo di tensione, in pratica si settano per le batterie NICD in modo che la soglia di taglio sia molto bassa e non intervenga mai.
Sono comunque d'accordo sulle limitazioni pwm di arduino che e' stato uno dei motivi per cui avevo scelto la scheda coridium, come dici tu bisogna passare al mega per avere pwm a frequenza costante e affidabile su piu' di 4 motori.

Ciao

[redfox74]

Mi suona strano, 400Hz ha il periodo di 2500uS

Per gli esc io uso i blackmantis a 495hz, settati a 16Khz per i motori medio piccoli e ad 8 Khz per i grandi.
Settandoli senza soft start, con timing automatico, no governor, no freno etc, e no controllo di tensione, in pratica si settano per le batterie NICD in modo che la soglia di taglio sia molto bassa e non intervenga mai.
Sono comunque d'accordo sulle limitazioni pwm di arduino che e' stato uno dei motivi per cui avevo scelto la scheda coridium, come dici tu bisogna passare al mega per avere pwm a frequenza costante e affidabile su piu' di 4 motori.

Ciao

Si è un po' piu' alto di 400 HZ ho detto esattamente perchè con l'oscilloscopio e tenendo d'occhio l'analogwrite si vede chiaramente che quando il dutycicle è a 255 va a sbattere sulla fine periodo. che è a 2000 micro secondi.
Saluti
Roberto

[redfox74]

Ciao Roberto, i regolatori PWM "seri" (Kontronik, Jeti, YGE, Castle) non sono sempre pensati per il pilotaggio in alta frequenza: hanno altre caratteristiche e funzioni (impostazioni di smothing, freno, soft start, governor, ecc...) nate per l'utilizzo su elicotteri o per particolari categorie di aeromodelli che ne fanno lievitare il prezzo, ma sono pressochè inutili (quando non dannose) per i nostri multirotori.

Ho costruito diversi multirotori con regolatori pwm da quattro lire che funzionano benissimo. Ho assemblato e piloto anche altri mezzi con regolatori I2C e la differenza nel volo mi sembra minima, nonstante sulla carta la risoluzione di comando sia nettamente inferiore.

Alla fine credo che molti si siano ormai convinti che serve a poco avere alte risoluzioni di comando, quando il pilotaggio avviene già ad alta frequenza e soprattutto il complesso motore/elica ha un' inerzia non trascurabile, che vanifica controlli estremamente precisi e veloci.

Io ho ormai diversi regolatori economici marchiati SP Strong Power (da 10, 18, 20, 30 e 40), tutti presi da giantcod e tutti funzionanti perfettamente a 490Hz. Secondo me sono un ottima scelta per iniziare. Non altrettanto adatti ai nostri scopi sono invece i turnigy o i towerpro, che hanno bisogno di modifiche al firmware per funzionare correttamente.

Ok ho ordinato questi : SP 18A ESC Speed controller Spero di avere azzeccato ... se vanno sono un vero affare

Sono pronto a volare con la mia bella Multipilot con il firmware Multiwii in versione quad x

Supporto Multiwii completato ho collegato:

• su i2c la wmp
• su 4 uscite PWM HW i 4 motori
• su ingresso Intterupt 2 la radio con la mia routine patchata per il PPM SUM.

.. per ora non uso i miei sensori che ho a bordo ... appena fatto il primo volo iniziero' a fare qualche aggiunta , penso che subito lavorero' sugli accelerometri ..

Saluti
Roberto