Mendelova univerzita v Brně Provozně ekonomická fakulta
Vytvoření knihovny do systému Control Web pro plný přístup k NXT Mindstorms Diplomová práce
Vedoucí práce: Dr. Ing. Radovan Kukla
Bc. Michal Kamenský
Brno 2013
Místo této strany bude list zadání
Rád bych na tomto místě poděkoval vedoucímu mé práce panu Dr. Ing. Radovanu Kuklovi za odborné vedení, Ing. Richardu Kleinovi a Ing. Janu Kolomazníkovi za odborné rady a panu Mirkovi Zálešákovi, z technické podpory pro systém Control Web, za odbornou pomoc při řešení unikátních problémů.
Prohlašuji, že jsem tuto práci vyřešil samostatně s použitím literatury, kterou uvádím v seznamu. V Brně dne 8. prosince 2013
__________________
Abstract Bc. Kamenský. M. Create a library into the system Control Web for full control NXT Mindstorms. Master's thesis. Brno, 2013. This thesis deals with making connection between the Lego Mindstorms NXT 2.0 and the Control Web system. Thesis contains description of communication between NXT brick and computer, and creation of driver into the Control Web system. There is also description of created libraries and their using in new application for Control Web system. Keywords Lego, Mindstorms, NXT, control, Control Web, communication, library.
Abstrakt Bc. Kamenský. M. Vytvoření knihovny do systému Control Web pro plný přístup k NXT Mindstorms. Diplomová práce. Brno, 2013. Práce se zabývá propojením Lego Mindstorms NXT 2.0 se systémem Control Web. Práce obsahuje popis komunikace mezi NXT kostkou a počítačem a tvorbu ovladače v systému Control Web. Dále obsahuje popis tvorby výsledných knihoven a jejich použití v nových aplikacích systému Control Web. Klíčová slova Lego, Mindstorms, NXT, ovládání, Control Web, komunikace, knihovna.
Obsah
6
Obsah 1
2
Úvod a cíl práce 1.1
Úvod .......................................................................................................... 8
1.2
Cíl práce .................................................................................................... 8
Robot 2.1
9
Robot Lego Mindstorms ..........................................................................10
2.1.1
Programovatelná řídící jednotka ..................................................... 11
2.1.2
Servomotory.....................................................................................12
2.1.3
Senzory.............................................................................................13
2.1.4
Světelný senzor ................................................................................13
2.1.5
RGB senzor.......................................................................................14
2.1.6
Ultrazvukový senzor ........................................................................14
2.1.7
Dotykový senzor...............................................................................15
2.1.8
Zvukový senzor ................................................................................15
2.2
Lego Mindstorms a komunikace přes bluetooth.....................................15
2.2.1
Bluetooth..........................................................................................16
2.2.2
Bluetooth - přenos dat .....................................................................16
2.3
Lego Mindstorms komunikační protokol................................................ 17
2.3.1 3
8
RealTerm – sériový terminál ...........................................................18
Control Web 3.1
22
Pracovní prostředí .................................................................................. 22
3.1.1
Grafický editor ................................................................................ 23
3.1.2
Textový editor ................................................................................. 25
3.1.3
Datové inspektory ........................................................................... 25
3.2
Překlad v Control Webu.......................................................................... 26
3.3
Události a aktivace .................................................................................. 26
3.4
Ovladače a kanály ................................................................................... 27
3.4.1
Volba vhodného ovladače ............................................................... 28
3.4.2
Ovladač ASCDRV5 .......................................................................... 29
Obsah 4
7
Vlastní práce 4.1
Vývoj jako aplikační knihovna................................................................ 33
4.2
Návrh grafického rozhraní...................................................................... 33
4.3
Servomotory............................................................................................ 34
4.3.1 4.4
Knihovna Motor .............................................................................. 35
Senzory.................................................................................................... 39
4.4.1
Knihovna Touch.............................................................................. 43
4.4.2
Knihovna Sound.............................................................................. 47
4.4.3
Knihovna Light ............................................................................... 49
4.5 5
32
Použití knihoven v nové aplikaci .............................................................51
Závěr
55
5.1
Shrnutí práce .......................................................................................... 55
5.2
Zhodnocení výsledků .............................................................................. 55
5.3
Budoucí využití a možná rozšíření ......................................................... 55
6
Literatura
56
A
Mapovací soubor
59
B
Parametrický soubor
60
C
Knihovna Motor
61
D
Knihovna Touch
62
E
Knihovna Sound
63
F
Knihovna Light
64
G
DVD se zdrojovými soubory knihoven
65
Úvod a cíl práce
8
1 Úvod a cíl práce 1.1
Úvod
Slovem robot se označují samostatně pracující stroje. Tyto stroje v posledních několika desetiletích zažívají rychlý rozvoj, zejména díky počítačům a pokročilejší elektronice. Tomuto rychlému rozvoji také dopomohli průmyslové roboty, které velmi zrychlují a zlevňují výrobu a začaly se tak ve velkém do výroby nasazovat. Roboty lze dnes ale najít na řadě dalších míst jako je například lékařství či vojenství ale dostaly se i k dětem v podobě hraček nebo do kuchyní, kde usnadňují rutinní činnosti. Vývoji na poli robotiky, tedy oboru, který se studiem a konstrukcí robotů zabývá, se v posledních letech věnuje mnoho pozornosti i na vysokých školách a univerzitách, kde vznikla řada předmětů zabývajících se touto problematikou. Tato práce se zabývá ovládáním robota, který se nacházejí na půdě univerzity. Na základě zadání této práce, vzniknou knihovny, kterými bude možné tohoto robota ovládat. Knihovny budou mít, kromě procedur v aplikačním rozhraní i grafickou podobu, díky které bude možné ovládat robota i pomocí jednotlivých ovládacích prvků. Výsledná práce bude sloužit při výuce a studenti pomocí těchto knihoven budou moci vytvářet zadané úlohy.
1.2 Cíl práce Cílem práce je vytvořit knihovny do systému Control Web, pomocí kterých bude možné ovládat robota Lego Mindstorms NXT 2.0. Pro propojení Lego robota se systémem Control Web bude použito ovladače v tomto systému, který bude tuto komunikaci zprostředkovávat. Knihovny budou skrze své aplikační rozhraní, poskytovat procedury, které budou sloužit k ovládání tohoto robota. Všechny knihovny budou mít i grafickou podobu a budou obsahovat přístroje, pomocí kterých bude možné také robota ovládat. Hotové knihovny budou sloužit k výuce a položí základ pro budoucí možné rozšíření o nové senzory a funkce.
Robot
9
2 Robot Robot je stroj, který pracuje s určitou mírou samostatnosti. Vykonává určené úkoly, a to předepsaným způsobem a při různých mírách potřeby integrace s okolním světem a se zadavatelem. Robot vnímá své okolí pomocí senzorů a je schopen do něj zasahovat, případně si o něm vytvořit vlastní představu. Vnímáním světa je schopen ho poznávat a zároveň také vyhodnocovat svůj vliv na něj a využívat tak zpětnou vazbu. Všeobecně je robot chápán jako stroj, který vykonává podobné činnosti jako člověk, především však činnosti pohybové a manipulační. Většinou musí takový stroj získávat informace o prostředí ve kterém se pohybuje a musí být schopen toto prostředí fyzikálně, především mechanicky, ovlivňovat.[1] To zajišťuje jeho motorický subsystém, ten svými efektory prostředí ovlivňuje. Efektory také zajišťují pohyb robota v prostoru. Robot musí být schopen nějakým způsobem reagovat na prostředí a jeho změny. To zajišťuje senzorický subsystém. Nad těmito systémy je nadřazen kognitivní subsystém, ve kterém probíhá rozhodovací a hlavní řídicí činnost. V tomto subsystému je ukryta inteligence robota. Senzorický systém je rozdělen na dvě části – receptory, které snímají fyzikální signály z prostředí a převádí je na vhodné vnitřní signály, a systém zpracování a výběru dat, který vybírá z takových signálů informace důležité pro robota. [2] Cíl Kognitivní subsystém
Plánování a řešení úloh
Motorický subsystém
K
Model prostředí
Realizátor plánů
O
Vnímání a chápání
K
Zpracování a výběr dat
Efektory
R
R
Prostředí
Receptory
Senzorický subsystém
Obr. 1
Blokové schéma robota
Oborem, který se zabývá studiem a konstrukcí robotů a jim podobných zařízení, je robotika. Robotika je moderní multidisciplinární obor zahrnující znalosti mechaniky, elektrotechniky, teorie řízení, měřící techniky, umělé inteligence a celé řady dalších disciplín. Robotika je v současné době nejvíce propojena s oborem
Robot
10
automatizace a může být chápána také jako snaha o automatizaci procesů a činností, které až dosud úspěšně vzdorovaly této snaze, jako např. manipulační činnosti. První zařízení, dnes označovaná jako roboty, jsou zmiňována již v začátcích našeho letopočtu. Slovo robot je však známo od r. 1920 zásluhou bratří Čapků a objevuje se poprvé v jejich hře R.U.R. Celá historie robotiky a zřejmě i její dohledná budoucnost je spojena se snahou vytvořit umělou, pokud možno nebiologickou napodobeninu člověka. Při této snaze však postupně vzniká řada technicky a ekonomicky užitečných robotů, kteří již dnes významně ulehčují člověku život. V současné době se do popředí výzkumu v robotice dostávají mobilní roboty. [1]
2.1 Robot Lego Mindstorms Je programovatelnou stavebnicí vyvinutou společností Lego. Jedná se o produkt, který v sobě skloubí výhody klasické lego stavebnice – otevřenost a volnost pří stavění s programovatelnou možností ovládání robota. Stavebnice Lego Mindstorms je navržena tak, aby dokázala zabavit jak dětí tak dospělé. Slouží ale i jako vhodná učební pomůcka pro studenty nebo učitele. Stavebnice Lego Mindstorms se již představila v několika verzích. Jako první přišla na trh v roce 1998 stavebnice RCX (Lego Mindstorms RCX). Tato stavebnice byla vyvinuta ve spolupráci s laboratoří MIT (Massachusetts Institute of Technology). Další verze se dostala na trh v roce 2006 pod názvem Lego Mindstorms NXT. Hlavním rozdílem, oproti minulé verzi, byla, kromě vylepšeného hardwaru a designu, možnost připojení robota pomocí bezdrátové technologie Bluetooth. V roce 2009 se na trh dostala vylepšená verze s názvem NXT 2.0. Tato verze oproti minulé podporuje operace s desetinou čárkou a v základu obsahuje nový barevný senzor. V srpnu 2013 představila společnost Lego zatím poslední verzi Lego Mindstorms EV3. Tato verze je kromě výkonnějšího hardwaru vybavena USB pro wifi a čtečkou microSD karet. Mendelova univerzita vlastní několik robotů Lego Mindstorms NXT 2.0, které slouží k výuce. Z tohoto důvodu byla tato verze vybrána pro tvorbu mé práce. [9] Základním prvkem stavebnice je inteligentní programovatelná řídící jednotka (tzv. NXT kostka), ke které je možné v základu připojit až tři servomotory a čtyři senzory.
Robot
11
Obr. 2
Lego Mindstorms NXT 2.0 – NXT kostka se zapojenými servomotory a senzory
2.1.1
Programovatelná řídící jednotka
NXT kostka je nejdůležitější součástkou stavebnice Lego Mindstorms. Je osazena 32-bit mikroprocesorem s flash pamětí o velikosti 256KB. Kostku pak lze připojit k PC buď přes USB kabel nebo přes bezdrátovou technologii bluetooth. Bluetooth umožňuje bezdrátové připojení mezi dalšími NXT kostkami, počítačem, mobilním telefonem nebo jiným bluetooth zařízením. Na čelní straně se nachází čtyři ovládací tlačítka (doleva, doprava, enter a escape) umožňující pohyb v menu. Kromě těchto tlačítek dominuje čelní straně monochromatický maticový LCD display o rozlišení 100 × 64 pixelů. Display slouží především pro zobrazení uživatelského prostředí. Lze ho ale použít i jako zobrazovač dat při běhu vytvořeného programu. Kostka je také vybavena vestavěným reproduktorem, který umožňuje přehrávat tóny. Napájet kostku je možné buď šesticí baterií typu AA (tužkové baterie) nebo nabíjecím akumulátorem, který je tvarově uzpůsoben tak aby se vešel na místo určené pro baterie. [10] Kostka má tří výstupní (A-C) a čtyři vstupní (1-4) porty. Výstupní porty jsou určeny pro servomotory a vstupní pro senzory. Propojení mezi motory (ale i senzory) a porty je realizováno přes 6-drátové kabely (RJ12). Standardní nastavení portů pro senzory a servomotory je následují:
Robot
12
Vstupní porty • Port 1: Dotykový senzor • Port 2: Dotykový senzor • Port 3: Senzor barev • Port 4: Ultrazvukový senzor Výstupní porty • Port A: Motor pro dodatečné funkce • Port B: Motor pro pohyb • Port C: Motor pro pohyb 2.1.2
Servomotory
Motory dodávané se stavebnicí jsou poměrně výkonné. Musí si poradit s možnou vyšší váhou robota nebo jízdě po nakloněné rovině. Po zapojení dvou motorů sloužících pro pohyb vpřed nebo vzad se z robota stává vozidlo typu tank. To znamená, že ke změně směru neslouží natáčení kol ale změna rychlosti jednoho či druhého kola v závislosti na požadované změně směru. Například, je-li požadavkem, aby robot změnil směr doleva, je nutné aby se levé kolo robota otáčelo pomaleji než to pravé. To je důvod proč je součástí motoru impulzní senzor otáček, který snímá natočení robota s přesností ±1%. Motory ovšem nemusí sloužit jen pro pohyb robota. Mohou například sloužit pro ovládání ramene. Proto jsou na NXT kostce tři výstupní porty.
Obr. 3
Vnitřní pohled na servomotor
Robot
2.1.3
13
Senzory
Senzory umožňují aby robot mohl reagovat na vnější prostředí. Ke kostce je možné naráz připojit až čtyři senzory (Porty 1 až 4). Se stavebnicí Lego jsou standardně přibaleny tyto senzory: • Světelný senzor • RGB senzor • Ultrazvukový senzor • Dotykový senzor • Zvukový senzor Kromě těchto základních senzorů existuje cela řada dalších a to nejen od společnosti Lego ale i od ostatních výrobců (např. HiTechnic). 2.1.4
Světelný senzor
Světelný senzor umožňuje kromě detekce intenzity světla také rozlišovat barvy v odstínech šedi. Součástí senzoru je i LED dioda, která je v závislosti, je-li aktivován mód detekce intenzity světla nebo detekce odstínu šedi, buď zapnutá nebo vypnutá. Je-li dioda zapnutá je v módu detekce odstínu šedi (osvětluje detekovaný objekt). Tento detekovaný objekt část světla pohltí a zbytek odrazí zpět, kde ho zachytí fototranzistor (tento fototranzistor je taktéž součástí senzoru). Se zachyceného odrazu světla se vyhodnotí odstín šedi, který se pohybuje v rozmezí hodnot 0-100. Při práci v tomto módu se doporučuje aby byly barvy co možná nejvíce kontrastní (v ideálním případě černá a bílá). V módu detekce intenzity světla je dioda vypnutá a fototranzistor snímá pouze intenzitu světla okolí. Hodnota odraženého světla je udávaná v procentech.
Obr. 4
Světelný senzor
Robot
2.1.5
14
RGB senzor
Tento senzor se začal dodávat od verze Lego Mindstorms NXT 2.0. Senzor detekuje barvy v barevném modelu RGB. Princip je obdobný jako u senzoru světla. RGB senzor má ovšem diodu, která svítí v barvách červená, zelená a modrá. Světelný senzor je v tomto případě citlivý na všechny světelné délky. Senzor umožňuje rozpoznávání barvy ve dvou módech. RGB vyčítá buď hodnoty intenzit jednotlivých barevných složek nebo Colorval. Ten udává přesné číslo barvy např. 1 pro černou a 6 pro bílou. Při využití tohoto módu je opět doporučeno používat při rozeznávání dostatečně kontrastní barvy ze základní barevné škály (černá, modrá, zelená, žlutá, červená, bílá).
Obr. 5
RGB senzor
2.1.6
Ultrazvukový senzor
Tento senzor umožňuje měřit vzdálenost od objektů, detekovat překážky a pohyb. Vzdálenost je schopen měřit v centimetrech nebo v palcích a to až do vzdálenosti 1,5 metru s přesností ±3 cm. Senzor pracuje na principu sonaru. Vysílá ultrazvukový signál, který se odráží od objektů a vrací zpět do senzoru. Vzdálenost se vypočítá podle času za který se odražený signál vrátí zpět do senzoru. Jeli v blízkosti více robotů, kteří ve stejný čas využijí tento senzor může dojít ke zkreslení naměřených údajů.
Obr. 6
Ultrazvukový senzor
Robot
2.1.7
15
Dotykový senzor
U tohoto senzoru jde v podstatě pouze o tlačítko bez aretace. To znamená, že jediná akce je stisknuto nebo nestisknuto. Tento senzor se používá k detekci překážek. Lze ho také například použít ke zjištění počtu ujitých kroků androidního robota (android je člověku podobný robot).
Obr. 7
Dotykový senzor
2.1.8
Zvukový senzor
Tento senzor měří úroveň hlasitosti zvuku v rozsahu 50-90dB. Hodnoty které senzor vrací jsou však v procentech. Senzor umožní robotovi reagovat na zvukové podněty jako například zatleskání nebo písknutí. [10]
Obr. 8
Zvukový senzor
2.2 Lego Mindstorms a komunikace přes bluetooth Bluetooth zařízení, které je zabudované v NXT kostce umožňuje bezdrátové připojení s počítačem, dalšími NXT kostkami, mobilním telefonem či jiným bluetooth zařízením. Pro komunikaci přes bluetooth má kostka zabudovaný čip CSR BlueCore 4 verze 2, který jí umožňuje připojení až ke třem dalším zařízením zároveň. V jeden časový okamžik však může komunikovat jen s jedním zařízením. Ke komunikaci se využívá Serial Port Profile (SSP), který umožňuje propojení jako bezdrátový sériový port. Pro úsporu energie byla použita technologie bluetooth třídy II, která má za následek snížení dosahu na 10m.
Robot
16
Kostky mezi sebou komunikují pomocí modelu komunikace master/slave. Kdy jedna kostka přebírá jednosměrné řízení nad jednou další nebo více kostkami. Tato řídící kostka se označuje jako master, ostatní kostky mají úlohu slave. Slave kostky nemohou mezi sebou komunikovat přímo. Komunikace mezi dvěma slave kostkami může probíhat pouze přes kostku master. Master kostka nemůže přijímat informace od všech slave kostek najednou, ale vždy jen od jedné z nich. [10] 2.2.1
Bluetooth
Technologie Bluetooth je standard pro připojení různých bezdrátových zařízení pracujícím na krátkou vzdálenost. Poprvé se technologie objevila v roce 1999. Záhy získala velkou oblibu nejen mezi uživateli ale i v mnoha průmyslově nasazovaných aplikacích. Úplné začátky technologie bluetooth ovšem spadají už do roku 1994, kdy divize Mobile Communications Division firmy Ericsson zadala k vypracování studii realizovatelnosti náhrady univerzálního kabelového propojení dvou mobilních telefonů, popřípadě mobilního telefonu s jinými zařízeními. Začátkem roku 1998 byla založena skupina Bluetooth Special Interest Group (BSIG). Za zrodem této skupiny byla pětice firem – IBM, Toshiba, Intel, Ericsson a Nokia. Cílem skupiny bylo vytvořit standard pro Wireless Personal Area Network (WPAN). První hotová specifikace byla uveřejněna v již zmíněném roce 1999 ve verzi 1.0a. [6] Postupem let přicházely novější verze, které vylepšovaly jednotlivé vlastnosti. V součastné době existuje bluetooth ve verzi 4.0. V této verzi se podařilo zlepšit dosah na vzdálenost 100m a snížila se spotřeba elektrické energie. Nově podporuje šifrování AES-128. Přenosová rychlost zůstala stejná jako u předchozí verze 24Mb/s. [7] Název technologie je odvozen ze jména dánského krále Haralda I Blaatanta, kterému se přezdívalo král Modrozub (angl. Bluetooth). Vládl v letech 940 – 981, přivedl do Dánska křesťanství a sjednotil Dánsko s Norskem. [6] 2.2.2
Bluetooth - přenos dat
Bluetooth je otevřený standard pro bezdrátovou komunikaci propojující dvě a více elektronických zařízení. Bluetooth je definován jako vrstvová architektura, kterou tvoří několik základních protokolů. Pro Bluetooth jsou povinné protokoly LMP, L2CAP a SDP. Kromě toho jsou všeobecně podporovány protokoly HCI a RFCOMM. Standard RFCOMM představuje jeden z nejdůležitějších aplikačních protokolů. Emuluje sériové rozhraní RS-232 a přizpůsobuje standardu Bluetooth část specifikace ETSI s označením TS 07.10. Tato specifikace popisuje připojení bodbod mezi dvěma zařízeními prostřednictvím sériového rozhraní typu „vzduch“. RFCOMM má klíčový význam podobně jako drátově připojené rozhraní RS232. [5] Toho bylo využito při tvorbě této práce, která se vyvíjela v programu Control Web. Standardní součástí tohoto systému je několik ovladačů a jedním
Robot
17
z nich je i ovladač ASCDRV5 pro komunikaci přes standardní sériové rozhraní počítače (více v kapitole Ovladače a kanály) a právě ten je využit jako základ komunikace mezi robotem a počítačem.
2.3 Lego Mindstorms komunikační protokol Robot Lego Mindstorms NXT 2.0 je schopen komunikovat bezdrátově pomocí technologie bluetooth nebo drátově přes USB. Níže uvedený obrázek ukazuje hlavní vrstvy v komunikačním protokolu mezi NXT kostkou a počítačem. Na obrázku jsou znázorněny oba způsoby komunikace.
Obr. 9
Diagram znázorňující komunikaci mezi počítačem a NXT kostkou [12]
Komunikace mezi počítačem a NXT kostkou probíhá prostřednictvím příkazů, které mají přesně určenou strukturu a délku. Přenášená data jsou číselného charakteru a jejich podoba je znázorněna na obrázku níže. [12]
Obr. 10
Struktura příkazu pro přenos dat [11]
První dva byty (byte 0 a byte 1) jsou pevně určeny a nachází se v každém vyslaném příkazu z počítače na kostku.
Robot
18
• Byte 0: typ příkazu. Tento byte definuje o jaký typ příkazu se jedná. NXT kostka rozlišuje dva typy příkazu: přímý příkaz a systémový příkaz. V tomto bytu se také definuje zda-li se jedná o příkaz, který má vyvolat odpověď od kostky zpět do počítače. o o o o
0×00: Přímý příkaz, vyžadující odpověď 0×01: Systémový příkaz, vyžadující odpověď 0×80: Přímý příkaz, nevyžadující odpověď 0×81: Systémový příkaz, nevyžadující odpověď
• Byte 1: tento byte určuje pro jakou část robota je příkaz určen. Zda-li má ovládat motor, senzor, vestavěný reproduktor apod. • Byte 2 – Byte N: počet a struktura těchto bytů závisí na bytu 1. To znamená, že druhý byte v příkazu pro ovládání motoru bude definovat zcela jiný parametr než například druhý byte v příkazu nastavující senzor. Popsaná struktura příkazu slouží pro komunikaci přes USB. Komunikace přes bluetooth je velmi podobná. Jediný rozdíl je v přidání dvou bytů definující délku celého příkazu. Tyto dva byty se nachází na začátku celého příkazu. NXT kostka používá metodu LSB (Least Signifiant Byte). To znamená, že každá hodnota, která je rozdělena na dva a více bytů se posílá tak, že nejméně významný byte odchází jako první. V případě, že se na NXT kostku vysílá například příkaz, který je dlouhý 8 bytů (0 až 7). První dva byty budou vypadat následovně. Číslo 8, které je reprezentováno ve dvou bytech má v šestnáctkové soustavě podobu 0×00 0×08. Použitím LSB metody ale dostaneme výsledek 0×08 0×00. Tyto dva byty tedy reprezentují délku celého příkazu ale zároveň se do celkové délky nezapočítávají. V tomto konkrétním případě má tedy odesílaný příkaz délku 10 bytů (2 + 8). [11]
Obr. 11
Struktura příkazu pro přenos dat přes bluetooth [11]
2.3.1
RealTerm – sériový terminál
Tento program byl využit pro testování komunikace probíhající přes bluetooth. Jedná se o program, který umožňuje zachytávat, kontrolovat nebo vysílat data na sériovém portu. Jde o pokračování známého programu COMMHEX, který pracoval ještě pod OS DOS (RealTerm již pracuje pod OS WINDOWS). Program lze využít i pro tuto úlohu přestože komunikace neprobíhá přes fyzický sériový port počítače ale přes bezdrátovou technologii bluetooth. Program umožňuje:
Robot
19
• Zobrazovat přijímaná data přes port • Vysílat sekvence dat (čísla nebo celý soubor) • Zachytávat přijímaná data (určitou dobu, nebo počet) • Zapisovat přijímaná data do souboru • Invertovat obě linky (Rxd, Txd) • Nastavit maskování přijatých bytů pomocí log. operací XOR, AND • Ovládat nejen z příkazové řádky nebo myši, ale i pomocí ActiveX Program je pomyslně rozdělen na dvě poloviny. Horní polovina je určena pro zobrazování dat, které byly zachyceny při komunikaci na lince. Spodní polovina programu je vyhrazena pro pole záložek, ve kterých je možné nastavovat požadované parametry. [8]
Obr. 12
Program RealTerm
Robot
20
Nejdůležitějšími záložkami jsou: • Display – zde si lze vybrat v jakém formátu se mají zobrazovat data v hlavním okně v horní polovině programu. • Port – tato záložka je velmi důležitá nastavuje se zde mimo jiné číslo portu, datová rychlost (v bitech za sekundu), typ parity, počet datových bitů a počet stop bitů. • Capture – v této záložce se nastavuje cesta k souboru do kterého se mají zapisovat příchozí data. Konec zapisování je možné nastavit podle času nebo podle počtu přijatých bytů. • Send - zde je možné nastavit posloupnost znaků, které se odešlou buď jako ASCII, nebo jako číselná hodnota a počet opakování, kolikrát se tyto data mají odeslat. V této záložce je možné vybrat i soubor, který se má odeslat na port. RealTerm umožňuje sledování COMu i na vzdáleném počítači připojeném do sítě pomocí TCP V každé záložce je také v pravé části tabulka (nazvaná Status), ve které jsou monitorovány stavy pinů. Tato tabulka je vždy ve stejném místě a má stejnou podobu napříč všemi záložkami.
Obr. 13
Stav pinů, které jsou neustále monitorovány
Program skvěle posloužil při monitorování komunikace mezi PC a NXT kostkou. Bylo možné detailně prozkoumat jaká data proudí při vysílání jednotlivých příkazů. Tyto data byla posléze použita v Control Webu pro tvorbu aplikace. Kromě sledování dat byla použita i funkce vysílání dat. Díky tomu bylo možné vyzkoušet přesné chování robota a ověřit správnou funkčnost testovaných dat. Jako jeden z prvních testů bylo vyzkoušeno spuštění motoru. Pro bezproblémový průběh testu bylo nezbytné, aby měl robot plně nabitou baterii a zároveň nebyla připojena nabíječka. K testu byly zapotřebí pouhé dvě součástky robota. Konkrétně hlavní řídící jednotka (NXT kostka) a motor. Motor musí být zapojen do některého z výstupních portů (v testu byl použit port C). V programu RealTerm pak bylo nutné v záložce Port vyplnit následující parametry komunikace: [13]
Robot
21
• Baund: 57600 (rychlost přenosu dat udávaná v bitech za sekundu) • Port: číslo COM portu, přes který bude probíhat komunikace • Parity: None (paritní bit sloužící pro kontrolu a odhalení chyb v přenesených datech) • Data Bits: 8 (počet data bitů) • Stop Bits: 1 (počet stop bitů) Poté už bylo možné v záložce Send do příslušného pole zadat následující hodnoty: • 0×0C 0×00 0×80 0×04 0×02 0×64 0×07 0×00 0×00 0×20 0×00 0×00 0×00 0×00 Pro odeslání příkazu slouží tlačítko „Send Numbers“ (angl. pošli čísla). V této fázi ještě bylo nutné pro vypnutí motoru vypnout celého robota. Zadané hodnoty definují následující parametry: [14] • 0×0C 0×00 – délka příkazu rozkládající se na dvou bytech (LSB). • 0×80 – značí přímý příkaz bez odpovědi. • 0×04 – tento byte definuje, že se jedná o příkaz nastavující servomotor (SETOUTPUTSTATE), který je připojen na výstupní port kostky. • 0×02 – značí, že motor je připojen do portu C (0×00 – port A, 0×01 – port B, 0×02 port C, 0×FF – všechny porty najednou). • 0×64 - rychlost v procentech. Číslo je zapsáno v šestnáctkové soustavě, jde tedy o 100%. • 0×07 – výstupní mód. Hodnota 0×07 značí, že skutečnou rychlost neovlivní vnější fyzické zatížení motoru (např. jízda do kopce). Tento režim má za následek větší spotřebu energie z baterie. • 0×00 – regulační mód (0x00 - mód není aktivovaný). • 0×00 – tento byte určuje odklon od přímého směru (robot zatáčí). Toho lze využít pouze při zapojení dvou motorů současně, zároveň však musí být aktivní regulační mód. Hodnota změny směru je udávaná v procentech (0×00 značí přímý směr). • 0×20 – fáze běhu motoru. Motor může postupně zrychlovat (0×10) nebo zpomalovat (0×40) na požadovanou rychlost. Hodnota 0×20 určuje konstantní běh bez zrychlování čí zpomalování. • 0×00 0×00 0×00 0×00 – Nastavení rychlosti rozkládající se na čtyřech bytech (TachoLimit), 0×00 pro nekonečný běh. [15]
Control Web
22
3 Control Web Control Web je univerzální nástroj pro vývoj a nasazování vizualizačních a řídicích aplikací, aplikací sběru, ukládání a vyhodnocování dat, aplikací rozhraní člověk-stroj. Unikátní objektově-orientovaná komponentová architektura zajišťuje aplikacím systému Control Web nejširší rozsah nasazení od prostých časově nenáročných vizualizací až po řídicí aplikace reálného času. Hlavním cílem návrhu systému Control Web je učinit realizaci běžných i komplikovaných úkolů možnou. Samozřejmě při respektování všech existujících standardů pro běh programů a jejich uživatelské rozhraní, výměnu dat a přístup k databázím, komunikaci po počítačových sítích a spolupráci s hardware pro sběr dat a řízení. Control Web pracuje v prostředí operačních systémů implementujících aplikační programové rozhraní Win32 a podporuje řadu průmyslových standardů. Control Web koncepčně vychází z osvědčené architektury svých předchůdců Control Panel a Control Web 2000. Nasazení těchto systémů od jaderných elektráren a celopodnikových vizualizačních systémů až po přímé řízení strojů a jednoduché vizualizace dokazuje velmi široké možnosti této architektury. Zachováním vzestupné kompatibility zároveň chrání investice do existujících aplikací, vzdělání a know-how. [3]
3.1 Pracovní prostředí Pracovní prostředí systému Control Web lze rozdělit na tři části, které jsou reprezentovány trojicí záložek v levém spodním okraji a jde o: • Grafický editor • Datové inspektory • Textový editor
Obr. 14
Hlavní záložky vývojového prostředí
Většina tvorby aplikace probíhá v grafickém editoru. Tvorba v tomto editoru je pro uživatele nejpříjemnější. Control Web má v dnešním světe velmi oblíbenou funkci drag-and-drop (táhni a pusť). Chceme-li do vytvářené aplikace vložit nějaký přístroj, vybereme jej z palety přístrojů a přeneseme ho tažením myši na zvolenou pozici v aplikaci. Tím odpadá zdlouhavé psaní kódu v textovém editoru, kde je nutné pro vložení přístroje napsat příkazy pro specifikaci pozice, vlastníka přístroje nebo například typ přístroje. Všechny tyto příkazy Control Web vygeneruje sám na základě vybraného a umístěného přístroje v grafickém editoru. Textový editor je však také důležitý. Mnohdy je nezbytné jej použít a určité příkazy dopsat ručně. V praxi se používají oba editory. Přepínání mezi nimi není nijak omezeno a může probíhat kdykoliv během tvorby aplikace.
Control Web
3.1.1
23
Grafický editor
Grafický editor si lze představit jako prostor, do kterého lze vkládat jednotlivé prvky a ty pak podle potřeby přemísťovat nebo upravovat. Prvky lze vkládat z takzvané palety přístrojů. V této paletě jsou jednotlivé přístroje uspořádány do kategorii a pro přehlednost a rychlou dostupnost ještě do podkategorií. Většina přístrojů má navíc několik variant zobrazení. Jako příklad lze uvést přístroj „meter“. Tento přístroj slouží pro zobrazení dat. Uživatel má na výběr z mnoha variant zobrazení (např. analogové s rafičkou nebo s digitální obrazovkou viz. obrázek níže). [3]
Obr. 15
Paleta přístrojů zobrazující možné varianty vzhledu přístroje meter
Po výběru správného přístroje ho lze přetažením, pomocí počítačové myši, přesunout do grafického editoru. Přístroj je i poté možné jednoduše editovat. Stačí ho označit (kliknutím myši na přístroj) a pak lze libovolně přemísťovat nebo měnit jeho velikost dle potřeby. Každý přístroj obsahuje nástroj v kterém lze upravovat jeho vlastnosti. Tím nástrojem je Inspektor přístroje a lze ho vyvolat dvojklikem na vybraný přístroj.
Control Web
Obr. 16
24
Inspektor přístroje
Jak je z obrázku patrné Inspektor přístroje obsahuje několik záložek v kterých lze přístroji nastavovat vlastnosti a funkce. V záložce Parametry se nachází tabulka s jednotlivými parametry z nichž některé mohou být dále rozděleny ještě na podtabulky, které se rozbalí stisknutím ikony + a opět sbalí stisknutím ikony -. Tato tabulka obsahuje taky sloupec nazvaný Hodnota. V tomto sloupci se vyplňují hodnoty k vybraným parametrům. Řada parametrů může nabývat předem známé hodnoty. Pro tento případ inspektor přístroje nabídne právě tyto předdefinované hodnoty v rolovací nabídce, ze které stačí vybrat požadovanou hodnotu. Řada hodnot je také v tabulce vytvořena defaultně již při vytvoření přístroje. Tyto hodnoty jsou znázorněny černou barvou a lze je také libovolně měnit. Hodnoty, které nastaví sám uživatel jsou znázorněny barvou modrou. To umožňuje jednoduchou orientaci v tabulce. Uživatel také není nucen vyplňovat všechny hodnoty ale pouze ty, které sám v dané situaci potřebuje. Ve třetím sloupci se ještě nachází stručný popis k jednotlivým parametrům. V záložce Lokální data si uživatel může vytvořit proměnné nebo konstanty se kterými bude v přístroji pracovat. Tyto proměnné budou dostupné pouze pro daný přístroj a nelze k nim přistupovat z jiného přístroje.
Control Web
25
V záložce Procedury se nachází seznam všech nativních procedur, které přístroj obsahuje. Do těchto procedur je možné přistupovat a rovnou do vybrané z nich vepsat svůj kód. Ten se okamžitě zobrazí i v textovém editoru. V záložce Barvy lze přístroji změnit barvy všech jeho grafických prvků. Je zde předpřipravená paleta barev, ze kterých je možné vybírat ale je zde také možnost si barvu zcela nově namíchat. Jako poslední záložka je zde Zdrojový kód. V této záložce se zobrazuje kód, který se vztahuje pouze k danému přístroji. Kód se zobrazuje v editoru, takže je možné ho rovnou ručně přepisovat nebo dopisovat. To může být výhodné v případě, kdy je celkový kód již příliš rozsáhlý a nepřehledný. Součástí grafického editoru jsou ještě v jeho levé části stromy se vloženými přístroji, které jsou rozděleny do čtyř záložek: Předlohy, Vzhled, Časování, Vybraný přístroj. V těchto stromech se zobrazují vložené přístroje a příslušné informace o nich. [3]
Obr. 17
Stromy s přístroji
3.1.2
Textový editor
Textový editor nemá žádné zvláštní funkce ale jeho nespornou výhodou je, že umí zvýraznit příkazy a čísla, což umožňuje lepší orientaci v kódu. V tomto editoru se zobrazuje kompletní zdrojový kód aplikace. Tedy i ten, který vygeneroval sám Control Web při práci v grafického editoru. 3.1.3
Datové inspektory
Poslední záložkou jsou datové inspektory. V této záložce se zobrazují globální datové elementy, tedy elementy, které jsou viditelné a dostupné pro celou aplikaci a všechny její přístroje. Pod datovými elementy se neskrývají pouze proměnné nebo konstanty ale i kanály, ovladače nebo moduly. Tento datový inspek-
Control Web
26
tor je opět rozdělen na dvě části. V levé se nachází strom s datovými elementy a v pravé části se zobrazují v závislosti na vybraném elementu data o již vytvořených elementech. V tomto místě se dle potřeby dají vytvářet i nové datové elementy. [3]
3.2 Překlad v Control Webu Control Web používá při překladu automatické zotavování chyb. Kdyby překladač nepoužíval toto zotavování, odhalil by v každém běhu pouze jednu chybu (pokud by v kódu chyby existovaly). V takovém případě by bylo nutné odstraňovat jednu chybu po druhé a překlad spouštět neustále dokola. Princip zotavení je jednoduchý, i když překladač odhalí chybu, pokračuje dál v prohledávání kódu a až dojde překladač na konec, vypíše všechny chyby najednou. V Control Webu existují celkem tři varianty překladu. Rozdíl mezi nimi spočívá v míře kontroly zdrojového textu. Čím pečlivější překlad je, tím déle to trvá. [3] První a nezjednoduší varianta překladu je jednoduchý překlad. Tento překlad je nejméně náročný na systém a je nejrychlejší. Při tomto překladu se kontroluje pouze syntaktická správnost aplikace (je-li formálně správně zapsaná). Tento překlad je dostupný buď prostřednictvím menu, nebo stiskem tlačítka Překlad aplikace v liště s nástroji. Další variantou je překlad pro překlopení. V grafickém režimu aplikace vypadá stejně jako za běhu. Je tedy nutno zkontrolovat datové soubory (jestli vůbec existují a jestli se dají načíst) a podle potřeby je zavést do paměti. Tento překlad se spouští automaticky vždy když proběhne přechod z textového do grafického režimu nebo naopak. Poslední variantou je překlad pro spuštění. Jednoduše řečeno v tomto překladu musí překladač zkontrolovat všechno. Přeložená aplikace musí být stoprocentně syntakticky a sémanticky správná, protože překladač musí zajistit správné napojení na okolí (na jiné moduly a ovladače) i správné napojení vnitřních procedur. Tato varianta je nejnáročnější a časově nejpomalejší. Spouští se vždy při startu aplikace. [3]
3.3 Události a aktivace Bloky kódu se v Control Webu nazývají procedury. Ale nejedná se o procedurální programování zejména proto, že chybí tzv. „hlavní modul“. To je část kódu, která se v procedurálním programování spouští jako první a ta pak volá další kód. Control Web staví na principu zpracování událostí a takzvané aktivaci. Příkladem události je například stisk tlačítka myši. Control Web je průmyslový systém pracující v reálném čase a proto jsou za události považovány i změny v ovladači vstupně/výstupních zařízení, virtuální přístroje nebo časovače. Na událost reaguje Control Web vyvoláním určité procedury. Tato procedura musí být v určitém přístroji. Žádná událost nemůže vyvolat proceduru, která se nenachází v některém z přístrojů. To je podstata Control Webu, každý přístroj obsa-
Control Web
27
huje nativní procedury, které reagují na svůj druh události. K těmto procedurám má uživatel přístup a může ovlivňovat jejich obsah, nikoliv však typ jejich aktivace. Dalo by se říct, že je tento typ programování blízký objektově orientovanému přístupu, kdy si můžeme představit procedury v přístroji jako metody objektu (toho přístroje). A aktivace je potom provedení akce datového elementu nebo přístroje. Aktivaci vždy musí něco způsobit a každá aktivace musí vždy projít jádrem, které požadované přístroje aktivuje. Mohou se vyskytovat i asynchronní aktivace a proto je nutné, aby se před aktivací případně probudil časovací tok, který jediný může zahájit časový krok. Systém Control Web zná následující důvody aktivace: • uplynutí periody - přístroj je aktivován periodou. V systému nejčastěji pomocí přístroje časovač, který odměřuje nastavený časový úsek mezi aktivacemi zadaného přístroje. Časovač může časovat více přístrojů naráz. • zpráva od přístroje - přístroj je aktivován jiným přístrojem nebo sebou samým. Toto může být vyvoláno například příkazem send. • zpráva od ovladače - přístroj je aktivován výjimkou ovladače. Tento způsob se často používá v přístroji, který přijímá data z ovladače1. • aktivace daty - přístroj je aktivován v důsledku změny dat (sledování určité proměnné a aktivace změnou nebo vyhodnocením jejího obsahu). [3]
3.4 Ovladače a kanály Jednou ze základních funkcí systému Control Web je schopnost číst a zapisovat data z a do periferních zařízení. Velmi důležitým rysem ovšem je dodržování nezávislosti na konkrétních typech hardwaru s nimiž se má komunikovat. Nezáleží na tom, zda aplikace čte nebo zapisuje data prostřednictvím zásuvné karty přímo v počítači nebo samostatné jednotky připojené standardním rozhraním (jako je například USB, RS-232C nebo RS-485 apod.). Aplikace má přístup k hardwaru prostřednictvím tzv. kanálu (channels). Na kanály se dá dívat jako na proměnné, ovšem určité rozdíly tu jsou: • Čtení kanálu způsobí komunikaci ovladače s periferií a přečtení její hodnoty • Zápis do kanálu způsobí zapsání hodnoty prostřednictvím ovladače do periferie. Na rozdíl od prostých proměnných, které mění hodnotu na základě zápisu v aplikaci, hodnoty kanálů se mění na základě přečtených dat z periferií. Podobnost s prostými proměnnými je i v případě vytváření nového kanálu. Vytváří se v záložce Datové inspektory (stejně jako proměnné). Obvykle se kanál vytváří až když je vytvořený ovladač (ovladačem je myšlen přístroj v Control Webu nikoli, ovladač hardwaru v operačním systému. V celé této kapitole je o ovladači mnoho Ovladačem je myšlen přístroj zvaný ovladač v Control Webu, nikoli ovladač hardwaru operačního systému 1
Control Web
28
zmínek, vždy je však myšlen právě ovladač v Control Webu). Je to z toho důvodu, že je nutné při vytváření nového kanálu nadefinovat s jakým ovladačem má daný kanál komunikovat. Kromě tohoto přiřazení ovladače musí kanál mít jméno a typ (podobně jako je tomu v případě vytváření proměnné). Kanály se rozlišují na: • Vstupní (určené k měření) • Výstupní (určené k zápisu dat) Data z aplikace se tedy dostávají prostřednictvím kanálu. Control Web ale ještě musí tyto data fyzicky dostat na konkrétní hardware. A k tomu slouží ovladač. Ovladač je nezávislá programová komponenta, která na jedné straně implementuje programové rozhraní vyžadované systémem Control Web a na druhé straně implementuje všechny zvláštnosti komunikace se zařízením, pro které je ovladač určen. Díky tomu jsou odstraněny všechny specifické vlastnosti takového zařízení a z hlediska zbytku systému tak všechny zařízení vypadají identicky. Přidání nového ovladače probíhá opět v sekci Datové inspektory. Po přidání nového ovladače je kromě jména nutné definovat ještě další povinné parametry. Těmito parametry jsou: • Ovladač – je nutné vybrat jeden ze seznamu kde se nachází všechny ovladače, které jsou v systému nainstalovány. • Mapovací soubor – soubor s definicemi kanálů ovladače obvykle s koncovkou .dfm (příklad msoubor.dfm). • Parametrický soubor – soubor s konfiguračními parametry daného ovladače obvykle s koncovkou .par (příklad psoubor.par). [3] 3.4.1
Volba vhodného ovladače
Zvolená komunikace mezi NXT kostkou a počítačem byla skrze bezdrátovou technologii bluetooth. Při této komunikaci je využito podporovaného protokolu RFCOMM. Tento protokol emuluje sériové rozhraní RS-232. Proto je možné využít jeden z předinstalovaných ovladačů Control Webu, které jsou pro komunikaci po sériové lince určeny. V Control Webu je na výběr ze dvou ovladačů, které umožňují přijímat nebo vysílat data po sériové lince. Těmi ovladači jsou ASCII ovladač a ovladač ASCDRV5. Oba tyto ovladače jsou určené pro příjem a vysílání textových řetězců což není příliš vhodné, protože komunikace mezi NXT kostkou a počítačem probíhá ve formě znaků respektive číselných hodnot. Tyto dva ovladače nejsou navíc mezi sebou vzájemně kompatibilní. Přestože na to není primárně ani jeden z ovladačů určen, byl vybrán jako vhodnější volba novější ovladač ASCDRV5, který obsahuje procedury i pro příjem a vysílání jednotlivých znaků. [3]
Control Web
3.4.2
29
Ovladač ASCDRV5
Ovladač je určen pro jednoduchou komunikaci se zařízením připojeným přes standardní sériové rozhraní počítače RS-232 (RS-485) a systémem Control Web. Ovladač je dodáván jako součást systému Control Web jak ve vývojové, tak v runtime verzi. Jméno souboru ovladače je 'ASCDRV5.DLL'. Jednoduchou komunikací je myšlena taková, při které se přenášejí data ve formátu textových řetězců (ASCII znaky) ukončených jedním nebo několika speciálními znaky (terminátor), např. CR, LF. Možnosti ovladače jsou následující: • Komunikace přes standardní sériové rozhraní počítače nebo prostřednictvím sítě ETHERNET (TCP/IP) • Vysílání textových řetězců (ASCII) ze systému Control Web do zařízení. • Příjem textových řetězců (ASCII) ze zařízení. • Řešení jednoduchých asynchronních komunikací. • Jednoduché synchronní komunikace (dotaz — odpověď). • Generování události při příjmu zprávy ze zařízení. • Definovatelné ukončovací znaky zpráv (terminátory) zvlášť pro příjem a vysílání. • Přidání předdefinovaných skupin znaků, které budou automaticky připojeny na začátek a konec vysílaného řetězce (prefix, sufix). • Možnost reinicializace a změny parametrů komunikace za běhu aplikace. [3] Textové řetězce jsou zpravidla tvořeny znaky s kódy z intervalu 20H až 7FH (čísla ukončená znakem H jsou zapsána v šestnáctkové soustavě). Prakticky je možno přenášet znaky z intervalu 01H až 0FFH. Znak s kódem 0 (NULL) slouží uvnitř systému k ukončení řetězců. Z toho vyplývá, že pokud je tento znak (NULL) součástí přijímaného řetězce, budou následující znaky ignorovány. Se znaky s kódy 01H až 1FH bývá poněkud obtížnější práce, protože se jedná o tzv. řídicí (nezobrazitelné) znaky. Proto je ovladač vybaven možností, jak tyto znaky do řetězců zadat. Délka řetězců je u ovladače omezená nastavením parametrů pro velikosti vstupních a výstupních bufferů. Systém Control Web dovoluje řetězce s neomezenou délkou. Ovladač vysílá data zápisem řetězce na kanál nebo voláním procedury ovladače. Ve speciálním případě je možno naplnit výstupní buffer kódy znaků a ty pak najednou vyslat voláním procedury. A právě díky této možnosti byl vybrán tento ovladač. Buffer lze naplnit konkrétními čísly a ty pak naráz vyslat na NXT kostku. Při vysílání dat je možno zvolit, jestli má ovladač čekat na odpověď od zařízení nebo ne (synchronní nebo asynchronní režim). Jsou-li data vyslaná v synchronním režimu, uplatňuje se timeout pro čekání na odpověď. Pokud do vypršení timeoutu nepřijde zpráva od zařízení (odpověď), je generována chyba. Výstupní řetězce se řadí do fronty a postupně se vysílají. V synchronním režimu je možno ještě určit, jestli má být odeslán další řetězec z výstupní fronty okamži-
Control Web
30
tě po přijetí odpovědi nebo až po povolení další výjimky od ovladače. Stav fronty je možno zjistit voláním procedury ovladače. Data, která jsou vysílána z NXT kostky jsou zachycována v přijímacím bufferu. Ovladač obyčejně čeká na výskyt ukončovacího znaku (terminátoru). Terminátor se může skládat z jednoho nebo několika znaků. Jakmile je zachycen terminátor, data z přijímacího bufferu se uloží do fronty. A zde nastal další problém z důvodu toho, že od NXT kostky neproudí textové řetězce ale znaky reprezentující čísla, která neobsahují žádný terminátor. Přestože na to ovladač není navržen je možno ho přepnout do zvláštního režimu, kdy bude do aplikace generovat výjimku od přijatých dat. Toto přepnutí se provádí v parametrickém souboru, kde je nutné nastavit tyto parametry na následující hodnoty: 1 2 3 4 5
[Settings] ... InpTerminator OutTerminator ReceiveMode
= none = none = char
Ukázka kódu 1 Nastavení ovladače do zvláštního režimu
Při zařazení položky do fronty se generuje výjimka. Jakmile aplikace zpracuje výjimku od ovladače, musí povolit výjimku novou. Děje se to buď zápisem do kanálu nebo voláním procedury ovladače. Povolení výjimky způsobí její nové generování v případě, že není fronta prázdná nebo když ovladač přijme nová data. Když nebude výjimka od ovladače povolena, budou se přijatá data pouze ukládat do fronty. Jakmile počet položek ve frontě dosáhne určité maximální hodnoty, další přijatá data budou ztracena. Nastane-li výjimka od ovladače, je možno číst přijatá data z fronty. K tomuto účelu slouží určité kanály nebo procedury. Data z fronty je možno přečíst několika způsoby: • přečtením kanálu • voláním procedury ovladače pro příjem celého řetězce • voláním procedury ovladače pro příjem jednotlivých znaků • čtením pole kanálů, ve kterém se nacházejí kódy jednotlivých znaků přijatého řetězce Obvyklé čtení a manipulace s přijatou položkou se týká vždy aktivní (první) položky fronty. Data se do fronty ukládají vždy na konec a vyčítají se od začátku. Jelikož byl ovladač přepnut do zvláštního režimu probíhá čtení trochu jinak. Při každém povolení výjimky se do vstupního bufferu dostane jeden znak přestože NXT kostka vyslala těchto znaků mnohem více a ovladač všechny tyto znaky přijal. Pro přečtení dalšího znaku je nutné opět povolit výjimku a znak si někam uložit. To celé je nutné opakovat do doby než jsou získána všechna data. [3]
Control Web
31
Pro správné fungování ovladače je nutné aby byl správně nastaven mapovací (viz. Příloha A) a parametrický soubor (viz Příloha B). Zejména následující nastavení v parametrickém souboru je klíčové pro správné fungování: 1 2 3 4 5 6 7 8
[Settings] ComDriver ... [comm] baudrate parity databits stopbits
= CWCOMM.DLL COM1 = 57600 = none =8 =1
Ukázka kódu 2 Důležité parametry ovlivňující komunikaci
V sekci [comm] se jedná o komunikační rychlost (baundrate), která je nastavena na 57600 bitů za sekundu. Počet data bitů na osm a počet stop bitů na jeden. Parita není využita. V sekci [Settings] je nejdůležitějším parametrem ComDriver. Tento parametr Control Webu označuje na jakém portu bude přenos dat probíhat. To bohužel není možné dopředu předvídat a tak je pravděpodobné, že bude nutné aby si tento parametr uživatel upravil sám podle vzniklé situace. To znamená, že si po spárování NXT kostky a počítače najde v sekci Zařízení Bluetooth všechny přidaná zařízení a ve vlastnostech zjistí přes který port bude NXT kostka komunikovat. Tuto informaci pak předá Control Webu ručním přepsáním v parametrickém souboru. Parametrický i mapovací soubor se nachází ve stejné složce jako samotné knihovny a lze je upravovat libovolným editorem.
Obr. 18
Vlastnosti spárovaného zařízení
Vlastní práce
32
4 Vlastní práce Při vymýšlení tématu a postupů tvorby mé závěrečné práce, byl brán v potaz fakt, aby existovalo konečné řešení. Proto bylo v zadání diplomové práce navrženo použití ActiveX komponenty, která by propojení Control Webu a Lego Mindstorms NXT 2.0 s jistotou umožnila. Systém Control Web je komponentově orientovaný a použití ActiveX technologie, je jediný zpùsob jak jej rozšířit. [3] ActiveX prvky jsou COM objekty, které oproti jednoduchému COM objektu musí obsahovat další standardem předepsaný „minimální“ kód (implementovat příslušná rozhraní), který z nich dělá právě ActiveX prvek. Zkratka COM pochází z výrazu Component Object Model. Tento model je platformově nezávislý, distribuovaný, objektově orientovaný systém pro vytváření binárních softwarových komponent, které jsou schopny spolupracovat. Technologie COM byla představena společností Microsoft v roce 2000. Tento komponentový model tvorby aplikací byl do nástupu technologie .NET vedoucí technologií v komponentové tvorbě. [4] Při analýze komunikace mezi NXT kostkou a počítačem se však velmi rychle ukázalo, že použití ActiveX komponenty není jediné možné řešení. Dalším řešením je ovládat NXT robota přímo přes vysílání přímých příkazů skrze ovladač v Control Webu, který je určený pro komunikaci po sériové lince. Při detailnějším zkoumání se tato varianta ukázala jako výhodnější. Jelikož se výsledky této práce začlení do výuky několika předmětů v jejichž osnovách je práce s Lego Mindstorms NXT 2.0, je velmi pravděpodobné, že se tato práce v budoucnu dočká řady vylepšení a rozšíření. Tato práce tedy bude sloužit jako základ, na který se budou nabalovat další funkce a vylepšení. Proto se volba řešení, které ovládá NXT kostku přímo přes ovladač v Control Webu, ukázala jako lepší varianta. Výhodou je také možnost lépe sledovat celou komunikaci mezi NXT kostkou a počítačem. Toho je možné v práci využít. Uživateli proto bude umožněno celou komunikaci sledovat. Okamžitě uvidí jak jeho nastavení mění příkazy, které se mají na NXT kostku vysílat a bude mu umožněno sledovat příchozí a odchozí data. Sledování příchozích a odchozích příkazů bylo, vzhledem k tomu, že má práce sloužit k výuce, vyhodnoceno jako cenné, proto bylo rozhodnuto, že uživatel bude mít přístup i k historii příkazů, které byly od spuštění vyslány či přijaty. Z těchto důvodů bylo po konzultaci s vedoucím práce rozhodnuto o opuštění původní varianty s využitím ActiveX komponenty a jako konečná varianta komunikace bylo přijato přímé ovládání skrze příkazy vysílané přes ovladač v Control Webu.
Vlastní práce
33
4.1 Vývoj jako aplikační knihovna Od počátku vývoje této práce, bylo bráno v potaz, že výsledkem nemá být jedna velká aplikace, ale sada několika knihoven, které budou ovládat jednotlivé periferie robota (servomotory, senzory). Těmi knihovnami jsou myšlené aplikační knihovny Control Webu. Tyto knihovny jsou vytvářené v Control Webu a pouze zde se dají takto vytvořené knihovny použít. Pod pojmem knihovna (v programování), je v informatice označován soubor funkcí a procedur (v objektovém programování též objektů, datových typů a zdrojů), který může být sdílen více počítačovými programy. Taková knihovna usnadňuje programátorovi tvorbu zdrojového kódu tím, že umožňuje použít již vytvořený kód i v jiných programech. Knihovna navenek poskytuje své služby pomocí API (aplikační rozhraní), což jsou názvy funkcí a procedur (včetně popisu jejich činnosti), předávané parametry a návratové hodnoty. Knihovny se v Control Webu vyvíjí stejně jako aplikace. Vlastně se knihovna vyvíjí jako aplikace a až následně se z aplikace vygeneruje knihovna. Je však potřeba dodržet několik pravidel. Nejprve je nutné v Control Webu nastavit, že se z aplikace má stát knihovna a procedury, které se mají nacházet v aplikačním rozhraní knihovny se musí nacházet v sekci date. Bohužel v této sekci nejde použít procedury s návratovou hodnotou. To by byl za normálních okolností velký problém, protože v řadě situací je nutné uživateli vracet hodnoty (typicky procedury jako jsou gettery). Control Web ale umožňuje v procedurách předávat parametry volané odkazem. Parametry tohoto typu se definují v proceduře klíčovým slovem var a s takovouto proměnnou pak lze pracovat i mimo tyto procedury. V proceduře se do ni přiřadí pouze hodnota, která by za normálních okolností byla v návratové hodnotě procedury. [3] Jelikož se v Control Webu knihovny vyvíjejí jako aplikace, lze naplno využít toho co z něho dělá tak silný nástroj – přístroje. Výsledné knihovny tedy nebudou jen neviditelné bloky kódu, ke kterým bude uživatel přistupovat pomocí API. Budou to zároveň viditelné panely s řadou přístrojů, které umožní uživateli ovládat jednotlivé periferie pomocí přístrojů pouhými několika kliknutími. Tato grafická část bude sloužit zejména pro demonstraci funkčnosti knihoven a pro seznámení uživatele s fungováním Lego robota. Pro běžné vytváření úloh bude výhodnější použít programové aplikační rozhraní knihovny.
4.2 Návrh grafického rozhraní Jak již bylo zmíněno v předešlé kapitole knihovny budou mít grafické rozhraní. Návrh takového grafického rozhraní měl několik požadavků na vzhled a funkčnost. Jelikož se práce skládá z několika samostatných knihoven bylo nutné dodržet jednotný grafický vzor, který bude stejný napříč všemi knihovnami. Jako další kritérium byla stanovena možnost zobrazení komunikace, mezi NXT kostkou a počítačem, spolu s historii. Tyto informace jsou pro uživatele zajímavé,
Vlastní práce
34
avšak jejich zobrazení není nezbytně nutné pro správné použití knihoven. Bylo tedy rozhodnuto, že volba, zda-li chce tyto informace uživatel zobrazit zůstane zcela na něm. Toto řešení má nespornou výhodu v přehlednosti. Zejména pro uživatele, který s těmito knihovnami teprve začíná. Jako nejlepší řešení tohoto požadavku, se ukázalo rozdělení celého panelu na dva menší z nichž ten informativní bude možné podle potřeby skrýt nebo zobrazit.
Část, kde probíhá nastavení
Část, kde probíhá nastavení
Detail
Detail
Informativní část
Obr. 19
Návrh grafického rozhraní se skrytou a zobrazenou informativní částí
V systému Control Web je možné vytvářet aplikace, které po spuštění nepoběží v okenní aplikaci, jak je to například v OS Windows běžné, ale poběží přímo na pracovní ploše. Za normálních okolností se tento způsob moc nepoužívá ale pro tvorbu knihoven se výborně hodí. Je to z toho důvodu, že knihovny nemohou být samostatně spuštěny ale musí být nejprve vloženy do nové aplikace. A až tu je následně, spolu s knihovnami, možno spustit. Nebylo tedy nutné budoucímu uživateli vnucovat práci knihovny v okně. Zůstává tedy zcela na něm zda-li chce, aby knihovna, použitá v jeho aplikaci, fungovala v okně, či nikoliv.
4.3 Servomotory Servomotory se na NXT kostce zapojují do výstupních portů (porty A - C) a lze je ovládat přes knihovnu Motor. Příkaz, přes který je umožněno tyto servomotory ovládat se nazývá SETOUTPUTSTATE. Příkaz se skládá ze 14 bytů a uživatel si může jeho strukturu prohlédnout v informativní části knihovny:
Vlastní práce Tab. 1
35
Struktura příkazu SETOUTPUTSTATE [11]
Pořadí bytů 0. byte 1. byte 2. byte 3. byte 4. byte 5. byte 6. byte 7. byte 8. byte 9. byte 10. – 13 byte
Význam 1. byte lenght (LSB) 2. byte lenght(MSB) Command type Command SETOUTPUTSTATE Port byte Power byte Mode byte Regulation mode Turn Radio Motor RunState TachoLimit
Ze servomotorů není potřeba získávat údaje, které by bylo nutné uživateli zobrazit (i když je možné je z motoru získat). Tato knihovna tedy zprostředkovává pouze vysílání příkazů na NXT kostku. Toto vysílání je realizováno nikoliv přes kanály (channels) ale pomocí procedur ovladače. Přes tyto procedury se naplní výstupní buffer znaky, které tvoří příkaz pro ovládání motoru a poté se celý jeho obsah odešle na kostku. 1 2 3 4 5
core.DriverQueryProc( 'nxt', 'SetTxIndex', 0 ); for i = 0 to hiindex( command ) do core.DriverQueryProc( 'nxt', 'PutCharSeq', command[i] ); end; core.DriverQueryProc( 'nxt', 'SendAsync', hiindex( command ) + 1 );
Ukázka kódu 3 Procedury zajišťující naplnění bufferu a jeho následné odeslání
4.3.1
Knihovna Motor
Knihovna slouží k ovládání jednoho nebo více servomotorů zapojených do výstupních portů NXT kostky. V každém odeslaném příkazu však lze nastavit parametry pouze jednoho motoru2. To znamená, chce-li uživatel ovládat tři servomotory je nutné odeslat tři příkazy z nichž každý může mít jiné nastavení. NXT kostka nedisponuje, žádnou pamětí příkazů, ke kterým by bylo možné se vracet. To znamená, že odešle-li se na port A nějaké nastavení, bude se vykonávat do doby než přijde jiné nebo se NXT kostka nevypne. V případě nutnosti, aby servomotor fungoval podle původně odeslaného příkazu, je nezbytné odeslat příkaz nový, ve kterém budou nastaveny původní parametry.
Výjimku tvoří pouze speciální případ, kdy se posílá stejné nastavení na všechny tři porty. V takovém případě lze odeslat nastavení všech portů v jednom příkazu.
2
Vlastní práce
36
Grafická podoba knihovny Motor se skládá ze tří přístrojů, které nastavují jednotlivé parametry příkazu pro servomotor a dvou tlačítek: • Nastavení portu – parametr, který definuje na který port se má příkaz odeslat. Kromě jednotlivých portů (A - C) je zde volba „Všechny porty“. Tato volba způsobí, že se odeslané nastavení projeví na všech portech současně. • Nastavení směru – parametr, který definuje směr otáčení motoru, na výběr jsou možnosti dopředu nebo dozadu. • Nastavení rychlosti – parametr, který definuje jakou rychlostí se má motor otáčet. Tento parametr lze nastavit pomocí posuvníku nebo v editačním poli a to v rozmezí 0 – 100 (udávané v %). • Tlačítko Odešli příkaz – tlačítko, které odešle příkaz na NXT kostku. • Tlačítko STOP – tlačítko, které umožní rychlé zastavení všech motorů. Parametry pro zastavení všech motorů jsou nastaveny vnitřně spolu s odeslání tohoto příkazu na kostku. Po stisku tohoto tlačítka se tedy vše provede automaticky od uživatele už není potřeba jiný zásah.
Obr. 20
Grafický panel knihovny Motor (zobrazena pouze jeho nastavovací část)
Jako poslední přístroj v panelu se nachází zatrhávací políčko s názvem Detail. Zaškrtnutím tohoto pole uživatel zpřístupní informativní část, ve které se nachází pole čísel, které zobrazuje strukturu příkazu SETOUTPUTSTATE spolu s textovým polem, do kterého se vypisují zprávy pro uživatele (logovací okno). V tomto logovacím okně může uživatel nalézt tyto tři typy zpráv:
Vlastní práce
37
• INFO – zprávy tohoto typu jsou pouze informativní (např. INFO: Start aplikace). • OUT – zprávy tohoto typu uživateli prozrazují jaká data byla odeslána na NXT kostku (např. OUT: 12 0 128 4 1 206 7 0 0 32 0 0 0 0). • UPOZORNĚNÍ – tyto zprávy jsou pro uživatele nejdůležitější. V nich se ukrývají chyby, které uživatel udělal při ovládání robota skrze procedury knihovny. Tyto upozorňující zprávy se objevují pouze tehdy, když uživatel předal proceduře špatný parametr (je myšlen parametr procedury). Ve zprávě pak nalezne informaci o tom, kde udělal chybu a jaká byla nastavena defaultní hodnota, místo jeho špatné hodnoty (např. UPOZORNENÍ: Zadané neexistující číslo portu - všechny porty byly nastaveny jako výstupní). Zprávami typu OUT byl splněn požadavek na uchovávání historie příkazů, které odchází na NXT kostku. Při nastavování vlastností tohoto logovacího okna, bylo bráno v potaz, že NXT robot může provádět úlohy, které budou časově náročné a mohlo by se stát, že zprávy, zejména typu OUT, by mohly neúnosně růst do závratného počtu. Jelikož jsou tyto zprávy cenné zejména pro ladění nové aplikace nebo při odstraňování chyb, bylo rozhodnuto, že se po každých 250 zprávách logovací okno vymaže a nové hodnoty se začnou zapisovat znovu od začátku. Možnost vymazání tohoto okna byla dána i uživateli – lze ho vymazat kdykoliv pouhým dvojklikem myši kdekoliv v onom okně. Mnohem častějším využitím knihovny však bude skrze jeho aplikační rozhraní. Procedury knihovny Motor jsou následující: • MotorStart( port : shortcard; direction : boolean; speed : shortcard ) • MotorStop( port : shortcard) • TimeOfRunning( var returning : longcard; port : shortcard) • SetPort( port : shortcard ) • SetDirection( direction : boolean ) • SetSpeed( speed : shortcard ) • Exekute() • GetPort( var returning : shortcard ) • GetDirection ( var returning : boolean ) • GetSpeed ( var returning : shortcard) Pro správné fungování všech procedur třídy Motor je nutné aby uživatel věděl jak své požadavky třídě předat. Musí tedy znát jak jednotlivé parametry procedur nastavit, tak aby plnili funkce podle jeho požadavků. Výstupní porty jsou na NXT kostce označeny jako port A, port B a port C. V procedurách, které obsahují parametr port, je ovšem číselný typ. To znamená, že výstupní porty v parametrech procedur jsou tedy reprezentovány čísly a to následovně:
Vlastní práce Tab. 2
38
Výstupní porty reprezentované čísly
Výstupní porty na NXT kostce Port A Port B Port C Všechny porty
Číselná reprezentace 0 1 2 3
Směr je možné nastavit pouze dopředu či dozadu. Bylo tedy využito datového typu boolean, který nabývá pouze dvou možných hodnot pravda/nepravda (v programovacím jazyce true/false): Tab. 3
Reprezentace směru pohybu robota
Směr Boolean reprezentace Dopředu True Dozadu False Posledním parametrem nacházejícím se v procedurách knihovny Motor je definice rychlosti. Rychlost je reprezentována číselnou hodnotou, která je udávaná v procentech: Tab. 4
Reprezentace rychlosti
Rychlost Číselná reprezentace 0 – 100% 0 - 100 Pro běžné ovládání servomotoru se budou nejvíce používat procedury MotorStart a MotorStop. Zejména procedura MotorStart, která umožňuje nastavení všech parametrů najednou. Tato procedura může být použita i pro zastavení motoru. V tom případě by však bylo nutné opět nastavit i směr (což je při zastavení motoru irelevantní parametr) a rychlost (na hodnotu 0). Pro usnadnění práce, proto byla vytvořena procedura MotorStop, která zastaví servomotor na portu, který je předán jako vstupní parametr této procedury. Dalším způsobem jak ovládat motor je použití samostatných procedur nastavujících jednotlivé parametry příkazu (SetPort, SetDirection, SetSpeed). To může být výhodné v případě, kdy je potřeba jen upravit jeden parametr (změnit rychlost apod.). Jelikož ale není možné dopředu určit, kterou z těchto procedur uživatel použije, nebylo možné do nich integrovat odeslání příkazu na kostku (na rozdíl od procedur MotorStart a MotorStop, které mají tento příkaz pro odeslání integrován). Z tohoto důvodu procedury pouze přenastaví parametry příkazu ale neodešlou ho na NXT kostku. Toto odeslání musí vyvolat sám uživatel procedurou Exekute.
Vlastní práce
1 2 3 4 5 6 7
39
(* nastaveni motoru na portu A, směr dopředu rychlostí 50% *) MotorStart(0, true, 50); … (* přenastavení směru a rychlosti na stejném portu*) SetDirection(false); SetSpeed(80); Execute();
Ukázka kódu 4 Ukázka dvou různých způsobů ovládání motoru
Pomocí procedury TimeOfRunning může uživatel zjistit jak dlouho je motor na dotazovaném portu spuštěn. Jelikož Control Web nepodporuje procedury s návratovou hodnotou při generování knihovny (viz. kapitola Vývoj jako aplikační knihovna) je uživateli tato hodnota zprostředkována pomoci parametru procedury volaného odkazem ( var returning : longcard ). Hodnota získaná z této procedury je udávána v sekundách a je měřena pouze po dobu, kdy je motor spuštěn. Pokud se motor zastaví a následně opět spustí, doba spuštění je opět počítána od nuly (nezapočte se do ní doba, po kterou byl motor spuštěn před zastavením). V případě, že se uživatel dotáže na motor, který nebyl vůbec zapojen nebo nebyl spuštěn je mu vrácena hodnota 0 a je o tom informován v logovacím okně zprávou typu UPOZORNĚNÍ. Knihovna motor také obsahuje procedury vracející (opět pomocí parametrů volané odkazem) informace o nastaveném portu, směru a rychlosti (GetPort, GetDirection, GetSpeed).
4.4 Senzory Senzory se na NXT kostce zapojují do vstupních portů (porty 1 – 4) a lze je ovládat přes vytvořené knihovny Light, Sound a Touch. Na rozdíl od knihovny Motor je nutné v knihovnách, které ovládají senzory přijímat data. Tyto knihovny tedy musí kromě vysílání dat umět data i přijímat. Pro ovládání senzorů slouží dva typy příkazů. Prvním z nich je příkaz SETINPUTMODE. Tab. 5
Struktura příkazu SETINPUTMODE [11]
Pořadí bytů 0. byte 1. byte 2. byte 3. byte 4. byte 5. byte 6. byte
Význam 1. byte lenght (LSB) 2. byte lenght(MSB) Command type Command SETINPUTMODE Input port Sensor type Sensor mode
Vlastní práce
40
Tento příkaz NXT kostce nastavuje jaký typ senzoru je do zadaného portu zapojen. Tento příkaz nevyvolává žádnou odpověď od NXT kostky. Druhým příkazem, který slouží k ovládání senzorů je příkaz GETINPUTVALUES. Tento příkaz slouží jako dotaz na daný senzor, který vyvolá odpověď od NXT kostky. V této odpovědi se skrývá hodnota, kterou daný senzor získal z okolí. Tab. 6
Struktura příkazu GETINPUTVALUES [11]
Pořadí bytů 0. byte 1. byte 2. byte 3. byte 4. byte
Význam 1. byte lenght (LSB) 2. byte lenght(MSB) Command type Command GETINPUTVALUES Input port
Příkaz GETINPUTVALUES lze použít až po nastavení senzoru na dotazovaném portu (po příkazu SETINPUTMODE). Jinými slovy příkaz SETINPUTMODE slouží pro nastavení daného portu a musí se odeslat jako první. Příkazem lze opět nastavit libovolný vstupní port a opakovaným vysláním toho příkazu lze nastavit všechny čtyři porty. V praxi bude nejčastěji použita varianta, kdy se na úplném začátku řešené úlohy pomocí příkazu SETINPUTMODE (maximálně čtyřnásobné odeslání tohoto příkazu na 4 vstupní porty) nastaví vstupní porty a poté už ve zbytku řešené úlohy probíhá pouze dotazování na konkrétní vstupní porty pomocí příkazu GETINPUTVALUES. To znamená, že jakmile je port jednou nastaven není nutné ho nastavovat znovu a může už probíhat pouze dotazování na tento port. Příkaz SETINPUTMODE lze samozřejmě použít i v průběhu řešené úlohy ale příliš běžné to nebude, neboť by bylo nutné tento senzor vyměnit i fyzicky na NXT kostce3. Jak již bylo zmíněno výše příkaz GETINPUTVALUES vyvolá odpověď od NXT kostky. Tato odpověď v sobě kromě žádané hodnoty ze senzoru ukrývá mnoho dalších informací:
Výjimku může tvořit světelný senzor, který pracuje ve dvou speciálních módech (snímaní okolního světla a snímání odstínu šedi). U tohoto senzoru by tedy bylo možné použít příkaz SETINPUTMODE bez nutnosti fyzického přepojení senzoru.
3
Vlastní práce Tab. 7
41
Odpověď, kterou vyvolá příkaz GETINPUTVALUES [11]
Pořadí bytů 0. byte 1. byte 2. byte 3. byte 4. byte 5. byte 6. byte 7. byte 8. byte 9. byte 10. – 11. byte 12. – 13. byte 14. – 15. byte 16. – 17. byte
Význam 1. byte lenght (LSB) 2. byte lenght(MSB) Command type Command GETINPUTVALUES Status byte Input port Valid? (true/false) Calibrated? (true/false) Sensor type Sensor mode Raw A/D value (LSB) Normalized A/D value (LSB) Scaled value (LSB) Calibrated value (LSB)
Každý ze senzorů pracuje v určitém módu závislém na typu hodnot, které má vracet. Senzory, pro které byly vytvořeny knihovny pracují v následujících módech: • Full scale mode: tento mód používají světelný a zvukový senzor, které vracejí číselnou hodnotu (v rozpětí 0 - 100). • Boolean mode: v tomto módu pracuje dotykový senzor, který vrací hodnotu true/false (stisknuto/nestisknuto). V odpovědi na vyslaný příkaz GETINPUTVALUES se hodnota přečtená ze senzorů skrývá ve dvou bytech označených jako Raw A/D value (10. a 11. byte). Tato hodnota se nachází na dvou bytech i v případě, kdy se jedná o dotykový senzor (přestože boolean mód nabývá pouze hodnot pravda/nepravda). Knihovny tuto hodnotu vnitřně převedou, provedou její přepočet a uživateli již poskytnou konkrétní číselnou nebo boolean hodnotu v závislosti na typu dotazovaného senzoru. Díky tomu, že knihovny, ve své informativní části, zobrazují celou příchozí odpověď, má uživatel možnost si sám zkusit výslednou hodnotu vypočítat. Je potřeba mít však na paměti, že zobrazená čísla jsou v knihovně již zobrazena v desítkové soustavě, zatímco původní komunikace byla v binární soustavě. Přestože se výsledná hodnota nachází na dvou bytech, jedná se o jedno číslo a proto musí uživatel tyto dva byty převést zpět do dvojkové soustavy a poté tyto dvě čísla spojit aby dostal původní hodnotu. Ale pozor Lego NXT používá metodu LSB (Least Signifiant Byte). To znamená, je-li hodnota rozdělena do dvou a více bytů, jako v tomto případě, odchází jako první méně významný byte. To znamená, že uživatel musí tyto dva byty spojit v obráceném pořadí než v jakém mu ve zprávě přišly (tedy spojit 11. byte s 10. bytem nikoliv 10. s 11.). Po tomto
Vlastní práce
42
spojení je možné toto číslo opět převést do desítkové soustavy a dosadit ho do jednoho ze dvou vzorců v závislosti na tom z jakého senzoru data přišla. Pro full scale mode: výsledek = ((1023 − rawValue) × 100 ÷ 1023)
(1)
výsledek = rawValue < 600 ?1 : 0
(2)
Pro boolean mode:
Využívání tohoto komplikovaného postupu, jak vyčíst konkrétní hodnotu z příchozí zprávy, nebude příliš běžné ale pro úplné pochopení jak Lego Mindstorms NXT 2.0 pracuje je dobré ho znát. V informační části všech knihoven je možné kromě příchozích hodnot ze senzoru, sledovat i strukturu příkazů sloužících pro nastavení (SETINPUTMODE) a pro dotaz (GETINPUTVALUES). Kromě těchto informací se zde opět nachází logovací okno. Ve kterém může uživatel nalézt tyto typy zpráv: • INFO - tyto zprávy jsou pouze informativní (např. INFO: Start aplikace). • OUT NASTAVENÍ - zprávy tohoto typu uživateli prozrazují podobu nastavovacího příkazu SETINPUTMODE (např. OUT NASTAVENI: 5 0 128 5 0 5 128) • OUT DOTAZ: tyto zprávy opět znázorňují odeslaní dat na NXT kostku ale v tomto případě se jedná o příkaz GETINPUTVALUES (např. OUT DOTAZ: 3 0 0 7 0). • IN - tyto zprávy zobrazují celou příchozí zprávu ze senzoru (např. IN: 10 0 3 7 0 0 1 0 5 128 157 2 78 1 32 78 1). • IN HODNOTA - tato zpráva zobrazuje již konkrétní hodnotu, která byla vypočítána z příchozí zprávy (např. IN HODNOTA: 38). • UPOZORNĚNÍ - tyto zprávy jsou pro uživatele opět nejdůležitější. V nich se ukrývají chyby, které uživatel udělal při ovládání NXT robota skrze procedury knihovny. Tyto upozorňující zprávy se objevují pouze tehdy, když uživatel předal proceduře špatný parametr (je myšlen parametr procedury). Ve zprávě pak najde informaci o tom kde udělal chybu a jaká byla nastavena defaultní hodnota, místo jeho špatné hodnoty. (např. UPOZORNĚNÍ: Na portu 2 není nastaven světelný senzor. Vrácena hodnota 0) • CHYBA ČTENÍ - tyto zprávy zobrazují chyby v komunikaci při čekání na odpověď od NXT kostky. Tyto chybové zprávy získává knihovna z příslušného kanálu (channels) ovladače a kromě oznámení chyby zobrazí i o jakou chybu se jedná (např. CHYBA ČTENÍ: Timeout). • CHYBA ZÁPIS - jedná se o podobný případ jako při chybách čtení s tím rozdílem, že jde o chyby zápisu (např. CHYBA ZÁPIS: Buffer full).
Vlastní práce
43
Zprávami typu OUT NASTAVENÍ, OUT DOTAZ, IN a IN HODNOTA byl opět splněn požadavek na uchovávání historie příkazů, které proudí mezi NXT kostkou a počítačem. Logovací okno se i zde po 250 zprávách vymaže a začne vypisovat nové hodnoty od začátku aby se předešlo nežádoucímu nárůstu těchto zpráv do závratných počtů. Uživatel má opět možnost vymazat logovací okno dvojklikem myši. Vysílání dat na NXT kostku je realizováno stejně jako v knihovně Motor (viz. kapitola Servomotory). V knihovnách ovládající senzory však bylo nutné vyřešit i příjem dat. Jelikož byl použit ovladač (je myšleno ovladač v Control Webu), který je určen pro komunikaci prostřednictvím textových zpráv, vznikl problém jak přijímat znaky číselného charakteru. Problém byl vyřešen díky radě, kterou mi poskytli z oficiální podpory výrobce softwaru Control Web. Ovladač bylo nutné přepnout do zvláštního režimu, ve kterém je schopen přijímat znaky (viz. kapitola Ovladač ASCDRV 5)4. Jelikož byl ovladač přepnut do tohoto zvláštního režimu, probíhá čtení trochu jinak. Při každém povolení výjimky se do vstupního bufferu dostane pouze jeden znak, přestože NXT kostka vyslala těchto znaků několik a ovladač všechny tyto znaky přijal. Pro přečtení dalšího znaku v pořadí je nutné povolit výjimku a předchozí znak si někam uložit. To celé je nutné opakovat do doby než jsou získána všechna data z příchozí zprávy. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
activity driver = nxt; (* přístroj je aktivován ovladačem *) end_activity; ... if es = ZMENENA_DATA then (* kontrola zda – li přišel nový znak *) core.DriverQueryProc( 'nxt', 'GetRxCount', &n ); i = 0; while i < n do core.DriverQueryProc( 'nxt', 'GetCharSeq', &c ); s = str (c, 10); in_data = in_data + s + ' '; (* uložení znaku do textového řetězce *) i = i + 1; end; end; chvyjimka = true; (* povolení vyjímky umožní další příjem znaku *)
Ukázka kódu 5 Blok kódu, který zajišťuje příjem dat
4.4.1
Knihovna Touch
Grafická podoba knihovny Touch vychází z jednotného grafického návrhu, který je jednotný napříč všemi knihovnami. Na rozdíl od knihovny Motor je však v knihovnách ovládající senzory potřeba zobrazit příchozí hodnoty z těchto senzoPozor tento zvláštní režim není popsán v dokumentaci výrobce a v Control Webu jeho nastavení upozorňuje v parametrickém souboru na nerozpoznaný parametr.
4
Vlastní práce
44
rů. Jako výhodnější umístění tohoto zobrazení bylo určeno v nastavovací části panelu. Je to z důvodu trvalého zobrazení tohoto panelu. Pro větší přehlednost a pro pomyslné oddělení od nastavovacích přístrojů je tato část v samostatném bloku, který je barevně odlišen od ostatních nastavovacích bloků.
Obr. 21
Grafický panel knihovny Touch (zobrazena pouze jeho nastavovací část)
V nastavovací části je opět několik přístrojů, kterými je možno ovládat senzor zapojený do jednoho ze vstupních portů: • Nastavení portu pro zapojení – tímto parametrem definujeme, na který port se má odeslat nastavení. • Tlačítko Odešli nastavení – stisknutím tlačítka se odešle nastavený port spolu s dalším nastavením týkající se dotykového senzoru (o toto nastavení se stará sama knihovna) na NXT kostku (příkaz SETINPUTMODE). • Nastavení portu pro dotaz – tímto výběrem se definuje na jaký port má být odeslán dotaz. • Tlačítko Odešli dotaz – po stisku tohoto tlačítka se odešle dotaz na nastavený port (příkaz GETINPUTVALUES) • Indikátor – jedná se o diodu, která zobrazuje, příchozí hodnotu ze senzoru. Červená barva značí, že senzor není stisknut. Zelená pak, že senzor stisknutý je.
Vlastní práce
45
Nastavení konkrétního portu pro zapojení je opět nutné odeslat jako první. Je-li port již jednou nastaven není nutné toto nastavení odesílat znovu (pokud není požadavek na změnu senzoru zapojeného do tohoto portu). Po nastavení portu je možné na tento port odesílat dotazy. Výsledky dotazu jsou zobrazeny pomocí přístroje Indikátor. Změna v tomto přístroji proběhne až když je odeslán další dotaz a vrácena opačná hodnota. To, znamená, že v případě kdy je senzor stisknut a je na něj v tu dobu odeslán dotaz zobrazí indikátor tuto skutečnost zelenou barvou. Touto barvou bude indikátor svítit i v případě, že senzor už stisknutý není ale po této změně stavu na něho nepřišel další dotaz. Knihovna bez odeslání dotazu nemá jak zjistit, že senzor již není stisknut. Pro zjištění aktuálního stavu senzoru (stisknut/nestisknut) je tedy nutné odeslat nový dotaz. Odešle-li uživatel dotaz na port, který ještě nebyl nastaven je mu automaticky indikátorem zobrazena defaultní hodnota nestisknuto a je na toto pochybení upozorněn v logovacím okně (v informativní časti panelu) zprávou typu UPOZORNĚNÍ (viz. kapitola Senzory). Knihovnu Touch lze opět ovládat skrze její aplikační rozhraní. • SetPortSettings( port : shortcard ) • GetPortSettings( var returning : shortcard ) • GetPortQuery( var returning : shortcard ) • ReadValueStart( port : shortcard ) • ReadValue( var returning : boolean ) • proměnná end_of_transfer
Od uživatele je pro nastavení portu a dotazu na tento port vyžadováno pouze specifikace tohoto portu v parametrech některých procedur. Vstupní porty na NXT kostce jsou označeny port 1, port 2, port 3 a port 4. Ale pozor v knihovně Touch bylo použito opět číselného typu, podobně jako v knihovně Motor a to opět od nuly! Tab. 8
Vstupní porty reprezentované čísly
Vstupní porty na NXT kostce Port 1 Port 2 Port 3 Port 4
Číselná reprezentace 0 1 2 3
Často používanou procedurou bude SetPortSettings, tato procedura odešle nastavení dotykového senzoru na port, který uživatel určí pomocí parametru procedury. Dalšími často používanými procedurami budou ReadValueStart a ReadValue. Pro správné vyčtení hodnoty, ze senzoru je nutné použít obě tyto procedury a k tomu ještě velmi specificky. Toto řešení vyčítání hodnot není pro uživatele příliš „přátelské“, protože je nutné přesně vědět jak tyto procedury použít.
Vlastní práce
46
Bohužel, tato poněkud komplikovanější varianta je jediné možné řešení, jak hodnoty ze senzoru získat. Důvod použitého řešení vyplívá z podstaty fungování systému Control Web. Vyčtení hodnoty ze senzoru má za následek využití dvou různých přístrojů, které na sebe nemají žádnou vazbu. První přístroj obstarává vyslání příkazu z Control Webu na NXT kostku (viz ukázka kódu 3). A druhý přístroj obstarává následný příjem dat od NXT kostky (viz ukázka kódu 5). Za normálních okolností by tedy procedura, která by měla sloužit pro získání dat ze senzorů musela jako první pomocí prvního přístroje odeslat dotaz na NXT kostku (příkaz GETINPUTVALUES) a poté by aktuální hodnotu ze senzoru vyčetla pomocí globální proměnné, do které by získanou hodnotu ze senzoru uložil druhý přístroj, který obstarává příjem dat od NXT kostky. Tuto hodnotu by následně procedura vrátila uživateli v návratové hodnotě. Jenomže systém Control Web provádí aktivaci přístroje a datového elementu v určitém časovém toku (viz kapitola Události a aktivace). Jelikož příjem dat chvíli trvá (i když jde jen o milisekundy) způsobilo by to, že přečtení hodnoty z globální proměnné, by proběhlo dříve než by druhý přístroj, který přijímá a zpracovává přijatá data, stihl do této proměnné získanou aktuální hodnotu uložit. Z toho plyne, že v tomto případě by byla uživateli vrácena stará hodnota, která se v proměnné nacházela z předchozího dotazu. V Control Webu je na však na takový případ pamatováno a existuje příkaz wait, který je schopen pozdržet jeden konkrétní datový element do doby než je splněna zadaná podmínka. Z tohoto důvodu vznikla proměnná end_of_transfer, která je při odeslání příkazu na NXT kostku nastavena na hodnotu false a tato hodnota je změněna na true až v okamžiku, kdy skončí příjem dat a jejich zpracování. Použití wait end_of_transfer v proceduře s návratovou hodnotou by tedy tento problém elegantně vyřešil. Procedura by na zavolání pomocí prvního přístroje starajícího se o vyslání příkazu na NXT kostku vyslala dotaz a poté by díky příkazu wait počkala na přijatá data a ty by následně vrátila v návratové hodnotě procedury. Problémem ovšem je, že Control Web nepodporuje procedury s návratovou hodnotou v sekci date (v této sekci se nacházejí, při vývoji knihovny, procedury, které mají tvořit API). Díky této vlastnosti Control Webu byly procedury, které by za normálních okolností byly vytvořeny jako procedury s návratovou hodnotou, upraveny tak, že jim byl přidán parametr volaný odkazem (viz. kapitola Vývoj jako aplikační knihovna). Tato úprava ovšem znovu způsobí problém se správným vyčtením hodnoty ze senzoru. Použití příkazu wait uvnitř procedury sice zajistí pozdržení do doby, než přijdou data ze senzoru ale pouze v onom datovém elementu, kde je příkaz použit (tedy pouze v této proceduře). A jelikož zde není použita procedura s návratovou hodnotou znamená to, že samotná procedura, kterou by uživatel na vyčtení dat zavolal by sice čekala na ukončení přijmu nicméně další kód, který následuje za touto procedurou by se vykonával dál bez čekání a tím pádem by bylo opět pracováno se starými hodnotami, původně získanými z předešlých dotazů.
Vlastní práce
47
Jediným možným řešením jak se tohoto problému zbavit, bylo přesunutí příkazu wait do datového elementu samotného uživatele, díky čemuž se ono pozdržení přesune do místa, kde tvoří svůj algoritmus. Tím se zajistí, že bude vždy pracovat s aktuálními hodnotami ze senzorů. Z těchto důvodů byla uživateli zpřístupněna proměnná end_of_transfer a vznikly procedury ReadValueStart a ReadValue. Procedura ReadValueStart zprostředkuje vyslání dotazu na NXT kostku a musí být proto použita jako první, Po této proceduře musí následovat popsaný příkaz wait end_of_transfer. A až po tomto příkazu, lze použít proceduru ReadValue, přes kterou lze získat aktuální hodnotu, ze senzoru. 1 2 3 4 5 6 7 8 9 10 11 12 13
var value : boolean; end_var ... SetPorSettings(0); (* nastaveni senzoru zapojeného do portu 1 *) ... ReadValueStart(0); (* na portu 1 zahájí přenos dat *) wait end_of_transfer; (* čeká na konec přenesení dat a jejich zpracování *) ReadValue(value); (* do proměnné value přiřadí aktuální hodnotu ze senzoru *) (* v těchto místech už má uživatel jistotu, že je v proměnné value aktuální hodnota ze senzoru a může s ní dále pracovat *)
Ukázka kódu 6 Příklad správného použití procedur pro vyčtení hodnot ze senzoru
Ve specifickém případě lze využít proceduru ReadValue i samostatně. Tím případem je potřeba získat starou hodnotu ze senzoru (hodnotu, která byla získána posledním dotazem na senzor). Dále jsou uživateli k dispozici procedury GetPortSettings a GetPortQuery, díky kterým může uživatel získat informace o tom, jaký port je nastaven v příkazu nastavení (SETINPUTMODE) – procedura GetPortSettings a jaký port je nastaven v příkazu dotazu (GETINPUTVALUES) - GetPortQuery. 4.4.2
Knihovna Sound
Knihovna Sound vychází ze stejného grafického vzoru jako knihovna Touch. Z tohoto důvodu na první pohled vypadá velmi podobně. Několik rozdílů tu však je. Zvukový senzor pracuje ve full scale módu. To znamená, že vrací číselné hodnoty v rozpětí 0 – 100. Čím vyšší číslo tím větší zaznamenaná intenzita zvuku. Z tohoto důvodu se v bloku, který je určen pro zobrazení hodnot ze senzoru místo indikátoru nachází přístroj, který zobrazuje číselnou hodnotu. Další odlišnosti, oproti knihovně Touch, si uživatel může všimnout v informativní části panelu, kde se liší číselné hodnoty v příkazu pro nastavení.
Vlastní práce
Obr. 22
48
Grafický panel knihovny Sound (zobrazena pouze jeho nastavovací část)
Opět platí, že hodnota ze senzoru, zobrazující se v přístroji meter (přístroj zobrazující číselnou hodnotu ze senzoru), se nemění do doby než je na senzor odeslán nový dotaz (podrobněji vysvětleno v kapitole Knihovna Touch). Pro snadnější používání všech knihoven byly zachovány (pokud to bylo možné) stejné názvy procedur a proměnných v aplikačním rozhraní knihoven. Knihovna Sound tedy obsahuje následující procedury: • SetPortSettings( port : shortcard ) • GetPortSettings( var returning : shortcard ) • GetPortQuery( var returning : shortcard ) • ReadValueStart( port : shortcard ) • ReadValue( var returning : shortcard ) • proměnná end_of_transfer
Názvy procedur a proměnné tedy zůstaly stejné. Jediným rozdílem je datový typ shortcard v parametru volaném odkazem procedury ReadValue. Důvod je jasný, zvukový senzor poskytuje číselné hodnoty na rozdíl od dotykového senzoru. Stejně jako v knihovně Touch je vyřešené i získávání aktuální hodnoty ze senzoru pomocí proměnné end_of_transfer a procedur ReadValueStart a ReadValue (jejich použití je podrobně popsané v kapitole Knihovna Touch). Od uživatele je
Vlastní práce
49
opět pro nastavení portu a dotazu na něj, vyžadováno pouze definování tohoto portu v parametrech příslušných procedur. Vstupní porty na NXT kostce jsou označeny port 1, port 2, port 3 a port 4. Ale pozor stejně jako v knihovně Touch bylo použito číselného typu začínajícího od nuly! Tab. 9
Vstupní porty reprezentované čísly
Vstupní porty na NXT kostce Port 1 Port 2 Port 3 Port 4
4.4.3
Číselná reprezentace 0 1 2 3
Knihovna Light
Knihovna Light opět vychází ze stejného grafického vzoru jako knihovny Touch a Sound. Zachovává si tak jednotný grafický design, který byl použit na všechny ostatní knihovny. Světelný senzor má však speciální vlastnost, kterou předchozí dva senzory nemají. Dokáže pracovat ve dvou módech. Prvním z nich je mód snímání odstínů šedi. Při výběru tohoto módu se na senzoru aktivuje dioda. Tato dioda osvětluje detekovaný objekt a tento osvětlovaný objekt část světla pohltí a zbytek odrazí zpět, kde ho zachytí fototranzistor. Ze zachyceného odrazu se vyhodnotí odstín šedi, který se pohybuje v rozmezí hodnot 0-100. Druhý mód je samotná detekce okolního světla. V tomto módu je dioda vypnutá a fototranzistor snímá pouze intenzitu okolního světla. Senzor nastavený v tomto módu opět vrací hodnoty v rozmezí 0 – 100. V obou těchto módech nižší hodnota značí nižší intenzitu světla respektive tmavší barvu (v módu snímání odstínů šedi). Z tohoto důvodu přibyl v nastavovací části přístroj ve kterém uživatel nastaví v jakém módu má senzor pracovat. V barevně odlišeném bloku, který je určen pro zobrazení hodnot ze senzoru, je opět přístroj zobrazující číselné hodnoty podobně jako v knihovně Sound.
Vlastní práce
Obr. 23
50
Grafický panel knihovny Light (zobrazena pouze jeho nastavovací část)
V aplikačním rozhraní knihovny Light byla opět snaha dodržet co možná nejvíce shodnou strukturu a názvy procedur sloužících k ovládání světelného senzoru. Ale díky nutnosti nastavení módu, v jakém má světelný senzor pracovat, bylo nutné některé procedury upravit. Aplikační rozhraní knihovny Light vypadá tedy následovně: • SetPortAndModeSettings( port : shortcard, mode : boolean ) • GetPortSettings( var returning : shortcard ) • GetModeSettings ( var returning : boolean ) • GetPortQuery( var returning : shortcard ) • ReadValueStart( port : shortcard ) • ReadValue( var returning : shortcard ) • proměnná end_of_transfer
Od uživatele je opět vyžadováno definování portu pro nastavení a dotaz. Stejně jako v předchozích dvou knihovnách bylo zachováno použití číselného typu začínajícího od nuly!
Vlastní práce Tab. 10
51
Vstupní porty reprezentované čísly
Vstupní porty na NXT kostce Port 1 Port 2 Port 3 Port 4
Číselná reprezentace 0 1 2 3
Na rozdíl dotykového a zvukového senzoru je potřeba u světelného senzoru v některých procedurách specifikovat mód ve kterém má senzor pracovat. Jelikož jsou módy jen dva byl zvolen datový typ boolean: Tab. 11
Reprezentace módu v jakém má světelný senzor pracovat
Mód, v kterém má senzor pracovat Boolean reprezentace Mód snímání odstínů šedi (dioda je zap.) True Mód snímání okolního světla (dioda je vyp.) False Přijímání hodnot ze senzorů je opět vyřešeno stejným způsobem jako v knihovnách Touch a Sound, pomocí proměnné end_of_transfer a procedur ReadValueStart a ReadValue (jejich použití je podrobně popsané v kapitole Knihovna Touch).
4.5 Použití knihoven v nové aplikaci Použití knihoven v aplikaci, kterou vytváří uživatel je velmi jednoduché a je vyřešené opět pomocí přístrojů. Do aplikace lze knihovnu vložit s pomocí kontejneru, kterým je přístroj library. Vizuální rozhraní knihovny je v místě vložení kontejneru napojeno na aplikaci. Přístroj library zajistí propojení datových elementů aplikace a knihovny a zpřístupní také procedurální rozhraní knihovny. S přístrojem library se pracuje stejně jako s kterýmkoliv jiným. Lze ho nalézt v paletě přístrojů mezi ostatními přístroji. Vložení jednoho přístroje reprezentuje vložení jedné knihovny. Chce-li uživatel použít více knihoven současně musí vložit odpovídající počet přístrojů library. V inspektoru přístroje je nutné definovat v parametru file, cestu k souboru s knihovnou. Kromě této cesty je nutné provázat proměnné knihovny a vytvářené aplikace. Toto provázání se provádí v parametrech library_input, kde se propojují proměnné, které mají do knihovny vstupovat a library_output, kde se napojují proměnné, ze kterých je možné získávat data vystupující z knihovny. U žádné z knihoven není nutné definovat vstupy (library_intput). Knihovna samozřejmě potřebuje vstupní data ale všechny potřebné údaje, které jsou potřeba získat od uživatele jsou vyřešeny pomoví vstupních parametrů procedur v aplikačním rozhraní. U knihovny Motor není nutné definovat ani výstupy (library_output). Ale u knihoven ovládající senzory (Touch, Sound, Light) už jeden
Vlastní práce
52
výstup existuje. Výstupem je proměnná end_of_transfer (podrobný popis včetně důvodu vzniku této proměnné a jejího použití se nachází v kapitole Knihovna Touch). Tato proměnná je typu boolean a je proto nutné aby jí na straně aplikace byla přiřazena globální proměnná opět typu boolean. Do této globální proměnné budou ukládány výstupy z proměnné end_of_transfer. Vloženou knihovnu není nutné jakkoliv časovat. Procedury v aplikační rozhraní knihovny si uživatel může prohlédnout v grafickém editoru ve stromu s přístroji v záložce Vybraný přístroj.
Obr. 24
Procedury knihovny Motor
Používání těchto procedur v aplikaci se provádí stejně jako se v Control Webu používají nativní procedury - přes tečkovou notaci. To znamená název přístroje tečka název procedury, kterou chce uživatel použít. Například jmenuje-li se přístroj library Motor a používá stejnojmennou knihovnu Motor tak přístup k proceduře Execute bude Motor.Execute().
Vlastní práce
53
1 program test; 2 activity 3 period = 0.1; 4 end_activity; 5 6 procedure OnStartup(); 7 begin 8 Light.SetPortAndModeSettings(0, true); 9 Motor.MotorStart(1, true, 50); 10 Motor.MotorStart(2, true, 50); 11 end_procedure; 12 13 procedure OnActivate(); 14 var 15 value: shortcard; 16 begin 17 Light.ReadValueStart(0); 18 wait konec; 19 Light.ReadValue(value); 20 if value < 40 then 21 Motor.MotorStop(1); 22 Motor.MotorStop(2); 23 end; 24 end_procedure; 25 end_program; Obr. 25
Jednoduchý příklad použití knihoven
Pro realizaci uvedeného příkladu je nutný Lego robot, který má zapojeny dva servomotory ve výstupních portech B a C. Kromě servomotorů je nutný světelný senzor zapojený do vstupního portu 1. Po spuštění se Lego robot rozjede dopředu a pojede do doby než jeho světelný senzor nenarazí na černou barvu. Pro správné fungování je nutné v aplikaci použít knihovny Motor a Light. Kód vykonávající úlohu je v přístroji program, který byl pojmenován „test“. Tento přístroj je virtuální a nemá žádnou grafickou podobu a z toho důvodu se automaticky vkládá do neviditelných přístrojů. Přístroj program je schopen vykonávat obecný algoritmus a volat nativní procedury jiných přístrojů, proto se dobře hodí pro případy, kdy chce uživatel používat pouze programový kód, jako v tomto příkladu. V přístroji se nacházejí dvě procedury OnStartup() a OnActivate(). Obě tyto procedury jsou nativní procedury přístroje program a mají následující vlastnosti. Procedura OnStartup() se provede za celou dobu spuštění pouze jednou a to hned na začátku startu aplikace jako první. V této proceduře se nachází příkaz, který nastaví na vstupním portu 1 světelný senzor do módu snímání odstínu šedi a příkazy, které spustí motory zapojené ve výstupních portech B a C. Druhá procedura OnActivate() se provede vždy, když je přístroj aktivo-
Vlastní práce
54
ván. Aktivace, v tomto příkladu, proběhne desetkrát za sekundu což zajišťuje časování přístroje periodou v sekci aktivity. Toto časování by se dalo přirovnat k cyklu, který proběhne desetkrát za sekundu a běží v nekonečné smyčce až do doby, než je aplikace zastavena. Příkazy v této proceduře zajišťují přečtení hodnoty ze senzoru. Následně jejich vyhodnocení v podmínce zda-li se nejedná o černou respektive tmavou barvu (value<40) a pokud ano oba motory jsou zastaveny. Celý příklad by se dal vylepšit o vložení tlačítka, které by po stisku opět spustilo oba motory a robot by opět mohl vykonávat danou úlohu bez nutnosti zastavení a opětovného spuštění aplikace. A zde se dostáváme k důvodu proč je ovládání Lego robota v systému Control Web tak výhodné a proč tato diplomová práce vznikla. Pomocí přístrojů v Control Webu je možné vytvářet speciální úlohy, které budou v reálném čase reagovat na události od uživatele (stisk tlačítka, výběr z možností apod.). Tyto události pak budou aktivovat určité bloky kódu naprogramované v daných přístrojích a ovlivňovat chování robota. V tom je síla Control Webu, který s využitím těchto knihoven posouvá možnosti ovládání robota do nových rozměrů.
Závěr
55
5 Závěr 5.1
Shrnutí práce
V práci bylo popsáno fungování robota Lego Mindstorms NXT 2.0 včetně všech jeho nejdůležitějších periferií (servomotory a senzory). Byla popsána i komunikace mezi NXT kostkou a Control Webem. Na základě těchto zjištěných informací, bylo v praktické části vytvořeno několik knihoven, které jsou schopné tohoto robota ovládat. Při tvorbě knihoven bylo vybráno řešení, které ovládá robota přímo, prostřednictvím přímých příkazů vysílaných na robota z ovladače v Control Webu. Namísto původního navrhovaného řešení s využitím ActiveX komponenty. Hotové knihovny byly otestovány, aby se prověřena jejich správná funkčnost a všechny zásady používání těchto knihoven byly následně popsány v teoretické části této práce.
5.2 Zhodnocení výsledků Správná funkčnost všech knihoven byla vyzkoušena na robotovi Lego Mindstorms NXT 2.0, který se nachází v laboratoři Mendelovy univerzity. U všech knihoven byly postupně vyzkoušeny všechny procedury, které tvoří aplikační rozhraní a vznikla řada jednoduchých úloh, které správnou funkčnost těchto procedur prověřily (jeden z příkladů je popsán v kapitole Použití knihoven v nové aplikaci). Při těchto testovacích úlohách nebyly zjištěny žádné problémy. Vypracováním práce byly splněny všechny cíle.
5.3 Budoucí využití a možná rozšíření Při tvorbě této práce bylo spolupracováno s lidmi z univerzity, kteří o tuto práci projevili zájem z důvodu jejího možného využití při výuce. Připomínky a návrhy těchto lidí byly v práci zohledněny a v řadě případů zapracovány. O budoucím využití práce je tedy již rozhodnuto, bude sloužit studentům univerzity při výuce v předmětech, které se zabývají touto oblastí. Vzniklé knihovny slouží pro ovládání servomotorů a pasivních senzorů robota Lego Mindstorms NXT 2.0. Tato diplomová práce tedy položila silný základ, který vyřešil největší překážky, které se skrývali zejména v komunikaci mezi NXT kostkou a Control Webem a je tedy možné v budoucnu na tuto práci navázat a vytvořit další knihovny ovládající nové senzory nebo rozšířit stávající knihovny o nové funkce.
Literatura
56
6 Literatura [1]
[2]
[3] [4]
[5]
[6]
[7]
[8]
[9]
[10] [11] [12] [13]
ŠOLC, FRANTIŠEK. Robotika, modelování a řízení robotů: Robotics, modelling and control of robots : teze přednášky ke jmenování profesorem v oboru "technická kybernetika". Brno: VUTIUM, 2004, 28 s. Vědecké spisy (Vysoké učení technické v Brně). ISBN 80-214-2618-7. CHURAVÝ, LUKÁŠ. Průmysloví roboti – základní pojmy. [online]. 2006 [cit. 2013-12-21]. Dostupné z: http://programujte.com/clanek/2006032007robotika-ii/ Control web 2000. vyd. 1. Praha: Computer Press, 1999, 382 s. ISBN 80722-6258-0. CHALUPA, RADEK. Programování COM objektů, ActiveX a Win32 aplikací: s využitím knihovny ATL. 1. vyd. Praha: BEN - technická literatura, 2006, 405 s. ISBN 80-730-0197-7 ČEPIČKA, DAVID. Základy technologie Bluetooth: komunikace a zabezpečení. [online]. 2009 [cit. 2013-12-21]. Dostupné z: http://pcworld.cz/hardware/Zaklady-technologie-Bluetoothkomunikace-a-zabezpeceni-6636 ČEPIČKA, DAVID. Základy technologie Bluetooth: původ a rozsah funkcí. [online]. 2009 [cit. 2013-12-21]. Dostupné z: http://pcworld.cz/hardware/Zaklady-technologie-Bluetooth-puvod-arozsah-funkci-6635 MITREGA, MICHAL. Bluetooth 4.0 přichází s dosahem 100 metrů. [online]. 2010 [cit. 2013-12-21]. Dostupné z: http://pctuning.tyden.cz/component/content/article/1-aktualnizpravy/18112-bluetooth-4-0-prichazi-s-dosahem-100-metru JEDLIČKA, TOMÁŠ. RealTerm - Sériový terminál. [online]. 2003 [cit. 201312-21]. Dostupné z: http://www.hw.cz/navrh-obvodu/software/realtermseriovy-terminal.html Lego Mindstorms. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2012 [cit. 2013-12-21]. Dostupné z: http://en.wikipedia.org/wiki/Lego_Mindstorms LEGO Mindstorms NXT User Guide. [s.l.] : [s.n.], ©2006. 64s LEGO Mindstorms NXT Direct Commands. [s.l.] : [s.n.], ©2006. 12s LEGO Mindstorms NXT Communication Protocol. [s.l.] : [s.n.], ©2006. 24s SANDLER, ANNA. How to make LEGO NXT drive. [online]. [cit. 2013-12-21]. Dostupné z: http://www.robotappstore.com/Knowledge-Base/How-tomake-LEGO-NXT-drive/86.html
Literatura
57
[14] SANDLER, ANNA. How to Control Lego NXT Motors. [online]. [cit. 2013-1221]. Dostupné z: http://www.robotappstore.com/Knowledge-Base/How-to-Control-Lego-NXT-Motors/81.html [15] SANDLER, ANNA. How to send commands to Lego NXT. [online]. 2010 [cit. 2013-12-21]. Dostupné z: http://www.robotappstore.com/KnowledgeBase/How-to-send-commands-to-Lego-NXT/37.html
Přílohy
58
Přílohy
Mapovací soubor
59
A Mapovací soubor 1 begin 2 1 real input 3 2 boolean output 4 3 real input 5 4 real input 6 5 real input 7 6 real input 8 7 string input 9 8 - 10 real input 10 11 real input 11 12 boolean output 12 13 real input 13 14 boolean output 14 15 real input 15 20 string input 16 21 real input 17 22 string output 18 23 string output 19 24 real output 20 25 real output 21 26 boolean output 22 27 real output 23 999 - 1999 real input 24 2000 - 2999 real output 25 end. Ukázka kódu 7 Struktura mapovacího souboru nxt.dmf
Parametrický soubor
B Parametrický soubor 1 [Settings] 2 ComDriver = CWCOMM.DLL COM1 3 NumRepeat =1 4 Timeout = 500 5 InputBufferSize = 2048 6 OutputBufferSize = 2048 7 InpTerminator = none 8 OutTerminator = none 9 Multistring = true 10 Trace = none 11 ReceiveMode = char 12 13 [comm] 14 baudrate = 57600 15 parity = none 16 databits =8 17 stopbits =1 18 cts_flow = disable 19 dsr_flow = disable 20 dtr_control = disable 21 rts_control = disable 22 dsr_sense = low 23 rx_interchar_timeout = 0 24 rx_char_timeout = 0 25 rx_timeout =0 26 tx_char_timeout = 0 27 tx_timeout =0 28 rx_buffer = 2048 29 tx_buffer = 2048 30 rx_frame_buffer = 0 31 tx_frame_buffer = 0 Ukázka kódu 8 Struktura parametrického souboru nxt.par
60
Knihovna Motor
C Knihovna Motor
Obr. 26
Grafický panel knihovny Motor (zobrazena jak nastavovací část tak i informativní)
61
Knihovna Touch
D Knihovna Touch
Obr. 27
Grafický panel knihovny Touch (zobrazena jak nastavovací část tak i informativní)
62
Knihovna Sound
E Knihovna Sound
Obr. 28
Grafický panel knihovny Sound (zobrazena jak nastavovací část tak i informativní)
63
Knihovna Light
F Knihovna Light
Obr. 29
Grafický panel knihovny Light (zobrazena jak nastavovací část tak i informativní)
64
DVD se zdrojovými soubory knihoven
65
G DVD se zdrojovými soubory knihoven / aplikace soubory pro CW nxt.dmf nxt.par Light aplikace.cw Touch aplikace.cw Sound aplikace.cw Motor aplikace.cw knihovny Light.cwl Touch.cwl Sound.cwl Motor.cwl nxt.dmf nxt.par zdrojové kódy zdrojový kód knihovny Light.txt zdrojový kód knihovny Touch.txt zdrojový kód knihovny Sound.txt zdrojový kód knihovny Motor.txt Obr. 30
Struktura souborů na přiloženém DVD
