ETHOS X20 telemetrické obrazovky

[vprheli]

Zdravím příznivce RC létání.
Před nedávnem jsem si pořídil vysílačku X20 a operačním systémem ETHOS ve verzi 1.6.0 Do té doby jsem létal s Horus X12S OpenTx.
Začal jsem se pídit pro nějakých telemetrických obrazovkách ale byl jsem dost zklamán. Buď nefungovaly nebo zabíraly celou obrazovku s údaji, které jsem nepotřeboval nebo obsahovaly grafiku, která zabírala cenné místo. Preferuji menší jednoúčelové obrazovky které mohu poskládat jak potřebuji.
Rozhodl jsem se proto předělat některé svoje OpenTx widgety upravit pro ETHOS případně jiné někde publikované opravit aby byly funkční a případně přidělat nějakou tu funkčnost.

• BatCap

Tady jsem se inspiroval grafikou baterie firmy Zavionix. Ta zdrojové kódy vůbec nepublikuje, což mi přijde ne dobrá strategie. Zrovna u výpočtu zbytkové kapacity je potřeba vědět jak se počítá, obzvlášť pokud se jedná o data z proudového senzoru doplněného napěťovým, kde se vkládá kapacita baterie. Většinou se procento odečítá od této kapacity. Komu se ale nestalo, že přišel s ne úplně nabitou baterií. To je ale špatně. Komunikoval jsem s nimi, ale nebyla s nimi moc řeč. Použil jsem tedy jen jejich ikonu baterie a zbytek zmigroval z mého widgetu z OpenTx.
U LiPo senzoru se zobrazí všechny články a ty s nejnižším napětím jsou označeny.
Pokud nastavíte jak LiPo senzor a zároveň jiný zdroj napětí (třeba VFAS senzoru) najednou, bude preferovaný LiPo a z něj bude počítána kapacita baterie.
Podporované baterie

• LiPo
  High Voltage LiPo
  Lion
  LiFe

LiPo v plné obrazovce

• Vario

Jednoduchý widget zobrazující výšku a vertikální rychlost z vario senzoru

Vario

• DigClock

Digitální zobrazení údajů stopek. Jze je zadokovat do většiny políček ve třech barvách.

Stopky na plné obrazovce

• Modifikace h4lgpsmap

Kdo má touhu a GPS senzor v modelu, může použít tuto modifikovanou mapu se zobrazením polohy modelu. Oproti původní, již nepodporované, verzi dokáže automaticky vybírat mapu z až 32 možných map.

• Pravidla konvence pojmenování:
  1) map1.lua až map32.lua
  2) název bitmapy až 10 znaků
  3) pokud více než jeden zoom na stejné místo, pak podrobná mapa musí mít menší číslo. Mapa vyhledávání systému od 1..32
  4) Použijte originální generátor map https://ethosmap.hobby4life.nl
  5) Počínaje mapou číslo 9 je potřeba mapu[1..8].lua z generátoru přejmenovat na vyšší čísla.
  6) "mapnames.lua" se již nepoužívá

• komentář
  a) Stick simulator umožňuje přesouvat modely mimo zobrazenou mapu. Toto nastavení umožňuje testovat různá měřítka mapy.
  b) Pokud je model mimo okraj mapy, zůstane zobrazena poslední mapa a směr k modelu je znázorněn velkou šipkou v horní polovině mapy.
  c) Při ztrátě telemetrie se zobrazí červený rámeček
  d) Při ztrátě telemetrie se zobrazí poslední známé souřadnice modelu
  e) Změnu výchozí výchozí polohy, pokud je aktivována v konfiguračním menu, je třeba potvrdit. Tím se zabrání nechtěné změně.
  f) Widget lze zobrazit pouze na celé obrazovce bez názvu.
  g) Widget používá jiný identifikační klíč. Proto není možné použít původní složku a konfiguraci.
  Uložte soubory maps.bmp a map[1..8].lua, smažte složku a zkopírujte tuto verzi a mapy zpět.
  h) Součástí distribuce je i několik map v měřítku okolí mého domovského letiště v Praze Lipencích.
  i) Při testování map upravte výchozí souřadnice pro simulátor ve funkci ReadSensors().

Zobrazení mapy

• Layouts

Pokud nejste spokojeni s rozvržením obrazovky, které je integrováno do operačního systému, lze si nadefinovat svoje vlastní.

Nová rozvžení obrazovky

Všechny moje widgety jsou multijazyčné. Zatím publikované jsou v Angličtině, Němčině a Češtině. Rozšířit jazykovou mutaci lze velmi snadno úpravou jazykové tabulky. Jazyková mutace se použije automaticky podle jazyka vysílačky.
Dále pak každý widget zobrazí červený rámeček při ztrátě telemetrie a důležité poslední známé údaje.

Screenshoty jsou ze simulátoru který bohužel nedokáže měnit hodnoty senzorů. Proto ze nedivte že některé údaje jsou jaksi divné.

Poslední verze najdete vždy na https://github.com/vprheli/ETHOS-Lua

[pstasek]

Předně, pěkná práce a moc díky za ni! Určitě užitečná inspirace.

Osobně preferuji widgety bez závislosti na bitmapách, protože takové pak lze používat s libovolným rozlišením a velikostí widgetu a navíc grafika většinou moc nezapadá do zbytku hranatého uživatelského rozhraní vizuálně.
Hotové bitmapové widgety například většinou nelze adaptovat na horní displej XE, který je 320x240 a je ho možno vyplnit celý, rozdělit na poloviny vertikálně nebo horizontálně, případně na čtvrtiny. To samé platí pro použití v rámci custom layoutů.

Chybí mi tovární widgety podle typu zařízení. Nabízí se mít widgety s kompletní sadou telemetrie např. od TD R18/12, RB25/35, Xact serv, Varia, ADV stabilizace, a to v různých konfiguracích v závislosti na velikosti widgetu.

Mimochodem, koukal jsem do zdrojáku, protože řeším widget pro procentuální zobrazení stavu baterky a AdvGauge, který používám je optimalizovaný pouze pro Li-Pol a já používám Li-Ion, což ukazuje nižší stav, než doopravdy je. Všiml jsem si, že typ Li-Ion má maximální napětí 3,65V, ale to odpovídá spíš LiFePo. Typické nominální napětí Li-Ion je 3,6V a maximální napětí je 4,2V na článek.

[vprheli]

V jistém ohledu máte pravdu. U bitových map se nedá měnit měřítko. Jenomže na druhou stranu není možné psát kód tak obecně aby se zobrazil na libovolně velké obrazovce. To samo o sobě kód dost komplikuje. Navíc hranatá grafika upřímně není moc hezká. Můžete opáčit, že pilot má koukat na oblohu a model a ne čučet na displej vysílačky. V tom bych souhlasil, proto jsem se snažil důležité údaje udělat dost velké a čitelné. Také je potřeba vycházet z možností, které v Lua skriptu máme k dispozici. Hodně velký font tam třeba není vůbec, všechny jsou proporcionální a uživatelský není žádný.
Tím se neobhajuji. Lua skript není mým chlebem. Chtěl jsem s co nejmenším úsilím předělat widgety z OpenTx co jsem měl pro Horuse do X20 než začne jaro.
Ty napěťové tabulky zkontroluji. Našel jsem je v několika různých skriptech vždy stejné, což neznamená že jsou 100% dobře. LiPo jsem si kdysi počítal podle nějaké formule ta by měla být dobře. Zbytek "kontrol Cizí / kontrol Vlastní"

[pstasek]

Hezká/nehezká je většinou otázkou vkusu a není na to jednoznačná odpověď, proto to píšu jako, že je to moje osobní preference.

Vaše Lua programovací schopnosti jsou o světelný rok nad mými. Bohužel se mi nedostává času, abych do toho více proniknul. Proto vítám, že jste zveřejnil Vaše zdrojáky, které jsou navíc hezky komentované a možná mi pomohou pomoci si sám

Chápu, že každý Open Source projekt si většinou lidé šijí na míru sobě a až jako druhotný efekt je, že to poskytnou komunitě, rozhodně to neberte jako kritiku, spíš vděk.

U těch tabulek baterek je to hodně také o proudovém zatížení, ale pro účely zobrazení stavu bych se přikláněl k průměru 0 - 1A, kde je to celkem vyrovnané.

Používám packy z těchto článků: https://lygte-info.dk/review/batteries2 ... %20UK.html
(Jeti PowerIon 2600A)

[vprheli]

Dobrý den,
děkuji za komentář. Mezitím jsem sehnal nějaké křivky pro "problematické" baterie. Nenašel jsem tabulku po jednom procentu ale po deseti. tak jsem ji prohnal co možná nejlepším kvadratickým splinem který prochází všemi body a tyhle údaje jsem dal do aktuální verze widgetu. Není to ale na základě vybíjecí charakteristiky, která závisí jak na vybjecím proudu, tak teplotě ale technické specifikaci vazby mezi napětím článku a kapacitou.

[vprheli]

Mezitím jsem spáchal ještě jednu systémovou obrazovku. Ti co používají OpenTx ji asi znají. Zobrazuje většinu stavů na vysílači. Stavy přepínačů, slidery, trimy, stopky, logické spínače a 24 kanálů.

verze 1.0.3 pro X20

verze 1.0.2 pro X18

verze 1.0.2 pro X10/X12

Snad už tam jsou všechny ovládací prvky. Logické spínače jsou do 40 (X20) u zbytku do 20 ale zdroják je tak udělaný, že si je ten, kdo bude potřebovat může rozšířit. Jen se pak bude zápasit s místem na obrazovce.
Pokud někoho něco podnětného napadne, co by tam mělo být, dejte vědět.

Je tady nová verze 1.0.2. Má tam všechno co má X20 a co může pomoci doladit nastavení vysílače na jedné obrazovce.

Podle simulátoru jsem upravil kód pro X18. Pro X12/X10 není simulátor, tak jsem jen nasimuloval rozměr obrazovky. Nemám ale možnost ten kód vyzkoušet na skutečném HW. Tak se kdyžtak ozvěte.

Dával jsem sem ty verze dost rychle za sebou. Více lidí může najít rychleji chyby, nikdo se neozval, tak to snad funguje. S tímto widgetem teď na delší dobu skončím. Mám v plánu předělat umělý horizont, který mám pro OpenTx. A pak už bude konečně jaro a teplo a nebudu sedět u počítače ale na letišti.

Nové verze a všechny moje scripty už hledejte na https://github.com/vprheli/ETHOS-Lua

[vprheli]

Protože právě konfiguruji éro s řídící elektronikou MATEK F405 což je pokročilá jednotka s možností plného a samostatného řízení modelu, která je vybavena IMU jednotkou s tříosým gyrem a akcelerometrem,rozhodl jsem se že opráším další svoji telemetrickou OpenTx obrazovku s umělým horizontem.

První verzi si můžete vyzkoušet.

Není to tak dávno co jsem měl diskusi o tom, že někdo programoval umělý horizont pro FrSky přijímače se stabilizací. Ty ovšem poskytují tři zrychlení AccX, AccY a AccZ. Dotyčný se se mnou přel o to, že přeci lze tyto souřadnice snadno přepočítat na dvě proměnné, které slouží k řízení umelého horizontu. Tedy roll (rotace podél podélné osy) a pitch (rotace podél příčné osy, tedy čumák nahoru/dolu).
Nevím jestli akceptoval moje argumenty, že to nebude fungovat.

Možná bych tuto problematiku lehce nastínil.
Stabilizační přijímače, jak jsem psal, poskytují hodnoty zrychlení. A v tom je zakopaný pes. Všechno funguje krásně doma na stole. Vrtíte s přijímačem a umělý horizont správně ukazuje polohu přijímače.
Dokud.... Dokud nejste na letišti a pustíte model do vzduchu. Pak samotným letem dochází k zrychlení, které nekoreponduje s požadavkem na umělý horizont.

Jako příklad si můžeme vzít příosý akcelerometr kdy X osu dáme do směru letu, Y ve směru křídel a Z směrm k zemi (podvozku) Mějme model vodorovně. AccX a AccY budou v nule a Z bude rovno 1. Zvedneme-li čumák nahoru, začne se snižovat hodnota AccX směrem do záporných hodnot, AccZ začne klesat a AccY zůstane na nule. Umělý horizont bude ukazovat že letadlo stoupá.
To je v pořádku.
A teď vezmeme letadlo na letiště a necháme ho v ustáleném vodorovném letu. AccX, AccY budou také více méně v nule, AccZ v jedniččce. A teď přidáme plyn ale udržujeme model stále ve vodorovném letu.
Akcelerometr AccX ale už nebude v nule ale začne se pohybovat do záporných hodnot. A náš umělý horizont ukáže že model stoupá. Můžeme to trochu okecat tím, že AccZ je stále rovno jedné. Ale toto je jen jednoduchý případ. Namalujte si jak to vypadá v zatáčce.

Z toho ven snadno prostě nejde. Průměrné hodnoty nám nepomohou, trochu lépa na tom jsou digitální filtry, ale ty určitě nechcete programovat v Lua skriptu. Proto mají stabilizační jednotky ku pomoci tříosé gyroskopy, které pracují v součinnosti s akcelerometrem a mohou poskytnout plnohodnotné hodnoty roll a pitch.

Můj umělý horizont vyžaduje reálné hodnoty roll a pitch, které poskytují stabilizační řídící jednotky. Jsou dnes tak univerzální, že řídí jak klasické koptéry, delta křídla i letadla.

Umělý horizont na X20

Ještě malá poznámka. Čeština v konfIguraci funguje dobře ve verzi ETHOS 1.6.2, kde je opravena dlouhodobá chyba a nesrovnalost v jazykovém kódu, který vycházel z OpenTx, kde je "cz" a Ethos až do verze .1.6.1 mixoval "cs" a "cz" a zdá se, že to konečně sjednotil na "cs".

[Jara11]

Pánové , jste moc šikovný. Já jsem ale daleko skromnější. Stačilo by mi když už obrazovku rozdělím v ETHOSU na čtyři políčka, tak aby písmo bylo co největší dle těchto políček. Při mrknutí na displej a slabším zraku nablízko jsou na dením světle čísla malá a přitom je kolem spousta místa. I dyž dám na displej dva údaje, jsou opět stejně malý.

[vprheli]

Pánové , jste moc šikovný. Já jsem ale daleko skromnější. Stačilo by mi když už obrazovku rozdělím v ETHOSU na čtyři políčka, tak aby písmo bylo co největší dle těchto políček. Při mrknutí na displej a slabším zraku nablízko jsou na dením světle čísla malá a přitom je kolem spousta místa. I dyž dám na displej dva údaje, jsou opět stejně malý.

Máte naprostou pravdu. Pilot má koukat na model a né čučet na obrazovku. A když už tak tam má být velkým písmem to co pilota zrovna zajímá.
Tomu ale ETHOS moc nepomáhá. Vždyť přepínání vpřed a vzad přes možné telemetrické obrazovky není dobře vymyšlený. Za druhé. Programátoři jsou omezeni velikostmi fontů. Zatím nelze používat vektorové fonty jako v PC. Je to jasné, žere to zbytečně procesorový čas.
Další problém ke splnění Vašeho požadavku je co se chce na obrazovku zobrazit. Pokud si dělám kód pro vlastní potřebu, napasuji si ho co nejlépe. Ale pokud má být kód co nejvíce obecný jet o problém jak velikosti obrazovky u jednotlivých vysílačů, tak rozdělených zón, které navíc mohou být uživatelem modifikovány.
Tak to prostě je. Piloti si hrají s modely, programátoři si hrají s programováním a některé z nás baví oboje. A pak, ano, vzniknou různé obrazovky, které jsou sice hezké ale mnohým jsou k ničemu. Tak si je prostě do vysílačky nedám.
Na druhou stranu, nestalo se Vám někdy, že Váš větroň je i při velkém rozpětí moc daleko a Vy nevíte jestli letí v Vám nebo se nenávratně ztrácí? Pak pokud má model GPS pomůže jednoduchý widget, který zobrazí aktuální kurz a směr k pilotovi. Ale zkuste ho najít. Tak si sednete a naprogramujete ho. A protože máte pocit, že Vaše práce může být k užitku někomu jinému, zveřejníte ji.
A pak je poslední možnost. nechat si u někoho naprogramovat obrazovku přesně jen pro sebe.

Jistým způsobem Vám může pomoci skript Status https://www.rcgroups.com/forums/showpos ... tcount=623. Pokud jste si koupil rádio od pana Urbánka, myslím že ji má v české lokalizaci.

[Jara11]

Naprostý souhlas se vším. Nechci ale prudit,někdo rád litá,někdo rád vymýšlí různá vylepšení, která jsou pro provoz nepodstatné. Ale přesně, lítám větší era a tak každé kouknutí mimo model je riziko. Ještě že hodně věcí souprava umí sdělit i hlasem než hledání na displeji. Soupravu mám od p. Urbánka, ale bojím se cokoli cpát do vysílače,aby se minimálně pokoušela spolehlivost. Přece jen je to počítač a každý ví,když si to postaví hlavu,tak je každá rada drahá a nedej bože když to nastane za letu. Rád ale kouknu a hlavně musim zhodnotit přínos oproti riziku. J.