CleanFlight/SpeedyFlight aka Baseflight (Multiwii)

[tommyleo]

Quindi il livello alto marrone indica la lettura dell'esc.
Le righe rosse sono l'output della FC
giusto?

abbi pazienza.
ma chi cacchio gli dice al livello marrone di risalire dopo 2ms? Che poi alla fine del grafico in realtà rimane piatto.

Ma la linea rossa che poi finisce con la scritta "ESC gets S1 again while ..."
cos'è?

Allora parti da questa logica, c'è la FC che comanda ed invia questo "voltaggio alto"...per una durata da 1 a 2 ms, sul canale PWM.....l'ESC è sempre in ascolto e lo interpreta.

Quel piatto a fine grafico è solo visivo....in realtà se la FC è attiva, invia il segnale e quindi non sarà mai piatto....quel piatto si verifica se non hai una FC collegata!

Quella scritta rossa, "ESC gets S1 again while ..." indica che l'ESC riceve un nuovo valore quando comunque non può rinfrescarlo...perché sta ancora gestendo il segnale ricevuto in precedenza....(perdita di sincronismo)!!!

[bandit]

ok, ma non mi hai risposto ...

le righe rosse orizzontali? cosa sono? perché sono più lunghe di 2ms?

Nella mia testa credevo che già funzionasse tutto come oneshot. Mi sembra la cosa più logica. Quindi sto cercando di capire come invece è!

[tommyleo]

ok, ma non mi hai risposto ...

le righe rosse orizzontali? cosa sono? perché sono più lunghe di 2ms?

Nella mia testa credevo che già funzionasse tutto come oneshot. Mi sembra la cosa più logica. Quindi sto cercando di capire come invece è!

Le righe rosse "sopra" rappresentano il segnale "fresco" che invia la FC e sotto visualizza quando questo nuovo segnale viene "gestito" dall'esc non ottimizzato come sincronizzazione!!!

Questa è la logica del PWM....e sui microQuad è sicuramente tutto è all'estrmo, infatti anche gli ESC stanno subendo dei cambiamenti....proprio per rispodere più velocemente alle esigenze.

[danveal]

Per capire come funziona oneshot.

Supponi che ti metti d'accordo con un amico e che gli dici via telefono un dato ogni 10 secondi ( ciclo di loop ) . Lui si mette in ascolto ogni 6 secondi ( frequenza PWM )
Accade che al secondo 6 lui riceve il dato A da te, il secondo 12 lui riceve B al secondo 18 lui riceve ancora B al secondo 24 riceve il dato C, con 4 secondi di ritardo rispetto a quando lo hai comunicato ( al secondo 20 ) Questo è il funzionamento normale

Con ONESHOT il tuo amico riceve il dato esattamente quando lo comunichi quindi non ci sono ritardi tra quando comunichi il nuovo dato da inviare ai motori e quando questo viene recepito

[bandit]

grazie del tentativo Dan ... La logica è chiara ma non capisco i dettagli.
Ma se io do un dato ogni 10 secondi vuol dire che gli dico al telefono "AAAA ... " per 10 secondi o gli dico "A" ogni dieci secondi.

Perché nel secondo caso se lui sintonizza ogni 6 allora si sfasa sempre e ci incontriamo ogni 30 secondi.
Se è il primo caso allora lui si sfasa come dici tu di un sample al max. Però non trovo la corrispondenza nel grafico. Il segnale inviato dalla FC all'esc ad un certo punto va nello stato basso.

[tommyleo]

grazie del tentativo Dan ... La logica è chiara ma non capisco i dettagli.
Ma se io do un dato ogni 10 secondi vuol dire che gli dico al telefono "AAAA ... " per 10 secondi o gli dico "A" ogni dieci secondi.

Perché nel secondo caso se lui sintonizza ogni 6 allora si sfasa sempre e ci incontriamo ogni 30 secondi.
Se è il primo caso allora lui si sfasa come dici tu di un sample al max. Però non trovo la corrispondenza nel grafico. Il segnale inviato dalla FC all'esc ad un certo punto va nello stato basso.

Allora, seguo il tuo ragionamento, giustamente quel segnale basso, gli serve per capire quanto è durato il segnale alto e calcolare così il valore da inviare al motore.
Cioè se inviamo 1000μs il segnale basso sarà di altri 1000μs, se inviamo 2000 μs il segnale basso NON c'è!!! (o meglio, con una frequenza di 490Hz, abbiamo un periodo di 2040μs, e così i 40μs di segnale basso ci sono e l'esc legge così il 2000μs)

Però il periodo è fisso 2040μs, quindi questi segnali bassi variano come durata, in funzione del segnale alto inviato!!!

Quindi segnale alto + segnale basso = 2000μs + 40μs (di margine)

Guardiamo nel dettaglio il grafico:
L'esc parte a 0ms con il primo S1(primo valore), a 2,6ms la FC invia S2 il secondo segnale, ma l'ESC sta processando ancora S1(l'onda quadra partita a 2ms). A 4ms parte la terza onda(il tezo periodo) e l'esc calcola S2 (al segnale basso, a 5,8 ms), quindi sono passati 3,2ms da quando è stato inviata S2.

Nella sfiga maggiore, se S2 viene inviato proprio poco dopo l'inizio del periodo ed il valore inviato è alto, quindi circa 2ms, questo S2 potrebbe essere letto solo dopo 4ms.



Allora guardando quel grafico,

[bandit]

Tommy quello che mi dici è chiaro, ma non risolve i miei dubbi. Scusa evidentemente ho il cervello in pappa ... è pure tutto il giorno che lotto con windows e so cotto...

Faccio un'altra domanda. Per vedere su un oscilloscopio il segnale marrone, dove devo mettere la sonda? 10 parole max per la risposta thnks ...

[tommyleo]

Tommy quello che mi dici è chiaro, ma non risolve i miei dubbi. Scusa evidentemente ho il cervello in pappa ... è pure tutto il giorno che lotto con windows e so cotto...

Faccio un'altra domanda. Per vedere su un oscilloscopio il segnale marrone, dove devo mettere la sonda? 10 parole max per la risposta thnks ...

Anche meno di 10....grrrr non ho l'oscilloscopio, piacerebbe anche a me!

[bandit]

cioé? non lo sai! eh allora come fai a spiegarmi quello che voglio sapere ...

[danveal]

cioé? non lo sai! eh allora come fai a spiegarmi quello che voglio sapere ...

Il segnale marrone è il cycle time del codice, ovvero il ciclo di loop. In quel grafico è riportato 2,6 millisecondi, significa che la flight control invia il dato nuovo agli esc ogni 2,6 millisecondi. Non puoi vederlo con l'oscilloscopio a meno che non inserisci nel codice una istruzione che ad ogni ciclo terminato invii l'impulso su un piedino di uscita.

Ritornando alla semplificazione che avevo fatto, significa che soltanto alla fine dei 10secondi viene inviato un nuovo dato, il resto del tempo viene inviato il dato vecchio.

Nella realtà i tempi non sono così tanto diversi, oneshot da solo un piccolo vantaggio che si potrebbe notare quando si richiedono le massime prestazioni assolute, come nel caso dei microquad racing.

[bandit]

dan, il ciclo marrone è di 2ms. Quello è il segnale di output della FC.
Rivedendo, ma sopratutto risentendo, 20 volte il filmato di dominic forse ho capito ed ho capito anche cosa mi fuorviava.
E Dan mi conferma quello che stavo pensando anche se forse s'è sbagliato sulla curva marrone.

Base e Clean hanno un parametro, di cui abbiamo parlato tante volte, che è motor_pwm_rate. di default è 400Hz ed indica quante volte al secondo il dato esce sul piedino di output verso l'esc. L'esc è sempre sincronizzato con questa uscita, in quanto il timing glelo dà il livello basso in uscita mentre io credevo che l'esc non si sincronizzasse con l'output della FC. Invece è proprio il dato che esce sul piedino di output che è sfasato con il looptime.
Quindi è la FC che se la canta e se la suona.

Ditemi che è così' vi prego ...

Ora provo a fare uno screenshot del video

[tommyleo]

cioé? non lo sai! eh allora come fai a spiegarmi quello che voglio sapere ...

Leggo il codice, il software parla chiaro!

p.s. Faccio l'ultimo tentativo, cancella tutto nella testa!

Parti dal fatto che gli ESC escono con un dato, la frequenza di aggornamento!

Tra l'altro quando ti parlavo di 500Hz stiamo parlando dei KISS, BS/Afro e altri lavorano sui 400Hz (e prima erano molto più bassi)

Prendiamo quindi ad esempio 400Hz, un esc normale risce a campionare 400 volte in un secondo il segnale che gli viene inviato, questo è un dato fisso, da codice non lo modifichi, l'ESC ha il suo periodo. (classico del pwm)

Quindi utilizza 2,5 ms per il suo periodo, ripeto fisso!

In questo caso abbiamo 2ms per segnale alto e segnale basso + 0,5ms di segnale basso(diciamo buttato via) rispetto a 40μs a 500hz. E già questo è il primo vantaggio dei KISS.

Quindi quando la scheda invia il dato sul canale PWM, è normale che l'esc lo rinfresca solo alla partenza del successivo campionamento, non può cambiare l'onda quadra in corsa, e ballano almeno 4ms, a secondo di quando cade il looptime e dalla durata del nuovo impulso inviato che potrebbe durare 2ms = 2000 di throttle!

Adesso guardiamo il codice di cleanflight, questo dice tutto:


motors[motorIndex] = pwmOutConfig(timerHardware, PWM_TIMER_MHZ, hz / motorPwmRate, idlePulse);

Qui setta la frequenza di aggiornamento (hz / motorPwmRate = hz=1.000.000/motorPwmRate=400 (questo è anche modificabile da cli, ad es. 500 con i kiss...ma meglio 490 per lasciare del segnale basso)


if(feature(FEATURE_ONESHOT125))

se ONESHOT

motors[motorIndex] = pwmOutConfig(timerHardware, ONESHOT125_TIMER_MHZ, 0xFFFF, idlePulse);

Se fai caso invia un valore che non ha senso "0xFFFF=65535" come frequenza/periodo, proprio perché non esiste più il periodo fisso, ma è il firmware oneshot dell'esc che si sincronizza con il colpo (l'inizo del voltaggio ricevuto sul canale).

Notte!

p.s. Infine lavornado da 125 a 250ms è comunque otto volte più veloce...anche se non si sincronizza!

[bandit]

Tommy, mi sa che abbiamo detto la stessa cosa.

Posto uno screenshot del video.
da 0:35 a 0.40 lui dice (credo):
what we can see down here, this is when the main loop start (A), this is when the motors have been written to. ( quest'ultima cosa dei motori written non la capisco ma la posso intuire.

e poi

0:42
This is the amount of time the main loop takes to start (A) and re-start (C).

Quindi quell'onda quadra in basso è esattamente il segnale che dice Dan e che caratterizza il looptime. Solo Dominic sa dove prenderlo ... e neanche il povero Tommy può saperlo.

Sopra ci sono due output dei motori presi sulla FC.
Si possono leggere (male nello screenshot) i valori del periodo dei segnali dei motori (2.5ms - 400Hz) e quelli del looptime in basso a dx (3.5ms).

E fino a qui ci siamo, no?

[tommyleo]

Allora ci siamo?

p.s. Quel segnale basso è facilissimo da prendere, è uguale a 0V...e lo prende l'esc per capire la fine dell'impuslo(pulse width del pwm)!!!

[bandit]

Dal minuto 1 stringe la scala e dice
"the mainloop starts and stops, the motors are written to and the signal is generated".

nel video si vede molto bene lo sfasamento temporale.

Quindi, a parte il disegno che rimane secondo me fuorviante, se è vero quello che ho detto, ero stato tratto in inganno dall'onda del looptime, che credevo fosse una uscita fisica, mentre in realtà indica uno stato e dal fatto che avevo interpretato con "motor output" l'output dell'esc e non il pin della FC.
In più la confusione aumentava perché immaginavo che fosse l'esc a sfasarsi rispetto all'uscita mentre è proprio l'uscita che si sfasa.

Insomma è come se la mano si muovesse in ritardo rispetto al comando che le dà il cervello... quindi se voglio acchiappare una cosa che cade, non ci riesco perché il comando che la mano riceve è sfasato rispetto al calcolo che aveva fatto il cervello elaborati i segnali che provengono dagli occhi ...

GIUSTO?! vado a dormire sereno?

e domani ragiono sullo oneshot ...