4. RENDSZER FELADATAI
4.8. M ODELLEZÉS ÉS TEXTÚRÁZÁS
A program fő célja, hogy a beérkező képek alapján egy olyan háromdimenziós modellt építsen fel, amely tükrözi a valós környezet felépítését és arányait. A térben lebegő pontfelhő helyett jobb vizualizációs megoldást nyújt, ha a pontok alapján elkészítjük a fényképezett jelenet testhálóját, majd a képkockák adataival textúrázzuk azt. A testháló felépítése igen sarkalatos kérdés, mivel gyakorlatilag ez fogja pótolni a modell azon részeit, amelyeken nem találtunk jellegzetes pontokat az előfeldolgozás során, így térbeli információt nem sikerült kinyernünk róluk. Gyakorlatban a legmegfelelőbb módszer erre a pontok közötti Delaunay-háromszögekkel felépített háló későbbi finomítása bizonyos paraméterek alapján. Végső lépésként a háló háromszögeihez tartozó megfelelő részletet kivágjuk a kamera által készített képekből, és ráillesztjük a háromszögre.
Oldal: 15 / 72 Ennek legkézenfekvőbb alternatívája, hogy egy egyszerű webszerver segítségével megjelenítsünk bizonyos adatokat, amik megtekintése nem igényel specializált programokat. Így bármilyen böngészővel, rendszerkezelő eszközzel képesek vagyunk adatokat közölni a rendszer állapotairól. Ez a részrendszer publikus adatok közzétételét szolgálja, nem a felhasználói interfész részeként funkcionál.
Oldal: 16 / 72
5. Rendszer modul terve kronológia sorrendben
5-1. ábra: Előzetes rendszerterv
Oldal: 17 / 72
5-2. ábra: Az újragondolt rendszer terve
Oldal: 18 / 72
6. A rendszer bemutatása 6.1. Robot leírása, ismertetése
A robot egység két fő részre bontható: hordozó és a rajta elhelyezett képi adatok beolvasásért, valamint azok továbbításáért felelős egységre. Kezdetben az elgondolás az volt, hogy egy notebookot és az ahhoz kapcsolt kamera párost elhelyezve a hordozón fogjuk megoldani mind a képek előfeldolgozását, mind azok továbbítását a távolban lévő gépnek. A notebookhoz egy soros porton keresztül csatlakoztatjuk a robot-vezérlő elektronikáját. A robot építése során azonban a méretproblémák miatt egy alternatív megoldás megvalósítására adtuk a fejünket; mégpedig egy okostelefon használata vetődött fel. Előnye hogy nem igényel nagyméretű hordozót, rendelkezik a kommunikációhoz szükséges portokkal és kamerával is.
6.2. A szerkezet műszaki paraméterei
A robot (6–1. ábra) 20x25 cm alapterületű. A tápellátásról 6 darab AA méretű ceruzaelem gondoskodik, amik így 9V bemeneti feszültséget állítanak elő az elektronika számára. A két motor meghajtása közvetlenül a telepekről történik. Az elektronika számára egy speciális feszültség konverter állítja elő az üzemi 5V feszültséget. A robot súlya elemekkel együtt: ~1kg
6.3. A robotvezérlő elektronika
6.3.1. Tápellátás
A tápellátás alapproblémája hogy a beérkező 9V feszültséget az elektronika számára 5V üzemi feszültségre kell csökkenteni. Lehetséges megvalósítás le lehetne egy ellenállás alapú feszültségcsökkentés. Ezen áramkörökből lehet fix kimeneti feszültségűt kapni (5, 12, 15V). Azonban ezek a chipek alacsony áramellátást képesek biztosítani. A másik hátrányuk a relatív alacsony hatásfok. Ennek oka, hogy az elektronika ellenállás segítségével állítja be a kimeneti feszültséget, ami azt jelenti, hogy azokon átfolyó áram hőt termel és ez jelentős energia veszteséggel jár. A hőtermelés miatt külön hűtőborda használata is szükségessé válhat. Ennek a módszernek egy egyszerűsített
6-1. ábra: Robot
Oldal: 19 / 72 alternatívája a Zener dióda és egy áram korlátozó ellenállás használata. A Zener dióda lényege, hogy a hagyományos dióda letörési feszültségét állítják be pontosan egy kijelölt feszültségértékre. Így érhető az el, hogy csak bizonyos feszültséget engedjen át helyes bekötés esetén. Ha egy Zener diódát fordítva kötünk be az áramkörbe, akkor úgy viselkedik, mint egy hagyományos dióda, nyitófeszültsége fordított irányba 0,3–0,7V közé esik típustól függően. Ennek a módszernek is az a hátránya, hogy a diódán és az ellenálláson is esik feszültség és az átfolyó áram hőt termel a komponenseken.
Az előző megoldásnál sokkal hatékonyabb megoldások léteznek, a kapcsoló üzemű tápegység speciális változatai. A lényeg, hogy ha kellően gyorsan fel-le kapcsolgatjuk az egyenfeszültséget, akkor azt a jelet kiintegrálva előállítható a kimeneten egy stabil egyenfeszültség. Ezeket Step-Down illetve Buck konvertereknek is nevezik [8]. Ennek előfeltétel egy olyan integráló, energiatároló egység, mint a kondenzátor. Tipikusan 30KHz – 10MHz es tartományban mozognak e típusú áramkörök működési frekvenciái. A kimenetet egy L-C taggal megszűrve az elektronika tüskéktől mentes kimeneti feszültségszintet állít be. A manapság legfejlettebb áramkörök a 94%-os4 hatékonyságot is képesek elérni. Ezeknek a rendszereknek másik nagy előnye, hogy gyakorlatilag hőtermelés nélkül képesek ellátni a feladatukat, akár 16 amperes áramerősség mellett is. Az alkatrészek költsége magasabb az ellenállásos feszültség korlátozóknál, valamint fizikailag is több kiegészítő alkatrészre van szükség. Azonban a most említett negatív tulajdonságok sokkal kevésbé fontosak egy akkumulátorról működtetett alkalmazás esetén, ahol a fogyasztás az egyik leglényegesebb pont a kritériumok közül.
6.3.2. Mikrokontroller
A hordozóhoz felhasznált elektronika „lelke” egy mikrokontroller (µC). A mikrokontrollerek speciális programozható mikroszámítógépek, amik rendelkeznek fel paraméterezhető perifériákkal, operatív tárral programozható I/O portokkal. Ezeket a mikroszámítógépet alapvetően beágyazott rendszerek vezérlésére használják. Ehhez a munkához az Atmel® cég AVR® típusú processzoraira esett a
4MAXIM MAX1951A
6-2. ábra: Vezérlő kapcsolási rajza
Oldal: 20 / 72 választás. A processzor családok közül a Mega sorozat 8-as szériáját választottuk (6–3. ábra). Ez az egység egy CMOS alapú kisfeszültségű 8 bites vezérlő. Architektúrájának alapját egy RISC processzor mag jelenti. Általános számítási kapacitása 1 MIPS per MHz. Ez azt jelenti, hogy egy óraciklus alatt egy utasítást képes végrehajtani.
A beépített perifériákat regisztereken keresztül lehet fel programozni. Egyes részegységek felprogramozhatók úgy, hogy a kiadott műveletvégzés után un. interruptok hívódjanak meg. Ilyen funkció lehet egy konvertálás, mivel egy A/D konverzió jelentős ideig tart az egyszerű műveletekhez képest, ezért jó lenne, ha nem kéne megvárni a folyamat végét, hanem addig folytatni lehetne a fő programot. Ha végzett a művelettel a konverter akkor majd meghív egy interruptot és a megfelelő programrész lefut. A szoftveres interruptokba írt algoritmusok segítségével célszerű az adott művelet eredményét feldolgozni. A perifériák a fő programfolyamtól függetlenül párhuzamosan képesek végezni a dolgukat, így a feladat kiadása után csak az eredmény megvárása a feladat. Ez hasonlít a .NET-os környezet eseménykezelésére, mint amikor egy eljárás feliratkozik egy másik eseményre, hogy az hívódjon meg az esemény bekövetkeztekor.
A fejlesztés során mi is az interruptok használata mellett döntöttünk. Minden AVR típusú µC rendelkezik belső órajel generátorral, ami programozható. Felprogramozás után kontrollernek másra nincs is szüksége csak tápellátásra.
Az eszköz rendelkezik belső órajel generátorral. Azonban ez az áramkör igen érzékeny a tápfeszültség zavarokra. Sajnos nem képes kellően stabil órajelet generálni az olyan érzékeny időzítést igénylő perifériáknak, mint a kommunikációhoz felhasznált USART vezérlő.
6.3.3. Kapcsolattartás az elektronikával
A kommunikációhoz felhasznált periféria az USART modul. Ehhez a perifériához rendkívül sok féle hardver illeszthető, ami ezt a protokollt képes implementálni. Tipikusan felhasználási területek: soros port, USB, Bluetooth. A projekthez egy egyszerű soros port illesztő használata mellett döntöttünk, annak egyszerű implementálhatósága és alacsony költségei miatt. Ez a modul egy egyszerű feszültség szintillesztő, ami a µC 0–5V-os üzemi feszültségét -12–12V-os soros porti feszültségszintekké konvertálja [9]. Kezdetben egy egyszerű MAX232 soros porti illesztőt használtunk, de ugyan ilyen jó megoldás lett volna USB-USART konverter, ami egy virtuális soros portot hoz létre a számítógépen, aminek a kezelése programozói oldalról megegyezik a hagyományos szintillesztős megoldással.
Programozási szempontból az olyan illesztők használata esetén nincs különbség, amik soros portként
6-3. ábra Vezérlő elektronika
Oldal: 21 / 72 szerepelnek a rendszerben. Tipikus példa a Bluetooth modulok. Ezért is volt egyszerű dolgunk lecserélni a vezetékes megoldást egy ilyen modulra. Egy Class 1 egységgel az áthidalható távolság 100 méter lehet. A .NET-es környezetben egy soros portot kezelő könyvtár felhasználásával azonnal küldhetőek információk a porton keresztül.
A µC esetében speciális regiszterek jelzik a beérkező információkat. Ezen regiszterek képesek szoftveres interruptokat kiváltani, ami után speciális eljárás hívódik meg és lefutnak a beprogramozott algoritmusok. A beérkező adatokat egy checksum - ellenőrző kód - védi a hibás irányítási adatok végrehajtódásától. Amennyiben hibás adatot kap a rendszer, azonnal leállítja a hajtást. Az alkalmazott csomagfelépítés a következő: (KÓD, BAL MOTORVEZÉRLÉSI ÉRTÉK, JOBB MOTORVEZÉRLÉSI ÉRTÉK, CHECKSUM). Az elektronikába bekerül egy olyan eljárás, ami bizonyos időközönként adatokat kér a gazda rendszertől (polling), hogy megbizonyosodjon a kapcsolat meglétéről. Ha a kapcsolat megszakadt, akkor a rendszert le kell állítani, és hibajelzést küldeni a felhasználónak, hogy értesüljön róla.
A felhasznált kapcsolati beállítások a következők: 9600 BaudRate5, 8 adatbit, nincs paritás bit, 1 StartStopbit, nincs kézfogás (handshake).
6.3.4. Robot vezérlése
Az elektronika fel lett készítve mind szervomotorok és hagyományos egyenáramú motorok kezelésére. DC motorok esetén egyszerű a vezérlés, hiszen a motoroknak nem kell speciális jelet biztosítani, csak a megfelelő kitöltési tényezőt kell beállítani és a motorvezérlőnek megadni a megfelelő irányt. A kitöltési tényezőt a µC PWM [10] (6-4. ábra) jel generátorának segítségével lehet beállítani. A megfelelő regiszterben be kell állítani a kíván értéket és a rendszer a következő ciklusban már a beállított paraméterek szerint képezi a jelet a motorvezérlőnek. A PWM jel integrálásának segítségével egy feszültségszintet kapunk, ami a motor esetében pl. a fordulatszámot és nyomatékot, de egy LED (Light Emitting Diode) esetében a fényerőt határozza meg.
Oldal: 22 / 72 A µC-be épített 16bites időzítő, számláló konfigurálása után a periféria két output lábán jelennek meg az előállított jelek a jobb, illetve a bal motor számára. A felhasznált motorvezérlő IC chip (L293) miatt az irányokat is meg kell tudni adni. Ez újabb 4 port vezérlését követeli meg.
A szervo motorok vezérlése jelentősen eltér a fentebb említett DC motorok vezérlésétől. Oda a 6–4-es ábrán jelzett típusú vezérlés szükség6–4-es, aminek az előállítása igen egyszerű. Azonban egy szervo motornak speciális időzített jelsorozat kell (6–5. ábra), hogy azzal beállíthassuk a forgási irányt és a tengelyek kitérési szögét, valamint a folyamatos forgásra képes motorok esetén a tengely forgatási nyomatékát.
A szervo vezérlés megvalósítására azért volt szükségünk, mert kezdetben speciális folyamatos hajtású szervók használata mellett döntöttünk. A későbbiekben ezt elvetettük és áttértünk a hagyományos, könnyen illeszthető és beszerezhető DC motorok használatára. Azonban ekkor a következő probléma ütköztünk a két motor karakterisztikája különböző és ezt kezelni kell és szinkronba kell azokat hozni.
6.3.5. Emulátor
A programok fejlesztése szempontjából előnyős, hogy rendelkezzünk egy emulátorral, amivel a fejlesztési munkálatokhoz nem szükséges maga a hardver, így mind tesztelési mind fejlesztési feladatok egyszerűsödnek. A felületen a megfelelő soros port kiválasztása után csatlakozhatunk a robot oldali szoftverkörnyezethez. A vezérléshez küldött adatok vizuális megjelenítésével egyszerűsödött a kódolási eljárások fejlesztése. Ahhoz, hogy tudjunk csatlakoztatni másik soros porti egységhez egy gépen két lehetőség van: Ha alrendszer fel van szerelve legalább kettő porttal, akkor azokat szembekötve egymással képesek lesznek kommunikálni, illetve virtuális soros port telepítése a fejlesztői gépre. Mivel mi nem rendelkeztünk olyan géppel a fejlesztés során, amin lett volna fizikailag két csatlakozás a virtuális megoldás mellett döntöttünk.
6.3.6. A robot biztonsági megoldása
A biztonsági megoldások több szempont szerint vizsgálhatjuk meg. Fizikális védelem valamit preventív jellegű, megelőző berendezések. Fizikai vádelem a rendszer robosztusságának növelésével érhető el, Ilyen szempontból a Husky (3–3. ábra) hordozó egy igen masszív felépítmény. A preventív jellegű berendezések, eljárások lehetnek pl.: távolság érzékelők vagy összeköttetés figyelése a szerverrel.
Távolságérzékelésre több módszer is adódik: ultrahangos vagy infravörös tartományban működő érzékelők.
6-6. ábra Sharp GP2D12 6-7. ábra Maxbotix LV-EZ0
6-8. ábra Működési ciklus [http://www.ikalodic.com]
Oldal: 23 / 72 rendelkezik poros, koszos környezetben is. [11]
A szenzorok lehetnek analóg illetve digitális kimenetűek is. Mi egy analóg kimenetű infra szenzort használunk fel. A szenzor kimenetét rákötjük a µC analóg komparátor bemenetére. Így tudjuk figyelni, hogy ha az előre meghatározott érték alá csökkenne az érzékelő kimenet, akkor a robotot az adott irányba nem engedjük tovább haladni.
Oldal: 24 / 72
6.4. Feladatok megvalósítása
6.4.1. Kommunikáció soros porton
A soros port megvalósítása a szoftverkörnyezetben soros port osztály esetében a megfelelő sebesség beállítások után, a soros port használatra kész is. Az osztálynál használt átvitelre vonatkozó beállítása a fentebb említettek megegyezik. A modulnál a DataReceived metódus került megvalósításra. Ebben a metódusban kiolvasásra kerül a µC-tól érkező üzenet és küldésre kerül a hálózaton felcsatlakozott felhasználónak, és egy logolásra szolgáló lista elembe kerül eltárolásra. A VisualStudio fejlesztő környezetben speciálisan lehet csak a beérkezett adatokat kiolvasni, mert különben szálhivatkozási hibát dob. Ennek a problémának a megoldására egy Invoke metóduson belül egy új delegate osztály létrehozásával az olvasás máris lehetséges. Adatok Küldése a µC felé az osztály Write metódusának meghívásával lehetséges.
6.4.2. Hálózati kommunikáció
A kommunikáció alapjául az operációs rendszer hálózat kezelését használtuk fel. A hálózatra azért esett a választás, mert a megfelelő osztályok példányosítása után TCP/IP protokollt használhatjuk.
Ennek felhasználásával egy igen széleskörűen alkalmazott közegen leszünk képesek kommunikációs csatornát felépíteni. Akár mobil hálózatok is felhasználhatóvá válnak. Először vezetékes hálózatokat használtunk, majd később áttértünk WIFI alapú közeg használatára.
Kezdetben a hálózati kommunikációs modul egy univerzális megoldás volt, amit a szerver és a robot oldalon is alkalmaztunk. Az itt bemutatott modul azonban már csak a szerver oldalon használatos mivel a fejlesztések előrehaladtával a mobil egységre egy iPhone típusú okostelefon került, aminek a hálózat kezelési metrikája eltér a . NET-es környezetben felhasználtaktól.
A .NET-es környezetben a kommunikációs modul egy külön osztálykönyvtárként került megvalósításra, amit a használathoz a referenciák közé be kell állítani majd példányosítani. Az osztályok közti kommunikációiért ez un. EventHandlerek felelnek, ezek azok az egyedi eljárások, amin keresztül az adott eseményre feliratkozott metódusoknak tudunk üzenetet küldeni és átadni paramétereket. Ilyenek például a DataReceived, ez akkor hívódik meg, ha a csatornán egy másik féltől érkező adatok kiolvasásra kerültek. A hálózati kapcsolat felépítése szempontjából fontos, hogy a háttérben folyamatosan figyeljük az adott kapcsolathoz beállított portot. Ehhez a szálak (threadek) alkalmazása elkerülhetetlen. Szálak alkalmazásával megvalósítható, hogy a fő program folyamtól függetlenül történjenek események vagy fussanak egyéb folyamatok a rendszerben, mint például egy port figyelése.
Az elkészített modul példányosításakor definiálni kell a csatornán átküldeni kívánt adatok típusát;
képek küldésére akarjuk felhasználni vagy egyéb irányítási információk továbbítására. Ez után célszerű egyből feliratkozni a modul eseménykezelőire, mint például a Connected aminek a segítségével értesítést kapunk ha csatlakoztak a rendszerünkhöz. A létrehozott saját osztály példány, StartServer() metódusát meghívva indul el az hálózati portnak a figyelése. A háttérben ekkor egy szálon folyamatosan egy ciklus fut, ami figyeli, hogy van e várakozó kapcsolat, amíg nincs akkor a szálat alvó állapotba teszi 1 századmásodpercre. Azért szükséges ez az eljárás, mert a rendszerben felemésztené az erőforrásokat a folyamatos lekérdezése a pending6 állapotnak. Várakozó kapcsolat
6 Várakozó
Oldal: 25 / 72 odafigyelést igényel, hogy bezáráskor egy szál sem maradhat futásban, mert az megakadályozza a program bezárulását, ezért a program bezárásakor mindenképp meg kell hívni a szál Join metódusát.
Így a fő programszál leállítása addig nem történik meg, amíg a háttérben futnak kapcsolódó szálak.
A modul tartalmaz egy Connect eljárást, amivel a már beállított szerverhez van lehetőség kapcsolódni az IP cím illetve a port megadása után. A SendData eljárás segítségével lehet az adott Streamre elhelyezni az adatokat. A NetworkStreamre helyezett adatokat a rendszer automatikusan elküldi a másik félnek, ezzel a programozónak már nem kell foglalkoznia.
Az iPhone esetében a hálózat kezelés alapjaiban nem sokban különbözik a .NET es féle megoldástól.
CFWriteStreanRef objektum az, ami hálózati Stream referenciáját eltárolja. Amikor adatot akarunk küldeni akkor ez a referencia objektum, amire hivatkozni kell. Ezután egy socket kialakítása következik a hosttal, ezzel azt mondjuk meg, hogy a Stream kivel áll kapcsolatban, és hova kell csatlakoznia. Néhány kapcsolati tulajdonság beállítása után a Stream megnyitható és ezzel készen álla a kommunikációra. Adatok küldésére a CFWritrStreamWrite eljárás használható, aminek paraméteri közt az előbb létrehozott NetworkStreamet illetve a továbbítandó adatokat kell megadni. Az adatok küldése előtt érdemes lekérdezni a csatorna állapotát, hogy az képes e fogadni a csomagokat, Ezt a CFWriteStreamGetStatus segítségével tehetjük meg, ami egy enum-ként adja vissza a kapcsolati státuszt.
6.4.3. Képkinyerés kamerából
A fejlesztések kezdetekor két számítógép hálózati kapcsolata jelentette a rendszer összetevőit, ezért egy olyan eljárást kellett találni, amivel a számítógépen sikeresen lehessen kiolvasni a képeket. Ehhez egy külön osztály készült, ami az EmguCV wrapper segítségével olvassa ki a webkamerától érkező képeket. A kiolvasott képek Bitmap osztály formájában továbbítja azoknak az osztályoknak, amelyek feliratkoztak az eseménykezelőre. A képkinyerő modul tartalmaz még egy megjelenítési részt is, ahol a kiolvasott képek látszanak, ezáltal könnyítve meg a későbbi tesztelést. A modult referenciaként megadva, majd példányosítva, bármilyen egyéb rendszerbe beilleszthetővé válik.
A képkiolvasást megvalósító osztályba került még elhelyezésre egy olyan funkció, aminek segítségével elmenthetővé válnak a kamera által készített és kiolvasott képek. Ezt később fel is használhatjuk például a publikus adatok közzétételénél, hiszen a modul által elmentett képeket le lehet kérni az integrált webszervertől.
7 Stream: egy előre meg nem határozott hosszúságú adatfolyam
Oldal: 26 / 72 Mivel nem adódott lehetőségünk olyan méretű hordozó építésére, ami egy teljes funkcionális számítógépet vagy laptopot elbírna, ezért alternatív megoldások számbavételére volt szükség.
Alternatívaként felmerült egy WIFI webkamera beszerzése, azonban a webkamerák általános képalkotási minőségét is felmérve, nem felelt volna meg a minőségi igényeknek, ezért döntöttünk egy okostelefon felhasználása mellett.
A rendszer fejlesztése végül iPhone használatával folytatódott. Azonban a képkinyerés a telefon esetében más megközelítést igényel, mint az EmguCV könyvtár használata estén. Az iPhone 4-es telefon kamerája autófókuszos. Ez azért probléma, mert az képfeldolgozási eljárások nem képesek az olyan képsorozatot kezelni, aminek minden képe más fókuszponttal készült el. Ezért ezt a funkciót ki kellett kapcsolni. Az Objective-C esetében az AVFoundation programkönyvtár az, ami a telefon média bemeneteinek kezelésére szolgáló függvényeket és objektumokat leírja. Ahhoz hogy a kamerából kinyerjük a képeket egy folyamatirányító objektumot kell felhasználni. Az AVCaptureSession esetén az adott folyamatra vonatkozó bemeneti eszközöket kell megadni. Nekünk csak a kamera képe kell, ezért elég megadni a videó típusú eszközöket a rendszerből, majd beállítani, hogy a fényképező optika fókusza ne változzon a képek készítése folyamán. Kimenetként érdemes megadni valamilyen képmegjelenítő modult, hogy látható legyen az elkészített kép. Ezek elmentése után a Sessiont el kell indítani és már is kinyerhetőek a képek a kamerából. A kapott képeket ezután már továbbíthatjuk a hálózaton a szervernek modellépítés céljából.
6.4.4. Irányítás
Az irányítási feladat egy igen érdekes feladatkör volt a számunkra. Egy robot manuális irányítása esetén egy olyan rendszer használata, ami sokkal jobban közelíti az analóg irányítási metrikákat, jelentősen finomabb mozgatást tesz lehetővé a digitálisnál, billentyűzetes vezérlésnél. Ezért egy speciális osztály beépítését alkalmazva illesztettünk egy botkormányt a rendszerhez. A SlimDX modul egy nyílt forráskódú DirecX wrapper, amit a .NET es alkalmazásokhoz fejlesztenek. Ezzel a modullal sikerült elérni a direct input API-t ami felelős a játékvezérlők kezeléséért a Windowsos rendszer alatt.
A botkormány illesztése azért is ajánlatos mert, mer így a gombok felprogramozásával sok funkciót kézre lehet szabni.
A játékvezérlők tengely állapotának leolvasása soros kóddal megtehető. Alapvetően a polling
A játékvezérlők tengely állapotának leolvasása soros kóddal megtehető. Alapvetően a polling