Építési napló 1.3 - a lélek a szoftverben lakozik

Azt hittétek, hogy ha összedobáljuk az alkatrészeket, már kész is a gép? Ó, ez hiú ábránd és örök hiba, hiszen a gép lelke nem a hardverben lakozik. Az áram őszinte, oda megy, ahova kötöd, ott ráz, ahová nyúlsz, ha értesz hozzá (én pl. nem:D) akkor méréssel még diagnosztizálni is lehet a problémákat. Persze van néhány nehezítő körülmény, de hardver sosem hazudik, mindig ad jeleket, igaz néha füst formájában. Ellenben a szoftver, Dante poklának különböző mélységeit tartalmazza, rettenetes mennyiségű kínnal és különböző szívásfaktorokkal. Ezt fejeljük meg a "világ legstabilabb operációs rendszerének" a sajátosságaival, a különböző konfigurációs rendszerek - mert olyan jól sikerült összeválogatnom, hogy Emax=baseflight, Ogre=cleanflight, Falcon=Librepilot mindegyik különbözik - beépített szívásaival, az eltérő ESC firmwarekkel. Akkora szivornya az egész, hogy az ember már szinte vágyik rá nem? Hát nem...

Attól, hogy a hardver még össze van rakva, nem annyira szeret repülni. Írtam már erről két bejegyzést, a Konfigurálás Baseflighttal I és II. részben, vannak alap dolgok, amiket mindenképpen be kell állítanunk. Persze nekem nem ARF verzióm volt, hiszen egy meglévő gépet szedtem szét, viszont voltak ettől még szoftveres problémák, amiken állítani kellett (volna). Ezek az alábbiak voltak:

ESC kalibráció (Emax 4 in 1 25A)
Barometrikus szenzor kalibráció
Fail safe konfiguráció

A gép egy fura jelenséget produkált, amit már videóban is megörökítettem. Ha felpörgettem a motorokat, majd elvettem a gázt, mintha bekapcsolt volna a failsafe, de igazából csak nagyon lassú teljesítményesés állt be három motor esetében. Erre úgy jöttem rá, hogy amikor elkezdtem mesterségesen felhúzni a Cleanflightban a motorteljesítményt és úgy hagytam, akkor dadogni kezdtek az értékek, majd nagyon lassan esni kezdtek, kivéve egy motor esetében. Ez abból adódott, hogy a távirányító által kiadott maximum értékek nem voltak azonosak. Vagyis ennek semmi köze a Fail Safehez, az egyszerűen nem akart bekapcsolni. Két típusú Fail Safet különböztetünk meg, egy vezérlő oldalit és egy vevő oldalit. A kettő között az a különbség, hogy ha a vezérlő valamilyen fals paramétert kap, lekapcsolhatja a motorokat. Ezt a funkciót kitehetjük egy AUX csatlakozóra is, de pl. az Arm/Disarm funkció is hasonlóan viselkedik. A vevő oldali Fail Safe azt figyeli, hogy a távirányító és a vevő között folyamatos-e a kapcsolat vagy sem. Ha szakadást észlel (adott időn belül nincs jelismétlés), akkor egy előre beállított eseményt hajt végre, pl. leveszi a motorok fordulatszámát, így a gép nem repül el, hanem leesik. Én ez utóbbit szerettem volna életre kelteni, de mivel ez nem sikerült, beértem volna az előbbivel is.

Első dolog az volt, hogy felfrissítettem a firmwaret a tavaly októberi verzióról az 1.12.1-es verzióra, ahol lett egy külön Fail Safe menü, de ezt hiába állítgattam halálra, semmi nem változott. Egyetlen egy megoldás kínálkozott, kirakni egy AUX portra a Fail Safe kapcsolót és arra felparaméterezni mindent. Ekkor esett le, hogy csak 5 csatorna van bekötve, ugyanis hiányzik egy szervó kábel a vezérlőről (tudom, láma vagyok), vagyis kizárólag mixben tudtam volna felprogramozni a távra a Failsafet, pl. Attitude/Horizon/Fail Safe, ami nem túl szerencsés, mert ha az ember véletlenül túlhúzza a módválasztó kapcsolót, már placcsan is a gép a földnek.

Aztán egy élelmes fórumtárs szólt, hogy ha nincsen otthon szervó kábelem, miért nem bontok szét régi, selejtezésre váró számítógépházat, annak az alaplapra menő 5V-os kábelei pont jók lennének ilyen célra. És milyen igaza volt, kiszedtem egy két power button meg HDD led kábelt, középen elvágtam őket, összeforrasztottam, majd lezsugorcsöveztem. Mivel elég egyetlen pinen feldugni a csatornát, ha másik csatornán kap a vevő tápot, ezért egyetlen szállal megoldható a probléma. Mivel ez a megoldás remekül működött, ezért fel is konfiguráltam a fail safe kapcsolót az AUX1 csatornára, ami a felső állásban kikapcsolja, míg az alsó kettőben bekapcsolja a manuális fail safet. Ez persze nem egy igazi, automata fail safe, de azért még is több, mint a semmi.

Mivel a motorok fura, lassú teljesítményesése továbbra is fennállt, ezért úgy döntöttem, újrakalibrálom az ESC-ket, hátha azonos érzékenységi tartományba kerülnek és itt jött az első giga pofon, még pedig az, hogy az ESC kalibrálás után sípjeleknél nem figyeltem eléggé, hanem belementem a paraméterállító menübe. Aki nem tudná mi ez, az ESC-knek van egy, a távirányítóról is állítható, sípjel alapú konfiguráló módja, ezzel ekvivalens az, amikor a konfigurátor programban bekalibráljuk az ESC-ket. A különböző paramétereket úgy tudjuk állítani, hogy adott számú sípjel után fel, majd le húzzuk a motorok master kapcsolóját. Mivel félre ment a konfig, ezért megkerestem az Emax Nighthawkhoz tartozó Simonk ESC konfigurációs leírást, gondoltam ugyan az, mint ami az Ogréban van. Lelövöm a poént, természetesen nem ugyan az.

Az Emax Nighthawk 280 Pro ESC-éinek a kalibrációs táblája ez
Az Ogre Emax 4 in 1 25A ESC-éjánek a kalibrációs táblája pedig ez

Az újabb ESC-kbe ugyanis bekerült a 6, D paraméter elé egy 7. ez az Active Breaking, ami miatt az összes többi paraméter sorszáma egyel elcsúszott. Így sikerült a D1-es paramétert, ami a Timing Advance, illetve a D4-et, ami a Control Frequency, elállítani, ettől pedig teljesen szétesett a vezérlés, ami a lenti videón remekül látszik is.

Így indult a nagy konfigurálás, ami néhány órás szenvedés árán oldódott csak meg. Szerencsére sikerült visszaállítanom az eredeti állapotot, de tanulságos eset volt. Ami a Fail Safet illeti, az Eachine Falcon 250-en már egy FS-i6AB vevővel próbálkoztam, mert azt hittem, a vevő (Flysky Fs-i6 és i6AB közötti különbség) a ludas, de mivel a neten minden videóban az látszik, hogy a Flysky Fs-i6 távirányító menüjében kell bekapcsolni az RX fail safet, ilyen része pedig az általam használt, kiherélt Nighthawk EM-16 távnak nincs, így nem tudom megmondani a vevőnek, hogy mit csináljon. Ezért kénytelen leszek beérni egy kapcsolóra kiprogramozott fail saffel, ehhez viszont egy szervó kábelre lesz szükségem.

Ami a barometrikus szenzort illeti, sajnos Cleanflightban nincen olyan rész, ahol paraméterezni lehet PID állítás nélkül. Egyetlen dolgot találtam, ez a barometrikus szenzorhoz tartozó PID érték. Ez azért baj, mert ha a PID értékekből ha nem az elsőn állítunk, akkor a többit is utána kell állítani. Ennek ellenére neki is kezdtem a beállításnak. A barometrikus szenzor P értéke 0-25 között mozoghat. Minél lejjebb áll ez az érték, annál lassabban reagálja le a baro szenzor bekapcsolását a gép, míg minél magasabb, annál inkább kitör felfelé és túlkompenzál. Ezért én úgy próbáltam beállítani, hogy olyan magasra (kb. 17-ig) emeltem a P-t amikor mér nem esett a magassága, de még nem tört ki durván felfelé. Amikor ezt megtaláltam, akkor elkezdtem emelni az I értékét és annak egyidejű emelése mellett a P-t lecsökkentettem, így az eséseket emelkedésekkel kompenzáltam nagyjából a középértékéig. Még persze távol vagyok attól, amit jónak lehet nevezni, de már most sokkal jobb, mint amilyen előzőleg volt. Ha megtaláltam az ideális beállítást, frissíteni fogom a cikket.

A PID-ekhez nem csak a barometrikus szenzor esetében kellett hozzányúlnom, ugyanis a gép nagyon csúnyán, rángva, hullámzóan repült. Ezért kiütöttem az összes PID értéket és visszaállítottam az alap értékekre, ezzel drámai változást elérve. Már az alapértékekkel is jól repül a gép, ha egy helyben lebegek, gyakorlatilag rezgésmentes képet lehet elérni. Persze a gép helyváltoztatása és a Vortex Ring State effektust semmi sem kompenzálja, hiszen ez egy teljesen fix kamera, mechanikus és elektronikus gimbal nélkül (aki eddig kétkedett volna a gimbal hasznosságában, az nézze meg a lenti két videót).

A lenti két videón lehet látni a különbséget, az első a PID állítás előtti, a második a PID állítás utáni állapot. Azmit még tapasztaltam, hogy az üzemidő a hőmérséklettől jelentősen függ, 15-20 fokban 12-13 percet tudtam a géppel repülni, míg 25-28 fokban ez felment 15 fölé, amit a lenti videóban is láthattok.