Szakdolgozat
Miskolci Egyetem
Pilóta nélküli járm¶vek látás alapú, precíziós navigálása
Készítette: Kálmán Roland 2015. Programtervez® Informatikus BSc.
Témavezet®: Árvai László
Konzulens: Dr. Házy Attila
Miskolc, 2015
Miskolci Egyetem Gépészmérnöki és Informatikai Kar
Szám:
Alkalmazott Matematikai Tanszék
Szakdolgozat Feladat
Kálmán Roland (FUDJ82) programtervez® informatikus jelölt részére.
A szakdolgozat tárgyköre: A szakdolgozat címe:
digitális látás
Pilóta nélküli járm¶vek látás alapú, precíziós navigálása
A feladat részletezése: Helyb®l fel- és leszállásra képes pilóta nélküli légi járm¶vek látás alapú leszállássegít® rendszerének kidolgozása. A feladat megoldásához szükséges áttekinteni a vonatkozó irodalmat - beleértve akár a pilóta által vezetett - leszállást segít® rendszereket. Ki kell választani a megfelel® képfeldolgozási környezetet, gyelembe véve a repül®eszköz fedélzeti korlátozásait (súly, energiafogyasztás, méret). Ezzel együtt meg kell alkotni és optimalizálni a rendszer által könnyen és megbízhatóan felismerhet® jelöl®rendszert. És az így megtervezett rendszer demonstrációs változatát el kell készíteni.
Témavezet®(k): Konzulens(ek):
Árvai László, vezet® kutató, Bay Zoltán Közhasznú Nonpro t Kft. Dr. Házy Attila, egyetemi docens
A feladat kiadásának ideje:
2014. szeptember 26.
................................. szakfelel®s
2
Eredetiségi Nyilatkozat
Alulírott Kálmán Roland; Neptun-kód: FUDJ82 a Miskolci Egyetem Gépészmérnöki és Informatikai Karának végz®s Programtervez® Informatikus szakos hallgatója ezennel büntet®jogi és fegyelmi felel®sségem tudatában nyilatkozom és aláírásommal igazolom, hogy a Pilóta nélküli járm¶vek látás alapú, precíziós navigálása cím¶ szakdolgozatom/diplomatervem saját, önálló munkám; az abban hivatkozott szakirodalom felhasználása a forráskezelés szabályai szerint történt. Tudomásul veszem, hogy szakdolgozat esetén plágiumnak számít:
•
szószerinti idézet közlése idéz®jel és hivatkozás megjelölése nélkül;
•
tartalmi idézet hivatkozás megjelölése nélkül;
•
más publikált gondolatainak saját gondolatként való feltüntetése.
Alulírott kijelentem, hogy a plágium fogalmát megismertem, és tudomásul veszem, hogy plágium esetén szakdolgozatom visszautasításra kerül.
Miskolc, . . . . . . . . . . . .év . . . . . . . . . . . .hó . . . . . . . . . . . .nap
................................. Hallgató
3
1. szükséges (módosítás külön lapon) A szakdolgozat feladat módosítása nem szükséges
......................
...........................
dátum
témavezet®(k)
2. A feladat kidolgozását ellen®riztem: témavezet® (dátum, aláírás):
konzulens (dátum, aláírás):
..............
.............
..............
.............
..............
.............
3. A szakdolgozat beadható: ......................
...........................
dátum
témavezet®(k)
4. A szakdolgozat . . . . . . . . . . . . . . . . . . . szövegoldalt . . . . . . . . . . . . . . . . . . . program protokollt (listát, felhasználói leírást) . . . . . . . . . . . . . . . . . . . elektronikus adathordozót (részletezve) ................... . . . . . . . . . . . . . . . . . . . egyéb mellékletet (részletezve) ................... tartalmaz. ......................
...........................
dátum
témavezet®(k)
5. bocsátható A szakdolgozat bírálatra nem bocsátható A bíráló neve: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ......................
...........................
dátum
szakfelel®s
6. A szakdolgozat osztályzata a témavezet® javaslata:
................
a bíráló javaslata:
................
a szakdolgozat végleges eredménye: . . . . . . . . . . . . . . . .
Miskolc, . . . . . . . . . . . . . . . . . . . . . . . .
................................. a Záróvizsga Bizottság Elnöke
4
Tartalomjegyzék
1. Bevezetés, célkit¶zés
7
2. Pilóta nélküli légijárm¶vek
9
2.1.
VTOL UAV és a precíz leszállási képesség jelent®sége . . . . . . . . . .
10
2.2.
Fejlesztési eszközök . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.1.
Quadrocopter . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.2.
Billen®rotoros repül®gép
13
. . . . . . . . . . . . . . . . . . . . . .
3. Leszállást segít® rendszerek 3.1.
3.2.
14
Pilóta vezette repül®gépek . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.1.1.
Rádiós rendszerek . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.1.2.
Optikai rendszerek
. . . . . . . . . . . . . . . . . . . . . . . . .
15
Pilóta nélküli repül®gépek
. . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2.1.
Amerikai Egyesült Államok Haditengerészet megoldásai . . . . .
16
3.2.2.
Kísérleti megvalósítások
18
. . . . . . . . . . . . . . . . . . . . . .
4. A rendszer
21
4.1.
Megközelítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2.
Leszállás megkezdése és leszállás . . . . . . . . . . . . . . . . . . . . . .
23
4.3.
A probléma pontos megfogalmazása . . . . . . . . . . . . . . . . . . . .
23
5. A rendszer implementálása
25
5.1.
Képfeldolgozó egység . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.2.
Képfeldolgozás folyamata . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5.2.1.
Átalakítás és képek el®sz¶rése . . . . . . . . . . . . . . . . . . .
26
5.2.2.
Blob detekció
28
5.3.
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Markerek meghatározása és felismerése
. . . . . . . . . . . . . . . . . .
28
. . . . . . . . . . . . . . . . . . . . . . . .
29
5.3.1.
Alakzat kiválasztása
5.3.2.
Trapéz felismerése, az algoritmus m¶ködése
5.3.3.
Trapéz optimalizálása
5.3.4.
Trapéz és annak felismerésének a gyakorlati megvalósítása
. . . . . . . . . . .
30
. . . . . . . . . . . . . . . . . . . . . . .
32
. . .
34
5.4.
Kamera kalibráció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.5.
Térbeli leképezés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.6.
Szimuláció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6. A rendszer megvalósítása, kiértékelése 6.1.
Számítási egység választás 6.1.1.
6.2.
44
. . . . . . . . . . . . . . . . . . . . . . . . .
Az algoritmus futtatása és kiértékelése az eszközön
44
. . . . . . .
45
Jöv®beli fejlesztési lehet®ségek . . . . . . . . . . . . . . . . . . . . . . .
49
5
7. Összefoglalás 7.1.
Elkészített programok
51 . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
Ábrák jegyzéke
53
Irodalomjegyzék
55
Adathordozó használati útmutató
58
6
1. fejezet Bevezetés, célkit¶zés
Programtervez® informatikus hallgatóként sok érdekes területtel volt alkalmam megismerkedni tanulmányaim során. Ezek közül, amelyeket szerettem volna e szakdolgozat munkakörébe választani az, az egyfajta mesterséges intelligencia megalkotása, számítógépi képfelismerés segítségével. Emellett másik számomra érdekes terület az, ahol adott egy eszköz, és annak a szoftveres vezérlése a cél, illetve egy szimulációs környezet létrehozása hozzá. Az el®z® szempontok alapján esett a gyelmem a pilóta nélküli légi járm¶vekre. Rengeteg olyan videót és képet találni az interneten manapság, amiket köznyelvben drónoknak is nevezett eszközökkel vettek fel. Manapság egyre elterjedtebb, hogy él® közvetítéseknél is jelen vannak, hisz nagyon praktikus mikor állványok és helyhez kötött eszközök nélkül is tudunk adni él® felvételt egy-egy nagyobb rendezvényr®l. Az el®bb említett céloknál, viszont vannak sokkal komolyabb alkalmazásai is. Mivel az irányító csak távolról vezérli az eszközt, így olyan helyekre is el lehet juttatni ®ket, ahova már csak esetlegesen emberi élet veszélyeztetésével lenne lehet®ség elérni. Nézhetünk akár egy katonai felderítést, vagy egy nagyobb kiterjedés¶ erd®t¶z esetén a terület belsejét. Továbbá ezekre a célokra beláthatjuk, hogy egyes esetekben nincs is szükség nagyméret¶ légi járm¶vekre. Így az emberi jelenlét elvételével, kisméret¶ gépeket is építhetünk. Ezek üzemeltetése és javítása jelent®sen olcsóbb. A költséghatékonyságból adódóan egyes online web áruházak, jelenleg is fejlesztenek drónokat, hogy megoldják a gyors és kényelmes házhozszállítást [1]. Ezen felül egyes helyzetekben hatalmas el®nyt jelenthet a kis méretük, illetve hogy egyes típusok képesek helyb®l fel- és leszállni. Lehet®vé válik számukra a zikai akadályok miatt nehezen megközelíthet® helyekre való eljutás. Ez például hasznos lehet, ha gyógyszereket [2], utánpótlást kell eljuttatni a rászorulóknak, elzárt falvakba, háborús övezetekbe. Természetesen az el®bb említett lehet®ségek mindegyikében már jelen vannak a drónok napjainkban is, ezért azok automatizálására történnek mindíg újabb fejlesztések. Ezt a feladatot is több kisebb-nagyobb részre tudjuk bontani, mint például az utak felderítése, akadályok felismerése és így az ütközések elkerülése, fel- és leszállás, stb. Ezzel pedig el is érkeztem a saját célkit¶zésemhez, amely az volna, hogy egy ilyen eszköz digitális szenzor (érzékel®) és egy kisméret¶ számítógép segítségével képes legyen egy ismert tulajdonságokkal rendelkez® marker (jelz®) rendszert felismerni, azok alapján pedig meghatározni a saját relatív helyzetét, majd elvégezni a leszállást. A dolgozat
7
témáján túl, pedig ezt megvalósítani akár egy mozgó járm¶re is. Így ami a munkám részét képezi, az angolul Unmanned Aerial Vehicle-nak nevezett, továbbiakban UAV-ok és az önm¶köd® leszállási rendszerek részletes megismerése, ezek ismeretében az optimális eszközök kiválasztása költség, súly, méret és hatékonyság tekintetében. Ezek közé tartozik maga a repül® szerkezet, a ráhelyezett fedélzeti számítógép, a kamera és a markerek. Ezután a már megfelel® kon gurációhoz megtalálni a legmegbízhatóbb jelöl®rendszert, nyílt forráskódú képfeldolgozót. Végül pedig megírni a végleges feldolgozó programot, szimulációkat készíteni és teszteket végezni. Végül pedig kiértékelni az elkészített algoritmusokat. Mivel a drónok vezérlésére már léteznek a piacon kapható használatrakész szoftverek, így a pályatervezés és irányítás nem témája a szakdolgozatnak, csak a digitális látás, képfeldolgozás és térbeli leképezés.
8
2. fejezet Pilóta nélküli légijárm¶vek
Pilóta nélküli légi járm¶veknek, egyszer¶bben drónoknak nevezzük azokat a repülni képes eszközöket, melyek vezérléséhez nem szükséges a személyzetnek a gépen tartózkodnia, egyes esetekben pedig képesek lehetnek önmaguk irányítására. A statisztikák azt mutatják, hogy egyre jobban kezd elterjedni a világ minden táján. A felhasználásuk nagy részét a katonaság és egyéb szervek teszik ki, de egyre többen kezdenek vele hobbiból is foglalkozni. A következ® ábrán [3] egy el®rejelzés látható az UAV-ok beszerzési és fejlesztési költségére:
2.1. ábra. Az UAV-ok költségvetésének el®rejelzése a világban [3] (Szerz® fordítása) Ebb®l is látszik, hogy az USA-n kívüli területeken is már 8 éven belül majdnem a duplájára fog emelkedni a drónok beszerzése, illetve ennek a területnek a kutatása és fejlesztése. Így nyilvánvalóvá válik az is, hogy még sok fejl®dés áll az eszközök el®tt. Visszatérve az UAV-okra, több típust tudunk megkülönböztetni m¶ködésük, felépítésük, méretük alapján. Els®sorban minket a mikro és kisméret¶ gépek érdekelnek. Ezek
9
2.1. VTOL UAV és a precíz leszállási képesség jelent®sége
0,5 és 25 kilogramm között mozognak. Hatótávolságuk nem túl nagy és 0-3 km-es magasságban üzemelnek. A piacon még ezeken a típusokon belül is nagy választék van, de jelenleg kett® fajta áll rendelkezésemre. Az egyik egy quadrocopter, a másik pedig egy xszárnyas- billen®rotoros repül®gép. Ezekr®l a fejezet végén esik részletesebben szó. A közös bennük, hogy képesek függ®leges irányú elmozdulásra fel- és leszálláskor. Ezek az úgynevezett VTOL (Vertical Take-O and Landing) UAV-ok. A rendszer fejlesztése kizárólag ilyen képesség¶ekre történik.
2.2. ábra. Az UAV-ok osztályozása (http://uav-society.blogspot.hu, szerz® fordítása)
2.1. VTOL UAV és a precíz leszállási képesség jelent®sége Ezeknek a drónoknak a felhasználási területein nagyrészt fontos, hogy rövid id®n belül úton legyenek, kis helyen is elférjenek, és könnyen tudjanak mozogni széls®séges terepviszonyok között is. Nincs szükség kifutópályára fel- és leszálláskor, így szinte bárhonnan képes elindulni a VTOL UAV. A céljuk is lehet összetett, ezért nem csak egy A-ból B-be való eljutásról van szó, hanem esetenként akár komoly man®verezésekr®l. Elengedhetetlenné válik tehát, hogy vertikálisan (függ®legesen) is tudjanak mozogni, vagy tartani a helyzetüket. A precíz leszállási képesség egyik legf®bb jelent®sége, hogy emberi beavatkozás nélkül tudjon a járm¶ egy adott platformra leszállni nagy pontossággal. Az emberi rontás lehet®sége kiesik és egy robosztus rendszernél a hibázás esélye nagyon alacsonnyá válik. Ezen felül egy nagyméret¶ gépet tekintve már elengedhetetlenné válnak képzett pilóták, akik felszállnak vele, majd lerakják azt egy nem túl távoli mobil központból. A közelben kell lenniük, hisz másodperces késések is számottev®ek ilyenkor. Viszont a küldetés közbeni utasításokat akár a bolygó másik felér®l is kiadhatják. Egy cikk szerint [4], a fel- és leszállás automatizálásával elhagyhatóvá válik a földi pilótafülke és az azokhoz tartozó kommunikációs kapcsolatok kiépítése. Ezért az egyik nagy korlátozó ok az UAV-ok felhasználásánál ez, hiszen kevés az erre képzett ember, az eszközök pedig drágák. Továbbá a kisméret¶ gépek üzemideje nagyon kicsi. Ugyanis minél nagyobb tömeget kell elbírnia, annál több energiát fogyaszt. Így az akkumulátor kapacitását a célnak
10
2.1. VTOL UAV és a precíz leszállási képesség jelent®sége
2.3. ábra. Egy földi pilótafülke (http://www.wired.com)
megfelel®en kell megválasztani és megtalálni a leghatékonyabb súly-energiafogyasztás arányt. Az átlagos munkaideje egy töltéssel ezeknek a drónoknak 40 perc és 1 óra körül van. Ilyenkor az irányító személynek le kell szállnia, majd kicserélni az energiaforrást, ami közben az emberi rontás veszélye fennáll. Továbbá a csere is id®igényes. Ennek a folyamatnak az automatizálásával is nagy el®nyre lehet szert tenni. Egy ilyen automatizált rendszerrel létre lehet hozni folyamatosan mozgásban lév® meg gyel® egységeket. Ezek biztonsági célokon felül katasztrófák megel®zésére is alkalmasak lehetnek. Történtek fejlesztések erd®tüzek meg gyelésére [5], amely segítségével az égb®l gyelhet®ek a veszélyeztett zónák. Továbbá egy jól m¶köd® rendszer esetén már akár a leszálló felület is lehet mozgásban, legyen az akár egy teherautó platója, vagy egy hajó fedélzete. Ez nagyban könnyítené az olyan helyzeteket, ahol az állomás mozgásban van. Visszatérve az el®z® példára, vegyünk egy természeti katasztrófát. Az egyéb funkcióra alkalmas (mentés, t¶zoltás) földi vagy vízi járm¶vek is összeköthet®vé vállnak a drón fel- és leszálló platformjával. Ez a valóságban úgy nézne ki, hogy menet közben valaki elküldi és vezérli az eszközt, eközben a szállító járm¶ végzi zavartalanul a saját feladatát, majd a drón visszatér és leszáll minden nehézség és bonyolult kézi man®verezés nélkül. Ebben a példában a legnagyobb nyereség az id®, ami életeket menthet. Az energiaforrás cseréjét tovább vezetve, itt is beláthatjuk, hogy egy t¶zoltásra szánt drón, ha képes a vizet automatikusan újratölteni, nagyobb hatékonyságot érhetnek el. Mivel nem kell ®ket kézzel irányítani, több gépet is üzemeltethetnek egyszerre, kevesebb személyzettel.
11
2.2. Fejlesztési eszközök
2.2. Fejlesztési eszközök Jelenleg az említett két eszköz áll rendelkezésre a fejlesztéshez. A közös bennük, hogy tartalmazniuk kell egy körülbelül bankkártya méret¶, egyetlen lapra integrált számítógépet és képi szenzort a feldolgozáshoz.
2.2.1. Quadrocopter Egy ezzel foglalkozó cikk [6] megfogalmazásában. Általánosságban multikoptereknek hívják azokat a mechanikailag egyszer¶ légi járm¶veket, ahol a mozgást több lefele irányított rotor sebességeinek kontrollálásával érik el. Aerodinamikailag nem stabilak, így szükség van szoftveres kiegyenlítésre, nélkülük nem is m¶ködnek. Ezek a programok adatokat gy¶jtenek a bels® giroszkóp és gyorsulásmér® segítségével, majd azok kiértékelésével vezérlik az eszközt. Irányításukat a rotorok forgási sebességével tudjuk elérni.
2.4. ábra. Egy X525-ös quadrocopter (www.aliexpress.com)
A kategórián belül az egyik legegyszer¶bb koncepció a quadrocopter. A nevéb®l is adódik, hogy négy rotorja van. Rövid légcsavarokkal szerelt és nagy el®nye, hogy nincs szükség mechanikailag összehangolni azok forgását. A propellerek méretéb®l következik, hogy a környezeti sérülésveszély kicsi ütközés esetén. Azok forgási iránya és sebessége alapján a 2.5 ábra mutatja, hogyan képes navigálni.
12
2.2. Fejlesztési eszközök
2.5. ábra. Az irányítás módja (http://wikipedia.org)
2.2.2. Billen®rotoros repül®gép Ezeknek az eszközöknek a felépítése nagyon változatos lehet. A rendelkezésre álló modell két cs®légcsavart tartalmaz. Ezek képesek elfordulni, így lehet®vé téve a helyb®l felés leszállást, azaz a vertikális mozgást a gépnek. Leveg®ben a szárnyak kialakításából adódóan hasonlóan m¶ködnek, mint a repül®gépek. Így nagyobb sebesség érhet® el velük, viszont a legnagyobb el®nyük egy hagyományos helikopterrel vagy multikopterrel szemben, hogy a repülési id® és hatótávolság megn®. Ugyanis a hajtóm¶veknek kisebb teljesítményt kell leadniuk a szárnyak által generált felhajtóer® miatt. A kialakításból még az is adódik, hogy sokkal kisebb terhet is bírnak el, mint a rövid vagy hagyományos nekifutással felszállni képes társaik. Ennek elkerülése érdekében futóm¶vekkel szerelhet® és VTOL helyett STOL-á alakítható. (Short Take-O and Landing). Ilyenkor a fel- és leszálláshoz rövid kifutás szükséges, viszont a szárnyak nagyban segítenek a megnövekedett teheremelésben. Egy másik el®ny¶k még, hogy meghibásodás esetén vitorlázással csökkenthet® a sérülés mértéke.
2.6. ábra. A gép tervezett kinézete (http://www.cygnusuav.hu)
13
3. fejezet Leszállást segít® rendszerek
A leszállást segít® rendszerek fontosságáról az el®z® fejezetben írtam. A jelenleg m¶köd® fejlesztések áttekintése pedig ennek a fejezetnek a tárgya. Érdemes el®ször áttekinteni a fejl®dést, illetve megnézni, hogy hol jár napjainkban ez a technológia.
3.1. Pilóta vezette repül®gépek Egy történelmi cikkre [7] hivatkozva az els® sikeres beavatkozás nélküli leszállást 1937ben hajtotta végre két pilóta. Ez a gép az egyik®jük által kifejlesztett rádiós jeladók és m¶szerek segítségével volt képes erre a mutatványra. Ett®l függetlenül sokáig mégsem volt megoldott a leszállás automatizálása a többi gépen, így kézzel kellett azt végrehajtaniuk az irányítóknak. Régóta léteznek az irányító segítségére kifejlesztett rendszerek, amelyek egy jó kiindulást biztosíthatnak arra, hogy egy fedélzeti szoftvernek mit kellene végrehajtania és hogyan tegye azt. Érdemes ezeket részletesebben is megismerni, hogy esetleges támpontokkal vagy ötletekkel szolgáljanak a saját munkámban. A két legelterjedtebb módszer részletezése következik.
3.1.1. Rádiós rendszerek Egyik ilyen közismert rendszer az úgynevezett ILS (Instrument Landing System). Segítségével akár veszélyes id®járási viszonyok között is biztonságosan letehet® egy repül®gép. M¶ködése azon alapszik [8], hogy a földön kihelyezett rendszer által kibocsájtott rádiós jelre csatlakozik a repül®gép fedélzeti számítógépe. Ekkor kioszt neki egy haladási útvonalat, majd a pilóta a m¶szerek segítségével a kiválasztott pályára állítja a gépet. Ezután különféle jelzések által vezérelt markerek segítik az irányító tájékozódását és a leszállás állapotát. Ez a technológia már az 1950-es években is létezett, a megnövekedett légi forgalom hatására.
14
3.1. Pilóta vezette repül®gépek
3.1. ábra. Egy ILS rendszer kialakítása (http://instrument.landingsystem.com/)
3.1.2. Optikai rendszerek Mivel kép alapú információk alapján szeretném a leszállást végrehajtani, így érdemes ezeket a technológiákat is szemügyre venni [9]. OLS-nek (Optical Landing System) hívják azokat a rendszereket, ahol a pilóta valamilyen optikai jelz®rendszer segítségével tudja megfelel® pályára állítani a gépet. Kezdetben a látásukra, és egy a földön jelzéseket adó irányító személyre hagyatkozva voltak kénytelenek landolni. Ezt a megoldást váltotta fel egy energiaforrásra kötött, mobil állomás, amit az adott helye telepítenek. Ezt a rendszert angolul meatball, azaz húsgolyónak is szokás hívni. A nevét onnan kapta, hogy egy látszólag fel-le futó csali fény jelzi a pilótának, hogy az optimális magassághoz képest milyen helyzetben van a gép. Ezt a fényjelzést persze nem kézzel vagy géppel irányítják, hanem egy olyan trükköt alkalmaznak, hogy a sugarakat feler®sítik, majd átengedik Fresnel lencséken [9]. Ezek a lencsék biztosítják, hogy a fényforrásra való rálátás beesési szögét®l függ, hogy a pilóta mit lát. M¶ködését úgy kell elképzelni, hogy ha a középs® fény lefele mozdul el, akkor a gép is túlságosan alacsonyan száll, ellenkez® esetben pedig túl magasan. Ebb®l következik, hogy a pilótának középen kell tartania ezt a fényt. További kiegészít® fények is találhatóak rajta, egyéb tájékoztatásakat szolgáltatva. Ezt a technológiát f®leg anyahajókon használják, és a mai napig nagyon elterjedt.
3.2. ábra. Egy mobil optikai leszállást segít® rendszer (http://wikipedia.org/)
15
3.2. Pilóta nélküli repül®gépek
3.2. Pilóta nélküli repül®gépek Az UAV-ok felhasználása napjainkban már nem csak katonai célúak, hanem belefolyt az egyéb szervek és hobbi felhasználók körébe is. Ezek automatizált le-és felszállása így nagyon sok embert foglalkoztat, és tényleges kivitelezésük még nem elterjedt. Ebben az alfejezetben megnézzük, milyen próbálkozások voltak erre, és hol tart a jelenleg az amerikai haditengerészet az anyahajós drónjaikkal.
3.2.1. Amerikai Egyesült Államok Haditengerészet megoldásai Mivel egyre több küldetésnél lett szükség az UAV-okra, így elengedhetetlenné vált a 100%-os önvezérlés. A felszállás könnyen kivitelezhet®, de a földet érés nagyobb fejtörést okoz. Ezért egy id®ben inkább arra törekedtek, hogy ezt a man®vert ki tudják kerülni. Szárazföldön például egyik megoldás, hogy ejt®erny®vel szerelik [10] a drónokat, majd a visszatéréskor kinyitják az ejt®erny®t, és ahova érkezik, ott összeszedik. Err®l még jóindulattal sem mondható el, hogy precíz, illetve egy mozgó anyahajón már közel lehetetlen megoldásnak számít. Ezért törekedtek helyette egyfajta elkapó rendszer kidolgozásán. Ez az úgynevezett háló-alapú befogás. A lényege, hogy egy hálós szerkezetet állítanak [11], majd a fedélzeti számítógép vagy egy vezérl® személy valamilyen módszerrel belevezeti a gépet. Ez egy elég low-tech (alacsony technológiájú) kivitelezés, már-már inkább csak valami ideiglenes és olcsó megoldásnak t¶nik, mintsem komoly találmánynak a probléma megoldására. Nagy súlyú gépekre nem alkalmazható, illetve kis eszközöknél is nagy a sérülés veszélye. Id®igényes a hálóból való kiszedés, továbbá költséges a folyamatos javítás. Ezen felül külön csapatokat kell fenntartani ezen munkák elvégzésére.
3.3. ábra. A hálós elkapás megörökítése (http://olive-drab.com)
16
3.2. Pilóta nélküli repül®gépek
Történtek próbálkozások ennek a technológiának a továbbfejlesztésére is. Egy elképzelésre [11] hivatkozva, megpróbálták lecserélni a hálót acél kábelekre, amit az UAV-nak a rajta kialakított fékhoroggal kell elkapnia. Ezután a kábel képes ráhúzni az eszközt egy guruló platformra. Ez egyébként egy mai napig használt módszer a pilóták vezette repül®gépek esetén is. Legnagyobb el®nye az el®djével szemben, hogy a gép sérülésének valószín¶sége csökken, kisebb a költségveszteség, és rövidebb id® a gépek visszanyerése, továbbá a gépeken csak egy kicsi átalakítást kell elvégezni. Hátránya pedig, hogy egy pályát kell kialakítani a guruló platformnak, illetve meg van rá az esély, hogy els®re nem sikerül elkapni a kábelt, csak többszöri próbálkozásra. Ezek a megoldások inkább mechanikai kivitelezések, mintsem a számítógépes technológia kihasználása. A cél így az volt, hogy különféle szenzorok segítségével legyen képes tényleges leszállást végrehajtani egy UAV. Egy, a haditengerészet által kiadott prezentációban [12] olvashatunk róla, hogy a tervek között szerepelnek olyan elképzelések, mint például az akadályok felismerése és kikerülése, érzékel®k általi adatkapcsolat, és olyan fedélzetre való leszállási képesség is, ahol maga a hajó nincs felszerelve erre kialakított eszközökkel. Ami fontos még, hogy mindezt úgy tudja végrehajtani, hogy az id®járás, a leszállópálya egyes pontjainak kitakarása, vagy rossz látási viszonyok se befolyásolják a man®vert. Mindezek megvalósítását a következ® módszerekkel szeretnék elérni:
•
Geostacionárius m¶hold (Pseudolite) alkalmazása a lokális helymeghatározáshoz.
•
SRGPS (Shipboard Relative GPS) használata, ami szintén a relatív helyzet ismeretéhez szükséges a hajó és az UAV között.
•
EO/IR (Electro Optical / Infrared) érzékel®k a leszállás segítésére. Ilyenek a lézerek, LED-ek, vezetett hullámok.
•
Lézer alapú távvezérlés (LIDAR).
•
Lézeres ILS rendszer.
•
Rádiófrekvenciás jelek közötti id® különbség mérése, ami a hátralév® repülési id®t, azaz a gép távolságát határozza meg.
•
Aktív és passzív RADAR-ok.
Továbbá a célok között említi, hogy kés®bbiekben mindezt úgy, hogy a GPS alapú navigáció teljes elhagyásával. Ez azért egy fontos lépés, mert sok esetben a jelet könnyen elveszítheti a gép, így nem lehet egy ilyen kritikus helyzetet alapozni rá. A nagy áttörés egy 2013. júliusi esemény [13], amikor megtörtént az els® sikeres leszállás egy anyahajóra, amit az X-47B elnevezés¶ lopakodó hajtott végre. Az internetet bejárta a híre, és egy videó, amin lerakják a gépet, de sajnos az automatikus leszállásról készült verzió nem került ki. Egy anyahajóra meg kell jegyezni, hogy a víz hullámzása és a folyamatos haladás megnehezíti a leszállást. Egy ilyen leszállópályának 6 szabadságfokú elmozdulása van, amivel tudnia kell számolni a rendszernek. Ebb®l adódik, hogy az els® ilyen sikeres leszállás ember által egy nagy eseménynek tudható be és történelemkönyvekbe is bekerült: 1911. január 18-án Eugene Ely hajtotta végre a USS Pennsylvania (ACR-4) cirkálóra. [14] Így láthatjuk, hogy elég sok id®nek kellett eltelnie, hogy egy repül®gép ezt a man®vert a fedélzeti program segítségével, önállóan
17
3.2. Pilóta nélküli repül®gépek
elvégezze. A megvalósítás pontos kivitelezésér®l nem adtak ki közleményt, de az el®z®ekben felsorolt lehet®ségek segítségével valósították meg. A bonyolultságáról viszont annyit tudni, hogy négy különálló, de egymással kommunikáló számítógépet alkalmaztak, amik folyamatosan adatokat cseréltek és abban az esetben, ha csak egyik®jük is eltér® eredményeket számol, a leszállás megszakítandó.
3.4. ábra. A leszállás megörökítése (www.dailytech.com)
3.2.2. Kísérleti megvalósítások A haditengerészeten kívül más szerveket is foglalkoztat ez a téma, viszont mivel a költségvetésük kicsi, ezért más, olcsóbb megoldások kerülnek el®térbe és persze az UAV-ok mérete is kisebb. Egy jelenleg is piacon lév® és m¶köd® technológiát [15] a RUAG Aerospace fejlesztett ki. Ez az OPATS (Object Position And Tracing Sensor) elnevezés¶ rendszer egy földi lézeres egységgel állapítja meg az UAV helyzetét. Amint a kihelyezett eszköz látótávolságába ér a drón, egy lézert irányít rá. A gépre szerelt macskaszem segítségével pedig a visszatükrözésb®l számolja ki annak helyzetét és a leszálláshoz szükséges pályát. Emiatt a rendszer egyszer¶ és olcsó sok UAV felhasználása esetén is. Bár sajnos egyszerre csak egy gépet tud kezelni és a jöv®beli lehet®ségek is korlátozottak.
18
3.2. Pilóta nélküli repül®gépek
3.5. ábra. A leszállás megörökítése (http://www.ruag.com) Egy másik lehetséges megoldást a Dél-kaliforniai Egyetemen fejlesztettek [16, 17] ki UAV helikopterekre. A képi feldolgozásra hagyatkozva képes felismerni, követni, pályát tervezni és leszállni egy mozgó platformra. El®re beleprogramozták, hogy milyen formájú alakokat kell keresnie a gépnek, majd az adott pillanat képe és a valós méretek ismeretében állapítja meg a saját helyzetét az eszköz. A kihelyezett jelzéseknél fontos, hogy minél egyedibbek legyenek bármi máshoz képest, ami a környezetében el®fordulhat. Nagy hátránya, hogy ezek a passzív markerek csak a közelb®l ismerhet®ek fel, rossz id®járási körülmények vagy fényviszonyok miatt nem láthatóak.
3.6. ábra. Passzív markerek felismerése (http://rd.csp.it/archives/1142)
19
3.2. Pilóta nélküli repül®gépek
Ehhez hasonló megoldásokkal sokan próbálkoznak jelenleg is. A felhasznált algoritmusok hasonló képfeldolgozási módszereket használnak. Ezekben különféle sz¶r®k segítségével feler®sítik a kép azon részeit, amelyet fel kell dolgozni, majd valamilyen algoritmussal kinyerik a kívánt információt. Ezekb®l az adatokból pedig megállapítják az UAV relatív pozícióját a markerekhez képest. Másik újszer¶nek számító megoldással többen is foglalkoznak jelenleg. Egy olyan jelenségr®l van szó, amit az emberek is nap-mint nap érzékelnek és feldolgoznak [18, 19]. Viszont az alapötletét a rovarok repülése adta, akik bármilyen újszer¶ környezetbe képesek mozogni hibátlanul a gyenge látásuk ellenére is. Ami lehet®vé teszi ezt számukra az úgynevezett optikai áramlás (Optical Flow). Nagy el®nye a korábbi képfeldolgozási megoldásokkal szemben, hogy alacsony min®ség¶ képekkel is nagy hatékonysággal tud dolgozni, így kisebb lesz a feldolgozásra szükséges kapacitás. Lényege a látott kép elúszási mértékének a mérése. Egyszer¶ logikával is rájöhetünk, hogy a vizsgáló és a vizsgált tárgyak között valamilyen matematikai összefüggés van. A közelebbi tárgyak elhaladás közben gyorsan mozognak, a távolabbiak lassabban. Például vegyünk egy olyan esetet, ahol a meg gyelt tárgy, adott id® alatt a látóterünk feléig jut el, ellenben azzal, amikor a teljes látótéren áthalad. A magasság ismeretében és a szenzor adataiból már számolható az elmozdulás mértéke. Ezt használják ki, a mintavételezéseket régiókra, vagy pixelekre osztva összehasonlítják egymással, majd az eltérésekb®l egy értéket adnak vissza a program számára. Ezekb®l a kapott eredményekb®l egy folyamatosan változó vektormez®t lehet felírni, amiben a vektorok irányát és hosszát ez a módszer adja.
3.7. ábra. Két képkocka között számolt vektorok (http://cbia. .muni.cz) Az én esetemben persze gyelembe kell azt is venni, hogy a vizsgáló eszköz és a vizsgált platform is mozog, illetve a drón ki is billenhet akár. Jelenleg ezzel a technológiával már képesek az UAV-ok tájékozódni a visszatérési ponthoz vezet® úton, és a közben felmerül® akadályokat felismerni, egy bels® modellt alkotva a környezetükr®l.
20
4. fejezet A rendszer
Egy ilyen rendszer m¶ködésének több meghatározó fázisa is van. Az els® az, amikor a drón túl messze van a leszálló platformtól, vagy még nincs jó rálátása a markerekre. Ekkor valamilyen módszer segítségével meg kell határozna a relatív helyzetetét a leszálló felülethez képest, majd megközelíteni azt néhány méteres közelségben. Miután ez megtörtént, egy másik üzemmódba váltva, a képi feldolgozásra hagyatkozva történik a további pályatervezés. Ekkor fenn áll a lehet®sége a leszállás megszakításának, ha a mért adatok egy bizonyos biztonsági küszöböt átlépnek. A harmadik üzemmód akkor következik, ha sikerült a gépet centiméteres pontosságig eljuttatni a leszálló felülethez. Ekkor egy mechanikai rendszer m¶ködésbe hozásával kell megfogni a drón talpát vagy lábait.
4.1. ábra. A leszállás fázisai (Szerz® saját képe)
21
4.1. Megközelítés
4.1. Megközelítés Ez az a rész, amelyben valamilyen technológia segítségével az UAV megközelíti a platformot. Ilyen technológia lehet például az egyszer¶ GPS, ami 10 méter körüli átlag pontosságot tud adni. Viszont itt ennél többre van szükség, így egy lehetséges megoldásnak bizonyulnak az úgynevezett dierenciál GPS-ek (DGPS) [20]. Ezek m¶ködése azon alapszik, hogy elhelyeznek egy referencia egységet a leszállón, és az ebb®l kapott adatokkal korrigálják a drónon lév® adatokat. A módszer segítségével, már akár centiméteres pontosságot is sikerült elérnie egyes gyártóknak. Ezen kívül léteznek LPS-ek [21] (Local Position System) is, melyek WiFi, ultrahang vagy rádiófrekvencia segítségével képesek helyzetet meghatározni. Egy közvetít® antenna jeleit mérik a gépre helyezett érzékel®k, és ezt használják tájékozódásra. A nagy el®nyük a GPS-ekkel szemben, hogy beltérben hatékonyak, illetve nem blokkolják az épületek a jeleket. Viszont hatótávolságuk nyílt téren jelent®sen alacsonyabb [22].
4.2. ábra. Egy dierenciál GPS m¶ködése (Szerz® saját képe) A folyamatot úgy kell elképzelni, hogy a drón felveszi a kapcsolatot a leszálló platformmal egy kommunikációs csatornán. Amennyiben egy folyamatosan mozgó objektumról van szó, akkor pályát és találkozási pontot egyeztetnek, majd az UAV az el®z®leg említett rendszer segítségével megtervezi a pályát a két eszköz között.
22
4.3. A probléma pontos megfogalmazása
4.2. Leszállás megkezdése és leszállás A rendszer amint képes a képi és egyéb érzékel®k adatainak feldolgozásából navigálni, átvált azok feldolgozására, és folytatja a pályatervezést a leszálláshoz. Ez a legkritikusabb fázisa a m¶veletnek. Itt fontos, hogy amint a mért adatok egy bizonyos hibat¶résen kívül esnek, a leszállás legyen megszakítható. Jobbik esetben a drónt el kell küldeni távolabbra, majd újrapróbálkozni az elejét®l. Ilyen az, amikor a mozgó platform megd®l esetleg, és emiatt a folyamat nem biztonságos. Rosszabbik esetben a géppel történik valami szerencsétlenség, így lezuhan. Ilyen rendszert egy szabályozási hurokkal tudunk létrehozni. Ez egy olyan ciklus aminek legmeghatározóbb lépései a képek feldolgozása, markerek felismerése, koordináták kinyerése, pálya megtervezése, majd a drón vezérlése, majd az egész újrakezdése. A 4.3 ábrán látható egy ilyen hurok m¶ködése.
4.3. ábra. Szabályozási hurok m¶ködése (Szerz® saját képe)
Miután az említett problémák megoldásával egy meghatározott távolságon belülre kerül a drón, akkor jöhet az utolsó fázis, ahol egy mechanikus rendszer képes a gépet valamilyen módon megfogni.
4.3. A probléma pontos megfogalmazása A szakdolgozat témáját az el®z®ekben felsoroltak közül a második fázis teszi ki. Ennek a fázisnak is a relatív helyzet meghatározása fontos számomra, és nem a vezérlés, a bevezetésben említett okok miatt. Kis költségvetéssel szeretnék hatékony rendszert létrehozni. A korábban említett módszerek közül ki kell zárnom teljesen a rádiós megoldásokat. Ezek hatékonyak és pro k, de frekvencia engedély kellene hozzájuk, publikust használva pedig könnyen zavarhatóak. Továbbá komoly infrastruktúra kiépítését és eszközöket igényelnek, amely szintén kizáró ok. Ellenben az optikai rendszerekhez nem kell más, mint egy feldolgozó számítógép, egy képi szenzor, a markerek kialakítása, és esetleg egy optikai áramlás érzékel®. Az eddigi hasonló megoldásokban passzív markereket használtak a fejleszt®k. Ezek széls®séges fényviszonyok és id®járási tényez®k mellett könnyen válhatnak felismerhetetlenné. Az én esetemben infravörös LED-ek (fényt kibocsátó dióda) alkotják majd ezeket, amelyeknek célom a megbízhatósági szintjét tesztelni. Mivel kültéren a Nap infra sugárzása zavaró jelnek számít, így kés®bbiekben megoldás lehet, hogy ezeket a fényforrásokat egy
23
4.3. A probléma pontos megfogalmazása
kódmodulált rendszer villogtatja olyan módon, amit a hardver képes érzékelni. Egyik akadály pontosan ebb®l adódik, hogy mi az a sebesség, amit a rendszer képfeldolgozása még kezelni tud. A LED-ek száma és kihelyezése egy el®re meghatározott alakban történik, amit az UAV-nak ismernie kell. Viszont így felmerül a kérdés, hogy mi az optimális módja az alakzat megválasztásának, ahol minél nagyobb hibat¶rése van egyegy marker kiesése esetén is a rendszernek. Ez lehet akár becsillanás, vagy adódhat id®járási viszonyokból is. Az eddigi megoldásokból kiindulva két nagy kategóriát lehet megkülönböztetni az ilyen rendszerekb®l. Az egyik, amikor valamilyen csatornán az UAV leküldi a mért adatokat, és egy földi számoló egység végzi a bonyolult feldolgozásokat. A másik, amikor az eszközre helyezett egykártyás számítógép teszi azt, és nincs kommunikációs csatorna földi egységekkel. A piacon már kezdenek elterjedni hatékony bankkártya méret¶ gépek, ami még újdonságnak számít. Az els® esetben hibaforrás lehet, hogy az adatok elvesznek, az újraküldés id®t vesz igénybe, zavarhatóak a jelek. Ezekb®l adódóan nem képes az azonnali reakcióra a drón, ami ennél a kritikus m¶veletnél fontos szempont. Amennyiben lehetséges, a második lehet®séggel szeretnék élni, így azok közül kell megtalálnom az optimálisat. Mivel a képfeldolgozási algoritmusok er®forrás igényesek, így a számolás id®igénye is egy probléma forrása lehet. Ezért másik kérdés, hogy milyen kóddal és nyelven érhet® el a kívánt hatékonyság. Az érzékel®k kiválasztása is egy fontos lépés. Ez lehet például olyan infra sz¶r® lencsével ellátott kamera, ami csak az infravörös hullámokat engedi át. Továbbiakban az infra sz¶r® kifejezés alatt ezt a típust értem. Léteznek más ilyen eszközök is, ilyen a Pixart Sensor, amit például a Nintendo Wii is használ. Ez egy optimalizált, gyors hardver/szoftver páros, de alacsony felbontáson m¶ködik, ami miatt csak kis hatótávolságon belül használható. Az eszközhöz közeli kézmozdulatokra és gesztusokra van kiélezve. Vannak még hasonló eszközök, de a dolgozat a kamera képeken alapul, így azokkal nem foglalkozom. A bemen® képi adatok pedig további kérdéseket vetnek fel, hogy milyen képfeldolgozó könyvtárak állnak rendelkezésre a feldolgozáshoz ingyenes felhasználással jelenleg. Mi az, ami a leghatékonyabb, és alacsony er®forrást igényel. Amennyiben a fedélzeti számítógép kapacitása képes kezelni az el®z®leg említett problémákat hatékonyan, további fejlesztés lehet egy optikai áramlás szenzor beépítésével a leszállás segítése. Ez megint felveti a kérdést, hogy az adott költségvetési korlátok között létezik-e olyan mini számítógép, ami képes kezelni ezeket az algoritmusokat hatékony sebességgel. Az el®z®leg említett problémák közül a markerek kihelyezését, algoritmusok hatékonyságát csak egy módon tudom felmérni, és az a tesztelés. Mivel egy drón beüzemelése körülményes lenne ilyen célokra, így a virtuális megoldásoknál kell maradnom. A képfeldolgozó egység egy külön modulban kerül megírásra. Ennek legf®bb bemen® információja maga a kép. Nagy el®nye, hogy valamilyen szimulációs környezetet rá tudok kapcsolni az algoritmusaimra anélkül, hogy bármi módosítást végeznék azokon.
24
5. fejezet A rendszer implementálása
5.1. ábra. A feldolgozás részei (Szerz® saját képe)
5.1. Képfeldolgozó egység Talán a dolgozat egyik legfontosabb része, hogy megtaláljam a leghatékonyabb képfeldolgozó könyvtárat. Itt a f®bb szempontok egyike, hogy kereszt-platform (több operációs rendszeren is futtatható) és lightweight (gyors és egyszer¶) legyen, széles dokumentációval és nagy függvénykészlettel.
Accord.NET
(http://accord-framework.net/)
Az AForge.NET könyvtár kib®vítéséb®l jött létre. Kép és hangfeldolgozó keretrendszer, rengeteg beépített függvénnyel. Alkalmas gépi tanulásra, genetikus algoritmusok létrehozására, és a fuzzy logikát is ismeri. Elterjedt eszköz az úgynevezett LEGO Mindstorm robotok programozói körében. Ezek speciális épít®elemekb®l készült robotok, amiknek
25
5.2. Képfeldolgozás folyamata
a vezérléséért felel®s szoftvereket ennek segítségével írják. Ahogyan a nevéb®l is látszik, ez a .NET keretrendszerhez kapcsolódik, ami gyors és hatékony programfejlesztést biztosít Windows rendszereken, illetve átjárást az operációs rendszer verziói között. A képfeldolgozó könyvtár programozási nyelve C# és található benne már Mono támogatás. Ez egy olyan platform, ami Linuxos környezetben is megvalósítja a .NET függ®ségeket és C#-ban íródott programok fordítására is képes. Viszont a Mono még ha minimális teljesítményromlást is okoz Windowshoz képest, az a pár képkocka is dönt® fontosságú lehet. Ezen felül a C/C++ nyelveken jobban megvalósítható a keresztplatform támogatás is, így ezt a lehet®séget elvetettem.
VXL
(http://vxl.sourceforge.net/)
Egykor hatékony képfeldolgozó könyvtár gy¶jtemény volt C++ nyelvhez. Elismert szakmabeliek fejlesztették és használták, nagyon hatékony, széles platformtámogatással rendelkezik, viszont gyenge és hiányos a dokumentációja, ma már nem fejlesztik, így háttérbe szorult a vetélytársaival szemben, elavult.
OpenCV
(http://opencv.org/)
Ha képfeldolgozásról esik szó, ma a legtöbb embernek az OpenCV jut eszébe el®ször. Hosszú évek folyamatos fejlesztésének eredménye hogy, magasan kiemelkedik társai közül. Kereszt-platformú, majdnem minden közismert nyelven implementálták már, vagy készítettek úgynevezett interfészt hozzá, amin keresztül az adott nyelv el tudja érni a könyvtár metódusait. Kimagasló dokumentáció, sok beépített függvény, hatékony algoritmusok, valós idej¶ feldolgozás, elterjedtségéb®l adódóan széles támogatottság fórumokon. Nyílt forrású és felhasználása ingyenes, els®sorban a valós idej¶ képfeldolgozáshoz fejlesztették. Széles képfeldolgozással kapcsolatos területeken használják. Ilyen például az arc és gesztus felismerés, mobil robotika, kép szegmentáció, mozgáskövetés, kiterjesztett valóság, stb. Minden megtalálható benne, amire szükség lehet a munkám során, így ez a választott rendszer.
5.2. Képfeldolgozás folyamata Ez az egység felel®s a valós idej¶ információ feldolgozásért. Tudjuk, hogy a markerek foltok formájában fognak látszódni a képen. Ezek megtalálására már elterjedt módszerek léteznek. Viszont ahhoz, hogy ezt elvégezhessük több el® feldolgozási lépésre van szükség.
5.2.1. Átalakítás és képek el®sz¶rése A képfeldolgozás már széles körben elterjedt folyamat. A beérkez® képek nagy valószín¶séggel RGB, azaz vörös, zöld, kék színkódolású, 24 bit mélység¶ek. Ez annyit jelent, hogy egyenként a kép összes pixelje 24 biten kerül reprezentálásra, így minden képpont 16 777 216 féle egyedi színt kaphat. Mivel a projekt esetében a színek nem
26
5.2. Képfeldolgozás folyamata
játszanak szerepet, így számítási id®t takaríthatunk meg, ha a képet szürkeárnyalatos bit-térképpé alakítjuk. Ez annyit tesz, hogy a pixelek egy 0-255 közötti számértékkel kerülnek tárolásra. A szám a fehér szín er®sségének mutatója lesz ezután, és elég 8 bit a tárolására. Ilyen átalakításra többféle számítási módszer [23] is létezik. Az egyik ilyen az, amikor a három színkomponens minimuma és maximuma összegének vesszük a felét. Továbbá létezik olyan módszer is, amikor a vörös, zöld, kék színeket átlagoljuk, esetleg súlyozzuk azokat. A mai képfeldolgozó rendszerekben már létezik ezekre optimalizált bels® függvény, így ezt nem kell megírnom. Az OpenCV egy olyan módszert alkalmaz, amely a pixelt körülvev® színek alapján egy formulával megállapítja, hogy mi a vizsgált képpont fényessége [24, 25].
5.2. ábra. Kép szürkeárnyalatossá alakítása (Szerz® saját képe) Mivel alakokat, objektumokat kell megtalálnunk a képen, ezért fontos, hogy kiemeljem a számomra fontos elemeket. Erre egyik legjobb módszer, a thresolding [26]. A kapott szürkeárnyalatos képen egy olyan átalakítást jelent ez, ahol bináris kép lesz a kimenet. Egy ilyen képnek a jellemz®je, hogy minden pixel igaz, vagy hamis értékkel bír, azaz fekete vagy fehér. A legtöbb számítógépes képfeldolgozási m¶veletnek egy ilyen kép a kiindulási követelménye. A thresolding [27] algoritmusok matematikai számításokkal képesek elérni a kívánt eredményt. A legtöbbjük el®re meghatározott küszöbértékekkel dolgozva vizsgálja a képpontokat, hogy elérnek-e egy bizonyos szintet, majd annak megfelel®en adnak eredményt. Az elterjedt feldolgozó könyvtárak erre is nyújtanak már beépített optimális megoldásokat a felhasználóknak, ahogyan az OpenCV is.
5.3. ábra. Kép bináris átalakítása (Szerz® saját képe)
27
5.3. Markerek meghatározása és felismerése
5.2.2. Blob detekció Az el®z®leg kapott bináris képen a cél, hogy megtaláljam a LED-eket. Ennek egyik lehetséges és elterjedt módja az angolul blob detection [28] (folt felismerés) nev¶ algoritmus alkalmazása. Az ilyen matematikai algoritmusok lényege, hogy a képen olyan alakzatokat keressenek, melyek színben, telítettségben, alakban elkülönülnek a környezetükt®l. Több változata létezik, például két meghatározó osztályozásuk, hogy színes képen adott szín¶ foltok keresése, vagy színt®l függetlenül, minden összefügg® alakzat megtalálása. Az én esetemben a markerek fehéren fognak látszódni a képen, így a színek vizsgálata elhagyható. A megtalált alakzatok közül ezután megvizsgálom, hogy melyek azok, amikkel továbbiakban dolgozhatok, és mi az, amit el kell vetni. Az OpenCV blobkeres® függvénye több paraméter megadásával is segít sz¶kíteni a találatokat. Ilyenek a szín, méret, alak, konvexitás és egyéb tulajdonságok. A keresést elvégezve egy tömböt ad vissza a blobok középpontjával és azok méretével. Ezeken a pontokon kell a kés®bbiekben megtalálni és felismerni az el®re meghatározott alakzatokat.
5.4. ábra. Foltok megtalálása és bekeretezése (Szerz® saját képe)
5.3. Markerek meghatározása és felismerése Az els® legfontosabb lépés, hogy a jelz®rendszer legyen meghatározva, és aztán minden további lépést csak erre lehet alapozni. A cél, hogy a leszálló platform felületéhez képest meg tudjam határozni a drón helyzetét. Mivel egy síkot legalább 3 pont határoz meg, így minimum ennyi jelzésre van szükségem. A markerek által meghatározott alakzat koordináta rendszere egy (Xp,Yp, Zp) hármas, az UAV-ét pedig szintén hasonlóképpen lehet felírni (Xd, Yd, Zd). Ezt a rendszer meghatározást mutatja az 5.5 ábra is. A platform rendszerében kell kés®bbiekben meghatároznom a drón koordináta rendszerének középpontját. Viszont egy robosztus rendszer létrehozásához gyelembe kell vennem, hogy kieshetnek pontok, ezért szükség van redundancia létrehozására. Ez azt jelenti, hogy a szükségesnél több információt tartalmazzon a kialakítás, amihez 4, vagy attól több pont szükséges. Ezek kihelyezése történhet sokféle módon, de olyanra van szükség, amib®l egyértelm¶en visszaszámolható a kamera relatív helyzete az alakzathoz képest, illetve minél kisebb er®forrást vesz igénybe a számolása. Egy robosztus algoritmusnak fel kell tudnia
28
5.3. Markerek meghatározása és felismerése
5.5. ábra. A platform és a drón koordinátarendszere (Szerz® saját képe)
ismerni az alakzatot valószer¶ szögtartományokon belül, nagy ponthalmazok között is. Erre minden el®zetes információ ismerete nélkül csak akkor van lehet®ség, ha az összes lehetséges megoldást kipróbálja. Így egy olyan sajátos alakzatra van szükségem, amir®l biztonságosan megállapítható, hogy az megfelel®, vagy sem.
5.3.1. Alakzat kiválasztása Végtelen változat létezik. A rálátás szögét®l függ®en a kétdimenziós leképezésük torzulhat. Ezt az okozza, hogy a kamera síkja és az alakzat síkja nem párhuzamos, így az alakzat vetülete úgynevezett perspektivikus torzulást szenved. A teljesen szabálytalan alakzatok legnagyobb hibája, hogy az élek és szögek elváltozásával nehezen és kis tartományban ellen®rizhet® algoritmusokkal, hogy helyes alakzatot találtam-e meg egy ponthalmazban. Redundanciák létrehozásával tudjuk ezt kiküszöbölni. Ilyen lehet például a hasonló szögek, hasonló oldalhosszúságok alkalmazása egy alakzaton belül. A fejlesztés során szeretnék minél kevesebb csúcsot alkalmazni, így négy ponttal dolgozok a következ®ekben a számítási igények csökkentése végett.
29
5.3. Markerek meghatározása és felismerése
Szabályos négyzet, téglalap, rombusz Ezek az alakzatok könnyen felismerhet®ek, sok az ismétl®d® oldalhosszúság és szögméret. Viszont a legnagyobb gond velük, hogy nem tudjuk meghatározni milyen irányból lát rá a rendszer. Képzeljünk el egy szabályos négyzetet, amit felülr®l nézünk. Nem tudnánk megmondani, hogy melyik az eleje és vége, ha nem vagyunk ismeretében az irányoknak. Így a relatív helyzet meghatározására sincs lehet®ség. A rombusz és téglalappal ugyanez a probléma. Ezeknél több információval rendelkez® alakzatokra van szükségem.
Egyenl® szárú trapéz Ez egy speciális négyszög. Sok olyan információt tartalmaz, amelyet algoritmusok tudnak kezelni. Van két egyenl® hosszúságú szára, két párhuzamos oldala, amelyek közül az egyik biztosan rövidebb a másiknál, két egyenl® hegyes és tompa szöge. Ezeket a tulajdonságokat csak széls®séges torzulások esetén veszíti el, de olyanba megfelel® m¶ködés közben nem kerülhet a drón. Kérdés, hogy trapézon belül mi az az optimális kialakítás, ami a legnagyobb szögtartományban használható. Ez az alakzat megfelel®nek bizonyult a fejlesztéshez.
5.3.2. Trapéz felismerése, az algoritmus m¶ködése A célom egy ponthalmazban megtalálni a nekem megfelel® arányokkal rendelkez® alakzatot. Az ismert információ a megtalált blobok középpontja a képen, a várt eredmény egy ismert trapéz arányaival megegyez® ponthalmaz megtalálása, a csúcsok és az élek felismerése, majd egy régió meghatározása, amelyben megtaláltam. Amennyiben még nincs régióm, a teljes képen kell keresnünk, ellenben elég a régión belül. Ez egy gyorsítási lehet®ség, amely segítségével, nagy valószín¶séggel a következ® képkockán meg tudom határozni, hogy hol találom meg a markereket. Abban az esetben, ha nem találom benne, visszaesik az algoritmus a teljes képre. A csúcsok megtalálására a pontok összes ismétlés nélküli kombinációját vizsgálva van lehet®ség. Nincs el®zetes információm, nem tudom, hogy mekkora blobok és egymástól milyen távol lév® blobok engedélyezettek, nem tudok kizárni semmit, így ez elkerülhetetlen. A vizsgálat els® lépéseként megpróbálok egy konvex alakzatot felrajzolni a pontok felhasználásával. Amennyiben nem sikerül, nem trapézt találtam. Erre a vizsgálatra kényelmes megoldást biztosít az OpenCV egyik beépített függvénye. Megkeresi a ponthalmazt magába foglaló legkisebb konvex alakzatot, majd visszaadja azokat a pontokat. Továbbá megadható, hogy az óramutató járásával ellentétes vagy azonos irányú körüljárást alkalmazzon. Ez az algoritmus amennyiben 4-b®l 4 ponttal tér vissza, akkor léphet a következ® vizsgálatra. A második lépésben egy segéd tömböt hozok létre, amelynek elemei olyan objektumok, amik tárolják a pontok közepének helyét, a pontokhoz tartozó bezárt szögeket, és egyéb mellékes információkat az indexekre vonatkozóan.
30
5.3. Markerek meghatározása és felismerése
5.6. ábra. Konvex alakzat meghatározása (Szerz® saját képe)
A bezárt szögek ismeretében megvizsgálom három egymást követ® szögek eltérését. Amennyiben itt nem találok 2 darab olyat, amik 10 fokos t¶résen belül megegyeznek, akkor az azt jelenti, hogy nem trapézt találtam. Erre abból lehet következtetni, hogy nem találtam meg az egymás mellett elhelyezked®, egyformának vélt hegyes vagy tompaszögeket, vagy túl nagy a torzulás mértéke. Ebben az esetben az algoritmus továbblép a következ® ponthalmaz vizsgálatára. Ellenben a következ® ellen®rz® lépés jön. A harmadik lépés el®tt a segédtömböt a pontokhoz tartozó szögek alapján növekv® sorba rendezem. Így el®re kerül a két hegyes szög, hátra a két tompa. Ezután az azonosnak vélt szögeket 10 fok t¶réssel összehasonlítom. Amennyiben nem egyeznek, azt jelenti, hogy nem szabályos trapézt találtam. Ellenkez® esetben már biztos lehetek a trapéz fogalmában, így a két párhuzamos oldal közé húzott mer®leges által meghatározható a magassága is. Negyedik lépésként, mikor már azonosítottam a trapézt, tudok a bels® szögekre nézve korlátokat felállítani. Mivel ismerem az eredeti alakzat szögeit, itt megtudom határozni, hogy adott szögeinek mekkora torzulást engedhetek meg biztonságos korlátok között. Viszont a gyakorlat azt mutatja, hogy a zavaró tényez®k, becsillanások nagyon csekély eséllyel formálnak szabályos trapézt, ezért ez elhanyagolható egyel®re. Ötödik lépésként egy POI-t (Point of Interest) hozok létre. Ez egy olyan régió, amelyben a számomra hasznos pontokat találtam, hogy a következ® vizsgálat során gyelmen kívül tudjam hagyni a nem bele es®ket, ezzel is gyorsítva a programon. Az 5.7 ábrán látható, hogy a kék négyzetben találhatóak az értékes pontok, azon kívül a program számára nem fontosak. Ezeket továbbiakban gyelmen kívül hagyja. Nagy valószín¶séggel e régióba fog esni a következ® képkockán is a marker. Amennyiben nem így történik, a teljes képet vizsgálja újra. Ezután az ismert indexek, a szögek, és a segéd tömb alapján beindexelem a pontokat úgy, hogy a kezd® szám mindig a tompa élekkel rendelkez® csúcsok közül az els®re essen, ha óramutató járásával azonos körbejárást alkalmazok. Erre azért van szükség, mert kés®bbiekben a relatív helyzet kiszámolásához tudnom kel, hogy melyik csúcs minek a megfelel®je a valóságban.
31
5.3. Markerek meghatározása és felismerése
5.7. ábra. POI meghatározása (Szerz® saját képe)
5.3.3. Trapéz optimalizálása A markerek optimalizálását két részre lehet osztani. Az egyik, amelyben meghatározásra kerül, hogy egymáshoz képest milyen viszonylatban legyenek a LED-ek. A másik egy kés®bbi probléma, ahol a felbontás és a LED-ek képének ismeretében kialakul a tényleges jelz®rendszer. Az els® problémát egy OpenGL és OpenCV-s alkalmazással készült szimulációban teszteltem. Az OpenGL egy olyan kereszt-platformos programozási interfész [29], amely segítségével két és háromdimenziós képmegjelenítés lehetséges. Széles körben használják, a legelterjedtebb nyelveken megírták már. Mivel ez egy speci káció gy¶jtemény, nem nyílt forrású, hanem az interfész speci kációja érhet® el ingyenesen. Az általa készült programok a videokártyát használják számolásra. Ez azért lehetséges, mert a processzorral ellentétben, ami nagy számításokra képes, itt sok gyengébb mag található, amikkel párhuzamosan lehetséges kis m¶veletek elvégzése. Az OpenGL által generálok fehér gömb alakzatokat a háromdimenziós térben. Ezek szimbolizálják a markereket, illetve kés®bbiekben a zavaró jeleket is. Transzformációk segítségével a kamera helyzetéhez képest ismert pozícióba teszem az összes pontot. Így egy olyan rendszert kapok, ahol ellen®rizni tudom a számolásokat. A generált képeket átveszi az OpenCV képfeldolgozója, majd a felismer® algoritmusom segítségével megtalálja a pontokat. További el®nye ennek a programnak, hogy egy ciklust alkalmazva állókép helyett egy irányítható környezetet alkothattam, így a markerek teljesen körbejárhatóak a billenty¶zet segítségével. Ennek nagy szerepe, hogy a számolt szögeket és helyzeteket ellen®rizhetem. Ezen felül ezekkel a mozdulatokkal képes vagyok tesztelni egy-egy alakzat megbízhatósági szintjét, amit a következ®ekben alkalmaztam is. További pontok hozzáadásával pedig látható, hogy az alakzat több felismert blobok között is megtalálható, az el®z®leg tárgyalt ellen®rzések segítségével.
32
5.3. Markerek meghatározása és felismerése
5.8. ábra. M¶ködés közben az említett technológiák (Szerz® saját képe) A képeken még látható továbbá a hasznos pontok régiója, amelyet a sárga jelöl® négyzet mutat. A módszer segítségével kipróbáltam több lehet®séget is. El®ször az ábrákon is látható verziót, amely a hegyes szögek miatt jól felismerhet®, de túl nagy alakzatot igényel. A közelébe kerül® drón látómezejéb®l hamar kiesnek a hegyes szögek végén található pontok. Ezt a jöv®ben egy olyan két részre bontott rendszer korrigálhatja, ahol adott magasság esetén a trapéz belsejében felgyulladó LED-ekkel új alakzat követésére válthatna a program. Következ® kísérlet kiindulása az el®z®nél kisebb hegyes szögekkel rendelkez® alakzat volt. A teszten jól teljesített, az elvárásoknak megfelelt.
5.9. ábra. Kísérleti alakzat és annak arányai (Szerz® saját képe)
33
5.3. Markerek meghatározása és felismerése
A két párhuzamos oldal hosszából úgy t¶nt az arány megtartásával lehet lejjebb venni. Nem fogja az eredményt befolyásolni. Így jött létre a végleges forma.
5.10. ábra. Végleges alakzat és annak arányai (Szerz® saját képe)
5.3.4. Trapéz és annak felismerésének a gyakorlati megvalósítása Ebb®l a megoldásból elkészült egy gyakorlati megvalósítás a teszteléshez.
5.11. ábra. Infra LED-ek összekötve (Szerz® saját képe) A projekthez jelenleg EL-1KL3 típusjelzés¶ diódák voltak kéznél. Ezek sz¶k sugárzási nyílásszöggel rendelkeznek, ami 16 fokot jelent. Kés®bbiekben ezek cserélhet®ek nagyobb szög¶ekre, ami valószín¶leg szélesebb szögtartományt is jelent a felismerésnél. Jelenleg az id® és költségek gyelembe vételével, ezzel készült el a rendszer. Több LEDre volt szükség egy-egy ponthoz, hiszen a magasból is jól észrevehet®nek kell lennie. Egy tranzisztoros, klasszikus áramgenerátoros rendszerbe a 4 LED csokor összekötésre
34
5.3. Markerek meghatározása és felismerése
került. A LED-ek sorba vannak kötve és minden csoporthoz tartozik egy áramgenerátor, aminek a célja, hogy állandó áramot hozzon létre számukra. Erre azért van szükség, mert a diódák fényereje az áramer®sségt®l függ, és így a tápfeszültségt®l függetlenül stabil fényt sugározhatnak.
5.12. ábra. Az áramkör kapcsolási rajza (Szerz® saját képe)
A teszteléshez egy infra sz¶r®t, laptopot és a régi telefonomat használtam. A sz¶r® 12 mm vastagságú, ami 808 nm - 1064 nm közötti tartományt ereszti át. A karakterisztikája sajnos nem található meg, de egy hozzá hasonló sz¶r® családé a 5.13 ábrán látható. Itt a vízszintes tengely jelzi a hullámhosszot, a függ®leges pedig az áteresztés mértékét százalékban. Látható, hogy a fény átengedése a látható tartomány végén, vagy utána kezd®dik.
5.13. ábra. Egy infrasz¶r® család karakterisztikája (http://www.hoyaoptics.com)
A telefont IP kamerának alkalmazva a következ® problémával szembesültem, hogy a LED-ek kialakításából adódóan egyes esetekben nem egységes alakzatot alkottak. A
35
5.3. Markerek meghatározása és felismerése
megoldás erre, hogy a blobok megtalálása után egy összemosást is kell alkalmaznom, ezzel a kis réseket eltüntetve. Erre tökéletesen használható az angolul box blur vagy lternek elnevezett elmosási technológia. Egyszer¶ implementálni, de az OpenCV tartalmazza már, ezért nem kell megírnom. Egy mátrixot alkalmaz [30], amelynek segítségével minden pixel a szomszédos képpontok átlagával lesz egyenl®. Ez pontokról pixelcsoportokra is alkalmazható. Az algoritmus pedig gyors és egyszer¶.
5.14. ábra. Elmosás el®tt és után a kép (Szerz® saját képe) A gond viszont az volt, hogy a két egymáshoz közel lév® csoport távolról becsillant és összemosódott. Ennek kiküszöbölése érdekében egy arányait megtartó, de nagyobb kialakításra volt szükség. Az újraforrasztgatás helyett megoldást a panel feldarabolása jelentette, ahol egy olyan alapot alkalmaztam, amiben szabadon mozgathatóak a csúcspontok. A lyukak 3 centiméterenként vannak elhelyezve, de újak is fúrhatóak. A panel darabokat elláttam egy-egy csavarral, amivel rögzíthet®ek. Ennek segítségével több alakzazatot és méretet is kitudtam próbálni.
5.15. ábra. A feldarabolt panel (Szerz® saját képe)
36
5.4. Kamera kalibráció
5.4. Kamera kalibráció A manapság használt kamerák el®állítása egyre olcsóbb, viszont az olcsó kameramodell negatív hatásaként van egy bizonyos torzításuk. Ez konstans mérték¶ és minden lencse esetében egyedi, de a jó hír, hogy utólag korrigálhatóak [31].
5.16. ábra. Kalibráció el®tti és utáni kép.(http://www2.tweakersoft.com) Ahogyan a 5.16 ábrán is látható, az egyenesek torzulása jelent®s is lehet. Ezért fontos lépésr®l van szó, hiszen a cél, hogy minél pontosabb reprezentációját kapja a program a valós világnak. Ezek a képek jelentik a számolások alapját. Két fajta kalibrációt lehet megkülönböztetni, amik a geometriai és színbeli torzítást jelentik, viszont ebben az esetben a színbélinek nincs jelent®sége. Az én esetemben több tényez® is szerepet játszik [31].
•
Képnek a középpontja. Ez nem biztos, hogy a kétdimenziós kép tényleges közepére esik, amíg nem történt meg a kalibrálás.
•
Fókusztávolság
•
Skálázási tényez®, ami sor és oszloponként eltér® lehet. Amennyiben ezt nem vennénk gyelembe, a képünk torzulhat.
•
Ferdeségi tényez®
•
Lencsetorzulás, ami a fenti képen is látható pszeudó nagyítás által keletkezett torzulás a képek szélein.
Az OpenCV kényelmes módot biztosít a felhasználóknak ezek kiküszöbölésére. Beépített függvények és példaprogramok segítségével két mátrixot állít el®. Az egyik ilyen a kamera mátrix, a másik a torzítási mátrix. Ennek a folyamata, hogy egy el®re ismert marker rendszer segítségével, több mintavételezés után kiszámolja a kiküszöböléshez szükséges értékeket. Erre az egyik legelterjedtebb a sakktábla módszer. A program bemen® információja lehet képsorozat, videó vagy valósidej¶ felvétel. Ezen felül fontos információ még a markerek száma, azok valós mérete és a képfelbontás is. A kalibrálás alatt fontos, hogy változatos d®lési szögeket alkalmazzak, a minél pontosabb eredményhez. Miután a program végzett, megkaptam az el®z®ekben említett két mátrixot a kép
37
5.5. Térbeli leképezés
korrigálásához és az egyéb adatokat.
5.17. ábra. Kalibráció folyamata (Szerz® saját képe) Az 5.17 ábrán látható a sakktábla módszer. A program megkeresi és azonosítja a bels® sarokpontokat. Ezek között a valóságban ismert a távolság, amit megkell adnunk bemeneti paraméterként. Ezek jelenleg 2,5 centiméter nagyságúak, ami 1 egységnek felel majd meg a számolásoknál, a kapott kalibrációs értékekkel. A térbeli leképezéseknél és pozíció számolásnál ezt gyelembe kell venni.
5.5. Térbeli leképezés A munkám legfontosabb része, hogy a markerek segítségével számítható legyen az UAV relatív helyzete a leszálló platformhoz képest. Ehhez valamilyen háromdimenziós helyzetbecslést (3D Pose estimation [32]) kell alkalmazni. Ezeknek az algoritmusoknak, az angolul úgynevezett PnP (Perspective-n-Point) matematikai probléma megoldása a kulcsa. Ennek lényege, hogy van egy kétdimenziós (U, V) képsíkunk egy ismert geometriai alakzatnak a vetületével, ez az egyik koordinátarendszerünk. Ennek az alakzatnak ismertek a paraméterei, viszont a saját háromdimenziós koordinátarendszerében van elhelyezve. A vizsgáló fél pedig azt a transzformáció együttest keresi a két koordináta rendszer között, ami meghatározza a kett® közötti kapcsolatot. Miután ezek az elmozdulási és forgási együtthatók ismertté válnak, könnyedén számolható a képsík origójának helyzete az objektum térbeli rendszerében. Egyszer¶sítve egy kamerakép alapján kell meghatározni a lencse helyzetét a vizsgált objektumhoz képest. Ismerjük az objektum saját rendszerbeli paramétereit és a vetületének adatait. A kérdésre már sok megoldás létezik napjainkban. Két f® csoportja az iteráló [33] és a nem iteráló [34] változatok. Ez egy bonyolult matematikai probléma, amely túlszárnyallja a jelenlegi tudásom, viszont az OpenCV több beépített lehet®séget is kínál a felhasználóknak a megoldásra. Ezek f® bemen® paraméterezése az objektum pontjainak térbeli koordinátáiból, a képsíkon található megfelel®ib®l és a két kamerakalibrációs mátrixból állnak. Ami fontos itt, hogy ismerni kell a képsík rendszerében, hogy egy pont melyik csúcsnak a vetülete. Megkell állapítani a képen valamilyen módszerrel minden számunkra fontos szögb®l, hogy egy adott csúcs a valóságban minek a megfelel®je. Kimen® adatként pedig a transzformációs és elforgási mátrixot adják. Ebb®l
38
5.5. Térbeli leképezés
pedig egyszer¶ mátrixm¶veletekkel számolható a relatív helyzet. A jelzés koordinátarendszerében fontos, hogy felfelé mindig a Z tengely áll, így ez mer®leges a trapézra, az X és Y tengelyek ennek megfelel®en helyezkednek el.
5.18. ábra. A két fontos koordinátarendszer a számoláshoz (Szerz® saját képe) A tesztelésre legjobb mód az el®z®leg létrehozott OpenGL-el egybekötött program, melyben ismert a kamera és a markerek pontos helyzete. A cél, hogy az ismert helyzet¶ pontok alapján meghatározzam a markerrendszer síkját, majd az origóba berajzoljam a tengelyhármast, ezzel is szemléltetve a számítások helyességét. Az 5.19 ábrán látható, hogy a pontok által meghatározásra került a trapéz, majd a tengelyek berajzolásával a trapéz síkja is.
5.19. ábra. OpenGL-es programban kiszámolt koordinátarendszer (Szerz® saját képe)
39
5.6. Szimuláció
5.6. Szimuláció A szimulációk talán egyik legnagyobb el®nye, hogy reprodukálni lehet valós helyzeteket, megállítani azokat, és kielemezni az adott pillanatban. Láthatjuk minden kockázat nélkül, hogy az algoritmusunk hogyan és miért m¶ködött úgy, ahogyan az adott körülmények között. Az interneten már megtalálható több olyan szoftver amely megadja ezt a lehet®séget a fejleszt®knek. Nekem egyik f® szempont az, hogy a program ingyenes legyen és könnyen kezelhet®, illetve legyenek adottak a lehet®ségek egy UAV modellezésére. Ilyen környezetek közül ma már sok megtalálható ingyenes használatra is akár. Mindegyiknek megvan a saját el®nye, így többet is áttekintettem, a végleges kiválasztása el®tt.
Gazebo(http://gazebosim.org) Nyílt forrású és jól dokumentált API-t kínál. Az API egy olyan alkalmazásprogramozási felület, amelyen keresztül képesek a felhasználók elérni küls® programmal egy adott szoftver egyes funkcióit és használni azokat. Nagy teljesítmény¶ zikai motort tartalmaz, van 3D-s vizuális megjelenítés, képes érzékel®k, kamerák, zajok szimulálására, ezeken felül sok hasznos dologra képes. Komplex rendszerek hozhatóak létre benne, ezért ez egy jó és elterjedt robot szimulátor, viszont nem található benne használatra kész quadrocopter, az id®m pedig sz¶kös, hogy sajátot hozzak létre.
Webots(http://cyberbotics.com) Ez a szoftver is egy elterjedt robot szimulátor. Kereszt-platformú, nagy közösség, jó dokumentáció, oktató verziós támogatás, dinamikus szimulációk, vizuális megjelenítés, el®re beépített modellek, könnyen tanulható programozási nyelv, illetve sok más támogatás. Hasonlóan a Gazebohoz, elterjedt programról van szó, viszont a számomra a legnagyobb negatívum itt is ugyanaz, hogy nem található benne gyári quadrocopter.
V-REP(http://www.coppeliarobotics.com/) Egy irodalom nyomán [35] a V-REP szoftverben megtalálható egy el®re beépített modell. A program egy valósághoz közeli környezetet biztosít a felhasználók számára. Ide tudunk elhelyezni el®re elkészített modelleket, objektumokat, érzékel®ket. Egyszer¶ Drag'n Drop (kattint és visz) módszerrel a környezetbe helyezhet® minden elem. Ezek egymással egy hierarchikus felépítést alkotnak, amely a függ®ségek megadására ad lehet®séget. Minden elhelyezett elemre lehet írni scriptet (parancsállomány). Ezek a programrészletek a játékprogramozás világában is elterjedt LUA nyelven készülnek. Továbbá a program API-ja mindenre lehet®séget nyújt, amire szükségem lehet. Socketeken (kommunikációs csatorna) keresztül képes kommunikálni küls® programokkal valós id®ben a szimuláció futásakor. Ennek segítségével képes vagyok közvetíteni a drón kamerájának képét, feldolgozni egy általam választott nyelven, majd azt kiértékelve irányítani a szimulációt. Elhelyeztem egy Vision Sensor objektumot a modell aljára, ez a valódi kamerának a megfelel®je. Ennek sokrét¶ beállítása van, többek között képes vagyok a képfelbontás megadására.
40
5.6. Szimuláció
5.20. ábra. V-REP szimuláció képe (Szerz® saját képe)
Az 5.20 ábrán látható a vizuális felületete a programnak. Bal oldalt a jelenleg használt objektumok és függ®ségeik. Jobb oldalt a szimulációs drón és alatta fehér gömbök, amik helyettesítik a markereket. A programban egy script hozzáadásával megnyitok 2 db TCP/IP portot (kapu) a kimen® és bejöv® kommunikációra. Majd az API-val csatlakozok rá. Ez több nyelven is elérhet®, hozzám a Java és C-s verziók állnak a legközelebb így azokkal foglalkoztam.
Java tapasztalatok Könny¶ kezelni vele a V-REP által nyújtott API-t. Sajnos a Java-hoz készült OpenCV implementáció, nagyon hiányos dokumentálású. Beüzemelésére egy olyan Java interfészre volt szükség (JavaCPP), ami biztosítja az összeköttetést a Java nyelv és a natív C++ nyelv¶ könyvtárak között, továbbá a funkcionalitás létrehozásához egy JavaCV névre keresztelt osztálygy¶jteményre van szükség. A programban a kliens oldal indít 2 darab szálat. Mind a kett® csatlakozik a V-REP által nyitott csatornákra. Az els®n keresztül a képi stream gyelése és feldolgozása történik. A kép szürkeskálás bittérkép formájában érkezik pixelenként. Ezek tömbbe rendezve kerülnek kiküldésre. A második szál küldi egy másik porton keresztül az irányítás paramétereit, képes a szimulációt vezérelni. A hiányos dokumentációból adódóan egyes OpenCV funckciókat nem sikerült kell® módon beüzemelni Java környezetben. Így egy olyan elképzelés született, amelyben a képi adatokat egy C++ nyelven írt egység dolgozza majd fel.
41
5.6. Szimuláció
5.21. ábra. Tervezett kommunikáció az egységek között (Szerz® saját képe)
Ez a kivitelezés nem jött létre végül, mert túl nagy er®forrás és id® pazarlásnak ítéltem meg.
C++ tapasztalatok Mivel a V-REP-hez az API C-ben is elkészült, illetve az OpenCV is ezen a nyelven íródott, így a Javaban ismertetett probléma itt kiküszöbölhet®. Az elképzelés szerint a következ® módon épül fel a kommunikáció.
5.22. ábra. Végleges kommunikáció az egységek között (Szerz® saját képe) Az 5.22 ábra tükrözi az eredeti elgondolást. A program ugyanazon az elven m¶ködik, mint amit a Java nyelvbeli testvérénél bemutattam. A markerek felismerése, térbeli leképezés m¶velete a szimulációban hozta a várt eredményt. A quadrocopter pályatervezésére is van lehet®ség, de az nem a dolgozat témája jelenleg. A konklúzió, hogy a V-REP szoftvere olyan környezetet biztosít, amiben megvalósítható az algoritmus tesztelése és egy drón vezérlése, illetve a mérések kiértékelése.
42
5.6. Szimuláció
Algoritmus kiértékelése Egy 200 mintavételes ellen®rzéssel megnéztem, hogy mekkora az eltérés az algoritmus által számolt értékek és a valósak között. Ennek a mérésnek az eredményeit az 5.23 ábra mutatja.
5.23. ábra. Z tengelybeli elmozdulás, számolt és valós értékei (Szerz® saját képe) A görbe els® felénél nem történt elmozdulás. Ezután az oldalirányú mozgatás látható, amelyet a számolt értkékek kilengése szemléltet. Ezt követ®en pedig a drón közelítése és távolítása gyelhet® meg. Látható, hogy nincs számottev® eltérés a mért és valós adatok között, az algoritmus jól teljesített. Ez a szimuláció egy zajmentes, steril környezetet biztosított számomra, amivel az algoritmusom számításait tudtam ellen®rizni.
5.24. ábra. A szimulációs környezet bemutatása (Szerz® saját képe)
43
6. fejezet A rendszer megvalósítása, kiértékelése
6.1. Számítási egység választás A piacon sok bankkártya méret¶ mini számítógép található már. Felhasználásuk sokrét¶, az oktatástól kezdve, a robotvezérlésen át, mivel kis méretük ellenére mégis egyre jobb teljesítmény¶ek. Ezek közül kell olyat választanom, amelyik viszonylag olcsó, de mégis er®s.
Arduino modellek
(https://www.arduino.cc/)
Felhasználásuk a mikrokontrollerek körében elterjedt. Programozásukhoz egy Java-ban írt fejleszt®környezetre van szükség, továbbá a hozzájuk tartozó szoftver könyvtárhoz, amelyek segítségével C vagy C++ nyelven íródnak a programok. A számítógéphez USBn keresztül csatlakoztathatóak. Létezik már olyan verzió, amely Linux rendszert futtat, de számítási teljesítményük kicsi, ezért képfeldolgozásra nem ajánlott a használatuk.
BeagleBoardok
(http://beagleboard.org/)
Akkumulátoros m¶ködésre alkalmas, nyílt forrású szoftverrel és hardverrel rendelkez® mini számítógépek. Több modell kapható, ami utoljára piacra került ezek közül az a BeagleBone Black 2013-ban. Oktatási céllal hozták létre, de felhasználása széleskör¶. ARMv7 architektúrájú processzort tartalmaznak, amelyek 600 MHz és 1GHz közötti sebességre képesek, továbbá 512 Mb DDR3-mas memóriát tartalmaznak. MicroSD-re el®re installált Debian rendszerrel kaphatóak és a méretük is megfelel® egy drónhoz (86.40 mm x 53.3 mm). Képfeldolgozásra alkalmasak, OpenCV-vel kompatibilis, de az áruk 25-30.000 Ft között mozog szállítási költséggel együtt.
6.1. ábra. BeagleBone Black(http://www.ti.com/tool/beaglebk)
44
6.1. Számítási egység választás
Raspberry PI 2
(https://www.raspberrypi.org/)
Egykártyás számítógép, felhasználása széleskör¶, a robotikában is elterjedt. 1 GB RAMot és egy 900 MHz-en futó ARMv7 architektúrájú négymagos processzort tartalmaz. Piacvezet® modell, jó teljesítmény¶. Többféle rendszer futtatható rajta, de ajánlott a saját fejlesztés¶ Raspbian-t használni, ami Debian Linux alapú, mivel ez az eszközre van optimalizálva. Továbbá kapható hozzá kialakított kamera modul, az úgynevezett RaspiCam. Ezek a kamerák gyárilag olyan infra sz¶r®vel rendelkeznek, amelyek csak a látható tartományt engedik át, azaz 390 és 750 nanométer [36] hullámhossz közötti sugárzást nagyjából. A probléma ezzel, hogy a számomra fontos tartomány ezen kívül esik éppen. Egy ilyen kamerát szétszerelni, és ezt a sz¶r®t kivenni körülményes munka lehet, de szerencsére gyártanak sz¶r® nélküli verziót is bel®le. Ez az úgynevezett Pi NoIR kamera [37], amely az általam használt sz¶r®vel kombinálva megfelel® eredményt ad. Ezen felül sok internetes segédlet áll rendelkezésre a beállításukhoz, és aki elakadna, könnyen találhat segítséget, mert nagy közösségeket foglalkoztat a téma. A számítógép programozása több nyelven is történhet, de mivel a C/C++ nyelveket támogatja, így az OpenCV is gond nélkül fut rajta. Ára meg zethet®, ami a 15.000 Ft környékét jelenti ezzel a BeagleBoard-ot megel®zve.
6.2. ábra. Raspberry Pi 2 és a kamera modul (Szerz® saját képe) Minden szempontból megfelel®nek t¶nik, így a projektben is ezt az eszközt fogom használni.
6.1.1. Az algoritmus futtatása és kiértékelése az eszközön Beszereztem az eszközt és a hozzá tartozó kamerát, illetve egy tokot. Sikeresen telepítettem a Raspbian operációs rendszert rá, illetve kon guráltam a megfelel® futáshoz szükséges dolgokat, telepítve lett az OpenCV is. Rögzítésre került az infra sz¶r® is a kamera elé.
45
6.1. Számítási egység választás
6.3. ábra. Raspberry Pi 2 és a kamera modul dobozban (Szerz® saját képe)
Ez a kamera képes full HD videó készítésére 30 képkocka/másodperc-es sebességgel, a dokumentáció szerint. Továbbá érdemes megjegyezni, hogy az eszköz támogatja a távoli asztalelérést, így egy laptoppal könnyedén LAN-ba köthet® egy Ethernet kábellel és vezérelhet® gra kus felületen. Természetesen a kamerát kalibrálni kellett, ami 320x240 és 640x480-as felbontásokra történt meg. A kalibrációs programom valós idej¶ felvétel mellett képes képsorozatok és videó alapján is számolni. Ezt kihasználva egy videót készítettem a sakktábla mintáról, majd annak segítségével az asztali számítógépen végeztem el a kalibrációt. Ezután jöhetett a program tesztelése éles környezetben.
6.4. ábra. Trapéz felismerés, számolások (Szerz® saját képe)
46
6.1. Számítási egység választás
Ahogyan a 6.4 ábrán látható, a blob detekció, trapéz felismerés és térbeli leképezés is megfelel®en m¶ködött. Ezen felül láthatóak még a számolt értékek is a képen. X, Y, Z mutatja a kamera helyzetét a jelzéshez képest. Az rX, rY, rZ pedig az egyes tengelyeken való elforgást mutatják szögben. Az értékek követésére egy 150 mintavételes ellen®rzéssel megnéztem, hogyan reagál a rendszer valós körülmények között. A következ® diagramon látható egy közelítéstávolítás eredménye, szabad kézzel való mozgatás közben. A marker koordinátarendszerében továbbra is a Z tengely, ami a 4 pont által meghatározott síkra mer®leges, így ez jelenti a távolságot.
6.5. ábra. Elmozdulási mérések eredménye (Szerz® saját képe) Az el®z® kísérletben a közelítés és távolítás mellett nem történt jelent®s elforgás a Z tengelyen. A kamera síkjának elforgását a 6.6 ábra szemlélteti. A szabad kézzel való mozgatásnál törekedtem rá, hogy ne legyen nagy az elforgás. Látható javarészt 4 fokos eltérésen belül mozognak a számolt értékek, ami azt jelenti, hogy leszállás közben is ilyen pontossággal képes számolni a program.
47
6.1. Számítási egység választás
6.6. ábra. Elforgási mérések eredménye (Szerz® saját képe)
Azonban a sebesség nem volt meggy®z®. Els®nek a 640x480-as felbontás mellett döntöttem, ami 5-7 képkocka/másodperces feldolgozást eredményezett. Így következett a kisebb felbontás, ami a 320x240-et jelentette. Ebben az esetben megduplázódott a sebesség, ami 10-15 képkocka/másodpercet jelent. Ezt nagyban befolyásolja az, hogy mennyi zavaró jel található a képen. Az algoritmus kiértékelése végett lemértem az egyes szakaszok futási idejét. Ezt egy 100 mintavételes ellen®rzéssel tettem, majd átlagoltam az értékeket.
6.7. ábra. Egy képkoca feldolgozásának, id®beli eloszlása (Szerz® saját képe)
48
6.2. Jöv®beli fejlesztési lehet®ségek
Ezzel a felbontással és a jelenlegi algoritmus beállításokkal, átlagosan 18cm és 180cm között képes megbízhatóan m¶ködni a felismerés. A határérték alá menve a markerek kiesnek a képb®l, túlmenve rajta pedig az elmosás következtében a LED-ek összefolyhatnak. A mostani beállításokkal átlagosan 30 fokos d®lésen belül képes biztonságosan a trapéz felismerésére az eszköz. Ezt a korlátot azzal módosíthatjuk, hogy a trapéz ellen®rzésénél a megegyez® szögek összehasonlításában nagyobb t¶rést engedünk meg. Így az algoritmus nagyobb torzulások esetén is felismeri a trapézt, viszont becsillanások és zavaró jelek esetén könnyebben találhat hamis alakzatot a ponthalmazban. Ebb®l következik, hogy egy ellen®rzött környezetben, beltérben érdemes csak a korlátot b®víteni, szabadban a Nap sütötte területen nem. A kísérlet alatt többféle er®s fényforrással megvilágított markerek nem befolyásolták egyáltalán a program m¶ködését. Szabadtéren a nap által generált becsillanások sem voltak számottev®ek a m¶ködést illet®en. Viszont, ha egy er®s fényforrás a kamerára szegez®dik, akkor elvakíthatja azt, és a jelenlegi sz¶r® nem képes megakadályozni. Összegezve a rendszer m¶ködési paraméterei a következ®ek:
Felbontás: 320x240 Képkocka/másodperc: 10-15 Egy képkocka átlagos feldolgozási ideje: 74 milliszekundum Megbízható távolság tartomány: 18cm - 180cm Megbízható szögtartomány: 30◦ -os d®lés A szimulációnál is szemléltetett, számolt és valós értékek eltérésének ellen®rzésére, zajszint mérésre jelenleg nincs eszközöm és nem találtam megbízható, kölcséghatékony módszert rá. Mér®szalagos vizsgálatokból látható volt, hogy centiméteres pontosságon belül képes üzemelni, de ezt bizonyítani jelenleg nem tudom.
6.2. Jöv®beli fejlesztési lehet®ségek Az egyik legfontosabb fejlesztés lehet®ség, a számítások gyorsítása. Ez történhet er®sebb egykártyás számítógéppel, vagy több párhuzamosításával. Már most is kapható a piacon olyan, amely megfelel® lenne, viszont erre jelenleg nincs elegend® költségkeret. Ezek ára viszont folyamatosan csökken a technológia fejl®désével, ezzel elérhet®bbé válva a hobbi fejleszt®knek is. A számítások gyorsulásával nagyobb felbontás érhet® el, így a biztonságos m¶ködés tartománya is többszöröz®dhet. Ezt továbbá még azzal lehetne javítani, hogy a trapézhoz egy bizonyos távolságba kerülés esetén a rendszer átvált egy új jelzésre. Ez lehet például a trapézon belül bekapcsolandó újabb LED-ek, amik új alakzatot formálnak. Ennek kivitelezéséhez viszont a drónnak és a jelz®rendszernek kapcsolatban kell állnia, hogy tudjanak kommunikálni a váltásról. A LED-ek kódmodulált villogtatására ilyen teljesítmény mellett nem volt lehet®ség, de kés®bbiekben megvalósíthatóvá válhat. Segítségükkel a csúcsok egyértelm¶en azonosíthatóak lesznek, kevesebb ellen®rzést kell végeznie a programnak, több pontot is lehetne
49
6.2. Jöv®beli fejlesztési lehet®ségek
alkalmazni. Nagyobb teljesítménnyel az algoritmus is gyorsulna, így további lehet®ségek nyílnak a megbízhatóság növelésére. Ilyen például egy el®z®ekben is említett optikai áramlás érzékelésének implementálása. Ezzel egy ismert pozícióból és az elmozdulás mértékéb®l számolható lenne a következ® pozíció, amivel az adatok helyessége ellen®rizhet®bbé válna. Erre a célra létezik külön szenzor is, de jelenleg nem állt rendelkezésemre bel®le. Továbbá er®sebb számítási egységgel implementálható lenne egy olyan algoritmus is, amely a mérések segítségével, statisztikai számításokkal képes megbecsülni az UAV helyzetét. Az egyik erre a célra készült módszer, a Kálmán-sz¶r® [38]. Ez tovább er®síthetné az el®z®ekben leírt áramlás érzékel®t. A jelenlegi marker rendszer tapasztalati alapokon került meghatározásra. Erre készülhetne a jöv®ben egy genetikus algoritmus, amely meghatározná az optimálisat. Ellen®rizhetné akár a több pont használatát és más alakzatokat is. Ez egy olyan optimumkeresési technológia [39], amely a biológiai evolúció m¶ködését veszi alapul. Kezdetben egyedeket hozunk létre, amelyek a trapéz paramétereit tartalmazzák. Az egyedek szaporodnak, a jó tulajdonságokat örökítik, újakat kapnak, mutálódnak. Ezeknek egy kiértékel® függvény meghatározza az úgynevezett tnesz értékét, ami a végs® célra való rátermettséget jelenti. Egy ilyen függvény jelentheti a legnagyobb tartományban való felismerhet®séget, zavaró blobok t¶rését, stb. Az algoritmusok általában addig nem állnak le, míg nem teljesül egy arra vonatkozó feltétel, amit a programozó határoz meg.
50
7. fejezet Összefoglalás
Sikerült megismernem és ismertetnem a terület jelenlegi megvalósításait, illetve a kapcsolódó technológiákat, amiket már használnak is. Betekintést nyertem a jelenleg m¶köd®, leszállást segít® rendszerek m¶ködésébe. Tanulmányoztam a pilóta nélküli légi járm¶veket, azok m¶ködését, a fontos lehet®ségeket, amit kínálnak a hétköznapokban is. A tanulság, hogy ezek automatizálására már alacsony költségvetéssel is történhetnek jelent®s fejlesztések. Olyan jelöl®rendszer megkeresése volt a cél, amivel még nem történtek próbálkozások és egyes helyzetekben el®nyösebb a társainál. Ezt megtaláltam és felderítettem a felismerésével foglalkozó ágazatot, ami a digitális képfeldolgozás. Ehhez sikeresen kiválasztottam azt a könyvtár gy¶jteményt, amivel az én feladatom megvalósítható. Egy ilyen jelleg¶ program futásához megtaláltam azt az eszközt, és a hozzá tartozó kamerát, sz¶r®t, amelyet a drón is elbír és fejlesztés céljából tökéletesen m¶ködik. Továbbá sikerült megírni a kit¶zött célra egy minimális er®forrású kereszt-platformú szoftvert is. A gyakorlati megvalósítással szemben viszont vannak kétségeim a számítási egység gyorsasága miatt. Több szimulációs környezetet is átnéztem, készítettem sajátot is. Lehet®séget nyújtottak egy optimális alakzat megtalálására és az algoritmusaim tesztelésére anélkül, hogy egy valódi drónt kellett volna beüzemelnem. Ezekkel a virtuális környzetekkel elkerültem az esetlegesen keletkez® károkat, és lehet®séget biztosítottam egy jöv®beli vezérléssel egybekötött teszteléshez.
7.1. Elkészített programok V-REP scriptelése és a hozzátartozó Java API összehangolása Egy olyan Java nyelv¶ alkalmazás, amely a V-REP által nyújtott API segítségével képes fogadni valós id®ben a szimuláció közben generált képet. A képeket feldolgozza, blobokat megtalálja, de számolni nem képes jelenleg. Ezek mellett képes beavatkozni a vezérlésbe és rendelkezik minimális gra kus felületettel.
V-REP scriptelése és a hozzátartozó C API összehangolása Egy olyan C++ nyelv¶ alkalmazás, amely hasonlít a Java-s változathoz, de közelebb áll
51
7.1. Elkészített programok
az OpenCV nyelvezetéhez, ami a képfeldolgozás legfontosabb függvényeit tartalmazza. Ez már képes pozíciót számolni, de a vezérléshez szükséges szál nem került megírásra.
OpenGL és OpenCV alapú alakzat szimulátor Egy olyan C++ nyelv¶ alkalmazás, aminek segítségével tesztelhet® mindenféle alakzat és az ®ket felismer® algoritmus határai, pontossága, hibat¶rése. Háromdimenziós térben forgatható a generált kép.
Képfeldolgozó rendszer Egy olyan C++ nyelv¶ alkalmazás, ami a Raspberry Pi-hez készült. Megkapja a kamera által látott képeket és valós id®ben feldolgozza, kiértékeli azokat.
52
Ábrák jegyzéke
2.1.
Az UAV-ok költségvetésének el®rejelzése a világban [3] (Szerz® fordítása)
2.2.
Az UAV-ok osztályozása (http://uav-society.blogspot.hu, szerz® fordítása) 10
2.3.
Egy földi pilótafülke (http://www.wired.com)
2.4.
Egy X525-ös quadrocopter (www.aliexpress.com)
2.5.
Az irányítás módja (http://wikipedia.org)
2.6.
A gép tervezett kinézete (http://www.cygnusuav.hu)
. . . . . . . . . .
13
3.1.
Egy ILS rendszer kialakítása (http://instrument.landingsystem.com/) .
15
3.2.
Egy mobil optikai leszállást segít® rendszer (http://wikipedia.org/)
15
3.3.
A hálós elkapás megörökítése (http://olive-drab.com) . . . . . . . . . .
16
3.4.
A leszállás megörökítése (www.dailytech.com)
18
3.5.
A leszállás megörökítése (http://www.ruag.com) . . . . . . . . . . . . .
19
3.6.
Passzív markerek felismerése (http://rd.csp.it/archives/1142) . . . . . .
19
3.7.
Két képkocka között számolt vektorok (http://cbia. .muni.cz)
. . . . .
20
4.1.
A leszállás fázisai (Szerz® saját képe) . . . . . . . . . . . . . . . . . . .
21
4.2.
Egy dierenciál GPS m¶ködése (Szerz® saját képe)
. . . . . . . . . . .
22
4.3.
Szabályozási hurok m¶ködése (Szerz® saját képe)
. . . . . . . . . . . .
23
5.1.
A feldolgozás részei (Szerz® saját képe) . . . . . . . . . . . . . . . . . .
25
5.2.
Kép szürkeárnyalatossá alakítása (Szerz® saját képe)
27
5.3.
Kép bináris átalakítása (Szerz® saját képe) . . . . . . . . . . . . . . . .
27
5.4.
Foltok megtalálása és bekeretezése (Szerz® saját képe) . . . . . . . . . .
28
5.5.
A platform és a drón koordinátarendszere (Szerz® saját képe) . . . . . .
29
5.6.
Konvex alakzat meghatározása (Szerz® saját képe) . . . . . . . . . . . .
31
5.7.
POI meghatározása (Szerz® saját képe) . . . . . . . . . . . . . . . . . .
32
5.8.
M¶ködés közben az említett technológiák (Szerz® saját képe) . . . . . .
33
5.9.
Kísérleti alakzat és annak arányai (Szerz® saját képe) . . . . . . . . . .
33
5.10. Végleges alakzat és annak arányai (Szerz® saját képe) . . . . . . . . . .
34
5.11. Infra LED-ek összekötve (Szerz® saját képe)
34
. . . . . . . . . . . . . .
9 11
. . . . . . . . . . . .
12
. . . . . . . . . . . . . . . .
13
. .
. . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . . . . . .
5.12. Az áramkör kapcsolási rajza (Szerz® saját képe)
. . . . . . . . . . . . .
5.13. Egy infrasz¶r® család karakterisztikája (http://www.hoyaoptics.com)
35
.
35
. . . . . . . . . . . . .
36
5.15. A feldarabolt panel (Szerz® saját képe) . . . . . . . . . . . . . . . . . .
36
5.14. Elmosás el®tt és után a kép (Szerz® saját képe)
5.16. Kalibráció el®tti és utáni kép.(http://www2.tweakersoft.com) . . . . . .
37
5.17. Kalibráció folyamata (Szerz® saját képe)
. . . . . . . . . . . . . . . . .
38
5.18. A két fontos koordinátarendszer a számoláshoz (Szerz® saját képe) . . .
39
5.19. OpenGL-es programban kiszámolt koordinátarendszer (Szerz® saját képe) 39 5.20. V-REP szimuláció képe (Szerz® saját képe) . . . . . . . . . . . . . . . .
41
53
5.21. Tervezett kommunikáció az egységek között (Szerz® saját képe)
. . . .
42
5.22. Végleges kommunikáció az egységek között (Szerz® saját képe) . . . . .
42
5.23. Z tengelybeli elmozdulás, számolt és valós értékei (Szerz® saját képe)
.
43
5.24. A szimulációs környezet bemutatása (Szerz® saját képe) . . . . . . . . .
43
6.1.
BeagleBone Black(http://www.ti.com/tool/beaglebk) . . . . . . . . . .
44
6.2.
Raspberry Pi 2 és a kamera modul (Szerz® saját képe)
. . . . . . . . .
45
6.3.
Raspberry Pi 2 és a kamera modul dobozban (Szerz® saját képe) . . . .
46
6.4.
Trapéz felismerés, számolások (Szerz® saját képe)
. . . . . . . . . . . .
46
6.5.
Elmozdulási mérések eredménye (Szerz® saját képe) . . . . . . . . . . .
47
6.6.
Elforgási mérések eredménye (Szerz® saját képe) . . . . . . . . . . . . .
48
6.7.
Egy képkoca feldolgozásának, id®beli eloszlása (Szerz® saját képe)
48
. . .
Irodalomjegyzék
[1] Wikipedia: Amazon Prime Air
http://en.wikipedia.org/wiki/Amazon_Prime_Air [2] How Delivery Drones Could Save Lives in Africa
http://gizmodo.com/how-delivery-drones-could-save-lives-in-africa-1545712551 [3] A Precision Investment Strike
http://www.investingdaily.com/17175/a-precision-investment-strike [4] UAV Auto Take-o and Landing Could Save Serious Money
http://defensetech.org/2010/11/12/ uav-auto-take-off-and-landing-could-save-serious-money/ [5] Automatic Forest Fire Monitoring and Measurement using UAV-s
http://www.upo.es/isa/lmercab/publications/papers/ ICFFR10_Merinoetal.pdf [6] What is a MultiCopter and How Does it Work
http://copter.ardupilot.com/wiki/what-is-a-multicopter-and-how-does-it-work/ [7] The First Autolanding
http://www.airspacemag.com/history-of-flight/the-first-autolanding-3818066 [8] Wikipedia: M¶szeres leszállító rendszer
http://hu.wikipedia.org/wiki/M%C5%B1szeres_lesz%C3%A1ll%C3%ADt%C3%B3_rendszer [9] Wikipedia: Optical landing system
http://en.wikipedia.org/wiki/Optical_landing_system [10] Recovery Parachute Systems
http://www.atair.com/parachutes/recovery/ [11] Ship-based UAV Recovery System (SURS)
https://www.navalengineers.org/SiteCollectionDocuments/ LAR Draft Documents/Hafer.pdf [12] Sea-based Automated Launch and Recovery System (SALRS)
http://www.onr.navy.mil/~/media/Files/Funding-Announcements/ Special-Notice/2012/12-SN-0020-Amendment-0001-Industry-Brief.ashx [13] Autonomous X-47B drone successfully lands on Navy aircraft carrier for the rst time
http://www.theverge.com/2013/7/10/4511476/ autonomous-drone-first-landing-on-navy-aircraft-carrier 55
[14] Ma szállhat le el®ször repül®gép-hordozóra az X-47B
http://htka.hu/2013/07/10/ma-szallhat-le-eloszor-repulogep-hordozora-az-x-47b/ [15] OPATS - The Laser-based Automatic Landing System for UAVs
http://www.ruag.com/fileadmin/ruag/Self-Protection/PDF/ broschueren/Brochure_OPATS_UAV_web.pdf [16] Development of an optical landing aid system for light Unmanned Aerial Vehicles
http://epubl.ltu.se/1402-1617/2008/192/LTU-EX-08192-SE.pdf [17] Landing a Helicopter on a Moving Target
http://robotics.usc.edu/publications/media/uploads/pubs/527.pdf [18] Optical Flow
http://www.centeye.com/technology/optical-flow/ [19] Kató Zoltán: Optikai áramlás és követés
http://www.inf.u-szeged.hu/~kato/teaching/IpariKepfeldolgozas/08-Motion.pdf [20] Wikipedia: Dierential GPS
https://en.wikipedia.org/wiki/Differential_GPS [21] Wikipedia: Local positioning system
http://en.wikipedia.org/wiki/Local_positioning_system [22] GPS vs. LPS
http://laptop-tracking-review.toptenreviews.com/gps-vs.-lps.html [23] Three algorithms for converting color to grayscale
http://www.johndcook.com/blog/2009/08/24/ algorithms-convert-color-grayscale/ [24] Wikipedia: Luma
https://en.wikipedia.org/wiki/Luma_(video) [25] OpenCV dokumentáció: cvtColor
http://docs.opencv.org/2.4/modules/imgproc/doc/ miscellaneous_transformations.html [26] Thresholding: A Pixel-Level Image Processing Methodology Preprocessing Technique for an OCR System for the Brahmi Script
http://www.ancient-asia-journal.com/article/view/aa.06113/25 [27] Wikipedia: Thresholding (image processing)
https://en.wikipedia.org/wiki/Thresholding_(image_processing) [28] Image Analysis and Processing
http://www.ni.com/white-paper/3470/en/ [29] Wikipedia: OpenGL
https://en.wikipedia.org/wiki/OpenGL [30] Wikipedia: Box blur
https://en.wikipedia.org/wiki/Box_blur
[31] Understanding Camera Calibration
http://prateekvjoshi.com/2014/05/31/understanding-camera-calibration/ [32] Wikipedia: 3D pose estimation
https://en.wikipedia.org/wiki/3D_pose_estimation [33] Denis Oberkampf, Daniel F. DeMenthon, Larry S. Davis: Iterative Pose Estimation Using Coplanar Feature Points
http://citeseerx.ist.psu.edu/viewdoc/ download?doi=10.1.1.441.251&rep=rep1&type=pdf [34] Shiqi Li, Chi Xu, Ming Xie: A Robust O(n) Solution to the Perspective-n-Point Problem
http://xuchi.weebly.com/uploads/5/6/7/3/5673896/rpnp.pdf [35] Setting Up a Testbed for UAV Vision Based Control Using V-REP & ROS
https://orbilu.uni.lu/bitstream/10993/19132/1/ ICUAS_14_OlivaresMendez_postpublish.pdf [36] Wikipedia: Látható spektrum
https://hu.wikipedia.org/wiki/L%C3%A1that%C3%B3_spektrum [37] Pi NoIR Camera
https://www.raspberrypi.org/products/pi-noir-camera/ [38] Wikipedia: Kálmán-sz¶r®
https://hu.wikipedia.org/wiki/K%C3%A1lm%C3%A1n-sz%C5%B1r%C5%91 [39] Wikipedia: Evolutionary algorithm
https://en.wikipedia.org/wiki/Evolutionary_algorithm
Adathordozó használati útmutató
Az adathordozón található mappák, fájlok szerepe.
A
•
pdf A szakdolgozat L TEX forrását tartalmazza
•
vrep_szimulacio A V-REP-es szimuláció állományai
•
java A V-REP-es API-t kezel® Java programom forrása
•
cpp A V-REP-es API-t kezel® C++ programom forrása
•
szakdolgozat.ttt A V-REP által megnyitható szimulációs állomány
•
opengl_szimulacio Az OpenGL-es szimulációs programom forrása
•
raspberry A Raspberry PI-n használt végleges programom és annak forrása
58
