NEUMANN JÁNOS INFORMATIKAI FŐISKOLAI KAR
SZAKDOLGOZAT
BMF-NIK 2005
BODOR LÁSZLÓ NIK-O-NI-02-019
HALLGATÓI NYILATKOZAT
Alulírott szigorló hallgató kijelentem, hogy a szakdolgozat saját munkám eredménye. A felhasznált szakirodalmat és eszközöket azonosíthatóan közöltem. Egyéb jelentősebb segítséget nem vettem igénybe. Az elkészült szakdolgozatban talált eredményeket a főiskola, a feladatot kiíró intézmény saját céljaira térítés nélkül felhasználhatja.
Budapest, 2005 ..........................................
................................................. hallgató aláírása
Absztrakt A dolgozat részletesen tárgyalja a Sony AIBO négylábú robotját, és az azokkal, a RoboCup keretében történő robotfutball bajnokságokat. Ismerteti egy robotfutball szoftver lehetséges implementálási lehetőségeit, és bemutat egy, a szerző által tervezett, egyszerűsített robotfutball rendszert. Kifejti a robot mozgásáért felelős alrendszer implementálását.
Abstract This thesis presents the Sony Corporation's four legged robot, called AIBO, and the RoboCup robot soccer games. It explains the possibilities of implementing a robot soccer software, and describes the design of a primitive version of such a software. Based on the designs it details the implementation of the motion subsystem.
Tartalomjegyzék 1. BEVEZETÉS.................................................................................................................................... 1 2. CÉLOK ............................................................................................................................................ 2 3. IRODALOMKUTATÁS .................................................................................................................. 4 3.1. AZ AIBO ROBOTKUTYA ............................................................................................................. 4 3.1.1. Az AIBO rövid története...................................................................................................... 4 3.1.2. Az ERS-210A ismertetése.................................................................................................... 7 3.1.2.1. Felépítés és kinézet...................................................................................................................... 7 3.1.2.2. A központi részegység................................................................................................................. 8 3.1.2.3. A feji részegység ......................................................................................................................... 9 3.1.2.4. A láb részegység ......................................................................................................................... 9 3.1.2.5. A farok részegység .................................................................................................................... 10
3.1.3. AIBO fejlesztőkörnyezetek................................................................................................ 11 3.1.3.1. RCODE SDK és az RCODEPlus ............................................................................................... 11 3.1.3.2. OPEN-R SDK........................................................................................................................... 11 3.1.3.3. Tekkotsu ................................................................................................................................... 13
3.2. ROBOCUP ................................................................................................................................ 13 3.2.1. A RoboCup és a ligák ....................................................................................................... 13 3.2.2. Sony négylábú robot liga .................................................................................................. 16 3.3. EGY ROBOTFUTBALL SZOFTVER MEGVALÓSÍTÁSI LEHETŐSÉGEI ............................................. 17 3.3.1. Bevezetés .......................................................................................................................... 17 3.3.2. Látás alternatívái.............................................................................................................. 18 3.3.3. Mozgás alternatívái........................................................................................................... 19 3.3.4. Helymeghatározás alternatívái ......................................................................................... 20 4. RENDSZERTERV......................................................................................................................... 21 4.1. MOZGÁS................................................................................................................................... 21 4.2. LÁTÁS ...................................................................................................................................... 22 4.2.1. Szegmentálás .................................................................................................................... 22 4.2.2. Összefüggő régiók képzése................................................................................................ 23 4.2.3. Régióegyesítés................................................................................................................... 24 4.2.4. Objektum felismerés ......................................................................................................... 24 4.2.5. Távolság meghatározás..................................................................................................... 25 4.3. LOKALIZÁCIÓ .......................................................................................................................... 26 4.4. KOMMUNIKÁCIÓ ...................................................................................................................... 26 4.5. VISELKEDÉS ............................................................................................................................. 26 5. MEGVALÓSÍTÁS ......................................................................................................................... 28 5.1. FELHASZNÁLT ESZKÖZÖK ........................................................................................................ 28 5.1.1. Hardver ............................................................................................................................ 28 5.1.2. Fejlesztő környezet............................................................................................................ 28 5.2. FEJLESZTÉS AZ OPEN-R SDK-VAL ......................................................................................... 29 5.3. A MOZGÁS ALRENDSZER .......................................................................................................... 31 5.3.1. A mozgások létrehozása.................................................................................................... 31 5.3.1.1. A MTN fájl formátum ............................................................................................................... 32 5.3.1.2. Skitter....................................................................................................................................... 32 5.3.1.3. A getpose segédprogram............................................................................................................ 33 5.3.1.4. A c2mtn átalakító segédprogram................................................................................................ 33 5.3.1.5. A mtntool segédprogram ........................................................................................................... 33 5.3.1.6. Létrehozott mozgások................................................................................................................ 34
5.3.2. A mozgások lejátszása....................................................................................................... 35 6. EREDMÉNYEK............................................................................................................................. 35 ÁBRAJEGYZÉK ............................................................................................................................... 36 IRODALOMJEGYZÉK .................................................................................................................... 38
1. Bevezetés “By mid-21st century, a team of fully autonomous humanoid robot soccer players shall win the soccer game, comply with the official rule of the FIFA, against the winner of the most recent World Cup.” (RoboCup Initiative, The Dream)
A mesterséges intelligencia és a számítógépek fejlődése az utóbbi néhány évben több látványos eredményt is produkált. Az egyik legkiemelkedőbb talán az, hogy 1997 májusában, az IBM Deep Blue legyőzte a sakkvilágbajnok Garry Kasparovot. Sokan gondolhatták úgy, hogy ilyesmi nem fog előfordulni, mégis az informatika fejlődése lehetővé tette ezt. Az 1993-ban bejelentett és 1997-ben először megtartott robotfutball világkupa és konferencia (Robot World Cup Soccer Games and Conferences), vagy röviden csak RoboCup, a fenti eredménynél nem kisebb célt tűzött ki: 2050-ig egy autonóm, humanoid robotokból álló csapat, győzze le a legutóbbi világbajnok futballcsapatot, a FIFA hivatalos szabályzatát betartva. A RoboCup létrehozóinak az volt a célja, hogy a kezdeményezéssel ösztönözzék a mesterséges intelligencia és robotikai kutatásokat. Továbbá, hogy egy komplex, de szabványosított problémát adjanak a kutatóknak, amely segítségével „mérhető” a kutatások előrehaladása. Bár ezen ugyancsak ambiciózus cél elérése semmilyen közvetlen hasznot nem hozna az emberiség számára, mégis mérföldkőnek számítana a mesterséges intelligencia és robotika kutatások történetében, és a probléma megoldásához kifejlesztett technikák minden bizonnyal különböző iparágakban kitűnően hasznosíthatóak lennének. A RoboCup játékokat és konferenciákat 1997 óta minden évben megtartják, igen nagy sikerrel. Csak az elsőn több mint 40 csapat és 5000 látogató vett részt. A játékokon – melyek több kategóriában, ligákban zajlanak – a különböző robotcsapatok egymás ellen játszanak mérkőzéseket. A mérkőzések eredményei alapján állítanak fel egy sorrendet a résztvevő csapatokról. Minden évben, a mérkőzések lezajlása után közzéteszik a robotokban futó szoftver forráskódját, amely szabadon felhasználható, illetve a konferencián és az Interneten megjelentetik a legújabb kutatási eredményeket. Azzal, hogy minden évben közzéteszik az eredményeket, intenzív kutatásra és fejlesztésre ösztönzik a résztvevőket, mivel így minden csapatnak, amely meg kívánja őrizni, vagy javítani helyezését folyamatosan fejlesztenie, javítania kell a szoftverén. A RoboCup egyik ligája a Sony Four Legged Robot League. Ebben a ligában a Sony által eredetileg szórakoztatási célokra kifejlesztett, AIBO nevű robotkutyákkal lehet részt venni. Ezen robotok alkalmasak arra, hogy elfogadható áron biztosítsanak egy kész hardverrel és fejlesztőkörnyezettel rendelkező platformot robotikai kutatásra és oktatásra, s emiatt a világon a különböző egyetemek mesterséges intelligencia laborjaiban igen elterjedtek. A szakdolgozat célja az AIBO robotplatformon, a RoboCup apropóján, ahhoz hasonló szabályokkal, de ahhoz nem szigorúan ragaszkodva, a robotfutball témakörének körbejárása, megismerése és néhány olyan szoftverkomponens kifejlesztése, amely a robotfutballhoz szükséges alapvető funkcionalitást biztosítja. 1
2. Célok Egy, a nemzetközi RoboCup versenyeken használt színvonalú, AIBO robotfutball szoftver kifejlesztése a robotika több kutatási ágának integrálását, igen sok időt és szerteágazó szaktudást igényel. Ezeket a szoftvereket, gyakran több évnyi tapasztalat és fejlesztés segítségével, több fős csapatok hozták létre. Emiatt egyetlen szakdolgozatnak – a szerző véleménye szerint – nem lehet célja egy teljes rendszer megalkotása. Ezért először mindenképpen egy egyszerűsített rendszer megalkotását kell célul kitűzni annak, aki robotfutballal kíván foglalkozni, és aztán a tapasztalatok birtokában lehet a szoftvert továbbfejleszteni. Ezen szakdolgozat célja, hogy egy leendő robotfutball szoftver kifejlesztését megalapozza, amit egy egyszerűsített rendszer megtervezésével, és részbeni implementálásával kíván elérni. Ezen egyszerűsített rendszer célszerű, ha egy teljes, működő egészt alkot, ugyanakkor csak a legszükségesebb funkciókat tartalmazza. Amit a rendszernek minimálisan tudnia kell, hogy még használható maradjon a következők: -
a robot képes legyen megállapítani saját és a labda pozícióját a pálya koordináta rendszerében a pályán a robot adott pozícióba tudjon menni a robot képes legyen a labdát megkeresni legyen képes a mozgó labda követésére, utolérésére kapusként tudjon viselkedni, és képes legyen a kapu fele guruló labda kivédése csatárként is tudjon viselkedni, és legyen képes gólt rúgni
A fentiek elmondhatók bármely robotfutball szoftverről, ezért ami kimaradt a felsorolásból talán még fontosabb. A magas szintű viselkedés, a stratégia, és a robotok közti kooperáció az, ami egy teljes implementáció esetén még szerepelne a listában. Ugyanakkor az is fontos szempont, hogy mennyire jól, mennyire hatékonyan valósítja meg egy rendszer a fenti funkciókat. Tehát a javasolt, egyszerűsített rendszer, egy teljes rendszertől alapvetően két fontos szempontban különbözik: a listában felsoroltakat csak minimális hatékonysággal tudja véghezvinni, és nem képes csapatjátékra, „gondolkodásra”, a játék előrelátására, stratégiák végrehajtására. Az első szempont az egyszerűsítés szükségszerű következménye. A stratégia és csapatjáték kihagyásának oka pedig, hogy azok viszonylag jól kutathatók szimuláció segítségével, ahogy ezt meg is teszik a RoboCup szimulációs ligában. A fenti listában megfogalmazott követelményeket alaposabban kifejtve, a rendszernek a következő funkciókkal kell rendelkeznie: -
a látott objektumok felismerése, a háttértől és a többi objektumtól való megkülönböztetése a látott objektumok távolságának meghatározása a labda, a kapuk és a jelzőoszlopok pozíciójának meghatározása a robothoz képest a robot pozíciójának meghatározása a pályán a robot haladási irányának meghatározása a robot képes legyen előre, hátra mozogni, fordulni, a kamerát adott irányba fordítani képest legyen egy látott objektumot követni a kamerával 2
-
rúgások végrehajtása mozgás során a robot elmozdulásának megbecslése a kamera alkalmazása nélkül (odometria) robot pózának meghatározása az izületek szöge alapján kamera irányának és pozíciójának meghatározása a robothoz rögzített koordináta rendszerben a robot és a labda pozíciójának továbbítása a PC felé
Összefoglalva tehát, a szakdolgozat a fent említett tulajdonságokkal bíró, egyszerűsített AIBO robotfutball szoftver megtervezését, és annak egy – lehetőleg minél nagyobb – részének implementálását tűzte ki célul.
3
3. Irodalomkutatás 3.1. Az AIBO robotkutya 3.1.1. Az AIBO rövid története A Sony által fejlesztett AIBO robotkutya története egészen 1992-ig nyúlik vissza. A Sony kutatói ekkor kezdtek el foglalkozni azzal az ötlettel, hogy az emberek szórakoztatására autonóm, mobil robotokat fejlesszenek ki [1]. Erre a számítógépek teljesítményének növekedése és a mesterséges intelligencia fejlődése ösztönözte őket. Különösképp az érzelmek megértése és kifejezése terén elért eredmények voltak nagy hatással rájuk.
3.1. ábra Az AIBO korai prototípusainak egyike
A tudományos közösség 1997-ben értesült a fejlesztésekről, amikor is megjelent Masahiro Fujita és Koji Kageyama, a Sony két kutatójának cikke [2] az OPEN-R architektúráról. Ebben az emberek szórakoztatására szánt, még fejlesztés alatt álló, ugyanakkor a közeljövőben piacra dobandó robotok számára egy nyílt szabványt ajánlanak. A Sony a cikk megjelenésekor már javában dolgozott egy ilyen roboton, mely segítségével a szórakoztató iparágban kívántak egy újabb piacot nyitni és meghódítani: a szórakoztatási célú robotika piacát. Nem sokkal később, 1998-ban megjelent egy újabb cikk a Sony kutatóitól, amiben egy MUTANT nevű robot, a AIBO elődjének részletes ismertetése [3] található. Ebben már világosan körvonalazódik a leendő AIBO felépítése, részegységei. A robot szoftveréről és a fejlesztő környezetről is szó esik a cikkben, azonban az ekkor megfogalmazottaknak csak egy része válik valóra a későbbiekben. Még 1998-ban a Sony egy sajtótájékoztató keretében bejelentette a nagyközönség számára az OPEN-R architektúrát és az AIBO legújabb prototípusát.
3.2.a. ábra MUTANT
3.2.b. ábra AIBO prototípus
4
A kész termék végül 1999 elején jelent meg. A Sony az AIBO nevet adta neki, amely japánul társat jelent, angolul pedig az Artificial Intelligence Robot rövidítése. Kódneve ERS-110-es volt. A korlátozott darabszámú, 3000-es készlet Japánban 20 perc alatt kelt el az Interneten, az Egyesült Államokba szánt 2000 darab pedig néhány napon belül. A hatalmas érdeklődés hatására 1999 végén a Sony megjelentette az ERS-111 kódnevű robotot, melyből 10000 darab állt rendelkezésre, immáron az európaiak számára is. Az ERS-111-es nem különbözött jelentősen az ERS-110-estől, néhány apróbb változtatást eszközöltek a robot külsejében és a továbbfejlesztették a robot szoftverét is. A ERS-110 és ERS-111 (továbbiakban: ERS-11x) főbb jellemzői a következők: 1db 64bites, 50Mhz-es RISC processzor, 16MB központi memória, 18 szabadságfokú robottest, melyből a fej 3 szabadságfokú, míg a lábak egyenként szintén 3 szabadságfokúak, a fejbe beépített színes kamera, sztereo mikrofon és hangszóró és számos egyéb szenzor a törzsben, kb. 1.5 órányi működést garantáló újratölthető akkumulátor és egy 8Mb kapacitású cserélhető memóriakártya, mely a robot programkódjának és a működéséhez szükséges adatok egy részét tartalmazza.
3.3. ábra Az ERS-110-es, az első AIBO és egyben az első kereskedelemben kapható szórakoztató célú robot
Mivel a Sony robotjai iránti érdeklődés továbbra is jócskán kitartott, ezért a Sony immáron korlátlan példányszámban kínálta a robotjait, és megkezdődött a következő generációs AIBO kifejlesztése is. Az AIBO-k második generációja 2000-ben jelent meg. Az ERS-210-es kódnevet kapta. Gyorsabb processzort és nagyobb központi memóriát kapott, mint elődje, továbbá memóriakártyájának kapacitását is bővítették. Külsejét is jelentősen megváltoztatták, és két további mozgatható izülettel bővítették. Szintén jelentős változtatás, hogy ellátták egy (opcionális) vezeték nélküli hálózati kártyával. Ennek segítségével képessé vált nagysebességű, de ugyanakkor mindenfelé helyhez kötöttség nélküli kommunikációra, bármely ugyanazon WiFi szabványt használó hálózati eszközzel. Így képes kommunikálni PC-kkel, más AIBO-kkal, vagy akár az Interneten keresztül bármely más számítógéppel. Szoftverén is jelentősen fejlesztettek. Hang és arcfelismerő programmal látták el, továbbá képessé tették rá, hogy automatikusan felismerje a töltő állomását, és csatlakozzon hozzá. A második generációs AIBO-kból több változat is készült. 2001-ben jelent meg az ERS-311-es és az ERS-312-es, melyek alapvetően más külsőt kaptak, mint az eddigi AIBO vonal. Alapvető cél, egy szerethetőbb és kedvesebb külső megalkotása, mellyel valószínűleg inkább a gyerekeket kívánták megcélozni, mint potenciális vásárlókat. Hardver tekintetében szinte teljesen megegyeznek az ERS-210-essel. Más szoftvert használnak, mint az ERS-210-es, de a szoftverük nem kínál újdonságot, sőt annál valamivel szerényebb képességekkel rendelkezik. Szintén második generációs AIBO az ERS-220-as, mely futurisztikus külsőt kapott, ugyanakkor az ERS-210-essel 5
ellentétben, nem rendelkezik mozgatható fülekkel és farokkal. Még megemlítendő az ERS-210A és az ERS-220A, mely a hasonló nevű robotok kétszer gyorsabb processzorral ellátott változatát takarják.
3.4.a. ábra ERS-210
3.4.b. ábra ERS-311 és ERS-312
3.4.c. ábra ERS-220
A Sony tovább folytatta az AIBO-k fejlesztését, és 2003-ban megjelentette a harmadik generációs ERS-7-est. Az ERS-7-es már 576Mhz-es MIPS R7000-es processzorral, 64Mbyte központi memóriával, 32Mbyteos memóriakártyával és beépített vezeték nélküli hálózati kártyával rendelkezik. Hardverén még további változtatásokat is eszközöltek, így gyorsabb és jobb minőségű szervókkal, nagyobb felbontású kamerával, fejlettebb nyomás és tapintás érzékelőkkel látták el. Minden hozzávaló szoftvert egyetlen kártyára tettek. Rendelkezik a már ERS-210-esben is meglévő összes funkcióval, így a hang és arcfelismeréssel is. Újdonságot jelent a „Visual Pattern Recognition” technológia, mely segítségével mintákat képes felismerni. Ezen technológiát használva színes mintákat tartalmazó kártyákkal is lehet a robottal kommunikálni, parancsokat adni neki.
3.5. ábra ERS-7, a legújabb generáció
6
3.1.2. Az ERS-210A ismertetése Megjegyzés: A szakdolgozat készítése során a szerző rendelkezésére állt egy darab Sony AIBO ERS210A típusú robot. A szakdolgozat ezért elsősorban erre a típusra vonatkozik.
3.1.2.1. Felépítés és kinézet Az ERS-210-es mérete 152x289x288mm. Kinézete az alábbi ábrákon látható.
3.6.a. ábra ERS-210A oldalról (műszaki rajz)
3.6.b. ábra ERS-210A szemből (műszaki rajz)
3.6.c. ábra ERS-210A felülről (műszaki rajz)
Az ERS-210-es egy moduláris felépítésű robot, az OPEN-R architektúrának megfelelően. A központi egységhez csatlakoznak a különböző részegységek, melyek a központi egységgel egy szabványosított buszon, az ún. OPEN-R buszon keresztül kommunikálnak. A részegységek a következők: feji részegység, farok részegység, 4 db. láb részegység.
3.7. ábra ERS-210A központi egysége és a hozzá kapcsolódó részegységek
Megemlítendő, hogy elvileg van lehetőség más, nem az ERS-210A-hoz gyártott részegség csatlakoztatására is, amennyiben az OPEN-R szabványnak megfelel és 7
mechanikailag illeszkedik. A gyakorlatban azonban ez általában nem kivitelezhető, mivel szükséges hozzá a robot szoftverének módosítása, ami viszont csak a Sony mérnökei számára hozzáférhető. Minden részegység több komponenst is tartalmazhat és az ERS-210A esetén tartalmaznak is. Továbbá minden részegységben található egy memória egység, amiben el vannak tárolva a részegység legfontosabb adatai. Ebben kerültek eltárolásra a részegység komponenseinek azonosításához és megcímzéséhez szükséges adatok, a részegység mechanikai tulajdonságai (tömege, tehetetlenségi nyomatéka, tömegközéppontja, alakja), a komponensek által biztosított funkciók és esetenként más adatok is [2]. 3.1.2.2. A központi részegység A központi részegység tulajdonképpen az AIBO lelke és elméje egyben. Itt történik az észlelt adatok feldolgozása, és az azokra adott válaszok előállítása. Minden fontosabb dolog itt helyezkedik el, a részegységekben „csupán” a szenzorok és beavatkozó szervek (aktuátorok) találhatók. A következő dolgok találhatók az egységben: • • • • • • • • • • • •
központi processzor és az áramellátást vezérlő mikrokontroller a központi memória egyes szenzorok (vibráció érzékelő szenzor, hőmérséklet szenzor, gyorsulásmérő szenzorok) memória kártya (Memory Stick) bővítő hely PCMCIA bővítő hely, a vezeték nélküli hálózati kártya számára a PAUSE gomb (a ki/be kapcsoló gombnak felel meg) hangszóró (buzzer), mely az áramellátást vezérlő mikrokontrollerhez csatlakozik lítium akkumulátor LCD kijelző és a hozzá tartozó kezelő szervek valós idejű óra OPEN-R busz vezérlő és csatlakozások tápcsatlakozó
3.8.a. ábra A központi egység elől nézetből
3.8.b. ábra A központi egység oldal nézetből
3.8.c. ábra A központi egység hátul és alul nézetből
8
3.1.2.3. A feji részegység A feji részegységen található a legtöbb komponens, és a legfontosabb szenzorok is itt találhatók. A feji részegységen található szenzorok a következők: • színes CMOS kamera (felbontása: 352x288 pixel, sebessége: 25 FPS) • infravörös fénnyel működő távolságérzékelő szenzor • sztereo mikrofon • 2 nyomásérzékelő szenzor • kétállapotú kapcsoló A feji részegységen található aktuátorok és kimenetek: • 7 LED • 7 izület • hangszóró A 7 izület a következő konfigurációban található: • egy izület a száj mozgatására • 1-1 izület a fülek mozgatására • 3 izület a fej 3 tengely mentén történő mozgatásához
3.9. ábra A feji részegység
3.10. ábra Feji részegség izületeinek szélső helyzetei (mértékegység: fok)
A 3.10. ábrán láthatók, hogy az izületek milyen határok között mozgathatók. A füleket mozgató izületek csupán két állapotúak (normál és lehajtott állapot). 3.1.2.4. A láb részegység A láb részegységek elsődleges feladata az AIBO mozgatása. Ugyanakkor a Sony véleménye szerint számos ember örömét leli különböző állatok mozgásának megfigyelésében [3]. Emiatt a Sony szoftvere a lábakat gyakran felhasználja a robot „érzelmeinek” kifejezésére, illetve számos „mutatvány” bemutatására. A fentiek miatt is volt fontos szempont a Sony számára, hogy lábak sok szabadságfokkal rendelkezzenek, és így a mozgások széles körét képes legyen produkálni a robot.
9
Első pár és a hátsó pár láb különböző alku, és az első és hátsó pár egymásra tükörszimmetrikus. Ugyanakkor ezen különbséget leszámítva teljesen megegyeznek, ezért általánosan lehet beszélni láb részegységről. A minden egyes láb részegység a következő komponenseket tartalmazza: • 3 izület • 1 kétállapotú kapcsoló A lábak alján található kapcsoló feltehetőleg arról kívánna visszajelzést adni, hogy a láb a földhöz ér –e, ugyanakkor a kapcsolók rossz minősége miatt erre nem igazán alkalmas. A 3 izület a láb 3 tengely körüli forgatását szolgálja. A vállnál két tengely menti, a térdnél egy tengely menti mozgatás lehetséges. Megemlítendő, hogy minden izület (ide értve a fejen található izületeket is) alapvetően a következőképpen épül fel: áll egy darab szervo motorból, egy darab potenciométerből és egy PID vezérlőből. A potenciométer szolgál visszacsatolásként a PID vezérlő számára, ami a motort vezérli. A PID vezérlő paraméterei szoftveresen beállíthatók. A PID vezérlőre érkező referencia jel alapján állítja a vezérlő a kívánt szögre az izületet. (Sajnos a PID vezérlő, illetve a kicsit „lötyögő” izületi csatlakozás miatt egyes izületek „remegnek”, nem áll be teljesen stabil állapot).
3.11. ábra A láb részegység
3.12. ábra A láb részegység izületeinek szélső helyzetei (mértékegység: fok)
3.1.2.5. A farok részegység A farok részegységnek nincs különösebb kardinális feladata. Itt helyezkedik el egy nyomógomb (az AIBO hátán), 2 LED a farokban, illetve két izület, mely a farok két tengely menti mozgatásáért felelős.
3.13. ábra A farok izületeinek szélső helyzetei (mértékegység: fok)
10
3.1.3. AIBO fejlesztőkörnyezetek A Sony az AIBO robotkutyájához számos fejlesztőkörnyezet elérhető. A Sony több fejlesztőkörnyezetet (SDE - Software Development Environment) is kifejlesztett és tett elérhetővé [4]. Ezek a következők: • OPEN-R SDK • RCODE SDK • AIBO Remote Framework • AIBO Motion Editor Továbbá létezik egy üzleti célú fejlesztő környezet is, mely kizárólag a Sony üzleti partnerei számára érhető el. Neve nem szerepel a Sony honlapján. Bár a Sony az AIBO Motion Editor-t is az SDE-nek hívja, valójában ez egy mozgás szerkesztő és készítő program, mellyel előre „felvett” mozgásokat hozhatunk létre, amit az AIBO képes visszajátszani. A szakdolgozat ezért sem tárgyalja a Motion Editort, továbbá a Remote Framework-t sem, ugyanis mindkét környezet az ERS-7hez érhető el csupán. Mások is készítettek az AIBO-hoz fejlesztő környezetet. Ezek közül a legfontosabbak: • Tekkotsu (a Carnegie Mellon University fejlesztésében) • RCODEPlus (www.aibopet.com oldalon elérhető) A Tekkotsu [5] környezet az OPEN-R SDK-ra épül, míg a RCODEPlus [6] az RCODE SDK továbbfejlesztésének tekinthető. 3.1.3.1. RCODE SDK és az RCODEPlus Az RCODE egy interpretált szkript nyelv, melyet a Sony alkotott, kifejezetten az AIBO programozására. Kifejezetten egyszerű és könnyen megtanulható. Nem programozók számára alkották, hanem minden AIBO tulajdonos számára. Igen magas szintű parancsokat tartalmaz, az OPEN-R architektúra úgynevezett alkalmazói rétegét (Application Layer) lehet vele elérni és programozni. Az alkalmazói réteg az alatta lévő és a Sony által implementált középszintű (Middleware Layer) és rendszerszintű (System Layer) réteget használja. Amennyiben az alkalmazói réteg által nyújtott szolgáltatások elegendőek, és nem kívánjuk az alacsonyabb rétegeket elérni, vagy esetleg módosítani, bővíteni, akkor az RCODE megfelelő választás. Azonban a Sony által elérhetővé tett alkalmazói réteg általában túl szegényes, és korlátozott kutatási célokra. Továbbá a nyelv interpretált volta miatt a sebessége közel sem lehet olyan nagy, mint egy natív alkalmazásé. Maga az RCODE SDK (Software Development Kit) egy a Sony által biztosított értelmezőből és leírásból áll. Az értelmező programot egy Memory Stick-re kell felmásolni és az AIBO-ba helyezni. A parancsokat és az adatokat vezeték nélküli hálózaton, adott TCP portokon keresztül lehet kiadni és elérni. Az RCODEPlus az RCODE kibővített változata, a hozzátartozó értelmezővel együtt. Az RCODE helyett sokan ezt használják bővebb parancskészlete miatt. 3.1.3.2. OPEN-R SDK A Sony 2002-ben tette elérhető, kizárólag nem üzleti célú felhasználásra. Az OPEN-R SDK egy C++ alapú, általános célú, teljes fejlesztő környezet, elsősorban kutatási célokra. Segítségével igen sokféle, és ugyanakkor nagy „teljesítményű” szoftver 11
fejleszthető az AIBO-hoz. Előnye, hogy a Sony biztosítja az operációs rendszert és hardver kezeléséhez szükséges szoftvert, így nem kell a legalacsonyabb, hardver szint programozásával foglalkozni. Emiatt ideális választás robotikai kutatási célokra, hiszen kész hardvert, alacsonyszintű kódot és fejlesztőkörnyezetet kapunk, és így a fejlesztést a robotikai kutatásokra lehet koncentrálni. Az OPEN-R SDK a következőket tartalmazza: • GNU C++ fordító és a hozzá tartozó könyvtárak • OPEN-R programkönyvtár (library) és fejléc (header) fájlok • Remote Processing OPEN-R programkönyvtár, fejléc fájlok és környezet • OPEN-R futtató környezet • néhány segédprogram • mintaprogramok Az SDK a nyílt forráskódú GNU C++ kereszt-fordítót (cross-compiler) és a hozzá tartózó C és C++ standard programkönyvtárakat alkalmazza. A standard programkönyvtárak bizonyos funkciói nem használhatók az AIBO-ban, és egyes funkciók a standardtól eltérően lettek megvalósítva, hogy illeszkedjenek az AIBO operációs rendszeréhez, amely nem POSIX kompatibilis, sőt nem is UNIX szerű. Az SDK tartalmaz néhány segédprogramot is, melyek nem részei a C++ fordítónak. Ezek nagy része a fejlesztéshez nélkülözhetetlen és a fordításban van szerepük. A futtató környezet Memory Stick-re felmásolandó fájlokból áll. Alapvetően az operációs rendszer egy részét, illetve rendszer programokat tartalmazza, melyek szükségesek az OPEN-R SDK által készített programok működéséhez. Az OPEN-R programkönyvtár és fejléc fájlok segítségével lehet elérni az AIBO és a futtató környezet által nyújtott szolgáltatásokat. Ezek a szolgáltatások alapvetően, az RCODE SDK-val ellentétben, az alacsony szintű szolgáltatások közé tartoznak. Egész pontosan az operációs rendszer és a rendszer szint szolgáltatásai érhetők el. A rendszer szolgáltatásai biztosítják a hardver egyszerű elérését és kezelését, de semmi többet nem. A középszintű és alkalmazói réteg szolgáltatásai nem érhetők el. A középszintű réteg egy kicsiny része mintaprogramok formájában rendelkezésre áll. Ide olyan dolgok tartoznak, mint pl. az AIBO izületeinek koordinált mozgatása (lépés), vagy objektumok keresése a kamera képén. Az OPEN-R SDK-val történő fejlesztés legnagyobb nehézsége a fentiek fényében abban áll, hogy ha magasabb szintű funkciók fejlesztésével kívánunk foglalkozni, akkor előtte magunknak kell kifejleszteni a hozzá szükséges középszintű funkciókat. Továbbá az OPEN-R SDK hátránya az is, hogy nem teljesen dokumentált, illetve nem nyitott, mivel a Sony üzleti okokból bizonyos információkat nem tesz elérhetővé. Az OPEN-R nem csak az autonóm szoftverek fejlesztését támogatja, lehetőség van távoli feldolgozásra (Remote Processing) is. Ekkor a programok elosztva futnak az AIBO-n és egy vagy több PC-n. Ezzel a módszerrel a számításigényes programok futhatnak a PC-n, így tehermentesítve az AIBO ugyancsak korlátozott számítási kapacitású processzorát. Az AIBO-n belül futó programok az ún. Inter Process Communication segítségével tudnak egymással kommunikálni. A távoli feldolgozás transzparensen biztosítja ezt a programok közötti kommunikációt, az AIBO és a PC között, a vezeték nélküli hálózat segítségével. Ezáltal úgy tűnik az AIBO számára, mintha a PC-n futó programok is az AIBO-ban futnának. Nagy előnye ennek a módszernek, hogy a program elkészítése után is eldönthető, hogy az AIBO-ban szeretnénk futtatni, vagy a PC-n. Ugyanis ugyanaz a forráskód, módosítás nélkül lefordítható az AIBO-ra és a PC-n futó távoli feldolgozás környezetre is.
12
3.1.3.3. Tekkotsu A Tekkotsu egy, az OPEN-R SDK-ra épülő keretrendszer. Az amerikai Carnegie Mellon egyetemen fejlesztik, és a szintén ott fejlesztett CMPack’02 robotfutball szoftvert nagymértékben felhasználja. Emiatt aztán igen sok szolgáltatást nyújt, a gépi látástól, az állapotdiagram alapú viselkedés leíráson keresztül, a futásidejű (kinematikai) mozgás generálásig. Az OPEN-R SDK-nál jóval magasabb elvonatkoztatási szintű programozást tesz lehetővé. Általános volta miatt számos problémához jól felhasználható, és ha szükséges akár módosítható is, mivel forráskódja nyilvános. Legfőbb hátránya a bonyolultsága. Igen jelentős méretű program, ezért teljes megértése, közel akkora tudást és ismeretet igényel, mint egy hasonló rendszer kifejlesztése. Továbbá, mivel nagymértékben fel és kihasználja a C++ nyelv lehetőségeit, megértéséhez és használatához jelentős szintű C++ ismeret szükséges.
3.2. RoboCup 3.2.1. A RoboCup és a ligák Az 1997-ben először megrendezett RoboCup [7] csupán néhány év alatt jelentős sikerre tett szert, és ugyancsak megnövekedett és kibővült. Az első RoboCup során mindösszesen 4 ligában mérhették össze tudásukat a versenyzők, addig 2004-ben már, csak futball keretében 6 liga volt, és a futball ligák mellett további két kategóriában, a RoboCup Rescue-ban (2 ligával) és a RoboCup Junior-ban (1 ligával) lehetett indulni. A RoboCup Rescue kategóriában a különböző mentési feladatokat ellátó robotok és fejlesztőik mérkőzhetnek egymással, mind számítógépen szimulált, mind valós (vagy legalábbis, ahhoz hasonló) környezetben. A RoboCup Junior-t pedig a fiatalabb korosztály számára hozták létre oktatási és ismeretterjesztési céllal, hogy a középiskolások is részt vehessenek és megismerhessék a robotikát és a RoboCup bajnokságokat. Az eredeti futball kategóriában, a RoboCup Soccer-ben, 2004-ben 6 liga volt, de 2005-ben várhatóan csak 5 lesz, és a korábbi egy-két évben is csak 5 volt. Így a legfontosabb ligák a következők: Simulation League, Small Size League, Middle Size League, (Sony) Four Legged (Robot) League, Humanoid League. A szimulációs liga (Simulation League), egy számítógép program, az ún. szimulációs szerver által szimulált környezetből és robotokból, illetve a szerverhez csatlakozó 2 x 11 ágensből áll. Az ágensek egymástól elkülönített környezetben futó, tetszőleges programozási nyelven megírt szoftverek, melyek a játékosokat szimulálják. A szimuláció diszkrét szimulációs lépésekből áll, és minden lépés során, minden ágens kommunikál a szerverrel. Ennek során az ágens megmondja, hogy milyen mozgást kíván végezni és megkapja a szimulált robot szenzorjai által érzékelt adatokat (melyek részlegesek és zajjal terheltek). Az ágenseknek korlátozott mértékben, a szerveren keresztüli, egymással való kommunikációra is lehetőségük van. A szimuláció eredménye folyamatosan nyomon követhető a szerver által biztosított grafikus felületen. Továbbá egy naplófájlba folyamatosan rögzítésre kerülnek a lépések, későbbi analízis céljából. A naplófájlok segítségével lehet „tréningezni” az ágenseket, különösen akkor, ha azok képesek fejlődésre, tanulás által. A szimulációs liga a hangsúlyt elsősorban a magas szintű viselkedésre, illetve az együttműködésre (multi-agent rendszerekre) helyezi. A robotok hardverének kezelésével nem kell törődni, mivel olyan nincs is, illetve nem kerül szimulálásra. 13
A kisméretű ligában (Small Size League, F-180) egy 18 cm átmérőjű és 15 cm magas hengerbe beférő robotok vehetnek részt. A robotok hardvere nincsen meghatározva, minden csapat szabadon fejleszthet a feltételeknek eleget tévő robotokat. A ligában a pálya mérete 3.4 x 4.9 méter. Két robot csapat mérkőzik egymással, mindkét csapatban 5-5 robottal. A labda, egy narancssárga színű golf labda. A robotok kommunikálhatnak egymással, illetve más számítógéppel vagy számítógépekkel. Tehát nem kell minden számítást a robotnak elvégezni, lehetőség van rá, hogy akár egy számítógépekből álló fürt végezze a számításokat. Továbbá a ligában engedélyezett a globális látás is. Azaz nem kell a robotokra kamerát szerelni, hanem az egész pályát belátó, egy vagy több kamera segítségével tudnak a robotok tájékozódni. Ehhez a robotokat színes mintákkal jelölik meg, hogy könnyen meg lehessen egymástól különböztetni őket. A ligában a játékidő 2x10 perc, maximum 10 perces szünettel. A játékszabályok a szabályzatában [8] pontosan rögzítve vannak, minden apró részletre kiterjedően. Játék közben két bíró ügyel azok maradéktalan betartására.
3.14. ábra Kisméretű ligában résztvevő robotok (CMU CM-Dragons)
A közepes méretű ligában (Middle Size League, F-2000) egyedi fejlesztésű, maximum 50 cm átmérőjű és 80 cm magas robotok vehetnek részt. A játékosok maximális száma 6 robot csapatonként, melyből 1-1 robot védő szerepet kell, hogy betöltsön. A pálya mérete 12 x 8 méter, a labda standard FIFA 5-ös méretű, narancssárga színű labda. A játékidő 2 x 10 perc, maximum 10 perces szünettel. A robotok közötti kommunikáció engedélyezett, azonban távoli számítógépen történő feldolgozás nem engedélyezett, azaz a robotoknak autonómnak kell lenniük. A globális látás szintén nem engedélyezett, minden robotnak saját magának kell érzékelni a környezetét. A robotoknak sötét színűeknek kell lenniük, és a szabályzatban definiált, színes megkülönböztető jelzésekkel kell rendelkezniük. A pálya minden részének színe is pontosan meghatározott. A színek alapján történő tájékozódás megszokott és elterjedt a ligában, bár nem kötelező. A játékszabályok [9] szintén pontosan definiáltak, betartásukra két bíró ügyel, akárcsak a kisméretű ligában.
14
3.15. ábra Közepes méretű robotok játék közben (2004-es RoboCup, Portugália)
A humanoid ligában két lábon járó, 2 karral és egy fejjel rendelkező, emberszerű, egyedi fejlesztésű robotok vehetnek részt. A robot testének méretarányai pontosan szabályozva vannak. A ligán belül további három kategóriára osztják a robotokat, a magasságuk alapján. Ezek a következők: H-40, H-80 és H-120. Ezek nevüket a tipikus robot magasságokról kapták. A robot magasságának rendre kisebbnek kell lennie, mint 44 cm, 88 cm és 180 cm, hogy részt vehessen az adott kategóriában. A labda és pálya mérete is a kategóriának megfelelő. A legnagyobb, H-120-as kategóriában 7.2 x 10.8 méteres a pálya és szabványos FIFA 5-ös méretű labdát használnak. A pálya itt is színkódolt, akárcsak a közepes méretű ligában. A játékosok száma, csapatonként 1-3 robotig terjedhet. A globális látás itt sem engedélyezett. A „távoli agy”, azaz a távoli feldolgozás engedélyezett, sőt ez az egyetlen liga, ahol a robotok kézzel történő irányítása is megengedett. Ennek oka, hogy a liga egyelőre leginkább demonstrációra szolgál, mintsem tényleges játékra. A hangsúly elsősorban a robot (alacsonyszintű) képességein van, nem a játékon és a stratégián. Ezt a tényt erősíti, hogy minden csapat lehetőséget kap egy 5 perces, a robot tetszőleges tulajdonságát bemutató demonstrációra, amit a zsűri a technikai teljesítmény és művészi benyomás alapján pontoz. Továbbá minden csapatnak demonstrálni kell, hogy a robot képes büntető rúgásra.
3.16. ábra Humanoid robot (2004-es RoboCup, Portugália)
15
3.2.2. Sony négylábú robot liga A Sony négylábú robot ligában (Sony Four Legged Robot League, vagy néha Four Legged League) AIBO robotok vehetnek részt. Minden csapatban 4 darab, 1 kapus és 3 csatár robot. Semmilyen hardver módosítás nem megengedett, kizárólag a vezeték nélküli hálózati kártya hozzáadása, azokhoz a típusokhoz, melyekbe ez nincs beleépítve. A robotok típusa is szabályozva van. A 2004-es játékokon a következő típusok vehettek részt: ERS-7, ERS-210, ERS-210A. Ez az egyetlen liga, ahol a robotok előre adottak. Emiatt a szoftverfejlesztésre ebben a ligában fordítják a legnagyobb hangsúlyt. A robotoknak autonóm módon kell működniük, távoli feldolgozás, illetve globális látás nem engedélyezett. A vezeték nélküli hálózat segítségével a robotok kommunikálhatnak egymással, illetve kötelezően kommunikálnak az ún. GameController-rel. Ez egy szoftver, melynek segítségével a játékvezetők a mérkőzést irányítják. A játékidő 2 x 10 perc. A pálya kinézete, méretei, a különböző objektumok színei előre adottak. A játék során alkalmazott megvilágítás is ismert, az erre vonatkozó részletes méréseket a liga honlapján [11] közzéteszik, még a mérkőzések előtt. A robotok a játék során színes „mezt” viselnek. Az egyik csapat kékszínűt, a másik vöröset. A labda, az AIBO-hoz adott szabványos, rózsaszínű labda. A pályán való tájékozódást 4 színkódolt oszlop, illetve a különböző színű kapuk segítik.
3.17. ábra A négylábú ligában használt pálya (2004-es RoboCup, Portugália)
A mérkőzés során a robotok, GameController szerinti állapota a következők valamelyike lehet: initial, ready, set, playing, penalized, finished. Az első három a robotok kezdeti állapotai. A playing állapotban játszik a robot, a finished állapotba a félidő végén kerül. A penalized állapotba akkor jut, ha megsérti a játékszabályok valamelyikét. Ezek a hivatalos szabályzatban [12] pontosan részletezve vannak, akárcsak a megsértésükért járó büntetés. A ligában három bíró felügyeli a játékmenetet. Az állapotok közötti váltás, vagy a robot adott kapcsolójával, vagy pedig a GameController által küldött üzenettel lehetséges. A GameController-t egy operátor (a vezető bíró utasításainak megfelelően), a robotokat két segédbíró kezeli. Büntetéskor a robotok kiállítását, és visszahelyezését a segédbírók végzik.
16
3.18. ábra A négylábú ligában, a játék során a robotok lehetséges állapotai és az azok közti átmenetek
A játékszabályok az évek során változtak a ligában. Mindig igyekeztek úgy meghatározni a szabályzatot, hogy folyamatosan nehezedjen a feladat. Egy konkrét példa: a pálya szélén lévő jelző oszlopokból a 2004-es játékok előtt még 6 volt, 2004től már csak 4. Mivel így a robotok a játék folyamán ritkábban látják az oszlopokat, ezáltal ritkábban kapnak pontos információt a helyzetükre nézve. Ezzel arra ösztönzik a csapatokat, hogy a pálya kevésbé speciális részeit is használják tájékozódásra. Nyilván a végső cél az, hogy a tájékozódás során csak azokat a jellemzőket használják a csapatok, amelyek egy valódi futballpályán is megtalálhatóak. Egyébként 2005-ben az oszlopok előbbre fognak kerülni, mivel 2004-ben túlzottan nehezen tudtak a robotok tájékozódni, túl ritkán látszottak az oszlopok. Minden évben vannak úgynevezett kihívások [13] is, melyeket a mérkőzéseken kívül kell teljesíteni. Ezek célja a fejlesztések ösztönzése. Gyakran olyan feladatokat adnak a szervezők, melyek néhány évben belül bekerülnek magába a játékba. Például a 2004-es évben az egyik kihívás, úgy szólt, hogy három robotot helyeztek a pályára, ebből kettő mozdulatlan volt, és csak mint akadály szerepelt. A harmadik robotnak pedig 3 perc állt rendelkezésére, hogy minél több gólt rúgjon, de úgy, hogy közben a fényviszonyok nem voltak ismertek, és esetenként erőteljesen változtak. A kihívás célja azt volt, hogy a csapatokat olyan látás alrendszert kifejlesztésére ösztönözzék, mely nem érzékeny a fényviszonyokra és annak változásaira.
3.3. Egy robotfutball szoftver megvalósítási lehetőségei Megjegyzés: A következőkben a RoboCup-ban, a négylábú ligában résztvevő néhány, kiválasztott csapat szoftvereinek összehasonlítására és működésük főbb elveinek bemutatására kerül sor. Az itt elmondottak általános trendeknek tekinthetők, azonban nem kizárt, hogy egy-egy csapat teljesen más módon közelítsen a problémához. A fejezet során a hangsúlyt az alacsonyszintű funkcióra helyeztük. A magasabb szintű funkciók, mint pl. a stratégia és a robotok közti együttműködés bemutatásától eltekintünk.
3.3.1. Bevezetés Egy AIBO-n futó robotfutball szoftver 5 fő funkcióra, alrendszerre bontható. Ezek a következők: 1. Látás 2. Mozgás 3. Helyzet meghatározás 4. Stratégia 5. Kommunikáció
17
A látás alrendszer feladata a kamera képének feldolgozása. Ez képszegmentálásból, objektum felismerésből, objektumok helyzetének meghatározásából áll. A mozgás alrendszer feladata a helyváltoztatás és a rúgások végrehajtása, ill. információ szolgáltatása arra nézve, hogy helyváltoztatáskor hozzávetőleg mennyit haladt előre a robot (odometria). Helyzet meghatározás alrendszer feladata a robot, a pálya koordináta rendszerében elfoglalt helyének meghatározása. Célszerű ezt úgy tenni, hogy egy valószínűségi eloszlást számoljon a szoftver, a robot és a pályán található objektumok helyzetére, felhasználva a régebbi adatokat is, mivel a látás által szolgáltatott objektumok pozíciói, és az ezekből számolt robot pozíció nagyon sok zajjal és más pontatlansággal terhelt. Egy jó helyzet meghatározó rendszer egy-egy teljesen rossz mérés esetén is viszonylag pontosan megadja a robot helyzetét. A stratégia alrendszer a robot magas szintű viselkedésért felel. Ezen alrendszernek kell ismerni a játék szabályait, eldönteni, hogy milyen helyzetben milyen cselekvést kell végrehajtani. Kommunikáció feladata a csapattárs robotok viselkedésének összehangolása, kapcsolattartás a GameController-rel ill. másodlagos funkciója a hibakeresés és tesztelés során szükséges adatok vétele és továbbítása. A továbbiakban a látás, a mozgás és a helymeghatározás megvalósításának alternatíváiról lesz szó, míg a kommunikáció és stratégia nem kerül külön kifejtésre. 3.3.2. Látás alternatívái A képfeldolgozás és gépi látás tudománya jól működő, és gyakran matematikailag is alátámasztott módszerekkel rendelkezik a robot látás problémáira. Azonban az ismert és bevált módszerek általában túl sok számítást igényelnek, hogy megvalósításuk célszerű legyen egy autonóm működésű roboton, így az AIBO-n is. Továbbá a robotfutball során különösképp gyorsan változik a robot által látott kép, így mindenképpen olyan módszerekre van szükség, amelyek megfelelően gyorsak, ugyanakkor még elfogadható módon robosztusak és megbízhatóak. Többek között ezzel is indokolható, hogy a látásra alapvetően csak kétféle megoldás terjedt el. A hagyományosnak mondható, szinte minden csapat által használt szín alapú osztályozáson alapuló módszer [14], ill. az él-pontdetektálásos módszer [15], [16]. A szín alapú osztályozás elve, hogy a YUV formátumú kamera kép minden pixelét besorolják valamely színosztályba, egy előre kalibrált táblázat segítségével. Ezután RLE (Run Length Encoding) kódolás, majd blob-ok (azonos színű, összefüggő régiók) keresése történik. Ezzel a lépéssel a kép régiókra bontása befejeződött. Az így létrejött kép jóval kevesebb információt tartalmaz, mint az eredeti, így a további feldolgozás gyors, mivel csak kevés adaton kell számolni. A blob-ok különböző tulajdonságait felhasználva (mérete, burkoló téglalapjának oldalainak aránya, stb.) azonosítják, hogy melyik objektumról van szó, ill. hogy hol helyezkedik el a pályán. Ezen módszer előnye, hogy igen gyors, bevált, sokak által használt megoldás. Nagy hátránya, hogy érzékeny a különböző fényviszonyokra. Általában manuálisan újra kell kalibrálni a színosztályozó táblázatot, ha a fényviszonyok jelentősebben változnak. Az él-pontdetektálásos megoldás alternatívát kínál a színalapú osztályozással szemben. Azonban az AIBO számítási kapacitása nem elegendő ahhoz, hogy a hagyományos rendszerekben használatos módon a kép minden pixelén végigmenve meghatározzák, hogy él-pont –e az adott pixel. Ehelyett egy rácsot illesztenek a képre, és csak a rácspontokban vizsgálják meg, hogy van-e él. A rács sűrűsége változó, attól függően, hogy közelebbi vagy távolabbi objektumot vizsgálnak. Meghatároznak egy horizontot a képen, és a horizont közelében sűrűbb, a horizonttól távolabbi részeken
18
ritkább rácsot alkalmaznak. A rács mentén végigmenve, mind a 3 színcsatornán, meghatározzák az ún. kontraszt mintákat. Ez úgy történik, hogy tekintik a rács mentén az egymás utáni pixelek intenzitás változását. Attól függően, hogy a változás pozitív vagy negatív, +1 ill. -1 értéket rendelnek a pixelhez. Ha nincs a küszöböt meghaladó változás, akkor 0 értéket rendelnek a pixelhez. Így minden rácsponthoz kapnak egy számhármast. Ez a kontraszt minta. Továbbá a rácsot alkotó pixeleket szín alapján is osztályozzák. Ezek után minden pixelt valamely él osztályba sorolnak, kivéve ha csupa 0 a kontraszt mintája, mert akkor ott nincs él. Ezen információk alapján, már meg lehet találni a keresett objektumokat a képen. A módszer kiegészíthető, úgy, hogy automatikusan alkalmazkodjon a fényviszonyok változásához, s így a szín alapú osztályozáshoz használt táblázatot nem kell manuálisan kalibrálni. Ezt úgy érik el, hogy zöld színű pixeleket keresnek a képen, de nem a színe, hanem a képen való elhelyezkedésük alapján. A megtalált pixelek segítségével meghatároznak egy referencia zöldet, s a többi színt ehhez képest adják meg. Az él-pontdetektálásos módszer előnye, hogy gyorsabb, mint a színosztályozáson alapuló módszer, és nem igényel manuális szín kalibrációt. 3.3.3. Mozgás alternatívái Kétféle megközelítés lehetséges a mozgások leírásánál. A dinamikus és a statikus mozgás leírás [17]. A statikus leírás esetén előre adott egy függvény, amely leírja a robot izületeinek szögét, az idő függvényében. A leírás statikus, mivel a mozgás előre adott, és nem lehet a visszajátszása közben változtatni rajta. A gyakorlatban ezt a függvényt csak bizonyos pontjaiban adják meg, az ún. kulcskockákban, a köztes pontokat pedig lineáris interpolációval határozzák meg. A kulcskockákban a robot izületeinek szögét általában kézzel adják meg. Az egyik módszer az, hogy manuálisan beállítják a robotot a kívánt pózba, majd lekérdezik az izületek szögeit. A statikus leírást általában a különböző rúgásokhoz alkalmazzák. A dinamikus mozgás leírás esetén a robotot matematikailag modellezik, és az így készült kinematikai modell segítségével írják le az egyes kartagok mozgását, egész pontosan azok térbeli helyét, az idő függvényében. Ezután inverz kinematikai számításokkal meghatározzák az izületek szögét, az idő függvényében. A leírás dinamikus, mivel a mozgás végrehajtása közben végzik a számításokat, és így lehetőség van rá, hogy a robot mozgását menet közben módosítsák, hogy az a legjobban illeszkedjen a robot állapotához és környezetéhez. A dinamikus mozgás leírást tipikusan a helyváltoztatáshoz, a lépések leírásához használják. A lépések leíráshoz használt, a robot végtagjainak (lábainak) pályája sokféle lehet, mint pl. trapéz vagy téglalap alakú, számos egyéb paraméterrel. További jellemzője ennek a leírási módnak, hogy a matematikai modell egyetlen paraméterének kis mértékű megváltoztatása is nagymértékben módosíthatja a létrejövő mozgást. Ezért a megfelelő paraméterek megtalálása nehéz. Ugyanakkor nem elég az, hogy a robot stabilan mozogjon, még igen fontos a robot haladási sebessége is, mivel a robotfutballban jelentős előny jelent a nagyobb sebesség. Továbbá nem elhanyagolható szempont az sem, hogy a kamera mennyire rázkódik a mozgás során, illetve mennyire marad a földhöz képest ugyanakkor magasságban, mivel ez befolyásolja a látás alrendszer működését. Ezen két szempont tovább nehezíti az ideális paraméterek megtalálását. A paraméterek meghatározása általában kézzel, heurisztikus módszerekkel történik, de van példa automatikus módszerek, konkrétan genetikus algoritmusok alkalmazására is [18]. Mind a statikus, mind a dinamikus leírás esetén szükséges, hogy meg lehessen mondani, hogy a robot a mozgás végrehajtása során, hogyan mozdul el a térben. Ezt
19
egy 3 dimenziós elmozdulás vektorral lehet megadni, és odometria néven szokás nevezni. Erre azért van szükség mivel a robot a pozícióját a pályán vizuális információk alapján határozza meg, azonban ezek az információk nem mindig állnak rendelkezésre. A köztes időpontokban a robot az odometriára támaszkodva becsüli meg a helyzetét. 3.3.4. Helymeghatározás alternatívái A nemzetközi RoboCup mérkőzéseken résztvevő csapatok a helyzet meghatározáshoz szinte kizárólag valamilyen statisztikus módszert alkalmaz. Ezek úgy működnek, hogy az éppen érzékelt és a régebbi adatok alapján, a pálya minden pontjára kiszámolják, hogy mekkora annak a valószínűsége, hogy a követett objektum (a robot, a labda, illetve a többi robot tipikusan) a pálya adott pontján helyezkedik el. Az objektum helyzetének pedig azt a pontot veszik, ahol a valószínűségi eloszlás függvénynek maximuma van. A ligában több módszer is használt. A Monte-Carlo lokalizáció [19], az adaptív Monte-Carlo lokalizáció, a Kalman és az Extended Kalman szűrő felhasználásával történő lokalizáció [20]. Még alkalmazzák a Markov lokalizációt [21] is. A különböző módszerek összehasonlítása nem triviális, jelentős matematikai apparátust, és kísérletezést, tapasztalatot igényel. Erre vonatkozó irodalom a szakdolgozat szerzője számára nem ismert. Azonban, néhány, különböző publikációkban leírtak alapján feltehető, hogy az Extended Kalman szűrő pontosabb, mint a többi megoldás, és mindkét Kalman szűrő gyorsabban érzékeli a hirtelen változásokat (pl. ha a robotot átteszik egyik helyről a másikra), mint a Monte-Carlo lokalizációs megoldások, de konkrét, méréssel alátámasztott adatok nem állnak a szerző rendelkezésére. A ligában 2004-ben a Monte-Carlo lokalizáció volt a legelterjedtebb, azonban ez nem jelenti azt, hogy jobb, vagy rosszabb lenne a többi megoldásnál.
20
4. Rendszerterv A kitűzött célokat megvalósítására egy 5 alrendszerből álló szoftverrel kerülhet sor. Az alrendszerek a következők: - Mozgás alrendszer: Feladata a robot mozgatása, rúgások végrehajtása, és az odometria számítása. - Látás alrendszer: Feladata a látott kép feldolgozása, az objektumok felismerése és a robothoz képesti helyzetének meghatározása. - Lokalizáció alrendszer: Feladata az objektumok koordinátarendszerében.
és
robot
helyzetének
meghatározása
a
pálya
- Kommunikáció alrendszer: Feladata a robot és a labda pozíciójának, illetve a hibakereséshez szükséges információk továbbítása a PC felé. A PC felőli utasítások fogadása. - Viselkedés alrendszer: Feladata a robot magas szintű viselkedésének irányítása. Ezek a következők: labdakeresés, navigálás, gól rúgása és védése.
4.1. Mozgás A rúgások és a haladó mozgás során az izületek szögét megfelelő időben, adott értékre kell állítani. Ezek a szögek egy fájlban kerülnek letárolásra, az időparaméterekkel együtt. A feladat leegyszerűsítése végett sem a rúgásoknál, sem a haladó mozgásnál nem kerül sor pályaszámításra, mivel az ahhoz szükséges inverz kinematika meglehetősen bonyolult. Pályaszámítás helyett a robot izületei kézzel kerülnek beállításra, majd lekérdezésre az aktuális szögértékek. Ez a mozgás minél több részletére kerül majd megismétlésre. Ezután a mozgás köztes időpontjaiban a szögek lineáris interpolációval kerülnek meghatározásra, a következő módon:
α (t 2 ) =
α (t 3 ) − α (t1 ) t 3 − t1
⋅ t 2 + α (t1) ,
ahol t1 < t 2 < t3 , és t1 , t3 időpillanatokban ismert az adott izület szöge ( α (t1 ) és α (t 3 ) ) és keressük az izület szögét t 2 -ben. Mivel egy izület sem fordulhat teljesen körbe, ezért a fenti képlet használható. A mozgás odometria adatokat is kell, hogy szolgáltasson. Ez úgy lesz megoldva, hogy megmérésre kerül egy adott mozgás során a robot egy pontjának az elmozdulása. Ezt többször megismételve és átlagot számolva minden mozgásfajtához hozzárendelhető egy elmozdulás vektor. Így a robot elmozdulásának kiszámításához csupán azt kell számon tartani, hogy hányszor hajtotta végre a robot a különböző mozgásokat.
21
4.2. Látás A látás szín alapú osztályozáson alapul. A látott objektumok megkülönböztetésének és felismerésének alapja az objektum színe. Ugyanakkor ez még önmagában nem elegendő az objektum felismeréséhez, ezért más módszerek is alkalmazásra kerülnek. Kiemelendő, hogy a szín alapú osztályozás sajnos érzékeny a fényviszonyokra, ezért általában újra kell kalibrálni a megvilágítás már kisebb változásakor is. 4.2.1. Szegmentálás
A kamera által rögzített kép pixelei a színük szerint kerülnek osztályozásra. A képek YUV formátumúak, ahol az U,V csatornák meghatározzák a pixel színét, az Y csatorna pedig az intenzitását. Az osztályozás a következő módon történhetne: Minden i. osztályra: ha ( i U TL ≤ U x , y ≤ i U TH és iV TL≤ V x , y ≤ iV TH és iY TL≤ Yx , y ≤ iY TH ) akkor az (x,y) pixel az i. osztályba tartozik (TL = Threshold Low, TH = Threshold High). Ugyanakkor ez a megoldás közvetlenül lekódolva, még a ciklust kifejtve is lassú lenne a sok feltételes ugró utasítás miatt. Helyette egy másik, gyorsabb módszer kerül alkalmazásra. Ezen gyorsabb módszer alapelve a következő: Minden i. osztályra: (x,y) pixel az i. osztályba tartozik (mint logikai változó) = ( i U LUT [U x, y ] és iV LUT [V x, y ] és iYLUT [Yx , y ] ) Az i U LUT , iVLUT és iYLUT mindegyike egy 256 elemű tömb, ami logikai értékeket tartalmaz (LUT = Look Up Table). Egy ilyen tömb közvetlenül megadja, hogy egy adott csatorna érték esetén a pixel tartozhat-e az adott színosztályba. Természetesen úgy kell minden osztályhoz tartozó tömb logikai értékeit megválasztani, hogy a 3 tömb segítségével a színek diszjunkt osztályokra legyenek bontva. Ezen módszer még mindig lassú, mivel ki kell számolni a logikai kifejezést minden osztályra. Ezt meg lehet tenni egyetlen lépésben is, mindössze annyit kell tenni, hogy minden tömbben nem egy, hanem több logikai érték kerüljön tárolásra, minden színosztályhoz egy. Mivel egy logikai érték egyetlen biten tárolható, ezért egy 32 bites regiszterben 32 logikai értéket kerülhet tárolásra, és ugyanakkor a processzor egyetlen ÉS művelettel képes feldolgozni mind a 32 logikai értéket. Ennek megfelelően a végleges változat a következő: U LUT [U x , y ] és V LUT [V x , y ] és Y LUT [Yx , y ] = szegmentált_pixel
Az U LUT , V LUT és Y LUT most rendre 256 darab 32 bites előjel nélküli egészt tartalmaz, ahol minden helyi értéken álló bitnek megfelel egy logikai érték. A szegmentált_pixel egy 32 bites előjel nélküli egész, hasonlóan megfeleltethető bitjeinek logikai értékek. Ha a szegmentált pixel i.-dik helyi értékén álló bit 1 értékű, akkor a pixel az i. osztályba tartozik. Most is célszerű diszjunkt osztályokat létrehozni, annak ellenére, hogy a fenti módszer képes kezelni azt az esetet is, amikor egy pixel több osztályba is tartozhat.
22
4.1.a. ábra RoboCup futballpálya képe
4.1.b. ábra 4.1.a. ábrán végrehajtott szín alapú osztályozás eredménye
A három tömb értékei manuálisan, a robot kamerájával készített több mintakép alapján kerül meghatározásra. 4.2.2. Összefüggő régiók képzése
A szegmentálást követően az azonos színű pixelekből régiókat kell képezni, mivel ezen régiók nagyrészt a képen lévő objektumokat jelentenek majd, a feldolgozás későbbi szakaszaiban. Először a kép x tengelye mentén kell végrehajtani egy Run Length Encoding (RLE) algoritmust. Így az egymás mellett lévő, azonos színű pixelek leírhatók egy színkóddal, és egy számmal, amely megadja, hogy hány darab van a pixelekből egymás után. Ezután y irányban is meg kell keresni az összetartozó régiókat. Ez a következő módon, az ún. fa alapú uniókereső algoritmussal történik: 0. lépés: Minden egyszínű szakasz adatstruktúrája kiegészítésre kerül egy új mezővel, a szakasz „szülőjére” mutató pointerrel. A szakasz szülője kezdetben önmaga. Ez a lépés az RLE kódolással együtt megtörténik. 1. lépés: A kép közvetlen egymás alatti sorai megvizsgálásra kerülnek. Ha van két olyan szakasz, amely egymás alatt van, és legalább 2 pixelben érintkeznek, akkor a felső, az alsó szülője. Ez, a gyermek szülő mezőjébe bejegyezésre kerül. 2. lépés: A létrejött fa adatstruktúrák a gyökértől a levelekig bejárásra kerülnek, és közvetlenül a gyökérhez kerül hozzárendelésre a fa összes eleme (kivéve a gyökér elem). Így egy kétszintű fákból álló erdő jön létre, ahol minden fa leír egy a képen található összefüggő régiót. Ezután meghatározásra kerül a régiók középpontja, méretei pixelekben, ill. a befoglaló téglalapok. A befoglaló téglalap az a legkisebb területű téglalap, amely még tartalmazza az adott régió összes pontját. Majd a fák színek szerinti külön szedésre, és a régió mérete szerint csökkenő sorrendbe állításra kerülnek. Ez a lépés azért előnyös, mert a magasabb szintű feldolgozás során előbb lehet foglalkozni a nagyobb méretű, s így valószínűleg közelebb lévő, objektumokkal. Továbbá a zaj által okozott – néhány pixeles – hibás objektumok valószínűleg a lista végére kerülnek.
23
4.2.3. Régióegyesítés
Bizonyos esetekben célszerű két régiót egyként kezelni. Például, ha az adott régiót elmetszi egy pixel széles szakasz, akkor a régió két régióra esne szét. Viszont ebben az esetben az egy pixel széles szakasz valószínűleg csak zaj okozta hibás színosztályozás, ezért célszerű lenne a két régiót összeolvasztani, egyetlen régióként kezelni. Ugyanakkor, ha a metsző szakasz már inkább tekinthető téglalapnak, akkor nem célravezető a két régió egyként kezelése, mivel ebben az esetben valószínűbb, hogy inkább két különböző objektumról van szó, köztük egy harmadikkal.
4.2. ábra Régióegyesítés szemléltetése
A régióegyesítés a következő algoritmus szerint történik: 1. lépés: Minden régiónak kiszámolásra kerül a „sűrűsége”. A régió sűrűsége jelentse az adott régió területének (pixeleinek számának) és a befoglaló téglalap területének hányadosát. 2. lépés: Ha két régió egy adott távolságnál közelebb van egymáshoz, és a közös sűrűségük (az egyesített régió sűrűsége), egy, az adott színhez előre megadott küszöbnél nagyobb, akkor a két régió egyesítésre kerül. Minél alacsonyabb a küszöb, az algoritmus annál inkább hajlamosabb a két régiót egyesíteni. 4.2.4. Objektum felismerés
Az objektum felismerés során a cél az, hogy a képen megkeressük azokat az objektumokat, amelyek a pályán lehetnek, továbbá, hogy meghatározzuk ezen objektumok távolságát és helyzetét a robothoz képest. Az objektum felismerés a következő lépésekből áll: 0. lépés: A lehetséges objektumok listájának összeállítása. 1.a. lépés: A lehetséges objektumok mindegyikére kiszámolni azokat a tulajdonságokat, amelyek a keresett objektumra jellemzőek. 1.b. lépés: A tulajdonságok számolt és elvárt értékének egyezésének valószínűségének kiszámítása.
24
1.c. lépés: A valószínűségekből egyetlen valószínűség képzése, mely azt jellemzi, hogy a lehetséges objektum mekkora valószínűséggel esik egybe a keresett objektummal. 2. lépés: A lehetséges objektumok közül kiválasztani azt, mely a legnagyobb valószínűséggel esik egybe a keresett objektummal. A 0. lépésben a 10 legnagyobb, a keresett objektum színével (vagy színeivel) megegyező régió kerül kiválasztásra. Az 1.a. és 1.b. egyetlen lépésben kiszámítható, míg 1.c. a valószínűségek összeszorzását „takarja”. A 2. lépés egy maximum kiválasztással valósítható meg. A különböző objektumok esetén különböző tulajdonságok számítására van szükség. Ezek még nem kerültek meghatározásra mind, s valószínűleg csak a fejlesztés folyamán derül majd ki, hogy mely tulajdonságokat érdemes számolni. A labda felismeréséhez használni kívánt néhány tulajdonság: - labda és a befoglaló téglalap területe elér -e egy minimális értéket? Bináris szűrő. Vagy 0 vagy, 1 valószínűséget vesz fel. - mennyire négyzet alakú a befoglaló téglalap? d=
w−h w+h
, o=e
2 d C − 2
, ahol
„w” a befoglaló téglalap szélessége, „h” a befoglaló téglalap magassága, C = 0.6, és „o” pedig a keresett valószínűség. - a labda területének és a befoglaló téglalap területének aránya. m = π ⋅ w⋅ h/ 4, d =
m−a m+a
, o=e
2 d C − 2
, ahol
„w” a befoglaló téglalap szélessége, „h” a befoglaló téglalap magassága, „a” a labda területe, C = 0.6, és „o” pedig a keresett valószínűség. 4.2.5. Távolság meghatározás
A távolság meghatározás a látott objektum mérete alapján történik elsősorban, de amennyiben feltételezzük, hogy az adott objektum nem emelkedik fel a földről, akkor az objektum távolsága a látott képen való elhelyezkedése alapján is meghatározható. Ez esetben nagyobb lesz a távolság meghatározás hibája, mint az első esetben. A robot izületeinek szögét ismerve meghatározható a kamera pozíciója és iránya. Ezek az adatok a robothoz rögzített koordinátarendszerben adhatók meg.
25
4.3. ábra Objektum kamerától való távolságának meghatározása, a mérete (pl.: magassága) alapján, egyszerű aránypárral
4.4.ábra Objektum robottól való távolságának meghatározása
4.3. Lokalizáció Szükséges, hogy a robot és az általa érzékelt objektumok helyzete a pályához rögzített koordinátarendszerben kerüljön meghatározásra, ugyanis a viselkedésért felelős alrendszernek szüksége van ezekre az adatokra. Elegendő a robot helyzetét meghatározni a pályán, mivel a többi objektum pozícióját ismerjük a robothoz képest, így meghatározható pályán lévő helyzetük is. Egész pontosan a robothoz rögzített koordinátarendszer egységvektorait kell meghatározni a pályához rögzített koordinátarendszerben. Ehhez szükség van a pályán lévő fix pontokra. Erre a célra szolgálnak a jelzőoszlopok, és a kapuk is felhasználásra kerülhetnek esetleg ebből a célból. Egyszerre legalább két ilyen fix objektumot kell látnia a robotnak ahhoz, hogy meg tudja határozni a helyzetét. Ha ismerjük a robot távolságát két ilyen fix objektum középpontjától (O1 és O2), akkor O1 és O2 középpontú, rendre az ismert távolság sugarú körök metszéspontja meghatározza a robot pozícióját a pályán. Azt, hogy a robot teste merre „néz”, a látott objektumok alapján, illetve a robot mozgásának nyilvántartásával megállapítható. Amennyiben nem látható két fix objektum a kamera képén, a robot az odometria adatait felhasználva becsüli meg, hogy egy előzőleg ismert helyzetéhez képest hol található az adott pillanatban. A lokalizáció során nyert adatokon egy alul áteresztő szűrőt alkalmazva, csökkenthető egy-egy, teljesen hibás mérés okozta pontatlanság.
4.4. Kommunikáció WLAN kártyán keresztül a robotnak utasításokat lehet adni, utasítani lehet különböző adatok PC felé történő továbbítására, ill. vezérelni lehet bizonyos funkcióit. A csapatjáték hiánya okán elsősorban hibakeresési célokra fog szolgálni. Továbbá a robot saját pozícióját és irányát, illetve az észlelt objektumok pozícióját képes lesz továbbítani a PC felé. Ezen alrendszer implementációja kizárólag programozási kérdés. Megvalósítása során célszerű a TCP vagy UDP protokollt használni.
4.5. Viselkedés Ezen alrendszer bemenetként megkapja a robot és az észlelt objektumok helyzetét, ennek megfelelően dönt, majd a mozgás alrendszer részére utasításokat ad. Alacsony szintű viselkedések, amiért az alrendszer felelős a következők: labda megkeresése, és navigálás. Az egyszerűség kedvéért a navigálás nem alkalmaz különösebb pályatervezést, ill. akadály kikerülést. A célkoordinátára egyenes vonalban igyekszik eljutni. A labdakeresés, úgy kerül implementálásra, hogy a robot először körülnéz a
26
kamerájával, majd ha nem látja a labdát, akkor elkezd körbeforogni. Ha néhány körbefordulás után sem találja meg, akkor megáll a keresés. A jelzőoszlopok és a kapuk megkeresése is ugyanígy történne. A magas szintű viselkedések az egyszerűbb viselkedések kombinációjából áll. Ezek megvalósíthatók állapot gépek segítségével. Két magas szintű viselkedés kerül implementálásra: a védő és a csatár szerepe. Ezeket a PC-ről küldött üzenettel lehet aktiválni. Védő szerepben a robot a kapu előtt áll és igyekszik követni a labdát a kamerával. Ha a labda megközelíti a kaput egy adott távolságra, akkor elindul a labda pozíciója felé. Ha elérte a labdát elrúgja, az ellenfél kapuja felé. Ezt az utóbbi két lépést addig ismétli, amíg a labda a kaputól adott távolságon kívülre nem kerül, ill. a robot a kaput adott távolságra el nem hagyja. Ezután visszamegy a kapu elé. A csatár szerepben a robot megkeresi a labdát, majd oda megy hozzá, és elrúgja az ellenfél kapuja felé. Ezt addig ismétli, amíg a labda a kapuba nem kerül. Ekkor visszamegy a kezdő pozíciójába.
27
5. Megvalósítás 5.1. Felhasznált eszközök 5.1.1. Hardver
A megtervezett rendszer megvalósításához rendelkezésre állt egy Sony ERS-210A robotkutya. Mivel csak ez az egyetlen robot állt rendelkezésre, ez a tény kezdettől fogva figyelembe lett véve. Így ez az egyik indoka, hogy kooperációról nem esik szó a szakdolgozatban. A robothoz adott szabványos kiegészítők a következők: rózsaszínű műanyag labda, 2 darab akkumulátor, akkumulátor töltőállomás, két darab rózsaszínű, 16Mbájtos OPEN-R memóriakártya. Fontos megjegyezni, hogy a memóriakártyák másolásvédelmi mechanizmussal vannak ellátva, ezért a különböző színű kártyák nem cserélhetők fel egymással. A memóriakártyák PC-vel való írásához és olvasásához rendelkezésre állt egy USB porton keresztül használható, külső kártyaolvasó. Az AIBO el volt látva a 802.11b szabványt használó vezeték nélküli hálózati kártyával. Továbbá rendelkezésre állt egy Linksys WAP11-es típusú Access Point és egy Linksys WUSB11 típusú USB-s hálózati kártya, melyek szintén a 802.11b WiFi szabvány szerint működnek. A hálózati kártya Ad Hoc üzemmódban nem volt képes kommunikálni az AIBO hálózati kártyájával, igen közelről sem. Ennek oka feltehetően az, hogy a hálózati kártya teljes egészében az AIBO-ban foglal helyet, és nincs külön antenna kivezetése, emiatt a jel igen gyengén fogható csak. Ugyanakkor az Access Point (továbbiakban: AP) jele elég erős volt ahhoz, hogy az AIBO 20-30 méter távolságról is fogja, illetve válaszolni is tudjon. Ezen 20-30 méter esetén nem volt közvetlen rálátás az AIBO-ról az AP-re, emiatt szabad terepen ez az érték feltehetően jóval nagyobb. Az AP jelenléte miatt a kommunikáció Infrastructure üzemmódban történt a PC és az AIBO között. Az AIBO támogatja a WEP titkosítást, azonban ez nem került felhasználásra. A 802.11b szabvány alapján a maximális átviteli sebesség a PC és az AIBO között 11Mbit/s. 5.1.2. Fejlesztő környezet
A fejlesztő környezetként a Sony OPEN-R SDK-ja került felhasználásra. Az ismertetett, illetve rendelkezésre álló fejlesztőkörnyezetek közül, még a Tekkotsu is megfelelt volna. Azonban a szakdolgozat során a robotfutball alacsony szintű vonatkozásaival kívántunk foglalkozni, ezért az OPEN-R SDK [24] megfelelőbb választásnak tűnt. Az OPEN-R SDK a Linux operációs rendszer alatt használható, azonban elérhető egy Cygwin (Windows-on futó Linux-os környezet) alapú változat is. A RoboCup-ban néhány csapat a Cygwin-es változatot használja, azonban a Linuxos megoldás jóval elterjedtebb és sok tekintettben jobban használható, így erre esett a választás. A Linux-on KDE, illetve GNOME grafikus felület futott. IDE (Integrated Development Environment) felhasználására kezdetben nem került sor, azonban a fejlesztés nehézkessége miatt a későbbiekben a KDeveloper nevű grafikus, C++ nyelvet támogató, IDE került felhasználásra, mely beváltotta a hozzáfűzött reményeket. Sajnos a hibakeresés része az IDE-nek nem használható, azonban ez nem a KDeveloper hiányossága. Ugyanis a KDeveloper a Linux alatti szabványos debugger programot a GDB-t használja, azonban az OPEN-R SDK ezt nem támogatja, illetve semmilyen más nyilvánosan elérhető debuggert sem. Ez a tény nagymértékben megnehezítette a fejlesztést. A Tekkotsu sem támogat egyetlen 28
debuggert sem, mivel az OPEN-R SDK-ra épül. Az OPEN-R SDK a hibakereséshez alapvetően két eszközt biztosít. Egyrészt rendelkezésre áll az OPEN-R programkönyvtárban egy, a C nyelv printf függvényének megfelelő függvény, aminek segítségével értékeket lehet kiíratni az ún. Wireless Consolra. A Wireless Console az AIBO IP címének 59000-es TCP portján érhető el, a telnet protokoll segítségével, és egy szöveges ki/be viteli felületet biztosít. Továbbá rendelkezésre áll az AIBO operációs rendszerének, az Aperios-nak azon szolgáltatása, mely a processzor kivétele esetén egy naplófájlt hoz létre a memóriakártyán, majd kikapcsolja az AIBO-t. Ezen naplófájl processzor, illetve operációsrendszer szintű adatokat tartalmaz. Ennek elemzésének megkönnyítésére az OPEN-R SDK biztosít egy segédprogramot, amely képes megmondani, hogy melyik program (az Aperios terminológiája szerint objektum) futása közben történt a kivétel, illetve melyik címen. Ezen adatok birtokában lehetőség van a program bináris kódjában, a kód visszafejtésével megkeresni a hibás gépi kódú utasítást. A hibás utasítás ismeretében már viszonylag könnyen megtalálható, hogy a forráskód melyik sorában keletkezett a hiba, annak okáról azonban, az esetek többségében, nem nyújt pontos tájékoztatást.
5.2. Fejlesztés az OPEN-R SDK-val Az AIBO operációs rendszerében minden program megfelel egy C++ objektumnak. Feltehetően emiatt, az AIBO-n futó programokat a Sony terminológiájában objektumoknak (továbbiakban Aperios objektum) hívják. Az Aperios objektumok konkurensen, egymással párhuzamosan futnak. Minden Aperios objektumnak több belépési pontja van, ellentétben a hagyományos C++ programokkal szemben, amelyeknek csak egy, a main nevű. Ennek illusztrálására a következő programkód szolgál: first.h #include #include #include #include
"OPENR/OObject.h" "OPENR/OSubject.h" "OPENR/OObserver.h" "def.h"
class first : public OObject { public: first(); virtual ~ first() {}; OSubject* subject[numOfSubject]; OObserver* observer[numOfObserver]; virtual virtual virtual virtual };
OStatus OStatus OStatus OStatus
DoInit(const OSystemEvent&); DoStart(const OSystemEvent&); DoStop(const OSystemEvent&); DoDestroy(const OSystemEvent&);
A programkódban a first nevű osztály alapján (futás közben, az Aperios által) létrehozott objektum felel meg a programnak, az Aperios objektumnak. A first kötelezően a OObject nevű osztályból kell, hogy származzon, és a következő négy tagfüggvénnyel kell, hogy rendelkezzen: DoInit, DoStart, DoStop, DoDestroy [22]. Ezek a függvények a belépési pontok, a program futása ezen függvények, Aperios által történő meghívásával indul, illetve végződik. A DoInit és a DoStart a program futásának kezdetén, a DoStop és a DoDestroy pedig futásának végén hívódik meg.
29
Ezeket a függvényeket minden esetben implementálni kell, minden Aperios objektumban. Továbbá létezik még egy belépési pont, a Prologue, melynek feladata a névtérbeli és statikus változók iniciálása, illetve a konstruktor meghívása. A Prologue létrehozásáról és implementálásáról a fordítóprogram gondoskodik. Az Aperios objektumok az Inter Process Communication (IPC) segítségével tudnak egymással kommunikálni, egy szabványos felületen, amit az Aperios biztosít. A kommunikáció előtt, le kell írni a kommunikáció felületét. Meg kell adni minden Aperios objektum esetén, hogy adatot küld –e, vagy fogad, milyen formátumú adatot kezel, illetve az Aperios objektum, mely függvényei kezelik a kommunikációt. Az Aperios objektum adatot küldő interfészét subject-nek, a fogadót observer-nek hívják. Egy Aperios objektumnak egyszerre lehet több subject, illetve observer interfésze. Az egyszerűség kedvéért, most tegyük fel, hogy két objektum kommunikál egymással, és mindkettőnek csak egy interfésze van, az egyiknek subject, a másiknak observer. Ekkor a kommunikáció a következő módon zajlik: a subject Aperios objektum átmásolja egy közös memóriaterületre (a megosztott memóriába) a küldendő adatot, majd a subjecthez csatlakozó observert egy függvény meghívásával értesíti, hogy új adat érkezett a számára. A observer objektum rendelkezik egy tagfüggvénnyel, ami egyben egy belépési pont is, mely meghívódik akkor, ha üzenet érkezett a számára. Ebben a függvényben felhasználhatja, vagy saját területére másolhatja a számára küldött adatot, majd ha végzett, egy függvény meghívásával értesíti a subjectet, hogy újabb adat fogadására kész. A kommunikáció felületét a stub.cfg nevű fájlban kell leírni. Itt kell megadni, hogy mi azoknak a fentebb említett tagfüggvényeknek a neve, amelyek a kommunikációt vezérlik. Azt pedig, hogy melyik Aperios objektum, melyik interfésze, melyik másik Aperios objektum melyik interfészével kommunikál, szintén egy fájlban, a CONNECT.CFG-ban kell megadni. Mivel minden Aperios objektum kommunikációs felülete előre definiált, ezért lehetőség van kicserélni vagy megváltoztatni egy objektumot, ha a kommunikációs felületét változatlanul hagyjuk, anélkül, hogy a többi objektumot újra kéne fordítani. Szintén nem igényel újrafordítást az sem, ha azt akarjuk megváltoztatni, hogy ki-kivel kommunikál, mindaddig, amíg a kommunikáló interfészek adatformátuma megegyezik. A programfejlesztés lépései az OPEN-R SDK esetén a következők: 1. 2. 3. 4. 5. 6. 7. 8. 9.
Aperios objektumok megtervezése, a feladat felbontása Objektumok közötti kommunikáció megtervezése Az objektum kommunikációs felületét leíró stub.cfg elkészítése Rendszer vázának elkészítése Aperios objektumok implementálása .OCF fájl elkészítése Fordítás (amíg már nincs több szintaktikai hiba) Rendszerbeállításokat tartalmazó fájlok szerkesztése A lefordított objektumok, rendszerbeállítások, és az OPEN-R futtató környezet felmásolása a memória kártyára 10. Szoftver futtatása az AIBO-ban 11. Hiba esetén a kivétel fájl elemzése, illetve a konzolon megjelenő üzenetek elemzése 12. Hiba esetén a hibás Aperios objektum forráskódjának módosítása, majd vissza a 6. pontra A 4. pont során kell létrehozni az Aperios objektumok osztályait, esetleg egyéb osztályokat, illetve a Makefile-okat (a fordítás mikéntjét leíró fájlokat). A 6. pontban
30
szereplő OCF kiterjesztésű fájl, minden Aperios objektumhoz el kell készíteni. Ez tartalmazza a verem (stack) és kupac (heap) méretét. A verem mérete futás közben nem változtatható, tehát az értékét elég nagyra kell megadni, míg a kupac, futás során dinamikusan növekedhet, vagy csökkenhet, azonban ez igen erőforrás igényes művelet. Ezért a kupac méretének a megbecslésére is célszerű egy kis idő fordítani. A 8. pontban szereplő rendszer beállításokat tartalmazó fájlok a következők: CONNECT.CFG, OBJECT.CFG, DESIGNDB.CFG. A CONNECT.CFG-ról már esett szó. Az OBJECT.CFG tartalmazza az Aperios által betöltendő és futtatandó objektumok (programok) listáját és azok elérési helyét. A DESIGNDB.CFG egy opcionális fájl, és azoknak a fájloknak a nevét tartalmazhatja, amelyeket egy azonosítóval lehet betölteni a memóriába futás során. A 10. pontban írt futatás minden esetben úgy történik, hogy be kell helyezni a memóriakártyát az AIBO-ba, el kell indítani és megvárni, míg betöltődik (bebootol) az operációs rendszer, és a többi Aperios objektum. Majd ki kell kapcsolni az AIBO-t, ha lefutott a program, és kivenni a kártyát, és visszahelyezni a PC-ben lévő kártyaolvasóba. Sajnos ez egy elég hosszadalmas, és nehézkes feladat, különösen azért, mert az AIBO szoftverinek betöltése sok idő vesz igénybe. Ezen hosszú várakozás különösen a hibakeresés során nehezíti meg fejlesztő dolgát. Létezik egy alternatív megoldás is, ahol egy FTP szervert megvalósító Aperios objektumot is felmásolnak a memóriakártyára. A FTP szerver segítségével fel lehet másolni a szükséges fájlokat a memóriakártyára, annak eltávolítása nélkül. Azonban ennek a módszernek hátránya, hogy a felmásolás után ugyanúgy újra kell indítani az AIBO-t, mint a hagyományos módszernél, továbbá hiba esetén az FTP szerver is le szokott fagyni, nem csak a hibás program. Szintén a módszer ellen szól, hogy a hálózati kártya nem túl gyors, illetve az AIBO lassabban írja a memóriakártyát, mint a PC-s kártyaolvasó.
5.3. A mozgás alrendszer A mozgás alrendszer a rendszertervnek megfelelően statikus mozgás leírást használ. A statikus leírás miatt szükség van a mozgások előre történő elkészítésére, és egy lejátszó programra, ami képes visszajátszani a mozgásokat. 5.3.1. A mozgások létrehozása
A robotfutballhoz minimálisan a következő mozgásokra kell képesnek lennie a robotnak: előre haladásra (lépés), fordulásra, rúgásra, illetve képesnek kell lennie felállni (bekapcsoláskor), illetve lefeküdni (kikapcsoláskor). A lefekvésre azért van szükség, mert a robot kikapcsolásakor a robot izületeit adott pozícióban tartó motor áramellátása megszűnik, és így a robot könnyen összeeshet. Az felsorolt mozgásokon kívül célszerű, ha a robot képes hátrafele menni, mindkét irányba is fordulni, illetve többféle rúgást is ismer. A felsorolt mozgások leírásához szükséges egy függvény, ami az idő függvényében megadja az izületek szögét, minden mozgás esetén. Ezen függvény tárolására egy fájlban kerül sor, a mozgás fájlban. E fájl formátuma azonban sokféle lehet. A RoboCup szoftverek gyakran saját formátumot használnak. Létezik azonban a Sony-nak is egy formátuma, a MTN formátum, amit a Sony szoftverei és még néhány szabadon elérhető szoftver is használ. Ez a formátum elég általános, ugyanakkor a robotfutballhoz is jól illeszkedik, ezért az implementáció során ez került felhasználásra.
31
5.3.1.1. A MTN fájl formátum Megjegyzés: A MTN fájl formátum specifikációja megtalálható az OPEN-R SDK-ban, a mintaprogramok között.
Egy MTN fájl alapvetően egy header és egy adat részből áll. A header írja le többek között a mozgás nevét, a fájl készítőjét, azt, hogy milyen AIBO típushoz készült a mozgás, illetve, hogy az izületek, mely részhalmazára nézve tartalmaz adatokat. Az idő leírására az ún. frame-eket használja. Egy frame-nek 8 ms felel meg. A frame-ek használatának oka, az AIBO hardverében és operációs rendszerében keresendő, azonban elég annyit tudni róla, hogy az AIBO a szenzorok adatai 4 frame-ként tudja elküldeni, 1 frame-ként lehet parancsokat küldeni neki. A MTN fájl az izületi szögek – idő függvényt tömörítve tárolja. Ez a tömörítés úgy történik, hogy a függvény értéke csak bizonyos pontokban, a kulcskockákban tárolódik, és a köztes pontokban lineáris interpoláció történik, aminek a végrehajtása a lejátszó program feladata. Az adatrészben kerülnek egymás után eltárolásra a kulcskockák, illetve a kulcskockákban az izületek szögei (a header-ben meghatározott sorrend szerint). Minden kulcskockában eltárolásra kerül az is, hogy a következő kulcskocka, hány frame-nyi távolságra van az aktuálistól. 5.3.1.2. Skitter A Skitter [23] az Internetről ingyenes letölthető és felhasználható, többek között MTN fájlok szerkesztésére és létrehozására alkalmas program.
5.1. ábra Skitter, MTN fájl szerkesztő program
A programmal létre lehet kulcskockákat hozni, és azoknál megadni az izületek szögét. Képes kirajzolni az idő – izületi szög függvényt, amit drag and drop módszerrel is lehet szerkeszteni. De talán a legfontosabb tulajdonsága, hogy rendelkezik az összes AIBO-ról háromdimenziós modellel, és ezen a modellen vissza tudja játszani a mozgást. A program jól használható a MTN fájlokban lévő kisebb hibák javítására, több fájl összeszerkesztésére, illetve egyes részek kivágására. Egyszerűbb mozgások is jól létrehozhatóak vele. Azonban olyan mozgások esetén, ahol a robot nincs minden pillanatban teljesen stabil, egyensúlyi helyzetben, nem használható. Ilyen mozgás a lépés is. A szakdolgozat szerzője jelentősebb időt töltött el azzal, hogy megpróbáljon létrehozni egy olyan mozgást, ami a robotot jobbra fordítja. Ezek a kísérletek kudarcot vallottak. A robot egyik lábának a felemelésénél már megakadt a szerző, a robot állandóan eldőlt. Ennek oka, hogy a szoftver nem szimulálja a gravitációt, ezért
32
ami a programban működőképes mozgásnak tűnik, az a valóságban kipróbálva egyáltalán nem az. 5.3.1.3. A getpose segédprogram A Skitter nehézkessége miatt került megalkotásra a getpose segédprogram, ami eredetileg csak arra szolgált, hogy a robot izületeinek szögét egy szoftverből le lehessen kérdezni egy AIBO-n lévő gomb megnyomásával. Az eredeti cél az volt, hogy a robot végtagjainak kézzel történő mozgatásával, a robotot adott pózba állítva, le lehessen kérni az izületek szögét. Az egyszerre lekért szögeket egy kulcskockának tekintve – a kulcskockák közti időbeli távolság megadásával – a kulcskockák egymásutánjai egy mozgást definiálnak. Ezáltal különféle mozgásokat lehet létrehozni. Később a program továbbfejlesztésre került. Az elkészült program képes az összes szenzor adatainak a folyamatos naplózására, és a memóriakártyára mentésére. Ezen ún. szenzor napló számos dologra használható. Például lehetőség van gyorsulás érzékelők adatainak, az AIBO mozgásával történő összevetésére is. Azonban az elsődlegeses arra való, hogy egy átalakító program segítségével mozgásokat lehessen létrehozni belőle. A következő fejezet erről az átalakító programról szól. 5.3.1.4. A c2mtn átalakító segédprogram A szenzor naplók elemzéséhez elkészült egy egyszerű listázó program (parser), majd egy jóval bonyolultabb átalakító program (c2mtn). Ezen átalakító program képes arra, hogy egy szenzor napló fájlból, az izületek szögét érzékelő szenzorok egy részhalmazát kiválasztva, azok adatait tömörítse és MTN fájl formátumba konvertálja. A program a szenzor napló alapján automatikusan megkeresi és létrehozza a kulcskockákat, és azokban a pontokban lementi az izületek szögét. Ez azért különösen hasznos, mert a getpose és a c2mtn segítségével az AIBO bármilyen kézzel történő mozgatása közvetlenül lementhető MTN fájl formátumba, és az betölthető és szerkeszthető a Skitter segítségével. Továbbá számos Sony szoftver is képes a MTN fájlok visszajátszására az AIBO-n. Ezen módszer előnye, hogy ha nem akarjuk a teljes MTN fájlt felhasználni, akkor lehetőségünk van arra, hogy csak bizonyos kulcskockákat használjunk a fájlból és a köztes frame-eket lineáris interpolációval határozzuk meg, amit megtehetünk pl. a Skitter segítségével. Összefoglalva tehát a Skitter, a getpose és c2mtn segítésével könnyen létrehozhatunk bármely olyan mozgást, amely során az AIBO-t kézzel mozgatjuk, mintha egy bábú lenne, illetve olyanokat, amelyeknél az izületi szögek – idő függvényt kézzel, kulcskockánként definiáljuk. 5.3.1.5. A mtntool segédprogram A MTN fájlok kezelésére készült még egy segédprogram, a mtntool. Ennek segítségével módosítani lehet a MTN fájlok szerzőjét és nevét. Ezen utóbbinak azért van nagyobb jelentősége, mivel a Sony lejátszó programjai a név felhasználásával biztosítják, hogy az egymás után lejátszott MTN fájlok határán nincs hirtelen ugrás az izületi szögekben. Erről még későbbiekben szó lesz, itt elegendő annyi, hogy ennek az átnevezésének képessége egy apró, ugyanakkor mégiscsak fontos képesség a mozgások létrehozáshoz. A program kifejlesztését is ezen képesség szükségessége indokolta. A program még képes arra is, hogy a bemeneti MTN fájlban felhasznált
33
izületek csak egy részhalmazát mentse le a kimeneti MTN fájlba. A mtntool bár egy elég egyszerű program, az általa biztosított funkcionalitás más, az Interneten elérhető – és a szakdolgozat szerzője által kipróbált – segédprogramokban nem volt megtalálható. 5.3.1.6. Létrehozott mozgások Sajnos a fejlesztés során derült csak ki, hogy a haladó mozgások kézzel gyakorlatilag nem hozhatóak létre. A tapasztalatok alapján, haladó mozgás egyedül a robot matematikai modellezésével és inverz kinematika segítségével hozható létre. Ennek oka a már említett egyensúlyi probléma. Ahhoz, hogy a robot ne boruljon fel biztosítani kell, hogy a tömegközéppontjának talajra eső vetülete minden pillanatban a kívánt helyre (a robot lábai közötti területen belülre) essen. A mozgás kézzel történő megadása esetén, még azon probléma megoldása is igen nehéz, hogy a robot négy lábából egyet felemeljen. Emiatt végül az OPEN-R SDK-hez biztosított néhány minta mozgás került felhasználásra a mozgás alrendszerhez. Ezek a következők: • • • • • •
előre lépés (a_walk#walk_fwd.mtn) hátra lépés (a_walk#walk_bwd.mtn) álló állapotból, lépés állapotba való átmenet (a_stand#walk_standard.mtn) lépés állapotból, álló állapotba való átmenet (a_walk#stand_standard.mtn) felállás (a_sleep#stand_standard.mtn) lefekvés (a_stand#sleep_standard.mtn)
Ezen utóbbi kettő könnyen létrehozható lenne kézzel is, azonban mivel rendelkezésre állt és megfelelő volt, felhasználásra került. A fordulások azonban nem álltak rendelkezésre. Ezekre a mozgásokra végül csak úgy sikerült szert tenni, hogy a getpose segédprogram segítségével, a Sony egyik programjának futtatása közben lementésre kerültek a mozgások, majd a Skitter programmal a megfelelő részek kivágásra és szerkesztésre kerültek. Ezek a következő mozgások: • •
jobbra fordulás (a_stand#stand_turnright.mtn) balra fordulás (a_stand#stand_turnleft.mtn)
A rúgások létrehozhatók a getpose, c2mtn és skitter programok segítségével, bár csak igen sok munkával. Ez különösen arra az esetre vonatkozik, amikor a rúgás az egyik láb felemelésével történik. A mozgás alrendszerhez kézzel létre lett hozva egy rúgásfajta. Ez nem az AIBO lábaival, hanem a fejével történik. Ennek neve a következő: •
fejjel történő rúgás (a_stand#stand_headkick.mtn)
A mozgások, összesen 9 MTN fájl, a könnyebb kezelhetőség miatt egyetlen fájlban, a MOTION.ODA-ban kerülnek letárolásra. Ezen fájl formátuma, a Sony által definiált ODA formátum. Ezen ODA fájl felfogható egy adatbázisnak, ami megkönnyíti a benne tárolt fájlok elérését és betöltését a memóriába. Az ODA fájlok létrehozására és kezelésére az OPEN-R SDK biztosít egy segédprogramot, amely felhasználásra is került.
34
5.3.2. A mozgások lejátszása
A mozgások lejátszására az eredeti tervekkel ellentétben végül nem készült saját fejlesztésű szoftver, hanem az OPEN-R SDK egyik mintaprogramja, a MoNet került felhasználásra, és egy kisebb mértékű módosításra. A MoNet forráskódja szabadon elérhető, felhasználható és módosítható nem üzleti célú felhasználásra. Sajnos azonban nincs dokumentálva a forráskód, illetve egyéb dokumentáció sincs hozzá. Azonban alaposabb tanulmányozás után kiderült, hogy alkalmas mozgás alrendszernek, néhány apróbb módosítással. Amivel mindenképpen ki kell még egészíteni az egy odometria modul. Ezt leszámítva viszont teljesen megfelelő. Statikus mozgás leírást alkalmaz és a MTN fájl formátumot használja. A mozgásokat a MOTION.ODA fájlból veszi és a MONETCMD.CFG fájl írja le, hogy milyen mozgás parancshoz, melyik MTN fájl tartozik. A parancsokat (ami egyszerűen egy szám) a „MoNet.ClientCommand.MoNetCommand.O” observer-nek kell küldeni. A parancs végrehajtásának eredményét a „MoNet.ClientResult.MoNetResult.S” subject küldi el. A MoNet maga tárolja a robot aktuális pózát, és ha olyan parancsot kap, amelynek kiinduló póza, nem egyezik meg a vele, akkor automatikusan megkeresi és végrehajtja azokat a mozgásokat is, amelyeknek eredményeképp a robot a kívánt pózba kerül. Ez funkcionalitás a következőképpen működik. Minden mozgás neve szabványos formátumú. A név tartalmazza a mozgás során a robot kiinduló pózát (állapotát), befejező pózát és a mozgás megnevezését. A formátum a következő: kezdőpóz#befejezőpóz_megnevezés. A MoNet ezekből az adatokból felépít egy irányított gráfot. A gráf csúcsai a pózok, a csúcsokat pedig akkor köti össze él, ha létezik olyan mozgás, ami a kiinduló csúcs pózából, a beérkező csúcs pózába vezet. Az élek is el vannak nevezve, a mozgás nevének megfelelően. Amikor a MoNet parancsot kap egy mozgás végrehajtására, akkor megvizsgálja, hogy a robot aktuális póza megegyezik –e a végrehajtandó parancs kiindulási pózával. Ha igen végrehajtja, ha nem, akkor a robot aktuális pózának megfelelő gráf csúcsból, keres egy minimális hosszúságú utat, a parancs kiindulási pózának megfelelő gráf csúcsba. Majd az élek nevének megfelelő mozgásokat végrehajtja, így már a kívánt kiinduló pózba került a robot. Ezután pedig végre lehet hajtani a kiadott parancsot is.
6. Eredmények A szakdolgozat készítése során sikerült megismerni és feldolgozni az AIBO robotfutballal kapcsolatos irodalom egy jelentősebb részét. A megismert irodalmak alapján megtervezésre került egy egyszerűsített robotfutball szoftver, amely egy későbbi, teljesebb rendszer kifejlesztéséhez alapul szolgálhat. A szakdolgozat során a rendszerterv alapján, annak egy része, a mozgás alrendszer megvalósításra került, apróbb hiányosságokkal. A létrehozott mozgás alrendszer felhasználható más AIBO szoftverekhez is, modularitásának köszönhetően. Továbbfejlesztés tekintetében még számos tennivaló akad. A mozgás alrendszer kiegészítése az odometriával mindenképpen célszerű és nem igényel sok fejlesztést. Ezáltal a rendszertervnek hiánytalanul megfelelő mozgás alrendszer jönne létre. Nagyobb távlatokban a rendszerterv többi alrendszerének implementálása kívánatos, amely elvezetne egy teljes egészében működőképes robotfutball szoftverhez.
35
Ábrajegyzék [3.1. ábra] Az AIBO korai prototípusainak egyike From engineering dream to robotic pet: the AIBO story Web: http://www.aibo-europe.com/downloads/AIBO_Story.pdf Utolsó hozzáférés: 2005-05-15 [3.2.a. ábra] MUTANT Masahiro Fujita, Hiroaki Kitano (1998). Development of an Autonomous Quadruped Robot for Robot Entertainment. Autonomous Robots 5: 7-18. [3.2.b. ábra] AIBO prototípus Masahiro Fujita, Manuela Veloso,William Uther et al. (2000). Vision, Strategy, and Localization Using the Sony Legged Robots at RoboCup-98. AI Magazine 21(1): 47-56. Web: http://www.aaai.org/Library/Magazine/Vol21/21-01/Papers/AIMag21-01-009.pdf Utolsó hozzáférés: 2005-05-15 [3.3. ábra] Az ERS-110-es, az első AIBO és egyben az első kereskedelemben kapható szórakoztató célú robot Sony Press Release Web: http://www.sony.net/SonyInfo/News/Press/199905/99-046/index.html Utolsó hozzáférés: 2005-05-15 [3.4.a. ábra] ERS-210 From engineering dream to robotic pet: the AIBO story Web: http://www.aibo-europe.com/downloads/AIBO_Story.pdf Utolsó hozzáférés: 2005-05-15 [3.4.b. ábra] ERS-311 és ERS-312 From engineering dream to robotic pet: the AIBO story Web: http://www.aibo-europe.com/downloads/AIBO_Story.pdf Utolsó hozzáférés: 2005-05-15 [3.4.c. ábra] ERS-220 (Google internetes kereső által) Web: http://www.watch.impress.co.jp/game/docs/20011108/aibo01.jpg Utolsó hozzáférés: 2005-05-15 [3.5. ábra] ERS-7, a legújabb generáció Sony AIBO USA honlapja Web: http://www.sonystyle.com/intershoproot/eCS/Store/en/imagesProducts/ProductTour/computing/ ers7/images/tour01.jpg Utolsó hozzáférés: 2005-05-15 [3.6.a. ábra] ERS-210A oldalról (műszaki rajz) [3.6.b. ábra] ERS-210A szemből (műszaki rajz) [3.6.c. ábra] ERS-210A felülről (műszaki rajz) [3.7. ábra] ERS-210A központi egysége és a hozzá kapcsolódó részegységek Sony OPEN-R SDK, Model Information for ERS-210 Web: http://openr.aibo.com/ Utolsó hozzáférés: 2005-05-15 [3.8.a. ábra] A központi egység elől nézetből [3.8.b. ábra] A központi egység oldal nézetből [3.8.c. ábra] A központi egység hátul és alul nézetből Saját fénykép
36
[3.9. ábra] A feji részegység [3.10. ábra] Feji részegség izületeinek szélső helyzetei (mértékegység: fok) [3.11. ábra] A láb részegység [3.12. ábra] A láb részegység izületeinek szélső helyzetei (mértékegység: fok) [3.13. ábra] A farok izületeinek szélső helyzetei (mértékegység: fok) Sony OPEN-R SDK, Model Information for ERS-210 Web: http://openr.aibo.com/ Utolsó hozzáférés: 2005-05-15 [3.14. ábra] Kisméretű ligában résztvevő robotok (CMU CM-Dragons) Carnegie Mellon University, CORAL Research, Robot Soccer Page (http://www-2.cs.cmu.edu/~robosoccer) Web: http://www-2.cs.cmu.edu/~robosoccer/image-gallery/small/2003/label-cmdragons02.jpg Utolsó hozzáférés: 2005-05-15 [3.15. ábra] Közepes méretű robotok játék közben (2004-es RoboCup, Portugália) RoboCup 2004, Portugália (http://www.robocup2004.pt) Web: http://www.robocup2004.pt/photosAndVideos/soccer/IMG_2236.htm Utolsó hozzáférés: 2005-05-15 [3.16. ábra] Humanoid robot (2004-es RoboCup, Portugália) RoboCup 2004, Portugália (http://www.robocup2004.pt) Web: http://www.robocup2004.pt/photosAndVideos/humanoid/P7300011.htm Utolsó hozzáférés: 2005-05-15 [3.17. ábra] A négylábú ligában használt pálya (2004-es RoboCup, Portugália) RoboCup Technical Committee: Sony Four Legged Robot Football League Rule Book (2004). Web: http://www.tzi.de/~roefer/Rules2004/figs/field_diagram.png Utolsó hozzáférés: 2005-05-15 [3.18. ábra] A négylábú ligában, a játék során a robotok lehetséges állapotai és az azok közti átmenetek RoboCup Technical Committee: Sony Four Legged Robot Football League Rule Book (2004). Web: http://www.tzi.de/~roefer/Rules2004/figs/states.pdf Utolsó hozzáférés: 2005-05-15 [4.1.a. ábra] RoboCup futballpálya képe [4.1.b. ábra] 4.1.a. ábrán végrehajtott szín alapú osztályozás eredménye James Bruce. CMVision library. Web: http://www-2.cs.cmu.edu/~jbruce/cmvision/ Utolsó hozzáférés: 2005-05-15 [4.2. ábra] Régióegyesítés szemléltetése Saját kép. [4.3. ábra] Objektum kamerától való távolságának meghatározása, a mérete (pl.: magassága) alapján, egyszerű aránypárral [4.4.ábra] Objektum robottól való távolságának meghatározása Scott Lenser, Manuela Veloso (2003). CMPack – High Level Vision. Web: http://www-2.cs.cmu.edu/~robosoccer/cmrobobits/lectures/vision-high-level.pdf Utolsó hozzáférés: 2005-05-15 [5.1. ábra] Skitter, MTN fájl szerkesztő program Saját kép, a Skitter programról futás közben
37
Irodalomjegyzék [1] Sony Corporation. From engineering dream to robotic pet: the AIBO story Web: http://www.aibo-europe.com/downloads/AIBO_Story.pdf Utolsó hozzáférés: 2005-05-15 [2] Masahiro Fujita, Koji Kageyama. (1997). An Open Architecture for Robot Entertainment. In Proceedings of the First International Conference on Autonomous Agents. ACM Press. 435-442. [3] Masahiro Fujita, Hiroaki Kitano. (1998). Development of an Autonomous Quadruped Robot for Robot Entertainment. Autonomous Robots, 5(1): 7-18. [4] Sony Corporation. AIBO Software Development Enviroment Web: http://openr.aibo.com Utolsó hozzáférés: 2005-05-16 [5] Tekkotsu Homepage Web: http://www.tekkotsu.org Utolsó hozzáférés: 2005-05-16 [6] AiboPet. RCodePlus: AiboPet R-CODE Extensions Web: http://www.aibopet.com/rcode Utolsó hozzáférés: 2005-05-16 [7] The RoboCup Federation. RoboCup Official Site Web: http://www.robocup.org Utolsó hozzáférés: 2005-05-16 [8] RoboCup Small-size League Technical Committee. (2005). Laws of the F180 League 2005a Web: http://www.itee.uq.edu.au/~dball/f180rules2005a.pdf Utolsó hozzáférés: 2005-05-16 [9] RoboCup Middle-size League Technical Committee. (2004). Middle Size Robot League Rules and Regulations for 2004. Web: http://www.er.ams.eng.osaka-u.ac.jp/rc2004msl/index.cgi Utolsó hozzáférés: 2005-05-16 [10] RoboCup Humaniod League Technical Committee. (2003). RoboCup Humanoid League 2003 Rules Web: http://www.ais.fraunhofer.de/robocup/HL2004/rule_humanoid.html Utolsó hozzáférés: 2005-05-16 [11] Legged League Committees. Sony Four-Legged Robot League Website Web: http://www.openr.org/robocup Utolsó hozzáférés: 2005-05-16 [12] RoboCup Technical Committee. (2005). Sony Four Legged Robot Football League Rule Book Web: http://www.tzi.de/4legged/pub/Website/History/Rules2005.pdf Utolsó hozzáférés: 2005-05-16 [13] RoboCup Technical Committee. (2005). Technical Challenges for the RoboCup 2005 Legged League Competition Web: http://www.tzi.de/4legged/pub/Website/Downloads/Challenges2005.pdf Utolsó hozzáférés: 2005-05-16
38
[14] James Bruce, Tucker Balch, Manuela Veloso. (2000). Fast and Inexpensive Color Image Segmentation for Interactive Robots. In Proceedings of IROS-2000. [15] Thomas Röfer, Ingo Dahm, Uwe Düffert, Jan Hoffman et al. (2004). GermanTeam 2003. 7th International Workshop on RoboCup 2003 (Robot World Cup Soccer Games and Conferences). Lecture Notes in Artificial Intelligence. Springer. [16] Röfer, T., Jüngel, M. (2004). Fast and robust edge-based localization in the Sony four-legged robot league.7th International Workshop on RoboCup 2003 (Robot World Cup Soccer Games and Conferences). Lecture Notes in Artificial Intelligence. Springer. [17] Manuela Veloso, Nick Aiwazian, Sonia Chernova. (2003). CMRoboBits: Actuators, Motion. Web: http://www-2.cs.cmu.edu/~robosoccer/cmrobobits/lectures/Motion.ppt Utolsó hozzáférés: 2005-05-16 [18] Dahm, I., Ziegler, J. (2003). Adaptive Methods to Improve Self-Localization in Robot Soccer. RoboCup 2002: Robot Soccer World Cup VI. Lecture Notes in Artificial Intelligence. Springer. 393408. [19] Scott Lenser, Manuela Veloso. (2003). Localization. Web: http://www-2.cs.cmu.edu/~robosoccer/cmrobobits/lectures/loc_lec.pdf Utolsó hozzáférés: 2005-05-16 [20] Paul E. Rybski. (2003). Mobile Robot Localization and Mapping using the Kalman Filter Web: http://www-2.cs.cmu.edu/~robosoccer/cmrobobits/lectures/Kalman.ppt Utolsó hozzáférés: 2005-05-16 [21] D. Fox, W. Burgard, S. Thrun. (1999). Markov localization for reliable robot navigation and people detection. Modeling and Planning for Sensor-Based Intelligent Robot Systems. Springer Verlag. [22] Sony Corporation. (2004). OPEN-R SDK Programmer’s Guide. Web: http://openr.aibo.com Utolsó hozzáférés: 2005-05-16 [23] DogsBody & Ratchet Software. Skitter (Version 2.60). Web: http://www.dogsbodynet.com/skitter.html Utolsó hozzáférés: 2005-05-16 [24] Sony Corporation. OPEN-R SDK. Web: http://openr.aibo.com Utolsó hozzáférés: 2005-05-16
39
