FrSky Taranis - Lua scripts per tutti

[TermicOne]

Originalmente inviato da Oldone

Non la trovo ....qual'è?

nel menu' HARDWARE dalla 2.1.9 c'è la nuova opzione per disabilitare l'ADC filter

[Oldone]

Lo cercavo su companion, pensando che fosse un'opzione di compilazione.

[TermicOne]

Originalmente inviato da Oldone

Lo cercavo su companion, pensando che fosse un'opzione di compilazione.

....in effetti il piano di sviluppo era di metterlo in una opzione di compilazione (così aveva detto kilrah) poi hanno messo l'opzione nell'hardware della radio (meglio).

[marcodef]

Originalmente inviato da TermicOne

In questo week end ho fatto l'upgrade di OPENTX da 2.0.19 a 2.1.9

Per quanto riguarda il jitter ed il ritorno dei servi ho verificato che il jitter (senza filtro ADC) non è particolarmente aumentato rispetto alla 2.0 (sulla mia Taranis ho tirato le molle al massimo). In ogni caso ho eliminato il filtro ADC con l'apposita opzione (per eliminare il problema del ritorno al centro dei servi) e ho visto che applicando agli output dei servi una curva con piccolissima deadband al centro (-3/+3) anche il jitter viene completamente filtrato e non viene passato ai servi.

Ciao Luciano,

il jitter che misuravo io (sia con oscilloscopio, che molto semplicemente guardando sulla mappa segnali di un programmino tipo cleanflight...) cambia sostanzialmente, il problema e' che non c'e' solo al centro (io ho i gimbal modificati con i bilanceri in alluminio e le molle dure futaba..) ma in tutte le posizioni degli stick.

Ai tempi ci avevo guardato abbastanza e purtroppo non c'e soluzione, ci sono solo delle patch che limitano il problema creandone altri... anche' l'idea di mettere una dead band al centro non mi piace molto: aggiungerebbe latenza e non so come diventerebbe il feeling dei comandi (il 3% mi sembra anche piuttosto alto), senza contare che non risolverebbe il problema in tutte le altre posizioni degli stick.
Ora, il problema non e' poi cosi' grande, ma se uno investe in servi molto precisi e veloci su modelli importanti, e poi si perde in precisione e in consume dei servi, questo e' un dealbreaker per me. Poi qui si discute su risoluzione di 1024 o di 4096, di servi digitali superveloci e poi il limite diventa la radio... francamente non mi piace.

questa solo la mia opinione

[Oldone]

ma tanto vale parlarne.
Qesto problema del jitter quando si è "palesato"?
Da una versione di OpenTx in poi o c'è sempre stato?
Ho avuto per le mani la Taranis sin da quando è uscita nel 2013 e non me ne sono mai accorto.
Può essere che io sia un po troppo "dummy" per accorgermene , ma mi piacerebbe capire.

[marcodef]

Originalmente inviato da Oldone

ma tanto vale parlarne.
Qesto problema del jitter quando si è "palesato"?
Da una versione di OpenTx in poi o c'è sempre stato?
Ho avuto per le mani la Taranis sin da quando è uscita nel 2013 e non me ne sono mai accorto.
Può essere che io sia un po troppo "dummy" per accorgermene , ma mi piacerebbe capire.

il problema si e' manifestato dalla versione OpenTX 2.1.
Se cerchi sul tubo trovi molti video che lo mostrano, la questione fu che la 2.1 era stata progettata per avere piena compatibilita' con la X9E che utilizza encoder ottici invece dei potenziometri sugli stick, il FW che permette di leggere entrambi introduce il problema sulla X9D con i potenziometri, ci sono molte discussioni anche su github: purtroppo non e' risolvibile a meno di patch che introducono altri problemi (vedi ritorno al centro etc..). Ripeto: per me e' un problema che limita la "qualita'" della radio nelle sue funzioni piu' importanti che sono la precisione, la risoluzione dei servi e la latenza. Se queste magari possono essere considerate cose soggettive, in realta' pongono un problema che con servi digitali e di buona qualita' sono avvertibili anche senza essere un pilota dai sensi sopraffini e puo' causare un consumo maggiore degli stessi. Purtroppo penso che le versioni di OpenTX che ora dovranno garantire la compatibilita' con sempre piu' modelli diversi (turnigy, X9D, X9E e Horus) diventeranno sempre piu' complicate da gestire perche' le piattaforme HW sono parecchio diverse...

[TermicOne]

Il discorso del jitter è interessante (non mi ero accorto che non è solo al centro) ma in effetti (anche se ahimè qui l'ho introdotto io) in questo thread sui LUA script non è molto in topic. Si potrebbe aprire un thread apposito e chiedere ai moderatori di spostare qualche post in modo da proseguire sul nuovo thread. Da parte mia devo dire che non ho modelli particolarmente sofisticati come quelli che usa MarcoDef (che ringrazio per gli interventi e per la bellissima guida sulla programmazione alianti che consiglio sempre a tutti) e quindi probabilmente non riesco a rilevare in concreto questo problema che indubbiamente è presente e rilevabile in modelli con elettronica più sofisticata. Presto o tardi comunque vorrei passare alla 9E che, se ho capito bene, è esente da questo problema del jitter ed è più adatta al pilotaggio a pulpito che utilizzo, mantenendo tutte le opportunità offerte da OPENTX e dai LUA script.

[TermicOne]

Sempre a scopo didattico ho provato a realizzare con LUA script un paio di semplici pagine di telemetria utilizzando le nuove modalità di utilizzo dei sensori. In particolare ho giocato un po' con il sensore di tensione delle LIPO (FLVSS) utilizzando anche i valori calcolati dalla nuova versione 2.1 per avere la tensione della cella con valore minimo, la tensione delle singole celle e il valore minimo di tensione raggiunto dalle singole celle sotto carico durante il volo che ho ritenuto utile per verificare lo stato di bilanciamento delle celle a carico.

Il primo script (motor1.lua) realizza la pagina di telemetria da usare durante il volo. Vengono visualizzati in grande il tempo motore e la tensione totale della batteria. Viene anche visualizzata con una barra la tensione della cella con valore minore che utilizzo per decidere quando la batteria è scarica (cerco di non far andare la cella più bassa sotto i 3,3-3,5V sotto carico). A motore spento (solitamente a terra) viene anche indicata una stima della percentuale di carica residua (sempre nella cella più scarsa) utilizzando una curva derivata da alcune tabelle che ho trovato in diversi siti che stimano appunto la percentuale di carica residua in base alla tensione della cella a vuoto.



Il secondo script (lipocel.lua) realizza la pagina di telemetria da usare a terra dopo l'atterraggio per vedere lo stato delle singole celle a riposo e la tensione minima raggiunta dalle singole celle sotto carico durante il volo (quando non si ha tempo di guardare la radio). Lo script si adatta al numero di celle LIPO rilevate dal sensore.



Gli script sono realizzati in modo molto elementare, evitando cicli complessi che, seppur eleganti, renderebbero poco leggibile lo script. Sono stati utilizzati solo i pochi statement descritti nei primi post di questo thread. Tutto è commentato in italiano per consentire eventuali modifiche ed adattamenti.

...sicuramente anche questi script non sono certo la fine del mondo e faranno sorridere gli esperti di programmazione ma io mi ci sono divertito e ho voluto condividere questa esperienza per stimolare anche voi a provare queste interessanti funzionalità che richiedono un minimo di studio ma permettono di personalizzare in modo sorprendente la propria radio per accedere a dati ed informazioni che rendono più completa la nostra esperienza di volo RC.

Luciano

.

[LONGFLYER]

Ciao TermicOne, non conosco bene il Lua anche se un linguaggio procedurale (specie nelle basi) è sempre simile ad altrettanti linguaggi. Notando pertanto l'attributo LOCAL mi è venuto in mente un piccolo ma vantaggioso suggerimento. Premettendo che la prima qualità di un codice è l'efficienza, intesa come rapporto tra costo di processo e risultato, se ti va, vedi se esiste anche l'attributo STATIC (o equivalente) che dovrebbe offrire il mantenimento del valore di una variabile dentro una funzione. Se esiste, al costo di sei variabili in più (una per cella), invece di confrontare con 0 il valore di ciascuna cella appena letto, lo puoi confrontare con la relativa variabile aggiunta. In questo modo, stamperai sullo schermo un valore solo se questo non è già stampato con evidente minor costo di processo, visto che la variazione del dato letto è certamente più lenta della frequenza di lettura.

Buoni voli.

[LONGFLYER]

PS. Se il suggerimento è apprezzato, allora dovrai porre a 0 le variabile nuove appena dichiarate cosicché la prima volta tutti gli if saranno eseguiti ed all'interno di ciascuno if, appena leggi la cella, il valore lo copi anche nella variabile aggiunta.