BADRX, FAILSAFE a verze Betaflight 4.4

Igor Vlahovič


Vzhledem k faktu, že používám FC jednotku (řídící desku) na mém FPV letadle, jsem ji nedávno aktualizoval. FC desku tam mám pro přenos telemetrie včetně údajů o poloze místa startu a vzdálenosti od něj.

Když jsem ji na palubě neměl, létal jsem čistě na obraz bez OSD parametrů Betaflight. V obraze brýlí jsem měl pouze telemetrii DJI (číslo kanálu, datový tok, info o záznamu a době letu). Další informace o výšce, rychlosti a napětí mi poskytovaly senzory umístěné v letadle.

Delší dobu mi trvalo, než jsem dospěl k použitelné formě telemetrie s pomocí FC Zeus F722. Na začátku mě trápily neduhy. Betaflight je poměrně složitý FW, který je Open Source a neustále se vyvíjí.

Jedním z problémů se kterým jsem bojoval, bylo provedení DISARMU po prudkém náklonu letadla. Toto jsem vyřešil příkazem na řádku CLI v programu Betaflight „set runaway_takeoff_ prevention=off“. Dát enter a pak SAVE a enter. DISARM způsobil ztrátu místa startu včetně cesty domů a vzdálenosti od HP. Pokud člověk zná terén a ví, kam se vrátit v případě Long Range letu… Pak OK. Ale jinak se pilot může v terénu ztratit.

Samozřejmě při používání DJI Air Unit (první generace), která nepodporovala Betaflight  Canvas Mode jsem neřešil varovná hlášení typu RXLOST, FAIL SAFE. Protože DJI umožnilo zobrazit jen některé parametry telemetrie do OSD.

S nástupem DJI O3 Ait Unit, která plně podporuje BF Canves Mode, jsem začal řešit další problém. Nedávno jsem se rozhodl aktualizovat FW řídící desky z verze BF 4.3.1 na 4.4. Důvodem byla možnost HD OSD. Ale po provedení jsem se setkal s problémem a to dost podstatným.

BF FW 4.3.0

Když jsem měl nahraný BF 4.3.0, tak se občas v brýlích objevilo hlášení RXLOST a FAILSAFE. Bylo to však nepochopitelné, protože spojení mezi modulem R9M 2019 a přijímačem R9 Stab OTA bylo bez problémů a úroveň řídícího signálu byla v pořádku. Většinou tato hláška trvala krátce a vůbec nenarušila průběh letu.

BF FW 4.4.0

Po aktualizaci BF na verzi 4.4 jsem však při jednom testovacím letu na vzdálenost cca 3km dostal informaci BADRX a za vteřinu potom FC deska provedla DISARM. A v ten okamžik spadl datový tok O3 Air Unit z 30mbs na 4mbs. Na tak velkou vzdálenost to je nedostačující a přišel jsem o obraz. Došlo sice ještě na krátkou ukázku obrazu (až jsem se divil), ale to pomohlo k navedení letadla na nouzové „přistání“ na pole.

Toto se opakovalo i po restartu. K tomu se objevovalo hlášení o RXLOST a FAILSAFE proceduře.  Ale tyto dvě nebyly důvodem k elektronickému DISARMu. Důvodem byl BADRX + THROTTLE. A tak začalo bádání, proč tomu tak je. BADRX není špatný přijímač, ale že kanál plynu není správně nakalibrován v BF. Ale zde jsem vše doladil, včetně správné orientace pohybu modelu vůči vysílači.

Částečně jsem riziko ztráty obrazu vyřešil tím, že jsem přes brýle vypnul na jednotce O3 Low Power State Mode. V podstatě než provedu ARM páčkou a přidám plyn, tak datový tok nejede naplno, ale je kolem 4mbs. Po ARM příkazu se rozjede plný vysílací výkon. Ale i přes to, že jsem jednotce řekl, pojedeš po zapojení na plný výkon, jakmile provedla FC deska DISARM, došlo ke snížení datového toku na 6 – 8mbs. Ale pozitivní zjištění bylo, že na vzdálenost 3km jsem nepřišel o obraz a mohl pokračovat v letu.

Obraz byl, ale zmizel údaj o vzdálenosti od místa startu a kam se mám vracet. Což bez znalosti terénu by byl velký problém.

Další pokusy pak spočívali v pokusu provést páčkou na vysílači DISARM a následný ARM. Toto se však ihned nepovedlo. Musel jsem většinou přiletět blíže a teprve pak po provedení ARM příkazu se obnovil datový tok naplno. S tím se však zapsalo nové místo startu.

Řešení vysílacího výkonu O3 AU sice částečně vyřešilo problém. Obraz pokračoval, ale bez potřebných OSD údajů se v neznámém prostředí špatně létá. Zvažoval jsem výměnu FC desky. Protože mezi tím jsem vyměnil modul R9M 2019 i přijímač R9 Stab Ota.

Nakonec jsem se rozhodl pro změnu FW v řídící desce.

BF FW 4.3.2

Když jsem nahrál do desky tento FW, provedl jsem zatím asi 3 lety v délce 20 minut jeden. A za tuto dobu se sice na krátkou dobu objevilo varování RXLOST a následné spuštění FAILSAFE. Ale BADRX se nezobrazil a k elektronickému provedení DISARM nedošlo. Pořád mi nejde do hlavy, na základě čeho vyhodnocuje řídící deska spojení s přijímačem přes SBUS protokol = varování o ztrátě signálu. Když řízení letadla probíhá naprosto v klidu s bezproblémovým RSSI údajem. Nicméně přechod na nižší FW pomohlo situaci vyřešit.

Pravdou je, že použití FC na modelu letadla (v mém případě) není zcela standardní. Ale snahou je mít při FPV letu co nejvíce telemetrických údajů pro zvýšení informovanosti a bezpečnosti. I když létám nad poli a loukami v malé výšce. Mám v trupu letadla externí GPS lokátor, který mi pozici letadla jistí nezávisle na GPS pozici letadla pomocí GPS senzoru. Ale to není řešení. Možná časem přijdu na důvod spouštění varování  RXLOST a s tím související FAILSAFE.