Jak jsem již zmínil dříve, to, co mělo být rychlým víkendovým projektíkem se změnilo na čtyřměsíční martirium ladění algoritmů a jejich nastavení. Dokonce i teď v listopadu není ognLogbook stále ve formě a ve stavu v jakém by mohl a měl být. V tomto příspěvku bych rád popsal problémy a jejich řešení, se kterými jsem se setkal během vývoje takovéto, na první pohled jednoduché a jasně definované aplikace.
První falešné případy detekce vzletu a přistání byly zaznamenány při nácviku startů z navijáku na letišti v Kolíně. Detekční rutiny založené hlavně na pozemní rychlosti (Ground Speed, GS), prahových hodnotách rychlostí a minimální době letu (přece nejde zaletět okruh rychleji než za 2 minuty, nebo jo?) Vše selhlalo, když rychlost při vzletu na navijáku klesla po odpoutání téměř na 0 km/h (kobra jak cyp, asi za to pěkně tahali), zde zůstala nějakých 5-8 sekund ve stoupání a konečně na okruhu pokračovali s Blaníkem těsně nad minimálním nastaveným limitem GS. Aby to nebylo tak jednoduché, tyto odvážné dívky a chlapci navíc trénovali nouzová přistání kolmo přes dráhu, čímž zkrálili dobu letu jednoho „okruhu“ klidně na nějakých 60 sekund.
Později v tom samém týdnu jsem zaznamenal druhý problém s detekcí – GS opět blízko 0, když ementálka (nebo noví instruktoři?) v Mejtě nacvičovali vývtrky. A kdyby jenom jednu otočku, oni hned několik za sebou! V tomto případě bylo zaznamenáno přistání, které hned následoval okamžitý vzlet na tom samém místě, což bylo způsobeno vágně nastavenými prahovými hodnotami v algoritmu pro detekci letmého přistání (kačenkou).
A ješte jedna taková perlička nastala ve chvíli, když se nějaký bojovník (či -ce) odvážně se vydavší do termiky za podmínek silného severozápadního proudění snažil se svým Šemíkem vtěsnat do úzkého stoupáku v proklatě malé výšce, přičemž ani do toho Hradce mu to v tu chvíli nevycházelo. Rychlost, na které umí Blaník kroužit mínus rychlost větru se opět dostala pod hranici nastavenou jako limitní pro přistání.
Další takový špek byl detekován jednoho dne v Polsku jak naznačuje tento obrázek. Teorií je, že po opravě motoru nechtěl tento (motor, mechoš určite ano) moc dobře vrčet a tak jej štelovali krátkými skoky po dráze. Zde již byla zavedena podmínka indikace vzletu po překročení určité minimální výšky (AMSL) při vypnuté podmínce minimální délky letu. V tomto případě to tedy bylo vyhodnoceno jako velmi krátké lety. Což je prakticky asi správně.
Přetrvávající problémy s detekcí startů a přistání mě tedy dovedly k nutnosti vytvoření další podmínky – výšky nad terénem (AGL). Jako obvykle mi ovšem odmítala fungovat lopata a těch pár ukázek, jak zacházet s GDAL knihovnou se mi nikdy nepodařilo oživit. Dobrou zprávou bylo, že reliéf terénu je volně k dispozici ze družice jménem Copernicus s neuvěřitelným horizontálním rozlišením 20m a použít to nějak půjde. Musí. Soubory s dlaždicemi, pokrývajícím celou EU mají pěkných 32GiB. Po zmenšení rozlišení na 500x500m se mi podařilo získat jeden 8MiB soubor pokrývající území celé EU. Což bylo jedinně dobře, protože v tu chvíli jedinný způsob jak pro danou polohu získat nadmořskou výšku terénu bylo spawnovaní externího procesu při volání nástroje gdallocationinfo na příkazovém řádku s následným parsováním jejo výstupu do konzoly. Samotné toto volání je pochopitelně pomalé, navíc, když se pokaždé musí načíst oněch 8MiB datového sobouru z disku do paměti (rozdíl mezi klasickým HDD a SSD byl skutečně enormní). Z toho důvodu byly tyto dotazy používány jen v blízkosti startu a přistání, ale jak bylo popsáno výše, toto stále nestačilo. Asi o měsíc později jsem ve fóru konečně narazil na nápovědu, jak úspěšně využít gdal přímo z Pythonu. Řřešení je relativně pochopitelné: verze pythonní knihovny musí být stejná jako binárka v systému, takže je potřeba ji downgradovat a zafixovat. Toto tedy konečně umožnilo nejen zvýšit rozlišení dlaždic na 200x200m (soubor 160MiB), ale jen jedno načítání do paměti při startu aplikace zároveň umožnilo počítat výšku nad terénem v každé poloze a tím pádem vyřešit některé z výše popsaných problémů. Ale zbývá samozřejmě ještě jeden problém – terénní data pokrývají pouze území EU. Ve zbytku světa je tedy velká díra..
Nejčerstvější zapeklitos se oběvila teď na podzim s příchodem vlnové sezóny. Rychlost větru v FL195 může být tak vysoká, že tam ta naše létadla prostě couvají – mají zápornou GS, což je samozřejmě také pod všemi nastavenými hranicemi pádových rychlostí. Nicméně teď už to zachraňuje algorimus výpočtu AGL popsaný před nepatrnou chvílí. Zdravím do ESNC (to je ve Švédsku)! 🙂
Původní ognLogbook pokrýval území jen do vzdálenosti 300km od našeho baru v Křižanově (holt pupek světa). Ale už během (tajného) testovacího provozu stačil někdo vykect adresu a tak se začali ozývat hlasy i z okolních zemí dožadující se, aby bylo pokryto i to jejich letiště. Proto byl rádius rozšířen na 1000km, ovšem stále omezen zejména z důvodu výkonosti tehdejšího serveru. Ten spočíval na ramenech torza rozbitého notebooku se slušným dvoujádrem Core i7-3537U, což do té doby mohlo stačit. Ale nestačilo. Limit výkonu byl rychle překročen jednoho polojasného letního dne, kdy celá Evropa vytáhla i toho posledního hadráka ze zaprášeného rohu do té doby opuštěného hangáru a s vidinou tisícikilometrových přeletů se směle vydala na štreku. Poslední stabilně zpracovávaný provoz z OGN sítě byl 120000 beaconů (paketů, poloh) za minutu. Celková kapacita front v u dobu byla z nějakého důvodu omezena na pouhý jeden milión záznamů a všechny co se nevlezlo bylo prostě zahazováno.
Toto samozřejmě nebyl žádný závažný problém. Stačilo jen změnit kapacitu front na nekonečno (fyzicky 8GB RAM) a už se neztratil ani jeden bajt. Pouze vyprázdnění těchto front pak zabralo o neco více času – do brzkých ranních hodin .. o dva dny později.
Bylo tedy jasné, že pětivláknová pythoní aplikace na 4 jádrech (z toho jen 2 fyzických) to prostě za daných podmínek rychleji nezvládne (vlákna: 1. – příjem dat, dekédování a rozřazení, 2. – OGN beacon processor, 3. – FLARM beacon processor, 4. – ICAO beacon processor, 5. – maria db insertion queue a konečně 6. – influx db insertion queue). To šesté bylo možné přidat až po přesunu na výkonnější ‚CML7‘ – virtuální mašinu s přiřazenými 4 fyzickými jádry CPU Intel Xeon Silver 4214 @2.20GHz. A jak byste čekali, od té doby už žádný další takový problém nenastal 🙂
Takže dokud nám náš štědře zapůjčený stroj běží, máme skvělou a možná i jedinečnou příležitost si dále s daty z OGN sítě hrát a analyzovat je. Kde se průměrný údržbář-traktorista z aeroklubu jako je ten náš normálně dostane ke zpracování real-time skutečně big dat(a)? 🙂 V tuto chvíli jsou zaznamenávána všechna dostupná data všech letů na celé planetě (teď tam čile spatříte například i provoz v Čile či Austrálii) do influxu pro pozdější kompletní a detailní analýzu záznamu letů (ta, co ještě není). Nicméně určitě ne na furt – doba po kterou zůstávají záznamy dostupné je omezena na jeden týden. Důvodem není jen jejich objem (800 miliónů záznamů během posledních srpnových latí), ale hlavně .. proč?
Práce, která stojí (a není zajíc ani ženská) je stále hodně – jak na straně backendu (algoritmů zpracování), tak i na webovém rozhraní (například responzivita, live data feed). Nebo to celé přepsat do rustu? Pokud byste měli zájem si to také zkusit, chcete se zabavit, nebo vás prostě jen neco štve a nikdo s tím nic nedělá, můžete směle přiložit ruku k dílu a jste vřele vítáni na GitHubu https://github.com/ibisek/ognLogbook. Jakékoliv vylepšení oceníme dozajisté úplně všichni 🙂
