Devblog - Powered by Gunpowder & Coffee

Vývojářský deníček #3 - Inference, kvantizace modelů a hovězí BLE

Ke stažení na Google play zde

Screen_Recording_20250630_091007-ezgif.com-optimize

V posledních dnech jsem se zaměřil převážně na optimalizace AI rozpoznávání zásahů a povedlo se mi dokončit upgrade který zrychluje automatické rozpoznání zásahů o 41%. Pokud AI rozpoznávání používáte (což doporučuju, ohromně to zpříjemňuje práci a zásahy jsou označené konzistentně) tak byste si po aktualizování aplikace měli všimnout citelného zrychlení. Nakonec se jako nejjednodušší cesta ukázalo stáhnout čas pro dekodování obrázku.

Srovnání výkonu AI detekce

Původní časy

Komponenta Čas (ms)
Načítání modelu 22
Dekódování obrázku 1,598
Zpracování obrázku 85
Příprava tensoru 150
AI inference 1,451
Zpracování výsledků 1
Celkový čas 3,312

Současné časy

Komponenta Čas (ms)
Načítání modelu 8
Dekódování obrázku 192
Finální zpracování 253
Příprava tensoru 140
AI inference 1,362
Zpracování výsledků 5
Celkový čas 1,968

Celkový čas inference se zkrátil z 3,312ms na 1,968ms, což představuje zrychlení o 41%.

Kvantizace AI modelu

Pokoušel jsem se také o další zrychlení pomocí kvantizace modelu z float32 na Float16, ale tady jsem si bohužel dost vymlátil zuby a nepodařilo se mi dosáhnout rozumné úspěšnosti rozeznání zásahů. Int8 model dopadl bohužel stejně. Vzhledem k náročnosti a přínosu ve stovkách milisekund to aktuálně dávám taky k ledu..

Reverse engineering Garmin protokolu BLE aneb jak jsem si vybil zuby podruhé

Moje myšlenka byla poměrně jednoduchá. Radar od Garminu přeci komunikuje s mobilní aplikací přes Bluetooth, proč bych tuto komunikaci nezkusil napodobit ve své aplikaci? Co jsem tím chtěl dosáhnout? Chtěl jsem aby se aplikace uměla připojit k radaru stejně jako to dělá nativní aplikace a třeba si rovnou stáhnout uložená naměřená data.

Povedlo se mi dokončit autentizaci, Garmin si s mou aplikací povídá, prošli jsme až k příkazu, který vypisuje obsah filesystemu ale tady jsem narazil. Reverzní engineering je vlastně cely jen hádání a zkoušení, bez dokumentace, bez nápovědy, bez ničeho. Když už jsme se dostali k příkazu pro vypsání uložených seancí, tak jsem si nebyl jistý, jestli ten příkaz v zařízení vůbec existuje a tak jsem se to pokusil ověřil způsobem, kdy zařízení pošlu prokazatelně neexistující příkaz, který jsem si random vymyslel (BEEF_REQUEST) a potvrdilo se, že zařízení skutečně odpovídá jinak než na (DOWNLOAD_REQUEST). To je prokazatelný důkaz, že (DOWNLOAD_REQUEST) v zařízení existuje, jen se mi ještě nepovedlo správně navázat komunikaci a postoupit dále. Tuto možnost jsem nakonec také dal k ledu kvůli časové náročnosti a rozhodl jsem se pro jiný přístup.

Změna importu dat z chronografů do aplikace

Aktuálně to tedy funguje tak, že si v mobilní aplikaci ShotView můžete vygeneroval xlsx soubor, kde můžou být klidně všechny naměřené seance nahromadě. Ten nahrajete do Shooting Companiona, ten to rozparsuje a podle času kdy byl uložen terč a kdy byla naměřená seance radarem přednabídne z hromady dat z xlsx tu správnou seanci. Samozřejmě jsou možné ruční korekce a toto je jen doporučení, ale aspoň trochu „inteligentní“ jsem to chtěl udělat a neodpustil jsem si to.

Veškeré tohle hraní bylo bohužel poměrně časově náročné, takže víc novinek v projektu nemám a a zřejmě se teď budu zase chvíli věnovat překladům.

Pokud byste měli nějaký poznatek, nápad na vylepšení, chtěli nahlásit bug, tak můžete klasicky na Canny nebo zde.

Screen_Recording_20250630_090326-ezgif.com-optimize