Kajfis Tamás: Szoftver fogalmak a távcsöves vezérlésben

Tisztázzuk a korszerű informatikai fogalmakat

Átléptünk a 21. századba, az informatika minden területen teret hódít, és ez alól a csillagászatban sincs kivétel. Régen a távcsöves követést áttételek és DC motorok fordulatszám szabályozásával oldották meg, és digitális fényképezők helyett analóg filmre rögzítették a képeket.

A mai modern eszközök már mind mikrokontrolleres vezérlést alkalmaznak. Sajnos a felhasználók egy jelentős részének nincs lehetősége tisztába kerülni a szoftveres kifejezésekkel, eszközökkel, nem tudják, mi mire szolgál, csak használják őket, és sok új kifejezés kering a köztudatban, aminek érdemes tisztázni a jelentését és tartalmát.

A cikkben a Microsoft által fejlesztett Windows operációs rendszerre (OS)-re fejlesztett környezetre fogok teljesen kitérni, a többi OS-t (Linux /Debian stb. disztribúció), csak dióhéjban említem majd.

 Fő két architektúra létezik, amiket mi amatőrök használunk:

• X86/X64
• ARM

Windows és ARM

Windows verziói csak is X86/X64 alá telepíthetőek (amúgy létezik ARM-es verziója csak használhatatlan, még), ezek a hétköznapi PC-k és laptopok, természetesen ezekre az eszközökre is elérhető a fent említett többi OS.

Az ARM rendszer mostanában közkedvelt hardvere a Raspberry PI (RASPI), erre az eszközre elérhető kifejezetten csillagászatra “optimalizált” és elterjedt OS a Stellarmate, Astroberry, és a ZWO által fejlesztetett ASI AIR csomag, ami egy RASPI és a ZWO által kiadott OS, megjegyezném az androidos mobilod is ARM.

Miért fontos ez, hogy elkülönítsük a két elérhető architektúrát egymástól? A kettő nem összekeverendő, az egyik szoftver csomagja nem telepíthető a másikéra, kivéve akkor, ha a fejlesztőmérnökök le nem fordítják az adott OS és architektúrára. Tehát Windows alatt csak ASCOM, Linux alatt csak INDI és most rá is térnék a cikk főtémájára.

Mi az ASCOM?

Angolul: AStronomy Common Object Model google translate: Csillagászat közös tárgymodellje. Magyarra értelmesen nem is lehet lefordítani, mivel a Common Object Model (COM) informatikában használatos szakszó.

Wikipédia:
„a Component Object Model (COM), mely ActiveX-ként is ismert, a Microsoft által kifejlesztett technológia a komponens alapú fejlesztés támogatására, mely a szoftverek közti kommunikációt teszi lehetővé. Bár több platformon is megvalósították, elsősorban a Microsoft Windows operációs rendszerében használják. Az elődje az object linking and embedding (OLE) technológia volt, ma a COM szerepét a Microsoft .NET rendszer veszi át.”

Tehát arról lesz szó leegyszerűsítve, hogy Windows alatt csak a csatlakoztatott szoftverek és hardverek tudjanak egymással ide-oda kommunikálni, minél egyszerűbben.

Hogyan működik az ASCOM?

Oké, de még is mi ez? Hogyan működik? És miért van rá szükségem?

Nézzünk egy példát, három különböző mechanika gyártóra (SW, Meade, Fornax) és három különböző szoftverre (PHDGuiding, NINA, Stellarium)! Ha nem létezne ASCOM, akkor a szoftver gyártói oldalról mind a három eszköz felé le kéne fejleszteni a megfelelő drivert, ami a mechanikákkal kommunikálna.

Ez így nézne ki:

A fenti kis ábrából elég jól kivehető a probléma, a fejlesztőknek mind a három mechanikához le kell programozni a megfelelő protokollt (erről később majd), ez persze nem azt jelenti, hogy nem is teszik meg. Ámde

• ez fejlesztései időt igényel,
• ismerni kell az adott eszköz protokollját,
• körülményes, ha gyártó módosít valamit a firmware-ben (erről később majd),
• és csak három gyártót említettem!

Ilyenkor jön képbe az ASCOM:

Nézzük meg mi a különbség a két ábra között:

• A nyilak, ill. vonalak száma
• Színe
• Nincs nyílhegy, csak vonal

Mi is történik a második esetben?

Az ASCOM Standards meghatározza az eszközök típusát, itt beleértve a mechanikáktól, a CCD-ktől át a csillagdavezérlésig minden olyan eszközt, amit a gyártók terveznek csillagászati célra. Meghatározza a hozzájuk tartozó meghívható eljárásokat, az eljárások alatt azt értem, hogy adott eszköznek milyen képességei vannak, pl. mechanika GOTO sebesség állítása, CCD gain szabályzás stb. A fejlesztőknek ezekhez kell idomulni. Az ASCOM-nál nem restek, és követik a gyártók trendjét, ha kijön valami újabb fejlesztés azt frissítéssel implementálják.

• A szoftverfejlesztőknek csak is az ASCOM eljárás hívásait kell használnia, nincs szükségük egyesével megírni az adott eszközhöz tartozó drivert.

Az eszköz fejlesztőknek amúgy is meg kell írni egy natív (önmagában működő) driver-t, ami tartalmazza azt a kommunikációs protokollt amely szükséges az eszköz irányításához, és az ascom “driver”-t ami magában foglalja a natív drivert is, csak ebben az esetben ascom hívásokká alakul át és ezen keresztül kommunikál a szoftverekkel.

Részletes ábra, ami a legegyszerűbben szemlélteti, mi is történik mikor a Stellarium-mal, ha GOTO-zol:

Firmware és protokoll

Említettem két ronda szót: a protokollt és a firmware-t. A firmware, -amit egyszerűbb megérteni-, az egy mikro-kód, ami egy programozható chipben fut. Mechanika esetén a firmware-nek tudnia kell pár dolgot, például mik a tengelyek áttételei, így lehet pontos a GOTO, az időt, melyik motort melyik lábkivezetéseken vezérli stb. és a protokollt.

A protokoll meghatározza, hogy az adott eszközzel hogyan kell kommunikálunk nem csak a sebességet, de azt is byte vagy szöveg alapú a kommunikáció és a nyelvezetét, pl. SkyWatcher esetén: e1-el indítjuk a kapcsolatot a mechanika felé.

Szerintem egyértelmű miért is van szükségünk az ASCOM-ra, megkönnyíti az életünk, eszközparkunk kommunikációja a szoftverekkel homogén. Csak az eszköz gyártói oldalról van szükség ASCOM driver programozásra.

Kanyarodjuk vissza kicsit Linux-s környezetre, itt INDI az ASCOM megfelelője, kicsit másképp működik, de az elv ugyanaz. Megjegyezném a speciálisabb gyártóknál mint pl. a ZWO ASIAIR-nél, ahol eléggé zárt a rendszer és saját eszközeiken kívül nem sok mindent támogat, ők saját natív drivereket használnak pl. egy Moravian CCD-t soha nem fog felismerni, de egy ASI294MM-et bármikor gond nélkül.

Végszó minden mostani csillagászati eszköz és szoftver ASCOM kompatibilisnek kell lennie, kötelező és alap. Ez egy keretrendszer, ami átjárót csinál felszerelésünknek. Az INDI-t is folyamatosan fejlesztik. Fontos tudni továbbá, hogy a közkedvelt EQMOD nem összekeverendő az ASCOM-mal. Az EQMOD alapvetően a kézivezérlőt helyettesíti többféle EQ mechanika esetében, és így lehetővé teszi azok PC-ről való működtetését.

Linkek:

ASCOM - https://ascom-standards.org/
INDI/EKOS - https://www.indilib.org/about/ekos.html
Stellarmate - https://www.stellarmate.com/
Astroberry - https://www.astroberry.io/
COM - https://hu.wikipedia.org/wiki/Component_Object_Model
Protokoll - https://hu.wikipedia.org/wiki/Protokoll_(informatika)
EQMOD – Ingyenes SkyWatcher protokollt használó ASCOM driver - http://eq-mod.sourceforge.net/