Katedra informatiky
Microsoft Robotics Developer
Studio - modelov ´an´ı ´
uloh
Microsoft Robotics Studio
-Modeling of Chosen Problems
robota LEGO NXT. Zab ´yv´ame se multiplatformn´ım Microsoft Robotics Developer Studio 2008 a s n´ım spojen ´ym Visual Programming Language, ve kter´em vznikaly ´ulohy popsa-n´e v t´eto pr´aci. Nˇekter´e z ´uloh byly tak´e modelov´any v simul´atoru robot ˚u Visual Simu-lation Environment. V teoretick´e ˇc´asti je pops´ana z´akladn´ı struktura platformy, princip sluˇzeb, tvorba a pr´ace se sluˇzbami ve Visual Programming Language.
Praktick´a ˇc´ast se zamˇeˇruje na implementaci nˇekolika modelov ´ych ´uloh, kter´e byly urˇceny k demonstraci programov´an´ı robot ˚u. ´Ulohy jsou realizov´any na robotovi v re´al-n´em prostˇred´ı, ale i v simul´atoru. Jsou zde pops´any postupy pouˇzit´e k implementaci a popis a ˇreˇsen´ı probl´em ˚u, kter´e se vyskytly v pr ˚ubˇehu programov´an´ı.
Kl´ıˇcov ´a slova: LEGO NXT, Microsoft Robotics Developer Studio, Visual Programming
Language, robot, Visual Simulation Environment, sluˇzba, Decentralized Software Ser-vice, Concurrency and Coordination Runtime
Abstract
This thesis deals with a description of new technologies which are used to program a LEGO NXT robot. It concentrates on the multiplatform Microsoft Robotics Developer Stu-dio 2008 and its Visual Programming Language which was used to implement the tasks described in this thesis. Some of the tasks were simulated in the product part called the Visual Simulation Environment. The basic structure of a platform, the system of services, creation and working with services in the Visual Programming Language are described in the theoretical part of the thesis.
The practical part is focused on the implementation of a few tasks which are intended to show programming robots. Our tasks are implemented not only on a real robot but even in the simulation environment. There are described procedures used for the im-plementation, and a description and a solution of the problems which emerged during programming.
Keywords: LEGO NXT, Microsoft Robotics Developer Studio, Visual Programming
Lan-guage, robot, Visual Simulation Environment, service, Decentralized Software Service, Concurrency and Coordination Runtime
DSS – Decentralized Software Services
DSSP – Decentralized Software Services Protocol HTTP – Hypertext Transfer Protocol
LED – Light-Emitting Diode
LCD – Liquid Crystal Display
MRDS – Microsoft Robotics Developer Studio PC – Personal Computer - poˇc´ıtaˇc
PDA – Personal Digital Assistant - digit´aln´ı asistent
RAM – Random Access Memory
SOAP – Simple Object Access Protocol URI – Unified Resource Identifier
VPL – Visual Programming Language
VSE – Visual Simulation Environment
Obsah
1 Uvod´ 7
2 Microsoft Robotics Developer Studio 9
2.1 Architektura . . . 9
2.2 Concurrency and Coordination Runtime . . . 9
2.3 Decentralized Software Service . . . 10
2.4 DSS uzel . . . 11 2.5 Sluˇzby . . . 11 2.6 Manifest . . . 11 2.7 Simulaˇcn´ı prostˇred´ı . . . 12 3 Robot LEGO NXT 15 3.1 Popis stavebnice . . . 15
3.2 Hardwarov´e komponenty robota NXT . . . 15
3.3 Komunikace s PC . . . 19
3.4 Konstrukce pro ´ulohy . . . 20
4 Visual Programming Language 21 4.1 Popis prostˇred´ı . . . 21
4.2 Princip implementace . . . 21
4.3 Vytvoˇren´ı nov´e aktivity . . . 22
4.4 Kompilace programu do sluˇzby . . . 23
4.5 Omezen´ı . . . 23
5 Modelovan´e ´ulohy 25 5.1 Konfigurace softwaru a hardwaru pˇri implementaci . . . 25
5.2 Popis d´ılˇc´ıch ´uloh . . . 25 5.3 Naklonˇen´a rovina . . . 25 5.4 Pˇrek´aˇzka . . . 27 5.5 J´ızda po ˇc´aˇre . . . 29 6 Labyrint 31 6.1 N´avrh . . . 31 6.2 Postup ˇreˇsen´ı . . . 32 6.3 Implementace a poznatky . . . 33 6.4 Nevyˇreˇsen´e probl´emy . . . 34 7 Z´avˇer 35 8 Literatura 37
Pˇr´ılohy 39
Seznam obr ´azk ˚
u
1 Architektura MRDS [6] . . . 9
2 Architektura CCR [2] . . . 10
3 Visual Simulation Environment . . . 13
4 Status Bar a Playback Bar . . . 13
5 Pravotoˇciv ´y souˇradnicov ´y syst´em VSE [7] . . . 14
6 NXT ˇR´ıd´ıc´ı jednotka a senzory [8] . . . 15
7 Dotykov ´y senzor [9] . . . 16
8 Zvukov ´y senzor [9] . . . 17
9 Ultrazvukov ´y senzor [9] . . . 17
10 Svˇeteln ´y senzor [9] . . . 18
11 Servo motor [9] . . . 18
12 Konstrukce LEGO NXT robota pro modelovan´e ´ulohy . . . 20
13 Prostˇred´ı Visual Programming Language . . . 22
14 VPL - dialog Run . . . 23
15 VPL - Debug and trace zpr´avy . . . 24
16 VPL - nov´a aktivita . . . 24
17 Uloha - Naklonˇen´a rovina . . . .´ 27
Seznam v ´ypis ˚
u zdrojov ´eho k ´
odu
1 Z´akladn´ı manifest v C# . . . 12
2 NaklonenaRovina.manifest.xml . . . 26
3 Pseudok ´od algoritmu sledov´an´ı ˇc´ary . . . 29
1
Uvod
´
Pr´ace se zamˇeˇruje na oblast robotiky. V modern´ı dobˇe je to dynamicky rozv´ıjej´ıc´ı se obor, kter ´y se ˇc´ım d´al v´ıce dost´av´a do povˇedom´ı veˇrejnosti. Automatick´a sekaˇcka na tr´avu, automatick ´y vysavaˇc nebo kuchy ˇnsk ´y robot jsou jasn ´ymi pˇr´ıklady toho, ˇze i roboti maj´ı m´ısto v bˇeˇzn´em ˇzivotˇe. Nicm´enˇe roboty m ˚uˇzeme potkat i v oblastech zdravotnictv´ı pˇri d ˚uleˇzit ´ych chirurgick ´ych operac´ıch, transplantac´ıch apod., kde je potˇreba pˇresnost z´akroku takov´a, kter´e nen´ı ˇclovˇek s´am o sobˇe schopen dos´ahnout. Robotika hraje tak´e v ´yznamnou roli ve vesm´ırn ´ych nebo arm´adn´ıch mis´ıch, kde jsou roboti vys´ıl´ani do ne-prob´adan ´ych nebo nebezpeˇcn ´ych oblast´ı, aby nebyl zbyteˇcnˇe ohroˇzen lidsk ´y ˇzivot.
V pr´aci se zamˇeˇrujeme na jeden z n´astroj ˚u pro programov´an´ı robot ˚u - Microsoft Robotics Developer Studia a jeho grafick ´y n´astroj Visual Programming Language. K prak-tick ´ym ´ukol ˚um a implementaci byl pouˇzit robot LEGO Mindstorms NXT.
Hlavn´ım c´ılem pr´ace je vytvoˇren´ı nˇekolika ´uloh, na kter ´ych je domonstrov´ana pr´ace s robotem a jeho senzory. Vˇetˇsina z nich je ˇreˇsena na robotovi v re´aln´em prostˇred´ı, nicm´enˇe jsme vyuˇzili i moˇznost simul´atoru, kter ´y MRDS nab´ız´ı.
´
Ulohy jsou v z´akladˇe jednoduch´e. Mˇely by jednoduˇse prezentovat pr´aci na modern´ım a aktraktivn´ım robotovi. Mezi navrˇzen´e ´ulohy patˇr´ı vyjet´ı robota na naklonˇenou rovinu, nalezen´ı pˇrek´aˇzky a jej´ı objet´ı, j´ızda po ˇc´aˇre a nalezen´ı nejkratˇs´ı cestu pr ˚uchodu labyrin-tem.
Druh´a kapitola se zab ´yv´a obecn ´ym popisem platformy MRDS, principy a sluˇzbami. Jsou zde vysvˇetleny z´akladn´ı technologie DSS a CCR, funkce sluˇzeb a manifest ˚u. Popisuje tak´e simulaˇcn´ı prostˇred´ı a pr´aci v nˇem.
V tˇret´ı kapitole se pr´ace zamˇeˇruje konkr´etnˇe na popis stavebnice LEGO NXT rob-ota. Jsou zde pˇredvedeny vˇsechny z´akladn´ı senzory, jejich vlastnosti a zp ˚usob pouˇzit´ı. Kapitola vysvˇetluje moˇznosti komunikace robota s jin ´ym robotem nebo poˇc´ıtaˇcem a jej´ı uskal´ı. Jak n´azev LEGO napov´ıd´a, modul robota je moˇzno r ˚uznˇe modifikovat. V z´avˇeru je prezentov´ana z´avˇereˇcn´a konstrukce robota, se kterou se modelov´e ´ulohy realizovaly.
V dalˇs´ı kapitole se sezn´am´ıme s grafick ´ym prostˇred´ım pro programov´an´ı - Visual Programming Language. Jsou zde uk´az´any z´akladn´ı ´ukony, jak toto prostˇred´ı pouˇz´ıvat, popis n´astroje a zp ˚usob jak program zkopilovat do k ´odu C#.
Pˇredposledn´ı ˇc´ast popisuje konkr´etn´ı modelovan´e ´ulohy. Ke kaˇzd´e ´uloze je uveden jej´ı n´avrh, postup, jak ´ym byla ˇreˇsena a n´aslednˇe tak´e probl´emy, se kter ´ymi jsme se setkali. U nˇekter ´ych ´uloh uv´ad´ıme konkr´etn´ı postupy pˇri konfiguraci MRDS a tipy pro pr´aci v nˇem.
Posledn´ı kapitola je vˇenov´ana posledn´ı modelov´e ´uloze - pr ˚uchod robota labyrin-tem. Pr´ace popisuje n´avrh a postup ˇreˇsen´ı. Opˇet se sezn´am´ıme s r ˚uzn ´ymi obt´ıˇzemi, kter´e nastaly pˇri implementaci. T´eto ´uloze byla vˇenov´ana samostatn´a kapitola, nebot’ je postavena na z´akladˇe pˇredch´azej´ıc´ıch ´ukol ˚u. Robot mus´ı projet bludiˇstˇe sestaven´e z ˇcar ve ˇctvercov´e s´ıti, prozkoumat ho a zapsat si vˇsechny moˇzn´e cesty. N´aslednˇe by mˇel naj´ıt nejkratˇs´ı cestu pr ˚uchodem bludiˇstˇe.
2
Microsoft Robotics Developer Studio
2.1 Architektura
MRDS je zaloˇzeno na platformˇe .NET ˇcili vˇetˇsina program ˚u je ps´ana v jazyce C# nebo Visual Basic .NET. S MRDS jste schopni programovat r ˚uzn´e typy robot ˚u pomoc´ı ob-dobn ´ych k ´od ˚u. MRDS obsahuje run-time prostˇred´ı, ve kter´em je moˇzn´e ps´at asynchronn´ı a distribuovan´e aplikace. Komponenty run-time prostˇred´ı jsou Concurrency and Coor-dination Runtime a Decentralized Software Services. Obecn´a architektura je uvedena na obr´azku 1.
MRDS nab´ız´ı tak´e Visual Simulation Environment, ve kter´em m ˚uˇzeme modelovat ve 3D r ˚uzn´e situace s robotem, ikdyˇz ho re´alnˇe jeˇstˇe nevlastn´ıme. VSE plnˇe podporuje fyziku prostˇred´ı, proto je moˇzn´e simulov´at s´ılu, hmotnost, barvu, velikost, svˇetlo a dalˇs´ı prvky re´aln´e situace.
VPL je vizu´aln´ı n´astroj pomoc´ı kter´eho lze programovat roboty a vytv´aˇret sluˇzby pomoc´ı grafick ´ych prvk ˚u na principu drag and drop. Programov´an´ı je n´azornˇejˇs´ı a l´epe se v nˇem lze zorientovat. Vizu´aln´ı program lze zkompilovat jako sluˇzbu do k ´odu MRDS.
Obr´azek 1: Architektura MRDS [6]
2.2 Concurrency and Coordination Runtime
CCR je knihovna na platformˇe .NET a jej´ı tˇr´ıdy a metody jsou k dispozici v ´yvoj´aˇr ˚um, kter ´ym zjednoduˇsuj´ı pr´aci pˇri psan´ı v´ıcevl´aknov ´ych k ´od ˚u. CCR za nˇe ovl´ad´a a ˇr´ıd´ı sou-bˇeh operac´ı, koordinaci a chr´an´ı pˇred asynchronn´ı koliz´ı.
Kdyˇz pˇr´ıjde zpr´ava, je um´ıstˇena do fronty nazvan´e port. Porty jsou fronty zpr´av, kter´e pˇrij´ımaj´ı zpr´avy stejn´eho datov´eho typu. Zpr´ava je v portu dokud ji nezpracuje
tzv. receiver. Kaˇzd ´y segment k ´odu m ˚uˇze bˇeˇzet asynchronnˇe. Programov´an´ı robot ˚u stoj´ı na asynchronn´ıch operac´ıch. Jinak bychom nemohli ovl´adat napˇr´ıklad senzor a z´arove ˇn j´ızdu robota. Asynchronnost umoˇz ˇnuje spouˇstˇet a dokonˇcovat sluˇzby v r ˚uzn ´ych ˇcasech a nez´avisle na sobˇe.
Pokud je tˇreba poˇckat, neˇz se nˇekter´a z operac´ı dokonˇc´ı, pak to ˇr´ıd´ı CCR. Pouˇz´ıv´a k tomu tzv. dispatchery, kter´e rozhoduj´ı o tom, kter ´y segment k ´odu aktu´alnˇe bˇeˇz´ı. M ˚uˇze nastat situace, ˇze je tˇreba vytvoˇrit podm´ınku mezi dvˇema porty. Vytvoˇr´ı se logick ´y v ´yraz jako je Join (ˇcek´a neˇz pˇr´ıjdou vˇsechny vstupn´ı zpr´avy a tvoˇr´ı logick ´y AND) nebo Choice (ˇcek´a na alespo ˇn jednu zpr´avu a tvoˇr´ı logick ´y OR). O vyhodnocen´ı tˇechto podm´ınek se star´a tzv. arbiter. Obr´azek ˇc´ıslo 2 vyobrazuje struˇcn ´y pˇrehled architektury Concurrency and Coordination Runtime.
Obr´azek 2: Architektura CCR [2]
2.3 Decentralized Software Service
DSS je knihovna, kter´a je grafickou nadstavbou pro CCR. Aplikace postaven´a na DSS je sloˇzena z nˇekolika nez´avisl ´ych sluˇzeb, kter´e mohou bˇeˇzet paralelnˇe. DSS je zodpovˇedn´e za ˇr´ızen´ı toku zpr´av mezi sluˇzbami. Naˇc´ıt´a konfiguraci sluˇzeb, kontroluje bezpeˇcnost, ˇr´ıd´ı pˇr´ıstup k lok´aln´ım soubor ˚um a poskytuje uˇzivatelsk´e webov´e rozhran´ı pro v ´yvoj´aˇre pˇres DSS uzel.
Pouˇz´ıv´a sv ˚uj vlastn´ı protokol DSS Protocol. DSSP rozliˇsuje stav a chov´an´ı sluˇzby. Reprezentuje veˇsker ´y pˇr´ıstup ke sluˇzbˇe jako operaci se stavem sluˇzby.
Abychom znali konkr´etn´ı stav sensor ˚u a motor ˚u robota je pro to tˇreba pouˇz´ıt ˇr´ıd´ıc´ı aktivity pro chov´an´ı robota. V dynamick´em prostˇred´ı hraj´ı d ˚uleˇzitou roli asynchronn´ı hl´aˇsen´ı ze sensor ˚u nazvan´e jako notifikace.
DSSP rozˇsiˇruje protokol HTTP a nab´ız´ı modifikovan´e metody pro operace se zpr´ava-mi. Napˇr´ıklad metoda HTTP GET je pˇr´ıstupn´a v cel´em MRDS. Nicm´enˇe abychom mohli pos´ılat zpr´avy mezi r ˚uzn ´ymi sluˇzbami, potˇrebujeme je pos´ılat ve form´atu SOAP.
DSSP tak´e nab´ız´ı nˇekolik pˇridan ´ych operac´ı, kter´e byly vyvinuty pro potˇreby MRDS. Kupˇr´ıkladu podporuje registraci sluˇzby, coˇz HTTP nepodporuje. V MRDS je ˇcast ´ym po-ˇzadavkem ˇcek´an´ı na aktualizaci informac´ı ze sensoru. Toto je ˇreˇseno pr´avˇe registrac´ı sluˇzby k jin´e sluˇzbˇe, ˇc´ımˇz zajist´ıme, ˇze notifikace budou sluˇzbˇe zas´ılany bud’ v pravi-deln ´ych intervalech nebo kdyˇz se hodnota zmˇen´ı.
2.4 DSS uzel
DSS uzel je prostˇred´ı, ve kter´em bˇeˇz´ı vˇsechny sluˇzby. Mus´ı b ´yt spuˇstˇeno jeˇstˇe pˇred t´ım neˇz spust´ıme jakoukoliv sluˇzbu. K DSS uzlu lze pˇristupovat pˇres webov´e rozhran´ı bˇeˇz´ıc´ı na adrese http://localhost:50000. Pˇri vstupu na toto rozhran´ı se setk´ame s poˇzadavkem na pˇrihl´aˇsen´ı, kter´e je shodn´e s t´ım, kter´e m´ate nastaven´e pro Windows.
M ˚uˇzeme zde sledovat vˇsechny bˇeˇz´ıc´ı sluˇzby, debugovac´ı zpr´avy, um´ıstˇen´ı bˇeˇz´ıc´ıch sluˇzeb, informace o vˇsech dispatcherech a jejich front´ach bˇeˇz´ıc´ıch v uzlu a dalˇs´ı informace o aplikaci.
2.5 Sluˇzby
Pomoc´ı sluˇzeb v MRDS ovl´ad´ame sensory, motory a ˇr´ıd´ıc´ı jednotku robota. Jsou to kl´ıˇcov´e komponenty MRDS. Sluˇzba je k ´od, kter ´y je schopen prov´est nˇejakou operaci nad jedn´ım nebo i v´ıce objekty. Jsou pouˇzity ke sbˇeru dat ze sensor ˚u robota, pro jeho ˇr´ızen´ı, komu-nikaci s extern´ımi aplikacemi atp. Robotick´a aplikace se skl´ad´a z mnoha sluˇzeb, kter´e pracuj´ı spoleˇcnˇe se spoleˇcn ´ym c´ılem - ovlad´an´ı robota.
Kaˇzd´a vytvoˇren´a sluˇzba m´a jedineˇcn ´y identifik´ator URI, kter ´y ji reprezentuje v cel´em MRDS. Sluˇzba m ˚uˇze m´ıt svou partnerskou sluˇzbu tak, ˇze si navz´ajem pos´ılaj´ı poˇzadavky a odpovˇedi.
2.6 Manifest
Manifest je XML soubor. Obsahuje seznam sluˇzeb a jejich partnersk ´ych sluˇzeb, kter´e maj´ı b ´yt spuˇstˇeny spoleˇcnˇe. M ˚uˇze v nˇem b ´yt i konfigurace, ale to z´aleˇz´ı na potˇreb´ach sluˇzby. Manifest soubor pouˇz´ıv´a sch´ema, kter´e je definov´ano firmou Microsoft. Z´akladn´ı sadu manifest ˚u pro r ˚uzn´e sluˇzby nab´ız´ı MRDS jiˇz po instalaci. Jsou um´ıstˇeny v C:\users\.. \Microsoft Robotics Dev Studio 2008\samples\Config. Jsou zde tak´e um´ıs-tˇeny konfiguraˇcn´ı manifesty pro hardware robot ˚u - pro senzory, ˇr´ıd´ıc´ı kostku a dalˇs´ı.
Vzor manifestu New.manifest.xml, kter ´y vytvoˇr´ı MRDS automaticky s nov ´ym projek-tem je demonstrov´an ve V ´ypisu ˇc.1. Manifesty lez upravovat pˇr´ımo v XML k ´odu po-moc´ı jak´ehokoliv textov´eho editoru nebo tak´e popo-moc´ı n´astroje v MRDS nazvan´eho DSS Manifest Editor. Ten je n´apadnˇe podobn ´y VPL a lze zde graficky upravovat partnerstv´ı a konfiguraci jednotliv ´ych sluˇzeb aplikace.
<?xml version=”1.0” ?> <Manifest xmlns=”http :// schemas.microsoft.com/xw/2004/10/manifest.html” xmlns:dssp=”http://schemas.microsoft.com/xw/2004/10/dssp.html” > <CreateServiceList> <ServiceRecordType> <dssp:Contract>http://schemas.tempuri.org/2010/03/new.html</dssp:Contract> </ServiceRecordType> </CreateServiceList> </Manifest>
V ´ypis 1: Z´akladn´ı manifest v C#
2.7 Simula ˇcn´ı prostˇred´ı
MRDS nab´ız´ı Visual Simulation Environment - n´astroj pro vytv´aˇren´ı 3D simulac´ı s robo-tem. VSE dodrˇzuje re´aln´e vlastnosti objekt ˚u, vˇcetnˇe hmotnosti, s´ıly, gravitace a vˇetˇsiny fyzik´aln´ıch z´akon ˚u. V ´yhodou simul´atoru je moˇznost pracovat s roboty, modelovat jejich chov´an´ı i v pˇr´ıpadˇe, ˇze ˇz´adn´eho re´aln´eho nevlastn´ıme. Je tak otevˇrena moˇznost v ´yvoje a debugov´an´ı algoritm ˚u na modelu robota. Naopak nev ´yhodou je, ˇze ne vˇsechny senzory a komponenty robot ˚u jsou v simul´atoru jiˇz vytvoˇreny. Ve verzi MRDS 2008 nejsou graficky podpoˇreny vˇsechny senzory pro robota LEGO NXT. Po z´akladn´ı instalaci je k dispozici jen senzor dotyku, ˇr´ıd´ıc´ı kostka a motory. Na obr´azku ˇc. 3 je uk´azka VSE s LEGO robotem NXT.
MRDS pouˇz´ıv´a pro VSE AGEIA PhysX Technology engine [12], kter ´y zajiˇst’uje cel-kovou fyziku simul´atoru. Simul´aˇcn´ı prostˇred´ı je zaloˇzeno na platformˇe Microsoft XNA, kter´a je bˇeˇznˇe pouˇz´ıv´ana pro programov´an´ı her pro Windows.
Ovlad´an´ı simul´atoru je intuitivn´ı. Pohyb pohledu na situaci je pomoc´ı kl´avesnice -p´ısmena Q a E (nahoru a dol ˚u), W a S (pˇribl´ıˇzen´ı a odd´alen´ı), A a D (vlevo a vpravo). Pˇri oznaˇcen´ı entity v nab´ıdce a stisknut´ı CTRL se entita zvyrazn´ı. Toto pom´ah´a pˇri sloˇzitˇejˇs´ıch modelech, kdy jsou objekty sloˇzeny z v´ıce entit a my chceme nastavit vlastnosti jen nˇekter´e z nich.
2.7.1 Status Bar a Playback Bar
V menu View VSE si lze zaˇskrtnout viditelnosti tˇechto dvou panel ˚u. VSE pouˇz´ıv´a pravo-toˇciv ´y souˇradn ´y syst´em (x,y,z) podle obr´azku ˇc.5 k urˇcen´ı pozice objektu.
Status Bar ukazuje aktu´aln´ı pozici kamery, coˇz jsou prakticky naˇse oˇci. Tyto souˇradnice se nastavuj´ı v manifestu pˇred spuˇstˇen´ım aplikace. D´ale poskytuje souˇradnice LookAt,
Obr´azek 3: Visual Simulation Environment
kter´e ud´avaj´ı m´ısto, na kter´e se bude kamera po spuˇstˇen´ı centrov´ana. Jakmile se v si-mul´atoru pohybujeme, tak se n´am souˇradnice mˇen´ı s konkr´etn´ım pohledem.
Playback Bar je ˇsikovn ´y n´astroj pomoc´ı kter´eho m ˚uˇzeme nahr´avat ˇcinnost robota v modelovan ´ych situac´ıch a n´aslednˇe porovn´avat jeho r ˚uzn´e aspekty. Umoˇz ˇnuje i zpˇetn´e pˇrehr´an´ı videa. Po stisku tlaˇc´ıtka se symbolem play na liˇstˇe si v dialogov´e oknˇe staˇc´ı jen vybrat soubor s pˇr´ıponou .plb. Obˇe liˇsty jsou na obr´azku ˇc. 4.
3
Robot LEGO NXT
3.1 Popis stavebnice
LEGO Mindstorm NXT je stavebnice, ze kter´e lze sestavovat r ˚uzn´e podoby robota. Ob-sahuje hlavn´ı ˇr´ıd´ıc´ı jednotku, sensory, servo motory, kabely a dalˇs´ı propriety k mode-lov´an´ı ´uloh (napˇr. pole s barvami a ˇcarou, bal ´onky ...). Komunikace robota s PC se liˇs´ı od starˇs´ıho modelu. Infraˇcerven´e z´aˇren´ı je nahrazeno technologi´ı bluetooth nebo kabelem USB 2.0. Tento kabel je tak´e souˇc´ast´ı z´akladn´ı stavebnice.
V sadˇe s robotem je dod´av´an tak´e jednoduch ´y software pro programov´an´ı a ovl´ad´an´ı LEGO NXT robota, tzv. LEGO MINDSTORMS Education NXT Software v1.1. Jedn´a se o grafick ´y programovac´ı n´astroj. Programovac´ı jazyk v tomto softwaru se jmenuje NXT-G. Programy vytvoˇren´e v NXT-G m ˚uˇzeme nahr´at pˇr´ımo do ˇr´ıd´ıc´ı kostky a spouˇstˇet je pˇr´ımo na robotovi bez spojen´ı s poˇc´ıtaˇcem. Tento software je urˇcen jen pro robota LEGO NXT, ˇcili oproti MRDS nen´ı multiplatformn´ı.
3.2 Hardwarov ´e komponenty robota NXT
Obr´azek 6: NXT ˇR´ıd´ıc´ı jednotka a senzory [8]
3.2.1 R´ıd´ıc´ı jednotkaˇ
ˇ
R´ıd´ıc´ı kostka je hlavn´ı ˇc´ast´ı stavebnice. Pˇredstavuje jak ´ysi mozek robota, d´ıky nˇemuˇz je robot schopem vykon´avat operace a ´ukoly, kter´e mu program naˇr´ıd´ı. Kostka zpracov´av´a vˇsechny ´udaje z pˇripojen ´ych senzor ˚u a pˇr´ıpadnˇe je pos´ıl´a zpˇet aplikaci. ˇR´ıd´ıc´ı jednotka je 32-bit mikroprocesor s 256 KB Flash pamˇet´ı a 64 KB RAM pamˇet´ı. Jednotka d´ale nab´ız´ı
adapt´er bluetooth tˇr´ıdy II, USB port (12 MBit/s), LCD maticov ´y displej s rozmˇery 100 x 64 pixel ˚u a reproduktor frekvenc´ı 8kHz. Na obr´azku ˇc´ıslo 6 m ˚uˇzete vidˇet ˇr´ıd´ıc´ı jednotku se vˇsemi zapojen ´ymi porty (senzory a motory).
3.2.2 Dotykov ´y senzor
Dotykov ´y senzor zn´azornˇen ´y na obr´azku ˇc´ıslo 7 poskytuje robotovi jeden ze z´akladn´ıch smysl ˚u - hmat. Robot pomoc´ı nˇej m ˚uˇze rozeznat, zda naraz´ı na pˇrek´aˇzku nebo pokud chce nˇeco uchopit, zda je dan´e tˇeleso dostateˇcnˇe bl´ızko. Senzor m´a dva stavy - stisknut ´y a uvolnˇen ´y. Stiskem senzoru m ˚uˇze b ´yt vyvol´ana i dalˇs´ı akce jako je mluven´ı, otoˇcen´ı,
´uchop aj.
Obr´azek 7: Dotykov ´y senzor [9]
3.2.3 Zvukov ´y senzor
Na obr´azku ˇc´ıslo 8 je senzor, kter ´y m ˚uˇzeme pouˇz´ıt napˇr´ıklad pokud potˇrebujeme vyvol´a-n´ı akce robota po zatlesk´avyvol´a-n´ı nebo pokud bychom chtˇeli, aby pˇri dan´e zvukov´e frekvenci nˇeco ˇrekl.
Zvukov ´y senzor je analogov ´y a reaguje na zvuky tich´e, ale i hlasit´e. Pracuje s intenzi-tou zvuku v decibelech (dB) a akustick ´ych decibelech (dBA)1. Senzor je schopen mˇeˇrit aˇz
do 90dB, coˇz je pˇribliˇznˇe hladina zvuku sekaˇcky na tr´avu. Hodnota pˇrij´ıman´eho zvuku nen´ı na robotovi prezentov´ana v decibelech, ale v procentech. Pro pˇredstavu - pˇribliˇzn´a hodnota 4-5% je ticho v pokoji, 10-30% je norm´aln´ı rozhovor nebo hudba v bl´ızkosti sen-zoru.
3.2.4 Ultrazvukov ´y senzor
Ultrazvukov ´y senzor na obr´azku ˇc. 9 umoˇz ˇnuje robotovi spoleˇcnˇe se svˇeteln ´ym senzorem vidˇet. Za pouˇzit´ı tohoto senzoru m ˚uˇzeme mˇeˇrit vzd´alenost r ˚uzn ´ych pˇrek´aˇzek a n´aslednˇe se jim vyhnout. Senzor vyuˇz´ıv´a stejn´eho principu jako je echolokace u netop ´yr ˚u.
Echolokace je postup, kdy se vys´ılan ´y zvuk od pˇredmˇetu odraz´ı zpˇet do m´ısta vys´ıl´an´ı, kde je zpˇetnˇe zachycen. Z celkov´eho ˇcasu, kter ´y uplyne od okamˇziku vysl´an´ı zvukov´e
1dBA - citlivost senzoru pro zvuky slyˇsiteln´e lidsk ´ym uchem; dB - citlivot senzoru pro zvuky pˇr´ıliˇs
Obr´azek 8: Zvukov ´y senzor [9]
vlny (obvykle vysokofrekvenˇcn´ıho zvuku) do okamˇziku zpˇetn´eho pˇr´ıjmu odraˇzen´e vlny (ozvˇeny neboli echa), se d´a spoˇc´ıtat vzd´alenost alokovan´eho pˇredmˇetu. Tento princip vyuˇz´ıvaj´ı nˇekter´e specializovan´e elektronick´e pˇr´ıstroje, napˇr´ıklad sonary. Princip echolo-kace je vyuˇziv´an pro mˇeˇren´ı hloubky moˇre [10].
Senzor vys´ıl´a zvuk s frekvenc´ı 40kHz. ˇCidlo je schopno urˇcit vzd´alenost od 0 do 255 centrimetr ˚u s pˇresnost´ı +/- 3 cm. Je tˇreba br´at v ´uvahu, ˇze ve stejn´em prostoru nesm´ı b ´yt pouˇzito v´ıce neˇz jedno toto ˇcidlo. A to z toho d ˚uvodu, ˇze by se mohly vys´ılan´e zvukov´e vlny navz´ajem ruˇsit.
Obr´azek 9: Ultrazvukov ´y senzor [9]
3.2.5 Sv ˇeteln ´y senzor
Je to druh ´y senzor, po ultrazvukov´em, kter ´y umoˇz ˇnuje robotovi realizovat vidˇen´ı. Analo-gov ´y svˇeteln ´y senzor (na obr. ˇc.10) je schopen rozliˇsit obklopuj´ıc´ı a odr´aˇzen´e svˇetlo. V pa-sivn´ım m ´odu na senzoru nesv´ıt´ı LED a je schopen urˇcit intenzitu svˇetla v okol´ı(rozliˇsuje svˇetlo a tmu). V aktivn´ım reˇzimu se rozv´ıt´ı LED, kter´a emituje svˇetlo k povrchu a po-dle odraˇzen´eho mnoˇzstv´ı svˇetla se urˇcuje barevnost povrchu. Tato fuknce je vyuˇzita pˇri modelovan´e ´uloze - J´ızda po ˇc´aˇre, kde na z´akladˇe odst´ınu, kter ´y robot vid´ı, se rozhoduje o pohybu.
Mˇeˇren´ı intenzity barvy je znaˇcnˇe z´avisl´e na podm´ınk´ach re´aln´eho porstˇred´ı. Hodnoty se mˇen´ı pˇri zmˇenˇe okoln´ıho osvˇetlen´ı m´ıstnosti, vzd´alenosti senzoru od povrchu a struk-tury povrchu (hladk ´y, drsn ´y). Standardn´ım mˇeˇr´ıtkem pro intenzitu je rozmez´ı procent od 0 do 100.
Obr´azek 10: Svˇeteln ´y senzor [9]
3.2.6 Servo motory
Sada obsahuje tˇri servo motory (obr. ˇc´ıslo 11), kter´e umoˇz ˇnuj´ı robotovi se pohybovat. Kaˇzd ´y motor m´a zabudovan´e rotaˇcn´ı ˇcidlo, kter´e s pˇresnost´ı na jeden stupe ˇn mˇeˇr´ı otoˇcen´ı robota. Motory mohou vyvinout relativnˇe dobrou kombinaci rychlosti a ot´aˇcen´ı robota.
3.3 Komunikace s PC
Robot LEGO NXT m ˚uˇze komunikovat s PC pomoc´ı technologie bluetooth2 nebo USB kabelem. Robota lze ovl´adat pomoc´ı bluetooth i mobiln´ım telefonem nebo lze sp´arovat i v´ıce LEGO NXT robot ˚u.
Komunikace pomoc´ı bluetooth je zaloˇzena na principu master and slave. Pokud PC inicijuje spojen´ı, st´av´a se z nˇej master a robot NXT ho pouze akceptuje jako slave. I robot m ˚uˇze b ´yt master. Mnohdy je toto v ´yhodn´e pˇri spojen´ı v´ıce NXT robot ˚u. NXT master m ˚uˇze b ´yt pˇripojen aˇz ke tˇrem dalˇs´ım NXT slave. Princip vztahu master-slave spoˇc´ıv´a v pos´ıl´an´ı zpr´av. Jen master pos´ıl´a zpr´avy se zdrojov ´ymi daty programu a m ˚uˇze poˇzadovat data, kter´a mu slave m´a poslat. Pokud master poˇsle data ke slave, pak m ˚uˇze, ale nemus´ı, poˇzadovat potvrzen´ı pˇr´ıjmu dat. Kdyˇz master ˇz´ad´a data od slave, pak odpovˇed’ obsahuje dan´a data, pokud jsou k dispozici. Pokud nejsou k dispozici, odpovˇed’ obsahuje chy-bovou zpr´avu.
Zpr´ava, kterou pos´ıl´a master, specifikuje, zda j´ı m´a slave potvrdit nebo ne. Podle toho se urˇcuje, kdo bude v n´asleduj´ıc´ı relaci vys´ılaˇc a kdo pˇrij´ımaˇc. Rychlost pˇrep´ın´an´ı blue-tooth mezi vys´ılac´ım a pˇrij´ımac´ım m ´odem je okolo 50 ms a m ˚uˇze doch´azet k nepˇresnos-tem.
Kaˇzd ´y NXT m´a sv ˚uj tzv. mailbox, ve kter´em uchov´av´a pˇrijat´e a odchoz´ı zpr´avy. Mail-box m´a celkem deset m´ıst, ˇcili m´a frontu pro pˇet odchoz´ıch a pˇet pˇrichoz´ıch zpr´av. Master nepotˇrebuje fronty zpr´av, jelikoˇz si vˇzdy od slave vyˇz´ad´a odpovˇedi a hned je zpracov´av´a. Vˇsechny zpr´avy od master ke slave jsou uchov´av´any ve frontˇe u slave. Pokud na slave dojde zpr´ava do fronty, kter´a je pln´a, pak je nejstarˇs´ı zpr´ava ve frontˇe smaz´ana bez toho, aby byla vykon´ana. Tato komunikace pˇres bluetooth nen´ı spolehliv´a. Spojen´ı funguje bez probl´emu pˇri kr´atk ´ych zpr´av´ach nebo pˇri mal´em (pˇrimˇeˇren´em) poˇctu zpr´av.
Tento probl´em lze jednoduˇse vyˇreˇsit t´ım, ˇze NXT robot bude master a PC bude slave. Zpr´avy se nebudou ztr´acet, protoˇze RAM pamˇet poˇc´ıtaˇce je udrˇz´ı. Nicm´enˇe tato moˇznost n´am vyluˇcuje pouˇzit´ı MRDS. MRDS je sice multiplatformn´ı, ale program v nˇem vytvoˇren ´y nelze nahr´at do ˇr´ıd´ıc´ı jednotky robota. NXT robot m ˚uˇze b ´yt master pˇri pouˇzit´ı LEGO MINDSTORM Education Software, jelikoˇz tyto programy lze do ˇr´ıd´ıc´ı jednotky nahr´at a n´aslednˇe pouˇz´ıt poˇc´ıtaˇc jako slave v dan´em bluetooth spojen´ı.
Pokud chceme pos´ılat data na robota NXT, pak by mˇel b ´yt slave. Pokud je robot slave, pak NXT firmware pos´ıl´a potvrzen´ı o kaˇzd´e pˇrijat´e zpr´avˇe. Pˇri t´eto konfiguraci je tˇreba pˇredpokl´adat ztr´atu zpr´av. Podle pokus ˚u z [11] se ztrat´ı okolo 18-20% zpr´av, nicm´enˇe kaˇzd´a zpr´avy byla doruˇcena za m´enˇe neˇz 5 ms.
Komunikace MRDS s robotem prob´ıh´a pouze pomoc´ı technologie bluetooth. MDRS nepodporuje komunikace skrz USB. Pˇri prvn´ım nav´az´an´ı spojen´ı PC s robotem je tˇreba je tzv. sp´arovat. Robot mus´ı b ´yt zapnut ´y a mus´ı m´ıt aktivov´an ´y bluetooth. P´arovac´ı heslo je defaultnˇe 1234. Po potvrzen´ı k ´odu na obou stran´ach je spojen´ı nav´azano. Windows pˇridˇel´ı bluetooth zaˇr´ızen´ı sv ˚uj COM port. Odchoz´ı port je tˇreba v MRDS nastavit dle aktu´aln´ıho zaˇr´ızen´ı. Tuto zmˇenu provedeme v souboru ..\Microsoft Robotics Dev Studio 2008\samples\Config\LEGO.NXT.Brick.Config.xml. V editoru
zmˇen´ı-2Bluetooth je bezdr´atov´a komunikaˇcn´ı technologie slouˇz´ıc´ı k bezdr´atov´emu propojen´ı mezi dvˇema a v´ıce
me ˇc´ıslo portu v elementu <serial port>. D´ale je tˇreba ovˇeˇrit, ˇze manifest ˇr´ıd´ıc´ı jednotky ˇcte nastaven´ı z n´ami upraven´eho souboru. To si ovˇeˇr´ıme v souboru ..\samples \Config\LEGO.NXT.Brick.Manifest.xmlv elementu <dssp:Service> mus´ı b ´yt n´a-zev konfiguraˇcn´ıho souboru.
Pˇri naˇsich modelov ´ych ´uloh´ach pouˇz´ıv´ame komunikaci bluetooth mezi robotem a PC tak, ˇze robot je slave a PC je master.
Software dod´avan ´y v sadˇe s robotem - LEGO Mindstorms NXT podporuje komu-nikaci s robotem jak pˇres bluetooth, tak pˇres USB kabel. Pˇres tento software je velmi jednoduch´e nahr´av´at do robota aktu´aln´ı firmware, kalibrovat senzory apod.
3.4 Konstrukce pro ´ulohy
LEGO NXT robot je stavebnice, ze kter´e lze postavit spoustu r ˚uzn ´ych modifikac´ı robota dle naˇsich pˇredstav. N´avody k postaven´ı r ˚uzn ´ych typ ˚u robot ˚u jsou v manu´alu, kter ´y je souˇc´ast´ı stavebnice.
K modelov´an´ı n´ıˇze popsan ´ych ´uloh vyuˇzijeme konstrukci, kde vyuˇz´ıv´ame dotykov ´y a svˇeteln ´y senzor. Z´akladem konstrukce je tzv. NXT Tribot. Nicm´enˇe je ochuzen o ostatn´ı ˇcidla, kter´a jsme u naˇsich ´uloh nepotˇrebovali. Jak robot vypad´a je zˇrejm´e z obr´azku ˇc. 12 Parametry robota z ˚ust´av´aj´ı stejn´e jako u tribota. Pr ˚umˇer kola je 56 mm a rozteˇc mezi koly 11,2 cm.
4
Visual Programming Language
4.1 Popis prostˇred´ı
VPL je souˇc´ast´ı instalaˇcn´ıho bal´ıku MRDS. Je to vizu´aln´ı prostˇred´ı, ve kter´em lze na prin-cipu drag and drop programovat robotick´e aplikace. Ve VPL lze vyuˇz´ıt komponenty, kter´e jsou ve VPL pojmenov´any jako tzv. aktivity. Z´akladn´ım stavebn´ım kamenem jsou opˇet sluˇzby, kter´e mohou m´ıt vstupn´ı, v ´ystupn´ı data a notifikace. MRDS jiˇz nab´ız´ı dan´e spektrum sluˇzeb nebo si uˇzivatel m ˚uˇze vytvoˇrit sluˇzbu, kterou je moˇzno do VPL pˇridat. V lev´em spodn´ım sloupci je seznam sluˇzeb, kter´e jsou k dispozici a v horn´ım lev´em oknˇe jsou aktivity - z´akladn´ı programovac´ı struktury. Ve VPL je moˇzno vytvoˇrit vlastn´ı aktiv-itu (vzd´alen´a obdoba metody v objektovˇe-orientovan´em programovan´ı), u kter ´ych lze konfigurovat vstupy, v ´ystupy, notifikace a n´aslednˇe je pouˇz´ıvat v hlavn´ım diagramu. Pouˇzit´e algoritmy je praktick´e zabalit do aktivit z d ˚uvodu pˇrehlednosti diagramu.
VPL poskytuje sluˇzby nejen pro NXT robota, ale i pro iRotota, FischerTechnic a dalˇs´ı. Poskytuje tak´e generick´e sluˇzby, kter´e se pouˇz´ıvaj´ı pro programov´an´ı v simul´atoru MRDS nebo je moˇzn´e jejich pouˇzit´ı, pokud nen´ı dan´a sluˇzba pro nˇejak ´y senzor v MRDS imple-mentov´ana. Vˇsechy tyto komponenty m ˚uˇzeme vloˇzit do diagramu, spojovat je pomoc´ı datov ´ych tok ˚u a t´ım tvoˇrit program. Ve VPL se nepouˇz´ıvaj´ı sekvence pˇr´ıkaz ˚u. Na z´akladˇe vstupn´ıch dat se zmˇen´ı v ´ystupn´ı data. Notifikace se mˇen´ı za z´akladˇe zmˇeny intern´ıch dat ve sluˇzbˇe (napˇr´ıklad zmˇena hodnoty svˇeteln´eho ˇcidla - pokud se zmˇen´ı hodnota, kterou ˇcidlo registruje, poˇsle ji na notifikaci), takˇze ze sluˇzby m ˚uˇzeme odeb´ırat z´arove ˇn vystupn´ı data, ale i notifikaci.
Ve VPL je moˇzno jednoduˇse programovat aplikace s paraleln´ım a distrubuovan ´ym chov´an´ım. Cel ´y diagram VPL lze zkompilovat do C# k ´odu. C´ılem VPL nen´ı nauˇcit uˇziva-tele programovat, nesposkytuje ani pˇr´ım ´y pˇr´ıstup k platformˇe .NET, nicm´enˇe VPL pˇred-stavuje rychlou a jednoduchou cestu k tvorbˇe robotick ´ych aplikac´ı.
4.2 Princip implementace
Implementace programu ve VPL je na principu “chyt’ a t´ahni” (drag and drop). Do dia-gramu si myˇs´ı pˇret´ahneme potˇrebn´e aktivity, sluˇzby a programovac´ı komponenty, kter´e n´aslednˇe spojujeme datov ´ym´ı toky. Kaˇzd ´y oddˇelen ´y datov ´y tok bˇeˇz´ı ve sv´em vl´aknˇe a navz´ajem jsou nez´avisl´e a paraleln´ı. Na obr´azku ˇc. 13 m ˚uˇzete vidˇet uk´azku programu se tˇremi vl´akny.
Na obr´azku ˇc. 13 je v prav´em sloupci dialog Properties, kter ´y se mˇen´ı podle oznaˇcen´e komponenty nebo sluˇzby. Ve properties sluˇzeb senzor ˚u a ˇr´ıd´ıc´ı jednotky m ˚uˇzeme nas-tavit tzv. z´akladn´ı konfiguraci nebo odk´azat na pouˇzit´ı manifestu jin´e sluˇzby. Nastaven´ı z´akladn´ı konfigurace je vidˇet vpravo na obr´azku ˇc. 13. Zde nastavujeme partnerskou sluˇzbu (pokud nˇejakou chceme). U senzor ˚u jako je svˇeteln ´y, ultrazvukov ´y, motory atd. mus´ı b ´yt partnersk´a sluˇzba nastavena na ˇr´ıd´ıc´ı jednotku. D´ale zde nastavujeme vlast-nosti konkr´etn´ıho senzoru jako je napˇr´ıklad u motoru rozteˇc kol, pr ˚umˇer kola, porty a frekvence sbˇeru dat ze senzoru.
Obr´azek 13: Prostˇred´ı Visual Programming Language
Seznam dostupn ´ych sluˇzeb m ˚uˇzeme naj´ıt na seznamu vlevo (viz obr´azek ˇc. 13). Sluˇzby se v tomto seznamu objev´ı aˇz po jejich kompilaci, kdy se knihovna sluˇzby uloˇz´ı do adres´aˇre ...\Microsoft Robotics Dev Studio 2008\bin. V tomto seznamu jsou sluˇzby jak pro re´aln´eho robota, tak pro simulaˇcn´ı prostˇred´ı.
Program spust´ıme pˇr´ıkazem Start, kter ´y najdeme v nab´ıdce Run v menu. N´aslednˇe se v oknˇe na obr´azku ˇc. 15 objev´ı seznam spuˇstˇen ´ych sluˇzeb, jejich stav a pˇr´ıpadn´e probl´emy a chyby. Debugging ve VPL nen´ı typick ´y. Sluˇzba Log poskytuje zaznamen´av´an´ı promˇen-n ´ych bˇehem programu. Po spuˇstˇepromˇen-n´ı a probˇehpromˇen-nut´ı programu lze dapromˇen-n´e hodpromˇen-noty promˇen-naj´ıt pˇres odkaz v dialogu Run (obr´azek ˇc. 15). Dostaneme se aˇz do debug and trace zpr´av, kde je m ˚uˇzeme r ˚uznˇe organizovat, ˇc´ıst a program debugovat.
4.3 Vytvoˇren´ı nov ´e aktivity
Novou aktivitu vytvoˇr´ıme pˇrenesen´ım komponenty aktivity do diagramu. N´asleduje jej´ı nastaven´ı. Dvojklikem otevˇreme diagram nov´e aktivity. V diagramu tvoˇr´ıme pro-gram. Nastaven´ı vstupn´ıch, v ´ystupn´ıch hodnot a notifikace se prov´ad´ı v nab´ıdce, kterou otevˇreme pomoc´ı ikony nahoˇre v liˇstˇe nad diagramem aktivity (obr´azek ˇc. 16). Pro kaˇzdou aktivitu m ˚uˇzeme naimplementovat v´ıce akc´ı, kter´e se mohou prov´est. Mezi akcemi se pˇrep´ın´ame tak´e v liˇstˇe aktivity.
Obr´azek 14: VPL - dialog Run
4.4 Kompilace programu do sluˇzby
Pokud chceme pro n´aˇs program vytvoˇrit vlastn´ı sluˇzbu, je tˇreba ji m´ıt zkompilovanou. Ve VPL toho doc´ıl´ıme pˇr´ıkazem Compile as a service, kter ´y najdeme v menu v Build. Do v´ami nastaven´eho adres´aˇre se program VPL zkompiluje do k ´odu C#, kter ´y n´aslednˇe lze otevˇr´ıt, upravit a spustit v Microsoft Visual Studiu. Projekty MRDS mus´ı b ´yt vˇzdy um´ıstˇeny ve sloˇzce ...\Microsoft Robotics Dev Studio 2008\, jinak nebudou spustiteln´e. Bohuˇzel, k ´od v C# z MRDS do VPL zkompilovat nelze.
4.5 Omezen´ı
Omezen´ı VPL jsme zaznamenali pˇri implementov´an´ı ´uloh n´aroˇcn ´ych na mnoho kompo-nent. Jakmile se do diagramu um´ıstilo okolo 70 komponent (sluˇzeb, aktivit apod.). VPL jen pˇri otevˇren´ı takov´eho diagramu vyuˇz´ıvalo velkou ˇc´ast RAM pamˇeti a zaˇcalo zamrzat a sekat se. T´ımto se pr´ace s n´ım st´avala nepˇrijateln´a.
VPL nem´a defaultnˇe k dispozici datov ´y typ pole. Nicm´enˇe toto lze ˇreˇsit pouˇzit´ım da-tov´eho typu seznam. VPL nab´ız´ı sluˇzbu ByteArray, pomoc´ı kter´e lze seznam pˇretypovat na pole a naopak. Pr´ace s poli ve VPL je dosti neobratn´a, ale je moˇzn´a.
Obr´azek 15: VPL - Debug and trace zpr´avy
5
Modelovan ´e ´
ulohy
5.1 Konfigurace softwaru a hardwaru pˇri implementaci
Nˇekter´e modelovan´e ´ulohy byly implementov´any na re´aln´em robotovi a nˇekter´e ve VSE. K implementaci ´ulohy jsme pouˇz´ıvali sadu LEGO Mindstorms NXT(robot s firmware verz´ı 1.28) a notebook Hewlett-Packard Pavilion dv5 s n´asleduj´ıc´ımi parametry: procesor - Intel Core(TM)2 Duo P7350 - 2GHz a RAM pamˇet’ 2GB, grafick ´y adapt´er - NVIDIA GeForce 9200M GS.
Z hlediska software bylo pro implementaci pouˇzito Microsoft Robotics Developer Studio 2008 nad 32bitov ´ym operaˇcn´ım syst´emem Windows Vista Home Premium, Ser-vice pack 2.
5.2 Popis d´ıl ˇc´ıch ´uloh
Prvn´ı z ´uloh je j´ızda robota na naklonˇenou rovinu. Tato ´uloha je implementov´ana pouze ve VSE pomoc´ı MRDS. ´Uloha demonstruje pr´aci s entitami ve VSE, implementaci vlastn´ı-ho objektu pro VSE a pr´aci s fyzik´aln´ım prostˇred´ım VSE. ´Ukolem robota je na naklonˇenou rovinu vyjet, pohybovat se na n´ı a n´aslednˇe sjet.
´
Uloha pˇrek´aˇzka byla ˇreˇsena jak pro VSE tak pro re´aln´eho robota v MRDS. Za pomoc´ı vyuˇzit´ı dotykov´eho senzoru robota mus´ı robot pˇri j´ızdˇe zjistit, ˇze pˇred n´ım stoj´ı pˇrek´aˇzka a objet ji.
Dalˇs´ı ´ulohou je j´ızda po ˇc´aˇre. Pro n´ı vyuˇz´ıv´ame simulaˇcn´ı pole s jiˇz pˇripravenou ˇc´arou, kter´e je souˇc´ast´ı stavebnice. Robot za pomoc´ı svˇeteln´eho senzoru rozpozn´a hranici b´ıl´e a ˇcern´e barvy a na z´akladˇe tˇechto inofrmac´ı ˇr´ıd´ı pohyb. Implementovali jsme algo-ritmus tzv. zig-zag a n´aslednˇe jsme ho optimalizovali tak, aby pohyb byl plynulejˇs´ı. Tato
´uloha je ˇreˇsena jen pro re´aln´eho robota pomoc´ı VPL.
Posledn´ı ´ulohou je pr ˚ujezd labyrintu. Labyrit je tvoˇren z ˇcern ´ych ˇcar ve ˇctvercov´e soustavˇe na svˇetl´em podkladˇe. ´Ukolem robota je na kaˇzd´e kˇriˇzovatce zjistit moˇzn´e cesty, cel ´ym labyrintem projet, naj´ıt nejkratˇs´ı cestu ze startu do c´ıle a projet j´ı. Pˇri t´eto ´uloze je vyuˇzito zejm´ena svˇeteln´eho senzoru k rozpozn´an´ı odst´ın ˚u barev. ´Uloha byla implemen-tov´ana jen pro re´aln´eho robota.
5.3 Naklon ˇen ´a rovina
Pro ´ulohu jsme museli implementovat rovinu jako extern´ı objekt, kter ´y jsme do MRDS pˇridali. ´Ukolem robota je na tuto rovinu vyjet a sjet a pohybovat se v simulovan´em prostˇred´ı. Ve VSE m ˚uˇzeme mˇenit fyzik´aln´ı podm´ınky pro robota (jeho s´ılu, gravitaci apod.) a n´aslednˇe sledovat jeho chov´an´ı v dan´e situaci.
Prostˇred´ı zakl´ad´ame na jiˇz pˇripraven´em modelu z SimulationTutorial 1. Toto pros-tˇred´ı jsme upravili pro naˇse potˇreby. Pro ovl´ad´an´ı robota pouˇz´ıv´ame partnerskou sluˇzbu simpledashboard, kter´a pˇri startu simulace vyvol´a tzv. dashboard - ˇr´ıd´ıc´ı desku.
5.3.1 Implementace
Cel´a implementace prob´ıhala v k ´odu v MRDS a pomoc´ı manifest ˚u sluˇzeb. Projekt Naklo-nenaRovina jsme zaloˇzili na SimulationTutorial1 a proto se n´am do sloˇzky projektu na-kop´ıroval i konfiguraˇcni soubor simulationengine.xml, ve kter´em je v ´ypis a z´akladn´ı nas-taven´ı entit a fyziky v prostˇred´ı VSE.
Do manifestu NaklonenaRovina.manifest.xml pˇrid´ame tag <ServiceRecordType> s od-kazem na partnerskou sluˇzbu simpledashboard, kter´a se spouˇst´ı pˇri startu simul´atoru. Obsah manifestu je ve v ´ypisu ˇc. 2.
<?xml version=”1.0” ?> <Manifest xmlns=”http :// schemas.microsoft.com/xw/2004/10/manifest.html” xmlns:dssp=”http://schemas.microsoft.com/xw/2004/10/dssp.html” > <CreateServiceList> <ServiceRecordType> <dssp:Contract>http://schemas.microsoft.com/robotics/2006/01/simpledashboard.html</dssp :Contract> </ServiceRecordType> <ServiceRecordType> <dssp:Contract>http://schemas.tempuri.org/2006/06/simulationtutorial1.html</dssp:Contract > </ServiceRecordType> </CreateServiceList> </Manifest> V ´ypis 2: NaklonenaRovina.manifest.xml
Naklonˇenou rovinu jsme vytvoˇrili ve freeware programu s n´azvem Anim8or v0.97b [13]. Tato utilita je pro tvorbu objektu dostateˇcn´a. Abychom mohli importovat do MRDS vlastn´ı objekt, mus´ı b ´yt ve form´atu .obj (form´at zn´am ´y jako Wavefront form´at, pˇr´ıpadnˇe i s materi´alov ´ym souborem s pˇr´ıponou .mtl). V materi´alov´em souboru jsou uloˇzeny in-formace o materi´alu, ze kter´eho je tˇeleso vytvoˇreno, jakou m´a barvu, povrch, drsnost, odst´ıny apod. Oba tyto soubory mus´ı b ´yt uloˇzeny v MRDS ve sloˇzce ..\Microsoft Robotics Dev Studio 2008\store\media, ze kter´e MRDS ˇcerp´a veˇsker´e grafick´e modely, povrchy a dalˇs´ı soubory k simulac´ım.
V k ´odu MRDS se jiˇz odkazujeme jen na soubor .obj. Simul´ator pˇri prvn´ım naˇcten´ı souboru .obj jej konvertuje na form´at .bos a vytvoˇr´ı s touto pˇr´ıponou nov ´y soubor se stejn ´ym n´azvem. Pˇri dalˇs´ım spuˇstˇen´ı simulace jiˇz MRDS pracuje s t´ımto souborem. Na-ˇc´ıt´an´ı soubor ˚u ve form´atu .bos je pro MRDS rychlejˇs´ı. Pˇr´ıkazov ´y ˇr´adek MRDS obsahuje pˇr´ıkaz Obj2Bos.exe, kter ´ym lze soubor zkonvertovat i bez spuˇstˇen´ı simul´atoru.
Pˇri spuˇstˇen´ı sluˇzby se z´arove ˇn spouˇst´ı i ˇr´ıd´ıc´ı deska pro robota. Pro spojen´ı desky a robota je tˇreba udˇelat n´asleduj´ıc´ı kroky. V nab´ıdce Remote Node v kolonce Machine napsat “localhost” a tlaˇc´ıtko Connect. Po tom, co se ve spodn´ım oknˇe objev´ı odkaz na NXT robota, je tˇreba na tento odkaz dvakr´at poklikat (aby se Motor v sekci Differential Drive pˇrepnul na On) a stisknout tlaˇc´ıtko Drive v sekci Direct Input Service. Ted’ lze j´ızdu robota jednoduˇse ovl´adat klikem a drˇzen´ım na ˇr´ıd´ıc´ı koleˇcko v sekci Direct Input service.
Uk´azka simulovan´eho programu je na obr´azku ˇc´ıslo 17.
Obr´azek 17: ´Uloha - Naklonˇen´a rovina
5.3.2 Probl ´emy a poznatky k ˇre ˇsen´ı
Pro spr´avnou kompilaci projektu je tˇreba zkotrolovat spr´avnou cestu k manifestu pro-jektu. V properties projektu, z´aloˇzka Debug v nab´ıdce Start options, je tˇreba tyto cesty nastavit.
Pˇri tvorbˇe extern´ıho objektu bylo n´aroˇcn´e zjistit, ˇze fyzik´aln´ı vlastnosti materi´alu, kter ´ym je objekt pokryt mus´ı b ´yt takov´e, aby robot po objektu opravdu vyjel. Dlouho se tak´e st´avalo, ˇze robot materi´al na objektu ignoroval a projel skrze stˇenu do roviny. Tato vlastnost se na rovinˇe objevila d´ıky nekorektn´ımu exportu z programu Anim8or. Po upgradovan´ı programu byl export soubor ˚u .obj i .mtl v poˇr´adku.
Pˇri vkl´ad´an´ı tˇeles (entit) do VSE je tˇreba vˇenovat pozornost um´ıstˇen´ı tˇeles. Jakmile se tˇelesa pˇrer ´yvaj´ı, pak je VSE “vystˇreluje” od sebe podle sil a hmotnosti entit.
5.4 Pˇrek ´aˇzka
Hlavn´ım ´ukolem robota je rozpoznat pˇrek´aˇzku, na kterou bˇehem j´ızdy naraz´ı a objet j´ı. ´
Ulohu jsme ˇreˇseli jak pro simul´ator, tak pro re´aln´eho robota. Vyuˇz´ıv´ame dotykov ´y senzor a na z´akladˇe informac´ı z nˇej zjiˇst’ujeme, zda robota do nˇeˇceho narazil.
5.4.1 Implementace ´ulohy Pˇrek ´aˇzka v simul ´atoru
Zvolili jsme moˇznost implementace ve VPL. Pro simulaci pouˇz´ıv´ame generick´e sluˇzby pro senzory i motory robota, kter´e n´am VPL nab´ız´ı. Simulaci jsme postavili na z´akladˇe manifestu LEGO.NXT.Tribot.Simulation.Manifest.xml. Pro vˇsechny sluˇzby pro robota, jako je GenericContactSensor a GenericDifferentialDrive mus´ıme v z´akladn´ı konfiguraci nas-tavit pouˇzit´ı manifestu a v ´yˇse zm´ınˇen ´y manifest importovat. D´ıky tomu se n´am do sloˇzky nakop´ıruje manifest a soubor lego.nxt.tribot.simulationenginestate (LEGO. NXT.Tribot.Simulation.Manifest).xml, ve kter´em je nastaven´ı simulaˇcn´ıho pros-tˇred´ı. V tomto souboru si nastav´ıme pozice kamer, svˇetla, robota i tˇelesa. ˇCili v tomto manifest souboru nastavujeme statiku simulace a v diagramu VPL implementujeme pouze dynamiku simul´atoru.
Na z´akladˇe notifikace z dotykov´eho senzoru se robot zastav´ı, vr´at´ı o kousek zpˇet a danou pˇrek´aˇzku objede. Jelikoˇz program je zaloˇzen na nˇekolika vl´aknech, je potˇreba po-hyb regulovat. K tomu vyuˇz´ıvame vlastnost dokonˇcen´ı popo-hybu DriveDistanceStage a Ro-tateDegreesStage. Tyto vlastnosti mohou pˇrech´azet mezi stavy InitialRequest > Started >Completed nebo InitialRequest > Started > Canceled. Pouze jedna operace m ˚uˇze b ´yt prov´adˇena na motoru a mˇen´ı se jej´ı stav. Aby robot dokonˇcil vˇsechna otoˇcen´ı a j´ızdy, vyuˇz´ıv´ame podm´ınky se stavem j´ızdy Completed. Jin ´ymi slovy, po dokonˇcen´ı jedn´e ˇcinnosti m ˚uˇze pokraˇcovat v jin´e.
5.4.2 Probl ´emy a poznatky k ˇre ˇsen´ı v simul ´atoru
K ˇr´ızen´ı pohybu robota je tˇreba vyuˇz´ıvat vlastnosti DriveDistanceStage a RotateDegrees-Stage. Dokud jsme je nevyuˇz´ıvali, pak korektnˇe robot nedokonˇcil pohyb, protoˇze jin´e vlakno robotovi pos´ılalo jin´e instukce.
Optimalizace programu spoˇc´ıv´a i v nastaven´ı s´ıly, hmotnosti a rychlosti robota. D ˚u-leˇzit´a je tak´e hmotnost a s´ıla tˇelesa, do kter´eho robot nar´aˇz´ı. Pokud tyto vlastnosti nejsou v urˇcit´e rovnov´aze pak se m ˚uˇze st´at, ˇze ve VSE robot tˇeleso potlaˇc´ı nebo se pˇri n´ar´azu pˇreklop´ı.
5.4.3 Implementace ´ulohy Pˇrek ´aˇzka v re ´aln ´em prostˇred´ı
I pro re´aln´e prostˇred´ı jsme zvolili k implementaci VPL. Vyuˇz´ıv´ame dotykov ´y senzor stejnˇe jako v simul´atoru. Pouˇz´ıv´ame sluˇzby pro senzory konkr´etn´ıho robota, kter´e MRDS nab´ız´ı. V naˇsem pˇr´ıpadˇe se jedn´a o LegoNXTBrickv2, LegoNXTTouchSensorv2 a Lego-NXTDrivev2. Jakmile je senzor ve stavu stisknut´y, pak notifikace ozn´am´ı jeho zmˇenu stavu a spouˇst´ı se vl´akno, kter´e vykon´av´a pohyby - objet´ı pˇrek´aˇzky. Do vl´akna jsme pˇridali aktivity WaitForDriveCompletition a Timer, kter´e vl´akno usp´avaj´ı tak, aby dan ´y pohyb byl vˇzdy dokonˇcen a nebyl pˇreruˇsen n´asleduj´ıc´ı aktivitou. Robot stejnˇe jako v simul´atoru naraz´ı na pˇrek´aˇzku, couv´a o 25 cm zpˇet a obj´ıˇzd´ı ji.
5.4.4 Probl ´emy a poznatky k ˇre ˇsen´ı v re ´aln ´em prostˇred´ı
ˇ
R´ızen´ı pohybu - ot´aˇcen´ı a j´ızdu prov´ad´ıme pomoc´ı vlastnosti DriveStage (obdoba Drive-DistanceStage v simul´atoru) a pomoc´ı ˇcasovaˇc ˚u, kter´e jsou nastaven´e tak, aby byla kaˇzd´a aktivita dokonˇcena.
VPL nab´ız´ı tak´e sluˇzbu WaitForDriveCompletition, kterou jsme tak´e vyuˇzili. Nicmˇenˇe jsou s n´ı nˇekdy probl´emy a chov´a se, jakoby v programu nebyla a program nepoˇck´a na dokonˇcen´ı aktivity. Z tˇechto d ˚uvod ˚u jsme zvolili kombinovav ´y zp ˚usob ˇr´ızen´ı pohyb ˚u pomoc´ı sluˇzby WaitForDriveCompletition a ˇcasovaˇc ˚u (sluˇzba Timer).
5.5 J´ızda po ˇc ´aˇre
K realizaci t´eto ´ulohy vyuˇz´ıv´ame pole s ˇcernou ˇcarou ze stavebnice s robotem. ´Ukolem robota je sledovat ˇcernou ˇc´aru a jet po n´ı. Robot se nesm´ı z cesty vych ´ylit, ani vyjet. Tato ´uloha je vypracov´ana ve dvou verz´ıch, pˇriˇcemˇz prvn´ı verze je z´akladn´ı a druh´a je optimalizov´ana - pohyb robota je v´ıce regulovan ´y.
5.5.1 Implementace
Pro implementaci jsme vyuˇzili VPL. Algoritmus je zaloˇzen na informac´ıch, kter´e posky-tuje svˇeteln ´y senzor. Svˇeteln ´y senzor pouˇz´ıv´ame v aktivn´ım m ´odu, kdy je rozsv´ıcen´a LED. Hodnoty svˇeteln´eho senzoru m ˚uˇzeme pouˇz´ıvat bud’ tzv. ˇcist´e nebo normalizovan´e.
ˇ
Cist´a hodnota je schovan´a za vlastnost´ı RawMeasurement a obsahuje procentu´aln´ı hod-notu namˇeˇren´eho svˇetla. Normalizovan´a hodnota je ˇc´ıslo datov´eho typu double od 0 do 1 a m ˚uˇzeme j´ı pouˇz´ıt pomoc´ı vlastnosti NormalizedMeasurement. Je to normalizov´an´a hodnota ˇcist´e hodnoty svˇetla vzhledem k vlastnosti RawMeasurementRange, coˇz je ma-xim´aln´ı rozsah mˇeˇren´ı ˇc´ıst´e hodnoty, kter ´y m ˚uˇzeme nastavit.
V naˇs´ı ´uloze pouˇz´ıv´ame ˇcist´e hodnoty. Hodnotu odst´ınu, kter ´y senzor vid´ı, ukl´ad´ame do promˇenn´e a podle podm´ınek ˇr´ıd´ıme pohyb robota.
Algoritmus je zaloˇzen ´y na principu zig-zag. Robot v podstatˇe sleduje hranu ˇcern´e ˇc´ary s b´ıl ´ym podkladem. Smysl algoritmu lze popsat pseudok ´odem ve v ´ypisu ˇc. 3. V naˇsem pˇr´ıpadˇe jsou hodnoty svˇetla pro b´ılou cca 63 a ˇcernou 35. Rozdˇel´ıme spektrum na tˇri intervaly ( 0-41, 41-58, 58-100). Senzor vrac´ı hodnotu svˇetla s toleranc´ı nˇekolika procent, proto k hraniˇcn´ım hodnot´am pˇrid´avame 5 procent.
POKUD je sv ˇetlo < 41 PAK otoˇc vpravo JINAK
POKUD je sv ˇetlo < 58 PAK jed’ rovn ˇe JINAK otoˇc vlevo
konec podm´ınky konec podm´ınky
V ´ypis 3: Pseudok ´od algoritmu sledov´an´ı ˇc´ary
Tento algoritmus pro n´as nebyl dostateˇcn ´y, protoˇze pohyb robota je tˇreba v´ıce regu-lovat. Svˇeteln ´y senzor pˇri pˇrechodu z ˇcern´e na b´ılou hodnoty mˇen´ı, a proto jsme do algo-ritmu pˇridali dalˇs´ı podm´ınky tak, aby byl pohyb v´ıce plynulˇejˇs´ı a pˇrirozenˇejˇs´ı. Spektrum
viditelnosti rozdˇel´ıme m´ısto tˇr´ı na pˇet interval ˚u (0-26, 26-33, 33-38, 38-58, 58-70, 70-100). Prakticky jsme jen pˇridali pohyb otoˇc lehce doprava a lehce doleva do pˇredchoz´ıho algo-ritmu. Smysl je zˇrejm ´y z v ´ypisu ˇc. 4
POKUD je sv ˇetlo < 26 PAK otoˇc prudce doprava JINAK
POKUD je sv ˇetlo < 33 PAK otoˇc lehce doprava JINAK POKUD je sv ˇetlo < 38 PAK jed’ rovn ˇe
JINAK POKUD je sv ˇetlo < 58 PAK otoˇc lehce doleva
JINAK POKUD je sv ˇetlo < 70 PAK otoˇc prudce doleva konec podm´ınky
konec podm´ınky konec podm´ınky
konec podm´ınky konec podm´ınky
V ´ypis 4: Pseudok ´od optimalizov´an´eho algoritmu sledov´an´ı ˇc´ary
5.5.2 Probl ´emy a poznatky k ˇre ˇsen´ı
Hodnoty odraˇzen´eho svˇetla od povrchu se mohou mˇenit, pokud realizujeme ´ulohu v jin´em prostˇred´ı. Senzor nen´ı na zaˇc´atku kalibrov´an a podle prostˇred´ı je ovliv ˇnov´an i okoln´ım svˇetlem. V d ˚usledku tˇechto vlastnost´ı se mus´ı hodnoty podm´ınek zmˇenit dle aktu´aln´ıho prostˇred´ı, kde se ´uloha realizuje.
V pr ˚ubˇehu ˇreˇsen´ı t´eto ´ulohy jsme narazili na probl´em komunikace robota a MRDS pˇres bluetooth. Jelikoˇz bylo potˇreba rychl ´ych reakc´ı na zmˇeny, kter´e robot pos´ılal, tak se zv ´yˇsil i poˇcet zpr´av, kter´e se zaˇcaly ztr´acet a robot se nechoval tak, jak bychom chtˇeli. V kapitole 3.3 je pops´an zp ˚usob pˇrenosu zpr´av mezi robotem a poˇc´ıtaˇcem. Robot pˇri pr ˚umˇern´e rychlosti j´ızdy nest´ıhal adekv´atnˇe reagovat na pokyny poˇc´ıtaˇce. Tyto probl´emy n´as nutily ´ulohu optimalizovat.
Optimalizaci jsme provedli metodou pokus ˚u. Vyuˇzili jsme sn´ıˇzen´ı rychlosti ot´aˇcen´ı robota do stran a ´upraven´ı hodnoty frekvence sbˇeru dat z svˇeteln´eho senzoru a servo mo-toru. Tato frekvence urˇcuje v jak´em ˇcasov´em intervalu bude zasl´ana zpr´ava o aktu´aln´ım stavu senzoru na poˇc´ıtaˇc. Nastavuje se v konfiguraˇcn´ım oknˇe dan´eho senzoru. Defaultnˇe je nastavena na hodnotu 0. V naˇs´ı ´uloze jsme nakonec zvolili nastaven´ı pro svˇeteln ´y sen-zor na 150 ms a pro servo motory na 80 ms.
Tato optimalizace by nebyla potˇreba, kdybychom nepotˇrebovali komunikovat s poˇc´ı-taˇcem pˇres bluetooth. Programy vytvoˇren´e v software pro LEGO NXT robota se nahraj´ı pˇr´ımo do ˇr´ıd´ıc´ı jednotky a odpad´a probl´em se ztr´atami zpr´av. J´ızdu po ˇc´aˇre lze pomoc´ı tohoto softwaru realizovat plynuleji, rychleji a spolehlivˇeji neˇz pˇres MRDS.
6
Labyrint
C´ılem ´ulohy bylo navrhnout a realizovat pr ˚uchod robota nezn´am ´ym bludiˇstˇem a vyh-led´an´ı nejkratˇs´ı moˇzn´e cesty skrz labyrint ze startu do c´ıle. Bludiˇstˇe je ˇctvercov´a s´ıt’ reali-zov´ana ˇcern ´ymi linkami na svˇetl´e podloˇzce. Vzor moˇzn´eho bludiˇstˇe je na obr´azku ˇc. 18. Kˇriˇzovatky jsou b´ıl´e ˇctverce na kˇr´ıˇzen´ıch ˇcern´e p´asky tak, aby robot mohl rozpoznat, ˇze dojel na kˇriˇzovatku.
Obr´azek 18: Vzor labyrintu
6.1 N ´avrh
Z´akladem ´ulohy je j´ızda po ˇc´aˇre pomoc´ı svˇeteln´eho senzoru. Jakmile robot vid´ı b´ılou barvu, v´ı, ˇze se ocit´a na kˇriˇzovatce, kterou je tˇreba prohledat. Zjiˇst’uje, jak´e jsou moˇzn´e cesty odjezdu z kˇriˇzovatky a informace si ukl´ad´a. Start a c´ıl jsou reprezentov´any silnˇejˇs´ım b´ıl ´ym pruhem v bludiˇsti tak, aby pˇri prohled´av´an´ı kˇriˇzovatky robot uvidˇel tˇrikr´at b´ılou barvu m´ısto oˇcek´av´an´e ˇcern´e (hled´an´ı cesty pˇred n´ım, vpravo a vlevo). Z tˇechto informac´ı usoud´ı, kde je c´ıl.
Pˇri j´ızdˇe a v ´ybˇeru dalˇs´ı kˇriˇzovatky pouˇz´ıv´ame typick ´y grafov ´y algoritmus prohled´a-v´an´ı do hloubky. Povaˇzujme kˇriˇzovatky v bludiˇsti za vrcholy v grafu. Z´akladn´ı myˇslen-kou prohled´av´an´ı grafu do hloubky (tzv. Depth first search) je snaha postupovat st´ale
d´al od poˇc´ateˇcn´ıho vrcholu dosud neprozkouman ´ym smˇerem. Pokud doraz´ıme do vr-cholu, ze kter´eho jiˇz nevede neprozkouman´a cesta, pak se vrac´ıme k prvn´ımu moˇzn´emu vrcholu, ze kter´eho vede alespo ˇn jedna neprozkouman´a cesta a d´ale prohled´av´ame n´a-sleduj´ıc´ı vrcholy (tzv. backtracking).
Pokud m´ame uloˇzen´e informace o bludiˇsti - jeho vrcholy a cesty, pak napˇr´ıklad podle Dijsktrova algoritmu nech´ame nal´ezt nejkratˇs´ı cestu. Robota um´ıst´ıme na v ´ychoz´ı pozici a robot projede bludiˇstˇe aˇz do c´ıle.
6.2 Postup ˇre ˇsen´ı
V t´eto ´uloze vyuˇz´ıv´ame algoritmus popsan ´y v kapitole 5.5. Jakmile robot vid´ı b´ılou barvu, spouˇst´ı se vl´akno, na kter´em prob´ıh´aj´ı aktivity pro zpracov´an´ı kˇriˇzovatky - za-pisov´an´ı moˇzn ´ych cest, sousedn´ıch vrchol ˚u a dalˇs´ı. Jedin´a informace, kterou robot zn´a pˇred spuˇstˇen´ım programu, je poˇcet kˇriˇzovatek v bludiˇsti, nicm´enˇe nev´ı nic o um´ıstˇen´ı startu, c´ıle ani o struktuˇre bludiˇstˇe.
Aplikace m´a vytvoˇren vlastn´ı souˇradnicov ´y syst´em s x-ovou a y-ovou osou a vˇzdy podle pohybu ukl´ad´ame aktu´aln´ı um´ıstˇen´ı v bludiˇsti. D´ale oznaˇcujeme vrcholy grafu = kˇriˇzovatky bludiˇstˇe, ˇc´ıslem. Neˇz se robot zaˇcne pohybovat, m´ame urˇcenou sadu smˇer ˚u, coˇz je reprezentace smˇer ˚u z vrchol ˚u ˇc´ısly (nahoru - 1, dol ˚u - 3, doprava - 2, doleva - 4). Uchov´av´ame si i informaci o tom, o kolik stup ˇn ˚u je robot otoˇcen ´y, a podle toho se tak´e sada smˇer ˚u mus´ı mˇenit, aby z ˚ustaly zachov´any stejn´a ˇc´ısla pro spravn´e smˇery.
V programu pracujeme s matic´ı sousednosti vrchol ˚u v grafu. Jakmile robot pˇri j´ızdˇe uvid´ı b´ılou kˇriˇzovatku, jako prvn´ı se prov´ad´ı kontrola souˇradnic a ˇc´ısla vrcholu. Zjiˇst’u-jeme, jestli nejsme ve vrcholu, ve kter´em jsme uˇz byli, a pokud je vrchol nov ´y, pak ho mus´ıme prohledat a informace zaznamenat.
Podle dan´eho smˇeru a otoˇcen´ı se transformuje sada smˇer ˚u. Robot dostane pˇr´ıkaz k prohled´an´ı kˇriˇzovatky, coˇz je realizov´ano j´ızdou vpˇred o 7 cm tak, aby byl senzor nad ces-tou, a nasledn ´ym otoˇcen´ım o 90 stup ˇn ˚u vpravo a 180 stup ˇn ˚u vlevo, abychom zkontrolo-vali vˇsechny smˇery. Informace o moˇzn ´ych smˇerech zapisujeme pomoc´ı ˇc´ısel do matice smˇer ˚u. Z´arove ˇn do t´eto matice na prvn´ı dvˇe pozice (index 0 a 1) zapisujeme souˇradnice naˇseho syst´emu pro kaˇzd ´y vrchol (x-ov´a souˇradnice na index 0 a y-ov´a souˇradnice na in-dex 1). Souˇradn ´y syst´em zav´ad´ıme, abychom se vyhli zacyklen´ı robota. Jelikoˇz je bludiˇstˇe pravo ´uhl´e, robot by mohl jezdit st´ale do ˇctverce aniˇz by vˇedˇel, ˇze uˇz vrcholy proˇsel. Souˇradn ´y syst´em toto zacyklen´ı vyluˇcuje. Matice seznam smeru m´a poˇcet ˇr´adk ˚u identick ´y s poˇctem kˇriˇzovatek v bludiˇsti. Sloupce matice jsou x-ov´a souˇradnice, y-ov´a souˇradnice a n´asleduj´ıc´ı 4 sloupce reprezentuj´ı moˇzn´e smˇery vedouc´ı z vrcholu(nahoru, doprava, dol ˚u, doleva). Do matice zapisujeme hodnoty 0, 1 a 2, kter´e reprezentuj´ı informaci, zda cesta v dan´em smˇeru neexistuje (0), je objeven´a (1) nebo je projet´a (2). Pˇri kaˇzd´em otoˇcen´ı robota zapisujeme do promˇennˇe orientace hodnotu 0 - 360. Hodnota 0 stup ˇn ˚u pˇr´ısluˇs´ı jizdˇe v pˇred, 90 stup ˇn ˚u otoˇcen´ı vpravo atp.
Po zkontrolov´an´ı kˇriˇzovatky se robot rozhoduje kudy pojede k dalˇs´ımu vrcholu. Jiˇz m´ame zjiˇstˇeno, kter´e cesty z dan´eho vrcholu vedou a jestli jsou prohledan´e nebo ne. Robot si podle algoritmu vyb´ır´a prvn´ı moˇznou cestu s oznaˇcen´ım 1 (objeven´a, ale ne-prohledan´a) a skrze n´ı jede k dalˇs´ımu vrcholu. Jakmile je urˇcen smˇer odjezdu z vrcholu
je moˇzn´e spoˇc´ıtat souˇradnice pro dalˇs´ı vrchol (standardnˇe pˇri j´ızdˇe nahoru, resp. dol ˚u se pˇriˇc´ıt´a, resp. odeˇc´ıt´a 1 na ose y a pˇri j´ızdˇe doprava, resp. doleva se pˇriˇc´ıt´a, resp. odeˇc´ıt´a 1 na ose x). Tyto souˇradnice se pˇri pˇr´ıjezdu na dalˇs´ı vrchol kontroluj´ı pˇres matici smˇer ˚u, abychom zjistili, jestli robot v tomto vrcholu jeˇstˇe nebyl. Postupn´e smˇery odjezd ˚u z kˇriˇzovatek si ukl´ad´ame do seznamu pro pˇr´ıpadn ´y backtracking.
Tento postup opakujeme tak dlouho aˇz naraz´ıme na vrchol, ze kter´eho jiˇz nen´ı moˇzno odjet po cestˇe oznaˇcen´e 1. V tom pˇr´ıpadˇe se podle algoritmu prohled´av´an´ı grafu do hloubky vr´at´ıme na prvn´ı moˇzn ´y vrchol, ze kter´eho takov´a cesta vede. Tuto kˇriˇzovatku nalezneme pomoc´ı tzv. backtrackingu v seznamu smˇer ˚u odjezdu z kˇriˇzovatek. Seznamem budeme proch´azet od posledn´ıho prvku a smˇery transformovat na opaˇcn´e, t´ım se dosta-neme aˇz k poˇzadovan´emu vrcholu. Z tohoto vrcholu opˇet pokraˇcujeme v prohled´av´an´ı bludiˇstˇe. Ve chv´ıli, kdy jsou vˇsechny vrcholy matice vyplnˇen´e a vˇsechny cesty oznaˇcen´e ˇc´ıslem 2 (objeven´e a projet´e), pak je bludiˇstˇe prohled´ano. Pomoc´ı Dijkstrova algoritmu nalezneme v matici sousednosti nejkratˇs´ı moˇznou cestu bludiˇstˇem a cestu uloˇz´ıme po-moc´ı smˇer ˚u do seznamu, ze kter´em pˇri n´asledn´e j´ızdˇe postupnˇe ˇcteme smˇery dojezdu z kˇriˇzovatek.
6.3 Implementace a poznatky
Cel´a ´uloha je ˇreˇsena ve VPL. Pro j´ızdu po bludiˇsti vyuˇz´ıv´ame algoritmus j´ızdy po ˇc´aˇre. Ve VPL m´ame jednotliv´e ˇc´asti programu rozdˇeleny do nov ´ych aktivit. Program obsahuje ak-tivity jizda, zpracovani, krizovatka, prevod indexu, zapis do seznamu a novy seznam. Vˇetˇsina tˇechto aktivit m´a naimplementov´any i svoje akce, napˇr´ıklad j´ızda m´a akce Otoc, Transfor-mace SadySmeru a TransforTransfor-mace SmerNaStupne.
VPL neposkytuje jako datovou strukturu jednorozmˇern´e ani dvourozmˇern´e pole. Nic-m´enˇe pro naˇsi ´ulohu jsme potˇrebovali pracovat s matic´ı. Jednorozmˇern´e pole lze ve VPL realizovat pomoc´ı sluˇzby ByteArray, kter´a um´ı konvertovat seznam ˇc´ısel datov´eho typu byte na jednorozmˇern´e pole a naopak. S jin ´ymi poli ve VPL pracovat nelze. Naˇse matice jsme museli reprezentovat jednorozmˇern ´ym polem tak, ˇze jsme jakoby poskl´adali ˇr´adky za sebe, toto vˇse jsme uloˇzili do seznamu a n´aslednˇe pˇrevedli pomoc´ı sluˇzby ByteArray na pole. Z tohoto pole lze klasicky ˇc´ıst prvky dle indexu apod.
Z´apis prvku do matice, resp. seznamu je ˇreˇsen specifick ´ym zp ˚usobem. Nejdˇr´ıve je tˇreba pole pˇrev´est na seznam a prvek na dan´em indexu smazat a pak na dan ´y index poˇzadovanou hodnotu zapsat. Vˇsechny tyto operace jsou prov´adˇeny nad aktivitou List Functions. Pokud jsou vˇsechny ´upravy na seznamu dokonˇceny je opˇet zapotˇreb´ı seznam konvertovat na pole byt ˚u.
Pˇri realizaci jsme se opˇet museli pot ´ykat s probl´emy komunikace robota a poˇc´ıtaˇce pˇres bluetooth. Opˇet jsme museli ˇreˇsit rovnov´ahu pos´ılan ´ych zpr´av pomoc´ı frekvence sbˇeru dat na svˇeteln´em senzoru a motoru. Aby robot dostateˇcnˇe rychle reagoval na zmˇenu barvy je hodnota frekvence sbˇeru dat na svˇeteln´em senzoru vyˇsˇs´ı neˇz u j´ızdy po ˇc´aˇre.
Bˇehem implementace jsme vyuˇz´ıvali dvˇe r ˚uzn´e aktivity merge a join. Rozd´ıl nen´ı zˇrejm ´y. Nicm´enˇe vypl ´yv´a z fuknˇcnosti a ovl´ad´an´ı vl´akna. Merge spojuje datov´e toky a jakmile pˇrijdˇe na spoj alespo ˇn jeden z nich, pak proch´az´ı d´al. Join spojuje tak´e datov´e toky, ale ˇcek´a aˇz na spoj doraz´ı vˇsechny vstupn´ı toky a n´aslednˇe pos´ıl´a impulz d´ale.
Tato ´uloha by se standardnˇe neˇreˇsila pomoc´ı vl´aken, ale sekvenˇcn´ım programov´an´ım. Nicm´enˇe pr´ace ve VPL je zaloˇzena na vl´aknech. Pˇrep´ın´an´ı mezi vl´aknem j´ızdy po ˇc´aˇre a vl´aknem, kter´e ˇreˇs´ı z´apis a zpracov´an´ı kˇriˇzovatky ˇr´ıd´ı pomocn´a promˇenn´a typu bool. 6.4 Nevyˇre ˇsen ´e probl ´emy
V pr ˚ubˇehu pr´ace ve VPL jsem doˇsli k z´avˇeru, ˇze VPL je moˇzno pouˇz´ıvat pro aplikace jednoduˇsˇs´ı na datov´e struktury a sluˇzby bez sloˇzitˇejˇs´ıch algoritm ˚u. V diagramu, kter ´y ob-sahuje v´ıce neˇz 70 komponent, si VPL zab´ır´a velk´e mnoˇzst´ı RAM pamˇeti a pr´ace v nˇem se st´av´a nerealizovatelnou. Naˇse ´uloha byla realizov´ana i pomoc´ı vlastn´ıch aktivit s akcemi. Poˇcet komponent v hlavn´ım diagramu se sn´ıˇzil, ale ne na realizovateln´e mnoˇzstv´ı.
Realizac´ı v re´aln´em prostˇred´ı n´am vyplynuly i fyzik´aln´ı aspekty ´ulohy. Vzhledem ke komunikaci pˇres bluetooth nebyl robot schopen pˇri ot´aˇcen´ı na kˇriˇzovatk´ach reagovat dostateˇcnˇe rychle na ˇcernou ˇc´aru, kterou vidˇel. Proto jsme ot´aˇcen´ı ˇr´ıdili poˇctem stup ˇn ˚u, vzhledem k tomu, ˇze bludiˇstˇe je pravo ´uhl´e, tak by to nemˇel b ´yt probl´em. Nicm´enˇe robot na kˇriˇzovatku mnohdy nepˇrijede otoˇcen pˇresnˇe rovnˇe, jak bychom chtˇeli a t´ım p´adem i n´asledn´e otaˇcen´ı je chybn´e. Toto vych´az´ı z algoritmu zig-zag pˇri j´ızdˇe po ˇc´aˇre, kdy robot sleduje hranu mezi b´ılou a ˇcernou a m ˚uˇze na kˇriˇzovatku dojet lehce natoˇcen ´y jin ´ym smˇerem. Tento probl´em by mohl b ´yt eliminov´an pomoc´ı senzoru kompasu, pˇr´ıpadnˇe vyuˇzit´ı dvou svˇeteln ´ych ˇcidel pro detekci ˇc´ary a t´ım p´adem i spr´avn´eho natoˇcen´ı robota. Vzhledem k vyvstal ´ym probl´em ˚um a fyzik´aln´ım chyb´am, kter´e jsme nemohli odstra-nit (napˇr. vyjet´ı robota z ˇc´ary, jak je pops´ano v ´yˇse), jsme se rozhodli pr´aci ukonˇcit ve f´azi realizace prohled´an´ı bludiˇstˇe. Pro korektn´ı vyˇreˇsen´ı ´ulohy by musel robot b ´yt vybaven dalˇs´ım senzorem, coˇz by vyˇzadovalo implementaci nov ´ych aktivit v diagramu VPL pro pr´aci se sluˇzbou dan´eho senzoru. Pro ´upln´e dokonˇcen´ı ´ulohy tj. realizaci vyhled´av´an´ı nejkratˇs´ı cesty v matici sousednosti by pak staˇcilo jen vytvoˇrit novou sluˇzbu, kter´a by realizovala algoritmus pro vyhled´an´ı nejkratˇs´ı cesty (napˇr.: Dijkstr ˚uv algoritmus).
7
Z ´av ˇer
V pr´aci jsme se sezn´amili s multiplatformn´ım n´astrojem pro programov´an´ı robotick ´ych aplikac´ı MRDS. V prvn´ı ˇc´asti se zab ´yv´ame teoretick ´ym rozborem technologi´ı a popisem struktury MRDS. Popisujeme i simul´ator VSE, ve kter´em implementujeme dvˇe z ´uloh.
L´epe jsme poznali pr´aci v grafick´em n´astroji MRDS, ve VPL. I jeho struktura je v pr´aci pˇredstavena. V praktick´e ˇc´asti jsme popsali probl´emy s implementac´ı ´uloh ve VPL.
Navrhli jsme nˇekolik ´uloh, kter´e jsme realizovali pomoc´ı robota LEGO NXT. Popsali jsme funkce a pouˇzit´ı vˇsech z´akladn´ıch senzor ˚u, kter´e jsou dod´av´any spoleˇcnˇe s robotem ve stavebnici LEGO NXT Mindstorms.
Pr´aci v simul´atoru jsme demonstrovali na ´uloze Naklonˇen´a rovina a Pˇrek´aˇzka, kterou jsme celou namodelovali a rovnˇeˇz jsme ji realizovali v re´aln´em prostˇred´ı. Pr´ace popisuje postup implementace a probl´emy, se kter ´ymi jsme se setkali.
Ostatn´ı navrˇzen´e ´ulohy pˇredstavily pr´aci ve VPL a MRDS. Narazili jsme na ´usk´al´ı ko-munikace robota a poˇc´ıtaˇce pomoc´ı bluetooth. Kv ˚uli tˇemto probl´em ˚um jsou mnoh´e ´ukoly pro robota probl´emem. V ´yhodou MRDS je moˇznost programov´an´ı r ˚uzn ´ych typ ˚u robo-ta. Nicm´enˇe za m´ınus m ˚uˇzeme povaˇzovat nemoˇznost konverze k ´odu z MRDS a pˇr´ım´e nahr´an´ı do robota. Software dod´av´an ´y s robotem (jazyk NXT-G) umoˇz ˇnuje nahr´at pro-gram pˇr´ımo do robota, a t´ım odpadaj´ı probl´emy s komunikac´ı. Robot reaguje na podnˇety podstatnˇe rychleji a ´ulohy jsou efektivnˇejˇs´ı.
Pr´ace na ´uloze Labyrint byla ukonˇcena dˇr´ıve, jelikoˇz jsme narazili na probl´em s prac´ı ve VPL s mnoha komponentami. Tento n´astroj nen´ı urˇcen ´y pro implementaci program ˚u, ve kter´em je tˇreba vyuˇz´ıvat mnoho komponent. D´ale vznikaly nepˇresnosti v pohybu rob-ota d´ıky fyzik´aln´ım aspekt ˚um ´ulohy.
Zaj´ımav ´ym n´amˇetem na dalˇs´ı ˇreˇsen´ı by mohla b ´yt realizace ´ulohy labyrint pomoc´ı v´ıce senzor ˚u, kter´e jiˇz nejsou obsahem z´akladn´ı stavebnice (napˇr. kompas, senzor barvy nebo senzor naklonˇen´ı). Vˇsechny ´ulohy byly realizov´any jen s robotem LEGO NXT. Pˇr´ı-nosem ve zkoum´an´ı programov´an´ı v MRDS by se mohla st´at i realizace jedn´e identick´e ´ulohy na robotovi LEGO NXT a jin´em typu robota. N´asledn´e porovn´an´ı komunikace a implementace m ˚uˇze pˇr´ın´est nov´e poznatky a v ´ysledky.
8
Literatura
[1] Morgan, Sara, Programming Microsoft Robotics Studio, Washington: Microsoft Press, 2008.
[2] Johns, Kyle, Taylor, Trevor, Professional Microsoft Robotics Developer Studio, Indi-anapolis: Wiley Publishnig Inc., 2008.
[3] LEGO c MINDSTORMS User Guide, The LEGO Group., 2007.
[4] Gasperi, Michael, Hurbain, Philippe, Hurbain, Isabelle Extreme NXT: Extending the LEGO MINDSTORMS NXT to the Next Level, California: Apress, 2007.
[5] Josefnav.cz [online]. Dostupn ´y z WWW: http://www.josefnav.cz/index.htm [cit. bˇrezen 2010 ]
[6] FrankPr’s World of Devices [online]. Dostupn ´y z WWW: http://blogs.msdn.com/frankpr [cit. bˇrezen 2010 ] [7] Wikimedia Commons [online]. Dostupn ´y z WWW:
http://commons.wikimedia.org/wiki/File:3D coordinate system.svg [cit. 7.4.2010 ]
[8] Lego camp 2007 [online]. Dostupn ´y z WWW:
http://engk12.ece.missouri.edu/LegoCamp/Gallery.html [cit. 2010-04-07 ] [9] RobotShop [online]. Dostupn ´y z WWW:
http://www.robotshop.ca/ProductSearch.aspx?qs=nxt [cit. 2010-04-07 ] [10] Wikipedie [online]. Dostupn ´y z WWW: http://cs.wikipedia.org/wiki
[cit. 2010-04-07 ]
[11] Tel Aviv University - Analysis of the NXT Bluetooth-Communication Protocol [online]. Dostupn ´y z WWW: http://www.tau.ac.il/∼stoledo/lego/btperformance.html [cit. 2010-04-08 ]
[12] Technologie NVIDIA PhysX [online]. Dostupn ´y z WWW:
http://www.nvidia.com/object/physx new.html [cit. 2010-04-28 ]
[13] Anim8or [online]. Dostupn ´y z WWW: http://www.anim8or.com/main/index.html [cit. 2010-04-28 ]
A
Obsah CD
• text pr´ace
• zdrojov´e soubory s ´ulohami - sloˇzka ULOHY\ULOHA_Cislo_NazevUlohy • software pro modelov´an´ı objekt ˚u - Anim8or
