Ugrás a fő tartalomra

Szoftver fogalmak távcsöves vezérlésben

Átléptük a 21. századot és az informatika minden területen tért hódít, 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, 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 verziói csak is X86/X64 alá telepíthető (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 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 azok a szoftverek és hardverek, amiket csatlakoztattál tudjanak egymással ide-oda kommunikálni, minél egyszerűbben.

 

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ó (SW, Meade, Fornax) és három különböző szoftver (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.

 

 

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 nem azt jelenti, hogy nem is teszik meg.
De,
- 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!

 

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íl, 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 miden 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, szóvá tenném az ASCOM-nál nem hülyék é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.

 

 

Talán ez az ábra szemlélteti, legegyszerűbben mi is történik mikor a Stellarium-mal GOTO-zol.

Említettem két ronda szót, protokoll és firmware.

Firmware amit egyszerűbb megérteni ez az a mikro kód, ami egy programozható chipben fut. Mechanika esetén a firmware-nek tudnia kell pár dolgot mik 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 ugyan az.
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. Szubjektív, de elég pofátlan az az ár, amit kérnek érte…


Végszó miden 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.
Az EQMOD nem összekeverendő az ASCOM-mal.

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/