Že by horizont?

[ellet]

Script pro "velký" Taranis. Konfigurační hodnoty lze nastavit (upravit) v editoru. Směr letu "od sebe" lze nastavit přepínačem. Výchozí nastavení je přepínač "se" (lze taky změnit). Všechny měnitelné parametry jsou na začátku souboru a jsou popsány.

Pro_Taranis.zip

(2.19 KiB) Staženo 698 x

[ellet]

Ještě jeden (a asi poslední) horizont k testování. Tentokrát s univerzální možností umístění na plochu a čistě kreslené scriptem, bez podpůrných obrázků.
Lze změnit barvy ukazatele směru. Barevné provedení jsou dvě.
Při volbě widgetu v menu se při každém najetí na widget, změní barvy ukazatele směru. Po potvrzení se však barvy opět změní. Při volbě widgetu je tedy třeba zvolit barvu kterou nechci.
Když chci změnit barvu již umístěného widgetu, stačí ho znovu vybrat a potvrdit.
Pokud je widget spuštěn vícekrát (t.j. na různých místech), změní se barvy u všech.
Bylo by možné i vícenásobné spuštění v různých barvách, protože to prakticky asi nemá význam (a je to komplikovanější), zvolil jsem tuto jednoduchou variantu.
I zde je možné vypnout zobrazení ukazatele směru a i ostatní parametry nastavení jsou stejné jako u předchozí varianty.
A protože jsem si už dost vyhrál, další varianty nebudou.

HzontUni.zip

(5.66 KiB) Staženo 638 x

[Kenumis]

Zkusil jsem několik cest. Nejjednodušší je použít sw "openXsensor" a zvolit hw, který tento sw podporuje. Zvolil jsem: Arduino Mini Pro 5V (není podmínkou), MPU6050 protože jsem ho měl doma a BMP180 kvůli ceně (a taky bylo doma). Místo BMP180 jsem původně zamýšlel použít MS5611, ale tam hodně vzrostla cena a to ztrácí půvab levné, užitečné "hračky". Ještě je třeba se trochu zamyslet nad napájním. Moje destičky měly vlastní stabilizátor napájecího napětí, proto jsem mohl zvolit 5V Aruino bez další destičky převodníku. U většiny dnes nabízených baro senzorů ale stabilizátor nevidím, potom bych volil 3V Arduino.
Nevím, jakými znalostmi a jakým vybavením disponuješ. Proto jen upozorním, že pokud zvolíš i možnost měřit napětí, je třeba mít alespoň levný voltmetr a trochu si pohrát i s odory.
Zatím jen stručně postup. V "openXsensor" jsou dva konfigurační soubory, tam je potřeba vše nastavit. Je tam i celkem jasný popis.
Potom je třeba zdroj v Aruino IDE přeložit a nahrát do destičky Arduina.
V zapojení komponent nelze moc chyb udělat, ale pokud bude potřeba, něco nakreslím, můžu i nakofigurovat, přeložit...
Myslím, že jako základní info by to mohlo stačit.

Zdravím!!!
Tak jsem se konečně pustil do "stavby" čidla a došel jsem až k samotnému nahrávání programů a musím přiznat, že jsem v pr**** jak Baťa s dřevákama.
Programováním se úplně nezaobírám, ale už jsem něco někde viděl. Ovšem openXsensor je pro mě totální chaos.
Použil jsem zcela stejné komponenty jako ty, spájení snad proběhlo v pohodě, ale nastavení a nahrání programu nedávám. Zkoušel jsem hledat na netu, koukal na videa, zkoušel něco nahrát, ale nic se mi nepovedlo. Můžu tě poprosit o pomoc?

[ellet]

Trochu jsi mě, po té dlouhé době, zaskočil. Většina se vykouřila z hlavy (teď si hraju s levným ESC pro ss motory) a čidlo je v éru, který nemám po ruce. Nějak to ale určitě dohromady dáme, jen nevím odkud začít.
Předpokládám, že máš stažený "openXsensor" a někde rozbalený (jako "openXsensor-master"). Tam je složka "oXs_Configurator". Spustíš konfigurátor, zaškrtáš na záložkách co chceš a vygeneruješ konfigurační soubory ("oXs_config_basic.h" a "oXs_config_advanced.h"). Těmi nahradíš původní soubory ve složce .."openXsensor-master\openXsensor\". Potom zkompiluješ "openXsensor.ino" a nahraješ do Arduina.(Mělo by to snad fungovat, já jsem ten konfugurátor nepoužil.)
Je to dost stručně, můžeme postupovat krok za krokem, ale možná lepší přes SZ. (Můžu ti i soubory vygenerovat, zatím ale nevím jestli chceš měřit i napětí...)

[Kenumis]

Ha! A je to!!!
Děkuji za nakopnutí. Já v tom hledal složitosti a zmaten videem nějakého němce, jsem upravoval soubor, který nebylo třeba upravovat.
Po troše zjišťování, jaký že mám programátor a jak se nastavuje, se to povedlo na první dobrou.

[ellet]

Tak gratuluji. Právě jsem se chystal napsat, že jsem se díval na ten konfigurátor a asi to nebude dobrá cesta, pokud neexistuje novější verze. Ten můj neumí tu 6050. Ale „ručně“ to jde dobře.
Jen pro upřesnění. Dodatečně jsem zkontroloval konfigurátor a poslední verze konfigurátoru už MPU6050 "umí".

[ellet]

Přidám odkaz na jedno praktické využití

[ellet]

V zimě jsem přešel na EdgeTX (2.9.4). Jen ze zvědavosti, protože pro moji „techniku“ nic nového nenabízí. A přišlo rozčarování. Poslední „Horizont“ se použít prakticky nedá. U tlačítek ovládajících nastavení se prodlouží čas odezvy až na několik vteřin a i skript je „na řadě“ jen občas (nebo nepravidelně?). Na řízení modelu to žádný vliv nemá, to je zcela plynulé. Ale čekání, pokud chci udělat změnu v nastavení, je hodně nepříjemné. Původní skript (na začátku vlákna) běží ale svižně a bez jakýchkoliv dalších nepříjemných projevů. Asi budu upravovat, optimalizovat…

[ellet]

Tak jsem to zmenšil a trochu zjednodušil. I když pod OTX to běží podstatně svižněji, je to tak nějak použitelný. Ověřil jsem, že, EdgeTX nemá rád kreslení (snad zatím).
A pro případné zájemce – jednu ze 6-ti barev textu lze vybrat v nastavení skriptu.

Edit: Tak se mně to nelíbí čím dál víc. Zdržuje to překreslení i ostatních widgetů na displeji. Proto ruším sdílení. Tuším jak na to, ale mám to zatím jenom v hlavě...

[ellet]

Tak kreslená verze je na světě. Konečně jsem spokojenej. Je to trochu kompromis, ale „co se hejbá“ je kreslený. Zobrazení změny polohy je proto zcela plynulé. Vlastní skript je jen pár řádků a nezaznamenal jsem žádný nepříjemný vedlejší efekt.

Omlouvám se za neopravenou cestu ve skriptu. Tady už dobrý.
Tak ještě trochu nepodstatných úprav a snad dost

HzontSRkr.zip

(2.8 KiB) Staženo 445 x

[ellet]

Tohle téma jsem použil hlavně pro zjištění rozdílů v běhu OpenTX-EdgeTX, ale jednoznačný závěr nemám. Dost blbě se to testuje, protože v Companionu to běží všechno dobře….
Tak poskytnu poslední z mých bezproblémových pokusů pro EdgeTX.

Hzont50.zip

(2.94 KiB) Staženo 246 x

Ptorože vidím, že to občas někdo stáhne a já vím, že je v rohu trochu vidět modrá z podkladu horizontu, dávám k dispozici ještě tuto verzi s drobnou opravou grafiky.

Hzont50_new.zip

(3.03 KiB) Staženo 221 x

[ellet]

Dobře, když už to zabere polovinu displeje, tak ať je víc počmáraná . Tak tady je ještě větší verze, která běží bez problémů (EdgeTX).

Vyměnil jsem to, aby byl kód čistší
....A ještě trochu srazit hrany...

Hzont60E.zip

(3.38 KiB) Staženo 235 x

[vprheli]

I když je to starší příspěvek, mám k němu určitou poznámku. Tohle jsem kdysi dělal pro OpenTx

OpenTx Horus X12S

ETHOS X20

Má to ale od začátku jeden problém. Nelze použít přímo data z akcelerometrů z prijímače. To funguje krásně doma na stole. Jakmile zafunguje přetížení při letu tak to ukazuja hausnumera. To proto, protože se jedná o akcelerometry, tedy zrychlení v daných osách. Proto jsou pro tento umělý horizont používané telemetrické hodnoty Roll a Pitch.
Teď to samé chci přepsat do ETHOSu a budu tento probl0m muset vyřešit. Obecně platí že s pomocí akcelerometrů lze spočítat roll a pitch. POkud chceme yaw, musíme mít k dispozici gyroskop. Tim ale dostaneme lokální souřadnou soustavu. Pokud potřebujeme skutečnou orientaci, musíme mít ještě magnetometr a resetovat s ním gyroskop.
Vy ale vystačíte s akcelerometry. Převod je jednoduchý a máte ze tří os roll a pitch. Pak ale musíte použít filtr jinak vám i při relativně klidném letu bude umělý horizont běhat jak veverka v bubínku.

Závěrem. Jde to ale není to tak snadné jak by se na první pohled mohlo zdát.

A ještě jednu poznámku. Goniometrické funkce žerou hodně času. Doporučuji použít tabulku 0-90 stupňů a sinus cosinus počítat z této tabulky pouhým přičítáním a odečítáním. Můj Horus X12S to prostě jinak nedal.

[libor]

Pro mě je to zbytečná fíčura zatěžující vysílač, letět se podle toho nedá. I kdybych nakrásně udržel náklon v kýžené poloze (a to možná půjde u nějakého stabilního školního letadla) tak nevím, kam letím. A koukat na horizont na vysílači a na model ve vzduchu jde jen když je model blízko. Když je daleko, tak koukání na displej rádia znamená, že už model ve vzduchu nenajdu.

[pstasek]

Pro mě je to zbytečná fíčura zatěžující vysílač, letět se podle toho nedá. I kdybych nakrásně udržel náklon v kýžené poloze (a to možná půjde u nějakého stabilního školního letadla) tak nevím, kam letím. A koukat na horizont na vysílači a na model ve vzduchu jde jen když je model blízko. Když je daleko, tak koukání na displej rádia znamená, že už model ve vzduchu nenajdu.

Use case pro umělý horizont pochopitelně není pro řízení modelu letadla na oči, ale pro případy FPV letu.

[ellet]

Když je daleko, tak koukání na displej rádia znamená, že už model ve vzduchu nenajdu.

Přesně tak. A když už se stane že je model špatně viditelný, mám jako záchranu toto;
viewtopic.php?f=48&t=891&p=6645&hilit=Map%2A#p6645
Ten horizont je jen taková hračka, ale i přes kritické připomínky - v pomalém větroni k mé spokojenosti použitelný. Problém je třeba i mítné chvění...
Jistě by se to, jako ostatně vždycky a všechno, vylepšit dalo (gyro). Data v tabulce – musel jsem něco použít v provedení HorizontUni. Ale jen tolik aby to Horus stihl ve vymezeném čase. Nechtěl jsem mít tabulky v kódu, počítají se jednou při inicializaci. Ošetřit to ale pro různou velikost zobrazení bylo dost pracný…a poslední pokusy pro ETX už mě zajímalo něco jinýho (grafika). V tomto provedení se to uplatní hlavně při nastavení éra do neutrální letové polohy při konfiguraci stabilizace před startem. Pro mě je to už historie a určitě nic upravovat nebudu.

Popravdě, tohle hraní je pro mě hlavně zábava.

[libor]

umělý horizont pochopitelně není pro řízení modelu letadla na oči, ale pro případy FPV letu.

To se nějak míjíme o čem hovoříme. Já vidím diskuzi o horizontu na displeji vysílače. Já létám FPV s brýlemi, na displej vysílače nevidím.