Systém pro robotickou tele-výuku

Transkript

Gerstner Laboratory
for Intelligent Decision Making
laboratory
Gerstner
SyRoTek: V003.1 Detailní koncepce systému
Jan Faigl, Jan Chudoba, Miroslav Kulich, Roman Mázl, Karel
Košnar, Libor Přeučil, Petr Štěpán
{xfaigl,chudoba,kulich,mazl,kosnar,preucil}@labe.felk.cvut.cz,
[email protected]
Report No. GLR 82/08 Date 13/02/2008
Gerstner Laboratory
Katedra Kybernetiky (K13133)
Faculty of Electrical Engineering
Technická 2, 166 27, Prague 6,
Czech Republic
http://gerstner.felk.cvut.cz
c 2008
Systém pro robotickou tele-výuku
SyRoTek
V003.1- Detailní koncepce systému
ver. 1.0
13/02/2008
laboratory
Gerstner
ČVUT v Praze, FEL, Gerstner Laboratory, ProTyS a.s.
OBSAH
SyRoTek - V003.1
Obsah
1 Úvod
19
2 Webové rozhraní
23
2.1
2.2
Základní webové rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.1.1
Vizualizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.1.2
Výukové kurzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Demonstrační rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3 Úlohy a návody
3.1
3.2
28
Úlohy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.1.1
Podpůrný software . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.1.2
Specifikace zadání úlohy . . . . . . . . . . . . . . . . . . . . . . . .
35
Návody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4 Databáze uživatelů
37
4.1
Autentizace uživatele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2
Autorizace uživatele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.3
Profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.4
Rezervace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.5
Datové a pracovní soubory . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.6
Logy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.7
E-Mailové zprávy a záznamy komunikace . . . . . . . . . . . . . . . . . . .
50
4.8
Data z vyplněných formulářů . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.9
Zálohování uživatelských dat . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.10 Vazby na ostatní části systému . . . . . . . . . . . . . . . . . . . . . . . .
53
ČVUT FEL, Gerstner Laboratory, ProTyS a.s.
5/217
OBSAH
SyRoTek - V003.1
5 Řídící počítač
5.1
5.2
58
Softwarová architektura řídícího počítače . . . . . . . . . . . . . . . . . . .
60
5.1.1
Systémové aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.1.2
Uživatelská aplikace . . . . . . . . . . . . . . . . . . . . . . . . . .
84
Operační systém řídicího počítače . . . . . . . . . . . . . . . . . . . . . . .
85
6 Roboty a senzory
88
6.1
Softwarová koncepce palubního počítače . . . . . . . . . . . . . . . . . . .
88
6.2
Mikrokontroléry robotu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
6.2.1
Unifikace přístupu k MCU . . . . . . . . . . . . . . . . . . . . . . .
92
6.3
Řízení spotřeby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
6.4
Charakteristiky a servisní procedury robotu . . . . . . . . . . . . . . . . .
97
7 Uživatelská stanice
100
7.1
Webové rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.2
Vizualizační rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.3
Vývojové nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.4
Podpůrné nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.5
Plán realizace uživatelské stanice . . . . . . . . . . . . . . . . . . . . . . . 109
8 Aréna
112
8.1
Konstrukce arény . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.2
Osvětlení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.3
Plocha desky arény . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.4
Překážky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.5
Dokovací stanice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.6
Údržba arény . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9 Servisní rozhraní
122
9.1
Údržba hardwarových komponent . . . . . . . . . . . . . . . . . . . . . . . 124
9.2
Administrátorské role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
9.3
Administrátorské rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.4
Logování a zpracování logů . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6/217
OBSAH
SyRoTek - V003.1
9.4.1
Logy systémových aplikací operačního systému . . . . . . . . . . . . 129
9.4.2
Logy systémových aplikací SyRoTek . . . . . . . . . . . . . . . . . 131
9.4.3
Logy uživatelské aplikace . . . . . . . . . . . . . . . . . . . . . . . . 133
9.5
Zálohování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
9.6
Softwarové požadavky z hlediska údržby . . . . . . . . . . . . . . . . . . . 134
10 Lokalizační systém
136
10.1 Způsoby kamerové lokalizace robotu . . . . . . . . . . . . . . . . . . . . . . 138
10.2 Technologie realizace lokalizace . . . . . . . . . . . . . . . . . . . . . . . . 140
10.2.1 IEEE1394 rozhraní a běžný stolní počítač . . . . . . . . . . . . . . 141
10.2.2 Počítač pro zpracování obrazu . . . . . . . . . . . . . . . . . . . . . 146
10.3 Zásuvné karty pro přenos obrazu . . . . . . . . . . . . . . . . . . . . . . . 147
10.3.1 Zásuvné karty pro zpracování obrazu . . . . . . . . . . . . . . . . . 154
10.4 Inteligentní kamery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.5 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
11 Vizualizace
175
11.1 Kódování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
11.1.1 Windows Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
11.1.2 Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
11.1.3 QuickTime
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
11.1.4 RealVideo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
11.1.5 H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
11.1.6 Theora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
11.2 Streamovací servery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
11.3 Kamery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
11.4 Hardware pro převod video dat . . . . . . . . . . . . . . . . . . . . . . . . 182
11.5 Streamovací servery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
11.5.1 HTTP Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
11.5.2 Streamování a další metody . . . . . . . . . . . . . . . . . . . . . . 189
11.5.3 Helix Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
11.5.4 Darwin Streaming Server . . . . . . . . . . . . . . . . . . . . . . . . 190
11.5.5 Flash Media Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
7/217
OBSAH
SyRoTek - V003.1
11.5.6 VideoLan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
11.6 Archivace video dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
11.7 Vizualizace v systému SyRoTek . . . . . . . . . . . . . . . . . . . . . . . . 193
11.7.1 Publikování audio, video a datových proudů a souborů . . . . . . . 201
11.7.2 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
12 Závěr
208
8/217
SEZNAM OBRÁZKŮ
SyRoTek - V003.1
Seznam obrázků
5.1
Propojení objektů systému SyRoTek s řídicím počítačem. . . . . . . . . . .
61
5.2
Abstrakce uživatelského přístup k robotu a senzorům. . . . . . . . . . . . .
63
5.3
Přístupový modul robotu. . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.4
Přístupový modul robotu. . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.5
Vizualizační prostředí ARDev, obrázek převzat z [21]. . . . . . . . . . . . . .
69
5.6
Vizualizace algoritmu sledování lidí rozhraním Player Viewer 3D. . . . . .
69
5.7
Příklady tématické konfigurace arény, pevné překážky jsou zobrazeny šedou
barvou, pohyblivé překážky červenou. . . . . . . . . . . . . . . . . . . . . .
71
5.8
Funkční bloky konfigurace arény. . . . . . . . . . . . . . . . . . . . . . . .
72
5.9
Schematické propojení uživatelských aplikací a evaluačního monitoru. . . .
77
5.10 Mechanismus vzdáleného krokování aplikace na robotu. . . . . . . . . . . .
82
5.11 Modul monitorování stavu robotů. . . . . . . . . . . . . . . . . . . . . . . .
83
6.1
Přístupu uživatelské aplikace ke komunikačním rozhraním palubního počítače. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
6.2
Základní připojení mikrokontrolérů robotu k OBC. . . . . . . . . . . . . .
91
6.3
Propojení jednotlivých MCU a senzorů na robotické platformě systému SyRoTek. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
8.1
Schematické uspořádání učebny, ve které je umístěna aréna systému SyRoTek.113
8.2
Snadno rozpoznatelné symboly v reálném prostředí Rat’s Life, obrázek převzat z [54]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.3
Rozdělení plochy na dokovací a operační prostor. . . . . . . . . . . . . . . 118
8.4
Rozvržení arény systému SyRoTek. . . . . . . . . . . . . . . . . . . . . . . 121
10.1 NorthStar projektor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9/217
SEZNAM OBRÁZKŮ
SyRoTek - V003.1
10.2 NorthStar detektor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
10.3 Typická konfigurace kamerového systému lokalizace MiroSot. . . . . . . . . 138
10.4 Ploška s šachovnicí pro jednoznačné zjištění natočení robotu. . . . . . . . . 139
10.5 Řada USB kamer firmy Matrix Vision. . . . . . . . . . . . . . . . . . . . . 144
10.6 Firewire kamera Unibrain Fire-i. . . . . . . . . . . . . . . . . . . . . . . . . 145
10.7 Firewire kamera Unibrain compact. . . . . . . . . . . . . . . . . . . . . . . 145
10.8 Firewire kamera Unibrain Fire-i. . . . . . . . . . . . . . . . . . . . . . . . . 145
10.9 Matrox 4Sight M, počítač pro zpracování obrazu. . . . . . . . . . . . . . . 146
10.10Zásuvné PCI karty řady GrabLink společnosti Euresys s rozhraním Camera
Link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
10.11Zásuvná karta DT3145 s rozhraním Camera Link společnosti Data Translation.149
10.12Zásuvná karta mvHYPERION-CLe s rozhraním Camera Link společnosti
Matrix Vision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
10.13Vysokorychlostní kamera Pantera 11M4. . . . . . . . . . . . . . . . . . . . 153
10.14Vysokorychlostní kamera Pantera série 2M30. . . . . . . . . . . . . . . . . 154
10.15Zásuvné karty pro zpracování obrazu řady mvTITAN společnosti Matrix
Vision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
10.16Zásuvná karta FastImage1303. . . . . . . . . . . . . . . . . . . . . . . . . . 155
10.17Zásuvná karta FastFrame1303. . . . . . . . . . . . . . . . . . . . . . . . . . 155
10.18Zásuvná karta Fast-X. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
10.19Zásuvná karta FastFrame-CB. . . . . . . . . . . . . . . . . . . . . . . . . . 156
10.20Zásuvná karta řady leonardo. . . . . . . . . . . . . . . . . . . . . . . . . . 156
10.21Zásuvná karta řady Odyssey XCL. . . . . . . . . . . . . . . . . . . . . . . 157
10.22Deska vývojového kitu DMEK642. . . . . . . . . . . . . . . . . . . . . . . 157
10.23Blokové schema kitu DMEK642. . . . . . . . . . . . . . . . . . . . . . . . . 158
10.24Inteligentní kamera Matrox Iris. . . . . . . . . . . . . . . . . . . . . . . . . 159
10.25Inteligentní kamera mvBlueLYNX1. . . . . . . . . . . . . . . . . . . . . . . 160
10.26Komponenty balíku mvIMPACT. . . . . . . . . . . . . . . . . . . . . . . . 160
10.27Deska se snímacím čipem pro zpracování obrazu mvBlueLYNX-M. . . . . . 160
10.28Kamera Apollo AIT100HS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
10.29Tělo kamery řady eXcite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
10.30Inteligentní kamery Vision Components s výkonem 3200 MIPS. . . . . . . . 163
10.31Inteligentní kamery Vision Components s výkonem 8000 MIPS. . . . . . . . 164
10/217
SEZNAM OBRÁZKŮ
SyRoTek - V003.1
10.32Inteligentní kamera NC5100. . . . . . . . . . . . . . . . . . . . . . . . . . . 164
10.33Kamera IMPACT A-10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
10.34Kamera IMPACT T série. . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
10.35Kamera IMPACT C série. . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
10.36Aplikace inteligentní kamery TAG Plus společnosti Tattile. . . . . . . . . . 166
10.37Inteligentní kamera TAG Plus. . . . . . . . . . . . . . . . . . . . . . . . . . 167
10.38Kamera systém XP TAG. . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
10.39Schema použití systému XP TAG. . . . . . . . . . . . . . . . . . . . . . . . 170
10.40Bayerova maska barevných snímacích čipů. . . . . . . . . . . . . . . . . . . 171
10.41Komprese obrazu sdílením jasových složek, obrázek převzat z [95]. . . . . . 171
10.42Ilustrace rozměrů plochy snímané kamerou v závislosti na parametrech optické soustavy, obrázek převzat z [96]. . . . . . . . . . . . . . . . . . . . . . 172
11.1 Ilustrace funkčnosti VLS serveru, obrázek převzat z [107]. . . . . . . . . . . 178
11.2 PTZ kamera EVI-D100P . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
11.3 PTZ kamera EVI-D70P . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
11.4 Webová kamera Logitech QuickCam Express. . . . . . . . . . . . . . . . . 182
11.5 Webová kamera Logitech QuickCam Ultra Vision. . . . . . . . . . . . . . . 182
11.6 Zachytávací USB zařízení Osprey50. . . . . . . . . . . . . . . . . . . . . . . 183
11.7 Zachytávací karta Osprey100. . . . . . . . . . . . . . . . . . . . . . . . . . 183
11.10Zachytávací karta Osprey300. . . . . . . . . . . . . . . . . . . . . . . . . . 184
R
11.13Princip činnosti software Osprey SimulStream.
. . . . . . . . . . . . . . 184
11.14Kódovací karta Osprey1000. . . . . . . . . . . . . . . . . . . . . . . . . . . 185
11.15Kódovací karta Osprey2000. . . . . . . . . . . . . . . . . . . . . . . . . . . 185
11.16Systém Niagara 4100. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
11.17Systém Niagara 7224. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
11.18Kódovací server MediaBox VS-2601. . . . . . . . . . . . . . . . . . . . . . 186
11.19Softwarová architektura Open Platform serveru MediaBox VS-2601. . . . . 187
11.20Zachytávací karta Spectra8. . . . . . . . . . . . . . . . . . . . . . . . . . . 187
11/217
SEZNAM OBRÁZKŮ
SyRoTek - V003.1
11.21Platforma Helix DNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
11.22Zdrojové kódy Helix DNA a software společnosti RealNetworks. . . . . . . 190
11.23Přehrávání více video záznamů na jediné HTML stránce. . . . . . . . . . . 191
11.24Zobrazení 2. video záznamu na ploše přehrávaného 1. videa. . . . . . . . . 192
11.25Koncepce vizualizace v systému SyRoTek. . . . . . . . . . . . . . . . . . . 194
12/217
SEZNAM TABULEK
SyRoTek - V003.1
Seznam tabulek
2.1
Části webového rozhraní realizovatelné funkcionalitami LMS. . . . . . . . .
24
2.2
Části webového rozhraní integrované zapouzdřením jiné aplikace.
. . . . .
25
3.1
Typy prostředí v systému SyRoTek. . . . . . . . . . . . . . . . . . . . . . .
30
3.2
Základní charaktery prostředí reprezentovatelné na ploše arény systému SyRoTek, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.3
Základní a rozšiřující konfigurace senzorické výbavy robotu. . . . . . . . .
32
3.4
Způsoby odevzdání úlohy. . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.5
Dílčí specifikace realizace úlohy. . . . . . . . . . . . . . . . . . . . . . . . .
35
4.1
Uživatelská data a jejich základní umístění. . . . . . . . . . . . . . . . . . .
39
4.2
Základní moduly vyžadující autentizaci uživatele. . . . . . . . . . . . . . .
39
4.3
Uživatelské služby v systému SyRoTek. . . . . . . . . . . . . . . . . . . . .
40
4.4
Zabezpečení uživatelských služeb systému SyRoTek. . . . . . . . . . . . . .
41
4.5
Uživatelské role v systému SyRoTek při přístupu přes webové rozhraní. . .
42
4.7
Hlavní kategorie uživatelů v řídicím počítači. . . . . . . . . . . . . . . . . .
43
4.8
Základní přístupová práva uživatele student, v závislosti na jeho zkušenostech rank. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.6
Rozlišení uživatelů podle zkušeností. . . . . . . . . . . . . . . . . . . . . .
45
4.9
Základní data profilu uživatele jednotlivých modulů/služeb systému SyRoTek. 45
4.10 Události generované přístupem do rezervačního systému a vytvořenými rezervacemi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.11 Podpůrné nástroje pro správu uživatelského prostředí na robotu. . . . . . .
48
4.12 Nástroje správy uživatelského prostředí pro podporu vytvoření důvěryhodných dat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.13 Funkcionality modulu uživatelských dat pro potřeby zálohování a údržby. .
53
13/217
SEZNAM TABULEK
SyRoTek - V003.1
4.14 Vazby databáze uživatelů na moduly systému SyRoTek. . . . . . . . . . . .
55
4.15 Základní funkcionality objektu uživatelské databáze. . . . . . . . . . . . . .
56
5.1
Základní funkcionality objektu řídicí počítač systému SyRoTek. . . . . . .
59
5.2
Poskytovaná rozhraní SyRoTek ovladačů systému Player. . . . . . . . . . .
64
5.3
Rozšířená rozhraní SyRoTek ovladačů systému Player. . . . . . . . . . . .
64
5.4
Základní funkce a vlastnosti simulace reálného prostředí. . . . . . . . . . .
70
5.5
Základní funkce a vlastnosti konfigurace arény. . . . . . . . . . . . . . . . .
73
5.6
Příkazy aplikace pro správu prostředí uživatelské aplikace. . . . . . . . . .
75
5.7
Základní parametry a data v prostředí uživatelské aplikace. . . . . . . . . .
76
5.8
Možnosti použití IDE a jeho propojení se systémem SyRoTek. . . . . . . .
81
5.9
Základní stavy robotu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.10 Základní části a vlastnosti aplikace monitorování robotů. . . . . . . . . . .
84
5.11 Předpokládané hlavní funkce/vlastnosti operačního systému řídicího počítače systému SyRoTek. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
5.12 Softwarové nástroje pro vývoj systémových a uživatelských aplikací pro řídicí počítač systému SyRoTek. . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.1
Dílčí kroky realizace unifikace přístupu k MCU robotické platformy. . . . .
93
6.2
Předpokládané kompilátory pro vývoj software robotu. . . . . . . . . . . .
94
6.3
Dílčí kroky realizace software MCU robotické platformy. . . . . . . . . . .
95
6.4
Periférie robotu a režimy sníženého příkonu. . . . . . . . . . . . . . . . . .
96
6.5
Základní informace profilu každého robotu. . . . . . . . . . . . . . . . . . .
98
6.6
Základní testovací a servisní procedury pro ověření činnosti a konfiguraci
robotu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
7.1
Specifikace požadavků webového rozhraní na vybavení uživatelské stanice
systému SyRoTek. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.2
Předpokládané požadavky vizualizačního software systému SyRoTek na uživatelskou stanici. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.3
Předpokládané verze podporovaných programovacích jazyků uživatelské aplikace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.4
Základní podporované nástroje pro překlad uživatelské aplikace. . . . . . . 105
7.5
Grafická rozhraní správce verzí systémem Subversion. . . . . . . . . . . . . 106
7.6
Aplikace s grafickým rozhraním pro podporu vývoje uživatelské aplikace. . 107
14/217
SEZNAM TABULEK
SyRoTek - V003.1
7.7
Základní funkcionality podpůrných vývojových knihoven uživatelské aplikace.108
7.8
Dílčí kroky realizace softwarového vybavení uživatelské stanice systému SyRoTek. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.1
Základní administrativní úkony servisního rozhraní systému SyRoTek. . . 122
9.2
Role administrátorů systému SyRoTek. . . . . . . . . . . . . . . . . . . . 127
9.3
Základní informace záznamu logu systému SyRoTek. . . . . . . . . . . . . 132
9.4
Základní požadavky na jednotlivé softwarové části systému SyRoTek z hlediska údržby. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
10.1 Způsoby kamerového systému. . . . . . . . . . . . . . . . . . . . . . . . . . 140
10.2 Řada kamer společnosti Basler s rozhraním 1394a, převzato z nabídky společnosti Total Turnkey Solutions [73]. . . . . . . . . . . . . . . . . . . . . . 142
10.3 Řada kamer společnosti Basler s rozhraním 1394b, převzato z nabídky společnosti Total Turnkey Solutions [73]. . . . . . . . . . . . . . . . . . . . . . 142
10.4 Řada kamer společnosti SONY s rozhraní IEE1394a a IEE1394b, převzato
z nabídky společnosti Total Turnkey Solutions [73]. . . . . . . . . . . . . . 143
10.5 Řada kamer společnosti Basler s rozhraním Camera Link. . . . . . . . . . . 147
10.6 Řada kamer společnosti SONY s rozhraním Camera Link.
. . . . . . . . . 148
10.7 Řada kamer společnosti Hitachi s rozhraním Camera Link. . . . . . . . . . 148
10.8 Řada kamer společnosti Miktrotron s rozhraním Camera Link. . . . . . . . 148
10.9 Řada kamera kitů SILICON VIDEO společnosti EPIX. . . . . . . . . . . . 150
10.10Kamery Prosilica s rozhraním IEEE 1394. . . . . . . . . . . . . . . . . . . 151
10.11Kamery Prosilica řady GC s rozhraním Gigabit Ethernet. . . . . . . . . . . 152
10.12Kamery Prosilica řady GE s rozhraním Gigabit Ethernet. . . . . . . . . . . 152
10.13Kamery společnosti DALSA. . . . . . . . . . . . . . . . . . . . . . . . . . . 153
10.14Řada inteligentních kamera Iirs B společnosti Matrox. . . . . . . . . . . . . 158
10.15Inteligentní kamery eXcite Basler. . . . . . . . . . . . . . . . . . . . . . . . 162
10.16Rozlišení a typ snímacího čipu řady IMPACT série T a C. . . . . . . . . . 166
10.17Řada inteligetních kamer PicSight společnosti Leutron Vision. . . . . . . . 169
10.18Odhad přesnosti určení pozice robotu na ploše 4m × 3m. . . . . . . . . . . 173
11.1 Parametry kamery EVI-D100P. . . . . . . . . . . . . . . . . . . . . . . . . 181
11.2 Parametry kamery EVI-D70P. . . . . . . . . . . . . . . . . . . . . . . . . . 181
11.3 Řízení pohyblivé kamery, návaznosti na ostatní moduly. . . . . . . . . . . . 195
15/217
11.4 Zachytávání video/audio signálů, návaznosti na ostatní moduly. . . . . . . 196
11.5 Synchronizace proudů dat, návaznosti na ostatní moduly. . . . . . . . . . . 197
11.6 Kódování výstupních audio, video a datových proudů, návaznosti na ostatní
moduly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
11.7 Plánovač archivace záznamů, návaznosti na ostatní moduly.
. . . . . . . . 201
11.8 Publikování audio, video a datových souborů. . . . . . . . . . . . . . . . . 204
11.9 Uživatelské rozhraní systému vizualizace, návaznosti na ostatní moduly. . . 206
ZNAČENÍ
SyRoTek - V003.1
Značení
MCU
cMCU
OBC
LMS
LCMS
PDF
HTML
XML
XSLT
TeX
Latex
DVI
(Microcontroller Unit) - mikroprocesor v mobilním robotu projektu SyRoTek. Mohou to být procesory dedikované pro specifické účely nebo
jako součásti inteligentních senzorů
( Central Microcontroller Unit) - hlavní řidicí procesor mobilního robotu
projektu SyRoTek
(Onboard Computer) - palubní počítač mobilního robotu projektu SyRoTek
(Learning Management System) - systém správy výuky. Softwarové balíky pro podporu studia, komunikace, sdílení a využívání znalostí a pro
řízení vzdělávání
( Learning Content Management System) - systém správy výukového obsahu. Softwarové balíky podporující efektivní tvorbu výukového obsahu
(Portable Document Format) - formát dokumentu vhodný zejména pro
výměnu dokuemtů navržený firmou Adobe Systems
( HyperText Markup Language značkovací jazyk pro tvorbu webových
stránek
(Extensible Markup Language) obecný, snadno rozšiřitelný, značkovací
jazyk
(eXtensible Stylesheet Language Transformations) - jazyk transformací
pro XSL. Slouží k převodům zdrojových dat ve formátu XML do libovolného jiných požadovaného formátů nebo struktur
systém pro sazbu textu vytvořený prof. Donaldem Knuthem
balíček TeXových maker, umožňující příjemnější práci při sázení dokumentu
( Device independent file format) - binární výstupní formát TeXu
17/217
ZNAČENÍ
SyRoTek - V003.1
18/217
KAPITOLA 1. ÚVOD
SyRoTek - V003.1
Kapitola 1
Úvod
Cílem této zprávy je blíže konkretizovat koncepci systému SyRoTek. Zpráva přímo navazuje na zprávu [1], která popisuje identifikované základní objekty systému a jejich vzájemné
vazby. Identifikované objekty jsou detailně specifikovány z hlediska požadovaných funkcionalit a návazností na ostatní části systému SyRoTek. Detailní koncepce vychází z klíčových
rozhodnutí realizace systému SyRoTek. Tato rozhodnutí jsou následující.
• Uživatelská aplikace řešící úlohu je realizována jako klientská aplikace instance serveru Player [2].
• Hlavním vývojovým prostředím systému SyRoTek je operační systém unixového typu
s rozhraním pokud možno kompatibilním s normou POSIX.
• Palubní počítač je realizován platformou ARM s instalovaným operačním systémem
s jádrem Linux.
• Webovým rozhraním výukového systému SyRoTek je některá instance LMS, pravděpodobně webová aplikace Moodle.
• Základním přístupovým bodem uživatele k systému SyRoTek je webového rozhraní,
vývoj bude primárně realizován formou vzdáleného sezení na řídicím počítači. Použité
protokoly vzájemné interakce vývojových komponent však umožňují i vývoj na jiném
počítači.
• Uživatelské aplikace budou spouštěny na řídicím a palubním počítači, případně uživatelské stanici.
• Roboty jsou propojeny s řídicím počítačem dedikovaným rádiovým spojením a lokální
WiFi sítí.
• Roboty jsou vybaveny základní senzorickou výbavou s možností rozšíření prostřednictvím výměnného modulu.
19/217
SyRoTek - V003.1
• Aréna obsahuje pohyblivé a statické překážky.
• Primární cílovou skupinou uživatelů jsou studenti bakalářských a magisterských studijních programů, sekundární cílovou skupinou jsou studenti středních škol.
Uvedená rozhodnutí mohou být případně rozšířena. Primární volba vývoje na řídicím počítači je motivována omezením požadavků na uživatelskou stanici, pro uživatele je mnohem
jednodušší přihlásit se k již plně nakonfigurovanému počítači, než řešit instalaci příslušného vývojového prostředí, neboť instalační proces může být ovlivněn lokálním nastavením.
Kromě této motivace je realizace plně distribuovaného prostředí v zásadě implementací přenosového protokolu nahrazující protokol vzdáleného sezení avšak využívající více lokálních
zdrojů.
Volba cílové skupiny neovlivňuje možnost využití systému pro výzkumné účely postgraduálních studentů nebo robotických výzkumníků, neboť ti mohou využívat stejných
rozhraních jako ostatní uživatelé. Potenciální využití platformy SyRoTek v robotickém výzkumu je především v ověření algoritmů na reálných robotech a možnosti srovnání různých
přístupů v dobře definovaném prostředí. Případné testování nových senzorů je také možné,
vyžaduje však jejich fyzické přizpůsobení schopnostem s rozhraním robotické platformy
SyRoTek.
Hlavním přístupovým bodem a celkovým rámcem systému SyRoTek je pro uživatele
webové rozhraní. V následující kapitole (2) jsou uvedené požadované funkce webového rozhraní s ohledem na současné možnosti systémů LMS. Webové rozhraní je součástí Internetového přístupu k systému SyRoTek a bude realizováno v následujících obdobích řešení
projektu. Proto jsou v kapitole popsány zejména ty části webového rozhraní, které nejsou
běžnou součástí systémů pro podporu vzdáleného vzdělávání.
Navazující kapitolou diskuse webového rozhraní je kapitola věnovaná úlohám a návodům (3). Úlohy jsou zde kategorizovány s ohledem na podpůrné funkcionality ostatních
částí systému SyRoTek tak, aby uživatelé mohli úspěšně implementovat příslušnou aplikaci, která je řešením zadané úlohy. Úloha je zde specifikována jako soubor údajů, které
kromě vlastního zadání obsahují informace pro navazující objekty systému SyRoTek Tyto
informace jsou využity při konfiguraci systému pro řešení úlohy uživatelem a podporu vyhodnocení úlohy. V závěru kapitoly je diskutována tvorba studijních materiálu řešitelským
kolektivem projektu SyRoTek.
Systém SyRoTek je zaměřen na cílovou skupinu uživatelů, kteří se systémem budou
pracovat delší dobu (například půl roku). Uživatel se k systému přihlašuje a využívá poskytovaných funkcionalit je vztaženo k jeho identitě. Současně tak, jak systém používá,
vytváří v systému datové soubory, které reprezentují je průchod příslušným kurzem. Veškeré uživatelské informace jsou reprezentovány základním objektem systému SyRoTek uživatelskou databází, která popsána v kapitole 4. Součástí této kapitoly jsou také informace
o autentizaci a autorizaci uživatele. Dále je diskutována problematika zálohování uživatelských dat, neboť z pohledu provozu systému jsou právě tato velmi obtížně nahraditelná.
20/217
KAPITOLA 1. ÚVOD
SyRoTek - V003.1
Jelikož uživatel pracuje se systémem SyRoTek v rámci webového rozhraní, řídicího a palubního počítače, jsou v závěru kapitoly uvedeny dílčí návaznosti na ostatní části systému
SyRoTek.
Přestože jsou pro uživatele základním přístupovým rozhraním webové stránky, je hlavním prvkem celého systému SyRoTek řídicí počítač. Řídicí počítač je ústředním prvkem při
řešení uživatelských úloh, v rámci kterých studenti implementují svoji vlastní uživatelskou
aplikaci pro řízení mobilního robotu. V kapitole (5) je uvedena architektura řídicí počítače
a příslušné vazby na ostatní části systému SyRoTek. Jádrem řídicího počítače jsou systémové aplikace SyRoTek, které zprostředkovávají přístup k mobilním robotům a ostatním
hardwarovým částem systému. Klíčovými funkcionalitami řídicího počítače jsou abstrakce
přístupu k palubnímu počítači, podpora vývoje a ladění uživatelské aplikace.
Kapitola 6 přímo navazuje na koncepci řídicího počítače, neboť je věnována palubnímu
počítači robotu. Podrobný koncept robotu je součástí zprávy [2], proto je v tomto dokumentu věnován prostor celkové koncepci v návaznosti na řídicí počítač, především pak
vývojovému procesu uživatelské aplikace. Součástí řešení projektu SyRoTek je realizace
a provoz více než 10 kusů robotů, proto je nezbytné unifikovat přístup k jednotlivým
výpočetním částem robotické platformy, které jsou tvořeny palubním počítačem, řídicím
procesorem, procesorem řízení napájení a inteligentními senzory vybavenými jednoduchými
mikrokontrolery. Údržba a provoz robotů vyžaduje servisní procedury, které jsou diskutovány v závěru kapitoly.
Uživatelská stanice reprezentuje druhý konec přístupové cesty uživatele k hardwaru
systému SyRoTek. Spolu s webovým rozhraním je součástí Internetového přístupu k systému, které bude řešeno v návaznosti na základní funkcionality ostatních částí systému.
V kapitole 7 jsou proto uvedeny pouze základní specifikace týkající se předpokládaných
požadavků na uživatelskou stanici a související aplikace systému SyRoTek. Hlavní část kapitoly je věnována vývojovým nástrojům a podpůrným nástrojům pro práci se systémem,
které velmi úzce souvisí s realizací řídicího a palubního počítače, neboť při realizaci těchto
dvou základních prvků systému budou vývojáři (realizátoři) projektů ve velmi podobné roli
jako uživatel u své uživatelské stanice. Závěr kapitoly proto obsahuje dílčí kroky realizace
uživatelské stanice, které jsou v prvních fázích součástí implementace systémových aplikací
řídicího a palubního počítače, neboť jsou založeny na stejných rozhraních.
Základní koncepce arény je uvedena v kapitole 8, která již respektuje plánované umístění arény v prostorách řešitelského pracoviště. V textu jsou blíže specifikovány požadavky
na realizaci překážek a ostatních konstrukčních prvků souvisejících s fyzickým umístěním
nezbytných hardwarových komponent systému SyRoTek v rámci konstrukce arény. V posledním oddíle kapitoly jsou uvedeny poznámky k údržbě arény, které souvisí s přístupem
obslužného personálu k jednotlivým částem systému.
Úkolem lokalizačního systému je poskytovat údaje o absolutních pozicích jednotlivých
robotů na ploše arény systému SyRoTek. Základem lokalizace je zpracování obrazu kamery
umístěné nad plochou arény. V kapitole 10 jsou uvedeny možné konfigurace řešení lokalizačního systému spolu s přehledem dostupných technologií, které jsou vhodné pro konkrétní
21/217
SyRoTek - V003.1
konfiguraci. V závěru kapitoly jsou uvedeny odhady přesnosti lokalizace robotu v závislosti
na použité kameře, předpokládaných rychlostech robotu a velikosti plochy arény.
Vizualizace podobně jako webové rozhraní a uživatelská stanice souvisí s koncepcí Internetového přístup uživatele k systému SyRoTek. V kapitole 11 je proto uveden přehled
aktuálně dostupných technologií jejich možností a potencionálních nevýhod. Hlavní část
kapitoly je však věnována podrobnému popisu návazností na ostatní částí systému a z toho
vyplývající požadavky.
Při provozování systému SyRoTek je nezbytná údržba systému a to jak hardwarová, tak
softwarová. Údržba systému je reprezentovaná základním objektem servisního rozhraní,
kterému je věnována kapitola 9. Součástí servisního rozhraní jsou jednotlivé uživatelské,
resp. administrátorské role správců systému. S ohledem na požadované znalosti správců je
uvedena problematika zodpovědnosti a pravomocí jednotlivých správců. Nezbytnou součástí servisního rozhraní jsou administrátorská rozhraní, která musí být jak vzdálená, tak
lokální v případě chyby spojení. Bezproblémový provoz systému je nutné podpořit monitorováním jeho aktivity, které je založeno na sofistikovaném systému logování dílčích
událostí v systému. Systém SyRoTek se skládá z množství softwarových komponent, proto
jsou v kapitole uvedeny základní požadavky na tyto komponenty z hlediska provozu a
údržby.
22/217
KAPITOLA 2. WEBOVÉ ROZHRANÍ
SyRoTek - V003.1
Kapitola 2
Webové rozhraní
Webové rozhraní tvoří hlavní přístupový bod uživatele k systému SyRoTek. Rozhraní
je reprezentováno webovými stránkami, které jsou poskytovány webovým serverem na základě uživatelských dotazů. Uživatel při přístupu na stránky interaguje s webovou aplikací,
která prezentuje uživateli stránky na základě posloupnosti jeho interakcí, neboť samotný
webový server poskytuje webové stránky protokolem Request/Response. Webová aplikace
bude založena na některém systému LMS (systém správy výuky - Learning Management
System), který je však nutné přizpůsobit požadavkům systému SyRoTek.
2.1
Základní webové rozhraní
Z rešerše současných systémů pro správu webového obsahu (LMS, LCMS) uvedené ve
zprávě [3] vyplývá, že většinu identifikovaných objektů základního webového rozhraní ze
zprávy [1] lze realizovat běžnými prostředky současných systémů LMS (například projekt
Moodle [4]). V tabulce 2.1 jsou uvedeny ty části webového rozhraní, které lze plně využít
v rámci základní instalace LMS, případně běžně dostupných rozšiřujících modulů.
Objekt / Funkce
Diskusní fórum
Aktuální informace
Diskuse se správci
Registrace uživatele
Přihlášení uživatele
Popis
Je součástí LMS systému.
Aktuální jsou realizovány jako takzvané News.
Diskuse je realizovatelná jako moderovaná diskuse v rámci
diskuzního fóra.
Mechanismus registrace může být otevřený pro všechny návštěvníku LMS, případně s potvrzením tutora.
Přístup na domovskou stránku je veřejný, veřejný přístup
k částem vyžadující uživatele je řešen přihlášením jako
host. Přihlášení uživatele je možné realizovat vůči LDAP
databázi, autorizace je však typicky realizována tabulkou
v podpůrné SQL databázi.
23/217
2.1. ZÁKLADNÍ WEBOVÉ ROZHRANÍ
Objekt / Funkce
Dokumentace
Softwarová podpora
Výukové kurzy
Správa uživatelů
Datový prostor uživatelů
SyRoTek - V003.1
Popis
Přístup k dokumentaci je možný prostřednictvím odkazů
na externí dokumenty, například soubory ve formátu PDF,
dokumenty ve formátu HTML nebo XML lze prezentovat
přímo v rámci příslušné webové stránky.
Softwarovou podporu lze realizovat odkazy na externí soubory.
Kurzy mohou být připraveny v rámci LMS systému, kde
jsou realizovány jako webové stránky s příslušnými odkazy
na externí soubory.
LMS nabízejí základní nástroje pro správu uživatelských
účtů. Nástroje jsou však omezeny pouze na prostor webového rozhraní.
V rámci webového rozhraní mají uživatelé přidělený datový
prostor, který zahrnuje například jejich příspěvky v diskusním fóru, vyplněné testy, dotazníky (formuláře). Přímý přístup na uživatelský diskový prostor je však typicky omezen
na upload souborů.
Tabulka 2.1: Části webového rozhraní realizovatelné funkcionalitami LMS.
Objekt Správa uživatelů je v LMS systému omezen, avšak toto omezení výrazným způsobem nelimituje použitelnost LMS při realizaci systému SyRoTek, neboť ostatní uživatelská
nastavení souvisejí s přístupem k řídicímu počítači a jsou do jisté míry nezávislá. Jedinou
výraznou komplikací může být uložení některých uživatelských dat profilu pro LMS v jiné
databázi než je centrální LDAP. V takovém případě musejí příslušné systémové aplikace
SyRoTek přistupovat nejen k LDAP, ale také do SQL databáze LMS. Alternativou je v takovém případě uložení pouze systémových (na úrovni operačního systému) údajů do LDAP
a ostatní uživatelská nastavení ukládat v rámci stejného SQL serveru.
Datový prostor uživatelů je v rámci systému SyRoTek mimo LMS systém reprezentován
uživatelským domovských adresářem a příslušným repositářem pro ukládání zdrojových
souborů. Plný přístup k domovskému adresáři přes webové rozhraní není nutné realizovat, neboť praktické využití je velmi malé. Základní operace upload / download souborů,
případně zobrazení obsahu je plně postačující, neboť editace a složitější operace uživatel zpravidla potřebuje až v okamžiku, kdy vzdáleně pracuje se systémem v rámci svého
uživatelského sezení na řídicím počítači.
Podobně přístup k repositáři lze realizovat dedikovanými nástroji, neboť zpravidla uživatel pracuje se svou lokální kopií repositáře. Základní vizualizace je možné implementovat
jednoduchým XML (resp. XSLT) skriptem, který je součástí základní instalace systému
Subversion spolu s příslušným moduly do webového serveru apache [5]. Komplexnější přístup je možné založit na některém projektu, který realizuje rozšířený přístup a vizualizaci
24/217
SyRoTek - V003.1
repositáře formou webových stránek, například [6].
Některé části základního objektu webové rozhraní identifikované v oddíle 2.1 zprávy [1],
mohou být velmi snadno integrované do systému LMS implementací příslušného rozhraní.
Pro webové aplikace to typicky znamená realizace skriptu v jazyku PHP. V tabulce 2.2
jsou uvedeny objekty spolu s popisem jejich možné realizace integrace do LMS.
Objekt / Funkce
Aktuální stav
Rezervační systém
Správa uživatelů
Datový prostor uživatelů (domovský adresář)
Repositář
Popis
Aktuální stav reprezentuje komponentu webového rozhraní, která zobrazuje stavové informace systémové aplikace, která monitoruje aktuální využívání systému SyRoTek. Tato aplikace je součástí systémových aplikací SyRoTek spuštěných na řídicím počítači.
Přístup k rezervačnímu systému z webového rozhraní lze
realizovat komponentou pro systém LMS, který bude využívat přímého přístupu do databáze s rezervačními údaji.
Alternativně lze využívat příkazů, které jsou součástí základních systémových aplikací SyRoTek, pro přístup k rezervačnímu systému. Tyto příkazy využívají přístupového
rozhraní, které je součástí systémové knihovny SyRoTek.
Vytvoření webového rozhraní pro tu část správy uživatelů,
která souvisí s přístupem na řídicí počítač, je nutné realizovat jako novou komponentu LMS. Jedná se vlastně o rozhraní pro příslušnou databázi, která obsahuje hodnoty příslušných proměnných uživatelského pracovního prostředí,
které je nastaveno po přihlášení uživatele. Součástí tohoto
rozhraní mohou být i pomocné administrativní nástroje,
resp. jejich webová vizualizace, především pro hromadné
příkazy nad skupinou uživatelů (vytváření, nastavování, rušení).
Základní rozhraní pro administraci domovského adresáře,
implementace příkazů pro upload, download a mazání jednotlivých souborů. Kromě práce se samostatnými soubory
je vhodné implementovat zejména rozhraní pro práci s prostředím uživatelské aplikace.
Realizace základních komponent pro vizualizaci souborů
v repositáři. Rozšířenou funkcionalitu lze realizovat samostatným webovým rozhraní, které již není součástí LMS.
Tabulka 2.2: Části webového rozhraní integrované zapouzdřením jiné aplikace.
25/217
2.1. ZÁKLADNÍ WEBOVÉ ROZHRANÍ
2.1.1
SyRoTek - V003.1
Vizualizace
Další komponentou systému SyRoTek, která v nějaké podobně může být přístupná
z webového rozhraní, je vizualizace. Webové rozhraní pro tuto funkcionalitu je zaměřeno
především na potencionální uživatele, kteří přistoupili na stránky projektu poprvé. Sledováním on-line vizualizace aktuálního dění na ploše arény může vzbudit jejich zájem a
budou tak lépe motivováni věnovat se základnímu seznámení se s funkcemi a možnosti,
které vyžadují hlubší porozumění a získání základních dovedností. Konkrétní realizace vizualizace pro tento účel a její integrace do LMS systému je závislá na zvolené technologii,
současnými možnými kandidáty jsou technologie Java Applet nebo Flash [7].
Pro již existujícího uživatele systému SyRoTek může být užitečné získat po přihlášení
do LMS aktuální informace o využití arény, resp. o dění na ploše arény. Pro tento účel
lze realizovat jednoduchou komponentu LMS, která zobrazuje statický obraz situace na
ploše arény, který je periodicky aktualizován například 2 krát za sekundu. Uživatel tak
nenáročnou formou získá základní přehled o dění na ploše a pro komfortnější vizualizaci
použije specializované vizualizační aplikace.
2.1.2
Výukové kurzy
Přestože je podpora výukových kurzů běžnou součástí LMS systému, jedná se převážně
o prezentování výukových materiálů a následné ověření získaných znalostí testem, případně
vypracovanou úlohou, která je reprezentována příslušným dokumentem, který je odevzdán
uploadováním do systému LMS. V systému SyRoTek je hlavním mechanismem ověření
získaných zkušeností realizace uživatelské aplikace, která dokáže řídit robot (roboty) v reálném prostředí s požadovaným chováním. Vyhodnocení chování robotu je dokumentováno
příslušným pohybem robotu/ů a vytvořením požadovaného výstupu (např. mapa prostředí
v úloze mapování), Tutor, kterému je příslušný uživatel přiřazen, využívá podpůrných prostředků systému SyRoTek pro snadnější a především jednoznačnější evaluaci úlohy. V nejjednodušším případě si lze situaci řešení úlohy představit tak, že si uživatel přečte zadání
požadované úlohy na webových stránkách a následně samostatně řeší úlohu. V okamžiku,
kdy je přesvědčen o správnosti řešení, odevzdává úlohu učiteli. Tento typický scénář systém
SyRoTek rozšiřuje v následujících oblastech:
1. Uživatel využívá systému pro získání zpětné vazby o správném postupu svého řešení
úlohy.
2. Uživatel může využít nezávislého ověření, zda úlohu skutečně vyřešil správně, respektive dostatečně.
První bod rozšíření je dosažen dílčími pod-úlohami, které vedou k realizaci výsledné
uživatelské aplikace pro řešení konkrétní úlohy. Své řešení pod-úlohy může uživatel ověřit vůči referenčnímu řešením konkrétního problému. Nezbytnou uživatelskou podporou je
26/217
SyRoTek - V003.1
databáze obvyklých dotazů, ve které by měl uživatel nalézt odpovědi na typické problémy.
Tím, že se uživatel sám aktivně snaží nalézt odpověď na svůj problém, získává cenné zkušenosti při vyhledávání relevantních informací. Pokud se uživateli nepodaří nalézt odpověď,
vždy může využít přímého dotazu na tutora nebo správce systému.
Druhá oblast rozšíření souvisí především s automatickou evaluací úlohy a je závislá na
realizaci dílčích softwarových komponent především na řídicím počítači. Již v současné
počáteční fázi řešení projektu však nelze očekávat implementaci plné automatické evaluace
pro všechny úlohy. V některých případech je proto postačující předzpracování výstupu
uživatelské aplikace do vhodné podoby pro objektivní zhodnocení správnosti řešení tutorem
Z hlediska vlastního řešení úlohy formou realizace uživatelské aplikace je vhodné, aby
grafická prezentace související webových stránek respektovala fakt, že webový prohlížeč
není hlavní aplikací se kterou uživatel pracuje. S ohledem na rozlišení pracovního prostředí uživatelské stanice je vhodné, aby uživatel mohl nahlížet do příslušné dokumentace
a zároveň neztratil kontakt s vlastním řešení v podobě zdrojového kódu své aplikace.
2.2
Demonstrační rozhraní
Demonstrační rozhraní souvisí s vizualizaci, viz 2.1.1. Liší se však tím, že kromě samotného zobrazování dění na ploše arény poskytuje rozhraní pro ovládání robotu. Ovládání
robotu je možné realizovat jeho přímým řízením. Této funkcionality lze však dosáhnout
realizací uživatelské aplikace, která navíc může poskytnou vyšší komfort ovládání než jednoduchá webová aplikace. Navíc toto rozhraní je, podobně jako jednoduchá vizualizace,
především motivačního charakteru, proto je vhodné teleoperovaný režim abstrahovat na
povelování robotu komplexnějšími příkazy typu jízda do bod A, návrat do výchozí pozice.
Uživatel prostřednictvím webového prohlížeče připraví krátkou posloupnost těchto příkazů,
kterou následně odešle serveru. Příslušný robot začne realizovat jednotlivé kroky a uživatel
bude moci sledovat jak plní zadané příkazy. Výhoda tohoto přístupu je v relativně jednoduchém řízení přístupu k robotu, neboť pokud robot plní zadaný plán, jiný uživatel jej
nemůže povelovat. Chtějí-li povelovat robot dva a více uživatelů, může jednotlivý uživatel
povelovat robot pouze jedenkrát během definovaného časového intervalu.
Alternativním komplexnějším demonstračním rozhraním je realizace řídicí aplikace,
která realizuje úlohu pursuit-evader, tj. robot se snaží uniknout pronásledovatelům. V této
demonstrační úloze se navíc mohou také pohybovat překážky. V autonomním režimu jsou
roboty ovládány řídicí aplikací. Při přístupu uživatele k demonstračnímu rozhraní a jeho
interakci s robotem, například přemístěním myší uchopeného fiktivního robotu, který je
vždy na aktuální pozici příslušného vizualizovaného robotu, je řízení robotu přepnuto do
manuálního režimu, ve kterém jej poveluje příslušný uživatel. Při nečinnosti uživatele po
definovaný interval robot přechází do autonomního režimu. Uživatelé mohou ovládat více
robotů, sdílení přístupu je přitom realizováno podobným mechanismem jako v případě
demonstrace činnosti vytvářením plánu pro robot.
27/217
SyRoTek - V003.1
Kapitola 3
Úlohy a návody
Úlohy a návody reprezentují hlavní studijní materiály, kterou jsou zdroji informací pro
uživatele systému SyRoTek. Rámcová témata úloh jsou náplní samostatné zprávy V003.2 Rámcová definice úloh, proto jsou v této kapitole uvedeny pouze informace, které vymezují
souvislosti dílčích úloh s ostatními částmi systému SyRoTek.
V systému SyRoTek souvisí úlohy, které řeší studenti v rámci výukového kurzu/ů mobilní robotiky, s reálnými roboty a jejich interakcí ve vymezeném prostředí. Problematiku
interakce studenta s reálným hardware systémy LMS nepokrývají, a to nejen z důvodu
velmi těsné vazby na příslušnou realizaci hardware, ale také proto, že to není jejich hlavním
cílem. Souvislosti úloh s jejich vlastním řešením v rámci dílčích modulů systému SyRoTek
jsou uvedeny v následujícím oddíle 3.1.
Ve zprávě [1] byla v oddíle 2.1.5 diskutována problematika přístupu ke studijním materiálům (editace a publikování). Základní přístup k těmto materiálům je realizován prostřednictvím webového rozhraní použitého LMS. V rámci tohoto rozhraní je typicky poskytována i podpora pro tvorbu příslušných materiálů, která je však většinou orientovaná
na tvorbu HTML, případně XML dokumentů konkrétním tutorem. Důležitým aspektem
těchto rozhraní je jejich orientace na technicky méně zkušené uživatele, neboť systémy LMS
jsou vytvářeny jako obecné nástroje pro podporu vzdáleného vzdělávání napříč spektrem
studijních oborů. Naproti tomu realizátoři a učitelé systému SyRoTek, který je zaměřen
na podporu výuky mobilní robotiky, jsou technicky založení lidé, kterým nemusejí vyhovovat nástroje určené pro netechnicky zaměřenou skupinu uživatelů. Této problematice je
věnován oddíl 3.2.
3.1
Úlohy
V rámci výukových kurzů systému SyRoTek budou uživatelé (studenti) řešit dva základní typy úloh. Prvním typem úloh jsou úlohy, které jsou plně v režii LMS a při jejich
řešení není nutná uživatelská interakce s řídicím počítačem systému SyRoTek. Tyto úlohy
28/217
KAPITOLA 3. ÚLOHY A NÁVODY
SyRoTek - V003.1
nemají zásadní vazby na ostatní části systému SyRoTek, proto nejsou v této zprávě diskutovány.
Druhým typem jsou úlohy, které tvoří zadání pro realizaci konkrétní uživatelské aplikace, která řídí mobilní robot. Systém vzdáleného vzdělávání však kromě prostého zadání
úlohy vyžaduje specifikaci podpůrných zdrojů informací spolu se specifikací vlastní realizace úlohy a popisem způsobu odevzdání úlohy. Specifikací realizace se rozumí vymezení,
z jakých základních komponent je uživatelská aplikace složena, resp. které komponenty
může využívat. Úlohy lze kategorizovat podle několika kriterií. Z hlediska návaznosti, resp.
požadavků na ostatní části systému SyRoTek jsou zajímavá dělení podle:
• náročnosti na realizaci implementace,
• typu prostředí, ve kterém se robot pohybuje,
• charakteru prostředí (konfigurace plochy arény),
• konfigurace robotu (požadavky na senzorické vybavení),
• výpočetní náročnosti úlohy,
• požadavků na rychlost řídicí smyčky (akceptovatelné dopravní zpoždění),
• počtu robotů,
• mechanismu (podmínkách) odevzdání úlohy.
Jednotlivé kategorizace jsou podrobněji diskutovány v následujících odstavcích.
Náročnost realizace úlohy
Při řešení konkrétní úlohy může být kladen důraz na základní myšlenku principu řízení
(chování) robotu nebo celkovou komplexnost systému řízení robotu. V prvním případě je
vhodné řešení úlohy podpořit nezbytnými moduly pohybu robotu, aby se mohl uživatel
plně soustředit na pochopení a ověření základního principu. Příkladem může být základní
seznámení s charakterem dat konkrétního senzoru při pohybu robotu v prostředí. Nezbytnou součástí řešení takové úlohy je vyčítání dat, jejich zobrazování a řízení pohybu robotu.
V závislosti na zkušenosti uživatele může tyto dílčí moduly realizovat sám, měl by však
mít možnost využít již ověřené realizace dílčích modulů. Naopak v případě řešení úlohy,
která je zaměřena na komplexnost architektury řízení robotu, není využívání jiných modulů
uživateli dovoleno.
29/217
3.1. ÚLOHY
SyRoTek - V003.1
Typ prostředí
Typem prostředí se rozumí jeho časová stálost. Základní rozdělení prostředí podle typu
je na statické prostředí a dynamické prostředí. Tabulka 3.1 obsahuje podrobné dělení v návaznosti na možnosti a potřebné funkcionality systému SyRoTek. Souvislosti se týkají především vlastností arény, které jsou uvedeny v kapitole 8 a realizace vytvoření dynamického
prostředí pohybem překážek a robotů.
Typ
1.
Název
Statické
2.
Dynamické prostředí s pohyblivými překážkami
3.
Dynamické prostředí s pohybujícími se objekty
4.
Dynamické prostředí s pohyblivými překážkami a pohybujícími se objekty
Statické prostředí s více roboty
5.
6.
7.
8.
Dynamické prostředí s více roboty a s pohyblivými překážkami
Dynamické prostředí s více roboty a s pohybujícími se překážkami
Dynamické prostředí s více roboty, pohyblivými překážkami a
pohybujícími se objekty.
Popis
Prostředí, ve kterém jsou pouze statické
překážky. V prostředí se pohybuje pouze
jediný robot, který je řízen uživatelskou
aplikací.
V prostředí dochází k modifikaci překážek, k jejich vysouvání resp. zasouvání.
Dále se v prostředí pohybuje jediný robot, který je řízen uživatelskou aplikací.
V prostředí jsou rozmístěny statické překážky. V prostředí se pohybuje jeden
nebo více robotů, které jsou řízeny systémovou aplikací, dále se v prostředí pohybuje jediný robot řízený uživatelskou
aplikací.
Kombinace 2. a 3. prostředí.
V Prostředí jsou umístěny statické překážky, v prostředí se pohybuje několik robotů, které jsou řízeny jedinou nebo několika uživatelskými aplikacemi.
Rozšíření 2. typu prostředí o pohyb více
robotů řízených uživatelskými aplikacemi.
Rozšíření 3. typu prostředí, na ploše
arény se pohybují dva typy robotů, roboty řízené systémovou aplikací a roboty
řízené uživatelskou aplikací.
V prostředí dochází ke změně překážek,
roboty jsou řízeny systémovou aplikací
nebo uživatelskou aplikací.
Tabulka 3.1: Typy prostředí v systému SyRoTek.
30/217
SyRoTek - V003.1
Hlavní rozdíl mezi roboty řízenými systémovou nebo uživatelskou aplikací je především
v garanci chování robotu. V případě řízení robotu systémovou aplikací je chování robotu
definováno a je součástí příslušné úlohy. Je-li však robot řízen uživatelskou aplikací, nelze
chování robotu garantovat, neboť je závislé na konkrétní implementaci řídicího algoritmu.
Explicitní rozdělení překážek a pohyblivých objektů (překážek) uvedené v tabulce 3.1
je zavedeno z důvodu značně rozdílné náročnosti implementace. Zatímco ovládání překážek spočívá v jejich zasunutí resp. vysunutí, ovládání robotu, jako pohyblivé překážky, je
složitější a konkrétní realizace je závislá na více částech systému SyRoTek.
Charakter prostředí
Charakter prostředí souvisí s konkrétní polohou jednotlivých překážek, jak jsou na ploše
rozmístěny. Podle konkrétního rozmístění překážek simuluje plocha arény příslušné prostředí. Z hlediska úloh souvisí význam rozlišení charakteru prostředí zejména s omezujícími
podmínkami, které často vedou na zjednodušení úlohy. Například plánovací algoritmy pro
pravoúhlé prostředí mají menší výpočetní složitost než pro obecné prostředí. V souvislosti
s realizací překážek, které mohou být dálkově ovládané nebo manuálně umístěné, je charakter prostředí důležitý zejména pro plánování manuálního přemístění překážek. Při realizaci
konkrétního studijního kurzu je nutné tento fakt zohlednit a sestavit úlohy v rámci kurzu
tak, aby se nemusel často měnit charakter prostředí. Základní charaktery prostředí jsou
uvedeny v tabulce 3.2.
Název
Volná plocha
Volný prostor s překážkami
Koridory
Kancelářské prostředí
Bludiště
Popis
Prostředí, ve kterém nejsou překážky, pouze obvodové mantinely vymezující operační prostor robotu.
Prostředí je tvořeno převážně z volného prostoru, ve kterém
jsou umístěny relativně malé (vzhledem k rozměrům volné
plochy) překážky.
Prostředí, které se převážně skládá z dlouhých souvislých
oblastí volného prostoru (koridorů).
Prostředí složené z „chodeb” a „místností”.
Prostředí s řadou slepých „uliček”.
Tabulka 3.2: Základní charaktery prostředí reprezentovatelné na ploše arény systému SyRoTek,
Konfigurace robotu
Rozdělení typů úloh s ohledem na konfiguraci robotu souvisí (podobně jako charakter
prostředí) s aktuálním stavem robotu, tj. instalovanou senzorickou výbavou robotu. Nedílnou součástí každého robotu je takzvaná základní senzorická výbava, kterou tvoří senzory
31/217
3.1. ÚLOHY
SyRoTek - V003.1
umístěné v šasi robotu, viz kapitola ??. Rozšíření senzorické základny robotu je možné
prostřednictvím výměnného senzorického modulu [2]. V závislosti na nezbytných senzorech potřebných pro realizaci úlohy je možné úlohy rozdělit podle konfigurace senzorické
výbavy robotu. Přehled možných (plánovaných) konfigurací robotu je uveden v tabulce 3.3.
Název
Základní senzory
Rozšiřující modul - základní
Rozšiřující modul - kamera
Rozšířující modul - laserový dálkoměr
Rozšířující modul - 3D
kamera
Externí kamera
Popis
Základní senzory jsou tvořeny množinou proximitních senzorů, inerciálních senzorů a senzorů odometrie.
V základní výbavě robotu je rozšířující modul s infračervenými dálkoměry a sonary.
Senzor kamery poskytující barevný obraz scény před robotem, případně výsledek jeho zpracování deskou inteligentní
kamery.
Senzor poskytující data o objektech vyskytujících se převážně před robotem v definované výšce a definované maximální vzdálenosti.
Kamera, která kromě barevného obrazu poskytuje také
hloubkovou informaci.
Barevný obraz kamery umístěné mimo robot na konstrukci
arény podobně jako například lokalizační nebo vizualizační
kamera.
Tabulka 3.3: Základní a rozšiřující konfigurace senzorické výbavy robotu.
Vzhledem k hardwarové konstrukci robotu může být robot vždy vybaven pouze jediným
rozšiřujícím modulem.
Součástí základní senzorické výbavy robotu jsou také informace o absolutní poloze robotu/ů z globálního lokalizačního systému podobně jako informace o poloze překážek na ploše
arény. Tyto informace jsou vždy dostupné, bez ohledu na aktuální senzorickou výbavu robotu. Informaci z těchto senzorů lze uplatnit při realizaci simulace některých senzorů, které
nemusejí být připojené k robotu. Těchto senzorů může být využito při úlohách, které pracují s binární senzorickou informaci, například robot „vidí” definovaný předmět (ano/ne).
Z tohoto pohledu lze rozdělit úlohy podle požadavků na fyzickou přítomnost senzorů na
robotu. Senzory pro řešení konkrétní úlohy mohou být:
• reálné - fyzicky přítomné na robotu nebo v systému SyRoTek,
• virtuální senzory, jejichž výstup je realizován systémovou aplikací využívající některých skutečných senzorů a modelu senzorů.
Konkrétní zadání úlohy může být zaměřeno na použití konkrétního senzoru. V takovém
případě mohou být jiné senzory na robotu přítomné, avšak z pedagogických důvodů je
32/217
SyRoTek - V003.1
vhodné při řešení této úlohy přístup k těmto senzorům uživateli zakázat. Podle tohoto
kriteria lze úlohy dělit podle
• nezbytných senzorů, které musí být uživateli přístupné a
• dostupných senzorů, které mohou být uživateli přístupné,
ostatní senzory jsou pro uživatele nedostupné.
Výpočetní náročnost a rychlost řídicí smyčky
Uživatelská aplikace, kterou uživatel implementuje jako součást řešení některé úlohy,
může být spuštěna na
• palubním počítači,
• řídicím počítači,
• uživatelské stanici.
Z hlediska výpočetní náročnosti aplikace je nutné zohlednit omezený výpočetní výkon
dostupný na palubním počítači, který je řádově menší než výkon řídicího počítače. Podobně
rychlost příslušné řídicí smyčky je omezená komunikační rychlostí. Aplikace spuštěná na
palubním počítači jistě dostane senzorické informace dříve než aplikace spuštěná na řídicím
počítači nebo uživatelské stanci připojené k systému SyRoTek například telefonní linkou.
Podobně žádaný akční zásah, tj. změna rychlosti motorů, je přenesen do řídicí jednotky
s menším nebo větším dopravním zpožděním. Zadání úlohy může specifikovat, kde může být
úloha spuštěna, případně kde musí být spuštěna. Například při předpisu spuštění úlohy na
palubním počítači nemůže student využít knihoven, které jsou dostupné pouze při spuštění
aplikace na řídicím počítači.
Počet robotů
Počet robotů, které jsou použity při řešení úlohy, ovlivňuje mechanismus nastavování
přístupu uživatele/ů k jednotlivým robotů a možnost jejich vzájemné komunikace. Více
robotů může být ovládáno jedinou uživatelskou aplikací, případně více aplikacemi téhož
uživatele.
Alternativou je spolupráce více uživatelů na řešení úlohy, kdy například každý uživatel ovládá jediného robota. Při této konfiguraci může být povolena explicitní komunikace
mezi jednotlivými uživatelskými aplikacemi nebo naopak uživatelské aplikace spolu nesmějí
explicitně komunikovat.
33/217
3.1. ÚLOHY
SyRoTek - V003.1
Mechanismus odevzdání úlohy
Mechanismus odevzdání úlohy je velmi úzce svázán s problematikou takzvaného procesu
vytvoření důvěryhodných dat a evaluace úlohy, která je diskutována v kapitole 5. Pro
automatickou resp. semi-automatickou evaluaci úlohy je nutné, aby součástí zadání byla
specifikace výstupu úlohy. Možné způsoby odevzdání úlohy jsou uvedeny v tabulce ??.
Odevzdání
Bez explicitního odevzdání
Vizuálním záznamem
Výstupním souborem
Sledováním
robotu
pohybu
Popis
Uživatel může úlohu realizovat, úloha je pro uživatele vyřešená v okamžiku jeho osobní satisfakce s chováním robotu.
Chování uživatelské aplikace (resp. robotu) je zaznamenáno
vizualizačním systémem SyRoTek. Záznam poté zhodnotí
příslušný tutor uživatele.
Řešením úlohy je vytvoření souboru/ů definovaného formátu.
Během spuštěné uživatelské aplikace a pohybu ovládaného
robotu je monitorován jeho pohyb, na základě kterého je
vyhodnoceno správné vyřešení úlohy. Příkladem může být
úspěšné nalezení cesty z bludiště, kdy robot dojede na definovanou pozici.
Tabulka 3.4: Způsoby odevzdání úlohy.
3.1.1
Podpůrný software
V předchozích odstavcích byly uvedeny některé softwarové komponenty, které přímo
souvisí s úlohami. Tyto komponenty jsou součástí zadání příslušné úlohy a při jejím řešení
úlohy je nutné jejich spuštění na řídicím případně palubním počítači. Jednotlivé konkrétní
implementace komponent tvoří množinu knihovních funkcí, které mohou být opakovaně
součástí různých úloh. Knihovny funkcí jsou:
• algoritmy řízení dynamických překážek (robotů),
• realizace virtuálních senzorů,
• algoritmy vyhodnocení výstupních souborů uživatelské aplikace,
• algoritmy on-line sledování pohybu robotu a vyhodnocování jeho akcí.
34/217
3.1.2
SyRoTek - V003.1
Specifikace zadání úlohy
Z předcházejících odstavců vyplývají požadavky na obsah zadání úlohy. Dílčí specifikace
požadavků na obsah zadání jsou uvedeny v tabulce 3.5.
Název
Robot
Software
Prostředí
Výstup
Komunikace
Spouštěcí prostředí
Odevzdání
Popis
Přesná konfigurace senzorického vybavení robotu, které
bude mít uživatel při běhu své aplikace k dispozici.
Množina použitelných modulů při realizaci aplikace.
Součástí zadaní úlohy je konfigurace prostředí arény, které
může být doplněno o algoritmy ovládání překážek v případě
dynamického prostředí.
Definice výstupu uživatelské aplikace, specifikace formátu
souboru/ů.
Definice možností komunikace uživatelské aplikace s jinými
uživatelskými aplikacemi.
Definice, kde bude úloha spouštěna, palubní nebo řídicí počítač, případně uživatelská stanice.
Definice mechanismu odevzdání úlohy.
Tabulka 3.5: Dílčí specifikace realizace úlohy.
3.2
Návody
Tento odstavec je věnován problematice tvorby podpůrných studijních materiálů především mimo systém LMS, respektive LCMS. Motivací této úvahy je předpoklad, že technicky
orientovaní realizátoři systému SyRoTek a případní tutoři upřednostní alternativní přístup
k vytváření studijních podkladů. Hlavními sledovanými cíly jsou:
• možnost simultánního přístupu a paralelní tvorba příslušných dokumentů (materiálů),
• komfortní přístup pro vlastní editaci dokumentů,
• vytváření kompaktních dokumentů pro off-line prezentaci, bez nutnosti Internetového
přístupu.
Dosažení prvního cíle je realizovatelné využitím systému pro verzování souborů. Efektivní využívání tohoto nástroje však vyžaduje uložení souborů dokumentu v textovém
formátu. Tato podmínka souvisí především s problematikou slučování dvou různých verzí
dokumentu, resp. řešení konfliktních situací, které jsou typicky důsledkem současné modifikace dokumentu dvěma nebo více autory.
35/217
3.2. NÁVODY
SyRoTek - V003.1
Komfortní přístup zahrnuje dva sledované aspekty. Prvním z nich je možnost editace
dokumentů bez přístupu k webovému rozhraní LMS. Druhým aspektem je samotná editace
souborů dokumentu v oblíbeném editoru, který příslušný autor běžně používá a je schopen
využít jeho pokročilých funkcí a tím je výrazným způsobem zvýšit svoji produktivitu.
Výsledná podoba dokumentu by měla být prezentovatelná přímo v rámci webového
rozhraní. Dále je vhodné podpořit možnost prohlížení dokumentů i mimo LMS systém,
případně jej vytisknout. V souvislosti s výsledným rozvržením stránek dokumentu, které
mohou kromě obrázků obsahovat také výpisy částí programů nebo matematické formule, je
vhodné, aby tato verze dokumentu byla pokud možno nezávislá na zobrazovacím zařízení,
které bude použito pro prezentaci dokumentu příslušnému čtenáři.
Vhodnými nástroji pro tvorbu dokumentů, které vyhovují sledovaným cílům jsou TEX,
resp. LATEX nebo technologie založené na XML jako je například DocBook [8]. V obou
případech jsou výchozími zdrojovými soubory dokumentů čitelné textové soubory. Oba
přístupy také umožňují vytvářet výstupy formátu vhodného pro přímou webovou prezentaci
(HTML) a jednoznačné zobrazování (DVI, PDF).
Hlavní rozdíl mezi XML a TEX dokumenty je především v přímě čitelnosti zdrojových
souborů. Přestože oba formáty jsou textové, XML dokumenty obsahují větší množství
formátovacích značek než TEX dokument. Dalším významný rozdíl mezi těmito formáty
vyplývá z jejich historického vzniku. Jazyk XML byl vytvořen jako popisný jazyk, TEX
je však programovací jazyk pro psaní dokumentů, ve kterém je napsána sada základních
maker plain TEX, resp. LATEX.
TEX vznikal v sedmdesátých letech, a přestože je výsledná sazba dokumentů stále na
velmi vysoké úrovni, používání základních maker plain i pozdějších maker LATEX, je z hlediska současných požadavků na dokumenty v některých případech obtížné. Komplikace
souvisí především s tvorbou interaktivních dokumentů PDF a grafickými možnosti zobrazovacích zařízení (včetně tiskáren), které již nevyžadují tak restriktivní rozvrhování obrázků
jako v minulosti. Tehdy byly hlavní motivací zavedení pravidel umísťování obrázků především omezené schopnosti zobrazovacích zařízení. Moderním rozšířením programovacího
jazyku TEX, které je orientované na současné trendy vzhledu dokumentu je sada maker a
skriptů CONTEXt [9], která významným způsobem zjednodušuje tvorbu dokumentu.
V současném stavu řešení projektu SyRoTek není nutné definitivně zvolit systém pro
tvorbu studijních materiálů. Pravděpodobně však bude zvolena kombinace XML souborů
a některého rozšíření jazyku TEX pro vytváření PDF souborů. Vhodnými kandidáty pro
použití tohoto hybridního přístupu je definice úloh, kterou je vhodné realizovat v XML
formátu, neboť součástí zadání úlohy jsou důležité informace, které je možné v XML dobře
definovaným způsobem načíst příslušnými systémovými aplikacemi ostatních částí systému
SyRoTek.Pro vytvoření kompletního dokumentu sbírky úloh lze využít jazyka XSLT pro
zpracování XML dokumentů a vytvořit tak vhodný zdrojový soubor pro přímé zpracování
systémem TEX.
36/217
KAPITOLA 4. DATABÁZE UŽIVATELŮ
SyRoTek - V003.1
Kapitola 4
Databáze uživatelů
Databáze uživatelů je tvořena množinou údajů pro každého uživatele systému SyRoTek.
Do této množiny patří tyto základní údaje (viz [1]):
• uživatelské údaje,
• přihlašovací údaje,
• registrovaná sezení,
• aktuální sezení.
Součástí informací o uživateli jsou také údaje o jeho práci se systémem, které mají
přímou souvislost s ostatními moduly systému SyRoTek, které uživatel využívá.
Z tohoto pohledu lze na databázi uživatelů pohlížet jako na soubor všech dat relevantních příslušnému uživateli, ačkoliv je jisté, že některá data nemají charakter klasické
databáze, resp. nejsou uložena identickými softwarovými nástroji. Příkladem rozdílných
dat jsou uživatelské kódy, diskusní příspěvky a osobní údaje jako je jméno a příjmení.
Konkrétní typ dat je vhodné ukládat příslušnou softwarovou technologií.
V komplexním výukovém systému SyRoTek vznikají uživatelská data v různých modulech, které využívají rozličné softwarové prostředky. Snaha o unifikaci dat, resp. o jednotné
uložiště všech dat, je z tohoto pohledu nevhodná, neboť mnohdy není technicky možné
využít konkrétní softwarový produkt v kombinaci se specifickým datovým uložištěm. Na
druhou stranu je však vhodné minimalizovat redundanci dat, zvláště těch, které je nutné
synchronizovat. Typickým příkladem jsou přihlašovací údaje, které mohou být uloženy v samostatných databázích pro webového rozhraní, vzdálený systém přihlašování (telnet,ssh)
nebo správce verzí zdrojových souborů (CVS, SVN).
37/217
SyRoTek - V003.1
Z pohledu typu dat uložených pro každého uživatele lze rozlišit následující kategorie:
• osobní údaje,
• autentizační údaje,
• autorizační údaje,
• konfigurační údaje (profil),
• rezervační údaje,
• datové soubory,
• zdrojové soubory,
• pracovní soubory,
• logy,
• e-mailové zprávy, záznamy komunikace,
• uživatelská data z vyplněných formulářů.
Vzhledem k různému způsobu uložení konkrétních dat je nejdůležitější funkcionalitou
objektu databáze uživatelů poskytování údajů o uživateli. Zpřístupnění konkrétních dat
o uživateli příslušnému modulu systému SyRoTek však není jedinou funkcionalitou. Způsob
získávání informací o uživateli, respektive údajů o jeho práci se systém SyRoTek je prvním
krokem pro vytvoření dat na jejichž základě lze vyhodnocovat používání systému SyRoTek.
Tato data umožňují provedení velmi důležité analýzy, které části jsou nejvíce využívány, a
které nejméně.
Vlastní realizace databáze uživatelů je především o volbě vhodné softwarové implementace, která umožní napojení na další softwarové části realizující příslušné modulové funkcionality systému SyRoTek. Tabulka 4.1 obsahuje popis uživatelských dat a jejich primární
umístění z hlediska přístupu.
Databáze v tabulce 4.1 reprezentuje datový soubor s příslušným vyhledávacím rozhraním (softwarovým rozhraním).
Uživatelské soubory jsou přirozeně umístěny v souborovém systému a jsou přístupné
základními nástroji operačního systému. Každý uživatel má v systému SyRoTek vyhrazený
prostor pro ukládání uživatelských dat. Tento datový prostor je však distribuovaný, neboť
uživatel může pracovat na řídicím počítači i na konkrétním palubním počítači robotu.
Záznamy o činnosti jednotlivých modulů obsahují informace o činnosti uživatele v rámci
modulu. Tyto záznamy jsou proto přirozeným zdrojem informace o aktivitách uživatele.
Tyto údaje příslušejí vždy konkrétnímu modulu.
38/217
Kategorie dat
autentizační
autorizační
profil
rezervace
datové soubory
pracovní soubory
logy
mailové zprávy
uživatelská data (formuláře)
SyRoTek - V003.1
Základní umístění
databáze
databáze
databáze
databáze
uživatelské soubory
uživatelské soubory
dílčí logy jednotlivých modulů
databáze
databáze
Tabulka 4.1: Uživatelská data a jejich základní umístění.
Z pohledu duplicity dat jsou nejdůležitější autentizační a autorizační údaje, které je
vhodné uchovávat v databázi s LDAP [10] podporou. Největší předností LDAP je, že
podpora tohoto protokolu je implementována ve většině důležitých programů.
V případě pracovních souboru je přirozené, že bude docházet k duplicitě dat, neboť tyto
soubory jsou vytvářeny na řídicím nebo palubním počítači, případně uživatelské stanici.
V řadě případů duplicita dat může kompenzovat pomalé komunikační projení příslušných
modulů, neboť současné pevné disky jsou stále mnohem rychlejší než běžně používané
přípojení k síti Internet. Vedlejším efektem duplicity dat, je také nepřímé zálohování, které
je však nutné chápat pouze jako doplňkové.
V následujících oddílech jsou popsány jednotlivé kategorie dat z pohledu dílčích modulů
systému SyRoTek. Oddíl 4.9 je věnován problematice zálohování.
4.1
Autentizace uživatele
V tabulce 4.2 jsou uvedeny moduly, které jsou přístupné uživateli a vyžadují autentizaci.
Modul
webové rozhraní
řídicí počítač
robot
Popis
Nepřihlášenému uživateli nejsou přístupné všechny
stránky.
Uživatelské programy jsou spouštěny s právy konkrétního uživatele.
Uživatelské programy jsou spouštěny na palubním počítači s právy konkrétního uživatele.
Tabulka 4.2: Základní moduly vyžadující autentizaci uživatele.
Na tomto místě je třeba zdůraznit, že autentizace přístupu k řídicímu počítači a robotu
39/217
4.1. AUTENTIZACE UŽIVATELE
SyRoTek - V003.1
je nutná pouze v případě, bude-li uživateli umožněno vzdálené přihlašování k řídicímu počítači, resp. palubnímu počítači. V případě přístupu pouze prostřednictvím rozhraní webových stránek jsou případné akce spuštěny programem obsluhující příslušnou uživatelovu
žádost v rámci webového serveru.
Moderní operační systémy (zejména unixového typu) jsou na více-programové a víceuživatelské prostředí velmi dobře připravené1 . Komplexnost souboru různých prostředí
a kombinování několika softwarových komponent v souvislosti s realizací autentizace a
autorizace může na první pohled vypadat zbytečně složitě v porovnání s prostým spuštěním
programu, který řeší příslušnou funkcionalitu pro libovolného uživatele a řeší případná
omezení služby samostatně v rámci své vlastní činnosti. V systému SyRoTek však bude
používáno několik specializovaných programů, které jsou specifické pro tento systém a
bude nutné je vytvořit. Zvyšování složitosti těchto programů o vlastní řešení autentizace
(v rámci každé dílčí aplikace), je nejen redundantní, ale také může zanést do programu
chyby. To je hlavním důvodem, proč je vhodnější přenechat autentizaci tomu určeným
softwarovým komponentám a využívat služeb operačního systému, ačkoliv takové řešení
znamená zvýšené nároky na konfiguraci systému.
Vedle modulů uvedených v tabulce 4.2 jsou plánovány pro uživatele systému SyRoTek
služby uvedené v tabulce 4.3. Ve sloupci označení je uvedena zkratka příslušné služby, která
je ve většině případů odvozena od použité technologie, programu nebo protokolu.
Služba
Správce verzí zdrojových souborů
Vzdálené přihlášení k systému
Grafické přihlášení k systému
Přístup k souborům
Přístup k vizualizaci
Přístup k senzorům a robotu
Datová výměna při vývoji aplikace
Označení
SVN
SSH
XDMCP
FTP
AV
ROBOT
DEVEL
Tabulka 4.3: Uživatelské služby v systému SyRoTek.
Uživatel je ve všech službách identifikován jednotným uživatelským jménem a heslem.
Uživatelské jméno je v rámci systému SyRoTek unikátní pro každého uživatele. Z hlediska
zabezpečeného přenosu uživatelského hesla z klientské stanice k autentizačnímu serveru je
vhodné používat některý ze zabezpečených přenosových protokolů. V tabulce 4.4 jsou uvedeny služby a zabezpečení přenosu autentizačních dat, služba WWW reprezentuje webové
rozhraní systému SyRoTek.
1
Nezřídka tyto služby zahrnují již od své první verzi, neboť byly navrženy tak, aby výpočetní prostředky
sdílelo několik uživatelů, poskytují tak záruku v podobě několik desetiletí ověřeného konceptu.
40/217
Služba
WWW
SVN
SSH
XDMCP
FTP
AV
ROBOT
DEVEL
SyRoTek - V003.1
Zabezpečení
Volný přístup na stránky protokolem HTTP, přihlášení uživatele je realizováno zabezpečeným protokolem HTTPS, využívající SSL [11].
Přístup k repozitáři zprostředkovává webový server, protokolem HTTPS
a WebDAV/DeltaV [12].
Vzdálené přihlašování je realizováno programem ssh, RFC 4250 – RFC
4255.
Grafické přihlašování je realizováno protokolem XDMCP. Tato služba je
v projektu SyRoTek přístupná pouze z vybraných, důvěryhodných, sítí.
Například ze stejného prostoru (podsítě), ke které je připojen řídicí/uživatelský počítač sítě, není tedy přímo přístupná z adresového prostoru
„veřejného” Internetu.
Autentizace je realizován protokolem TLS/SSL.
Přístup specializované aplikace pro zobrazování audio/video souborů,
on-line pozorování prostředí, způsob zabezpečení závisí na použité technologii (např. prostřednictvím webového rozhraní).
Přístup ke čteným datům ze senzorů a ovládání robotu, z hlediska minimalizace transportního zpoždění bude zabezpečení pravděpodobně realizováno pouze spojovanou dvoubodovou komunikační cestou, explicitně
vytvořenou až po provedení autentizace a příslušné autorizace přes některou jinou službu (SSH, DEVEL nebo WWW).
Datová výměna pro podporu vzdáleného vývoje aplikace na uživatelské stanici a spouštění aplikace na řídicím/palubním počítači vyžaduje
samostatný komunikační kanál. Zabezpečení je závislé na použitých softwarových komponentách aplikace běžící na uživatelské stanici. Jako minimální variantu lze použít technologii SSH tunelu, viz například [13].
Tabulka 4.4: Zabezpečení uživatelských služeb systému SyRoTek.
Způsob autentizace uživatele do služeb AV a DEVEL je závislý na konkrétní použité
technologie realizace těchto služeb. Z hlediska uživatelské databáze je podstatné, že tyto
služby přistupují k identitě uživatele a také k jeho datům. Koncepce vizualizace je popsána
v části 11.7, mechanismy vývoje aplikace na uživatelské stanici a její přenos na řídicí počítač
v kapitole 7.
4.2
Autorizace uživatele
Autorizace uživatele, po té co je autentizován, zpřístupňuje konkrétní služby příslušného
modulu. Uživatel systému SyRoTek má v rámci interakce s funkcionalitami modulu vždy
některou konkrétní roli, která ho opravňuje využívat pouze některé služby. Tyto role jsou
41/217
4.2. AUTORIZACE UŽIVATELE
SyRoTek - V003.1
závislé na konkrétní implementaci příslušného modulu, principiálně však lze vždy nalézt
základní rozdělení na běžného uživatele a privilegovaného uživatele. V rámci LMS systému,
existuje více rolí, které souvisí s tvorbou a vedením příslušného kurzu.
V systému SyRoTek jsou v zásadě dva hlavní prostory, ve kterém jsou definované uživatelské role. Prvním prostorem je webové rozhraní, které je realizováno LMS systémem.
Druhým prostorem je řídicí (resp. palubní) počítač, na kterém jsou umístěny a spouštěny
uživatelské programy. Samotný výpočetní systém (operační systém), obsahuje celou řadu
uživatelů a skupin uživatelů, které souvisí s během a bezpečností jednotlivých softwarových
komponent. 2 .
role
admin
teacher
student
mentor
Popis
Administrátor webového rozhraní, resp. příslušného systému
pro správu obsahu.
Učitel, tvůrce kurzu, je zodpovědný za obsah příslušného kurzu.
Běžný uživatel, který pracuje systém využívá.
Zkušený uživatel, který pomáhá příslušným studentům s řešení
úloh a samotnou prací se systémem SyRoTek.
Tabulka 4.5: Uživatelské role v systému SyRoTek při přístupu přes webové rozhraní.
Základní uživatelské role webového rozhraní jsou uvedeny v tabulce 4.5. Tyto role se
uplatňují pouze při přístupu přes webové rozhraní, jsou de-facto spravována použitým
systémem pro podporu vzdáleného vzdělávání (LMS).
Pro jemnější rozlišení uživatelů systému SyRoTek je vhodné zavést dělení podle zkušeností uživatele s prací se systémem SyRoTek, tzv. rank. Toto rozlišení je také vhodné
z hlediska komunikace mezi jednotlivými uživateli systému SyRoTek, například v rámci
diskuzního fóra, je odpověď více zkušeného uživatel pravděpodobně relevantnější. Možné
dělení je uvedené v tabulce 4.6. Samotný způsob získávání zkušeností je řešen v rámci
modulu pro vzdálené vzdělávání. Také příspěvky v diskuzním fóru mohou mít další dělení
rolí, například moderátor nebo učitel. Označení uživatelů z tabulky 4.6 má však vliv na
přístupová práva v rámci práce uživatele s řídicím počítačem.
role
root
Popis
Super uživatel (administrátor) operačního systému, je zodpovědný za chod operačního systému, nastavení kapacit disků, zálohování, instalaci a aktivaci služeb.
2
Například FTP server je zpravidla spuštěn s právy uživatele ftp, a jednotlivá spojení jsou pak obsluhována v rámci prostoru toho uživatele (anonymní přihlášení) nebo konkrétního autentizovaného uživatele,
a přístup k souborů je pak řízen podle nastavených práv jednotlivých souborů a adresářů.
42/217
role
admin
student
robot
syrotek-developer
SyRoTek - V003.1
Popis
Administrátor systému (SyRoTek), je zodpovědný za funkčnost
příslušných služeb. Těchto administrátorů může být více a jejich administrativní pravomoce mohou být disjunktní, například správce ftp serveru, www serveru.
Běžný uživatel, který systém SyRoTek využívá.
Dedikovaný uživatel pro spouštění aplikací souvisejících s ovládáním robotu, a které vyžadují právo přístupu k periferiím a
nejsou udělena uživateli typu student.
Vývojář systému SyRoTek, který zpravidla zodpovídá za programy podporující komunikaci uživatelské (studentské) aplikace
s robotem.
Tabulka 4.7: Hlavní kategorie uživatelů v řídicím počítači.
Tabulka 4.7 obsahuje základní kategorie uživatelů v rámci prostoru řídicího počítače.
Uživatelé z kategorie admin jsou přiřazeni do příslušných skupin, které mají oprávnění pro
administraci konkrétní služby.
Podobně je dělena kategorie student s ohledem na konkrétní rank uživatele. V tabulce 4.8
jsou uvedena práva uživatele s příslušným hodnocením zkušeností. V posledním sloupci je
uvedena podmínka získání příslušného oprávnění.
rank
guest
novice
intermediate
advanced
export
master
Práva
Přístup na veřejné stránky systému SyRoTek, pasivní pozorování
dění na ploše.
Přístup k základním výukovým
kurzům, možnost tele-operování
volného robotu.
Přístup k nahrávání vlastní aplikace do systému SyRoTek.
Přístup k hardware robotu, řízení
robotu vlastní aplikací.
Přístup k hardware robotu, řízení
robotu vlastní aplikací.
Možnost vedení a pomáhání ostatním uživatelům, přednostní přístup pro řešení vlastních výzkumných aktivit.
Podmínka získání
Návštěva stránek SyRoTek.
Potvrzení registrace do systému
SyRoTek.
Prokázání základní dovednosti implementace jednoduchého kódu robotu.
Prokázání funkčního programu
v simulátoru.
Úspěšné absolvování vybraného
kurzu.
Dlouhodobá úspěšná práce se systémem.
43/217
4.3. PROFIL
rank
developer
SyRoTek - V003.1
Práva
Vytváření a ladění kódů pro systém SyRoTek, které mohou využívat ostatní uživatelé. Možnost používání samostatných verzí podpůrných knihoven.
Podmínka získání
Schválení žádosti o aktivní vývoj, která obsahuje popis plánované funkcionality, uživatel musí
být minimálně úrovně expert.
Tabulka 4.8: Základní přístupová práva uživatele student, v závislosti na jeho zkušenostech
rank.
Označení uživatele podle jeho zkušeností může probíhat automaticky na základně splnění daných podmínek. Zpravidla však příslušné ohodnocení, resp. prokázání znalostí vyhodnocuje učitel, který potvrzuje získané zkušenosti.
Uživatelské programy běžící na řídicím počítači slouží k ovládání robotu, to je však
možné pouze tehdy, má-li student příslušný robot rezervovaný. Samotná příslušnost ke
konkrétní skupině uživatele sice opravňuje k ovládání/spouštění konkrétní aplikace, není
však jedinou podmínkou, která musí být splněna, aby mohl ovládat příslušný robot. Přístup ke sdíleným zdrojům, kterými jsou v systému SyRoTek především roboty a systém
vizualizace arény, je nutné řešit dynamickým přidělováním rolí. Ve fázi vytváření detailní
koncepce systému je důležité respektovat, že autorizace uživatele je závislá nejen na jeho
příslušnosti, ale také na systému rezervací. Detailní návrh uživatelských rolí je součástí
specifikace Internetového přístupu, která je naplní dalších cílů řešení projektu.
Uživatel během průchodu určitého kurzu postupně získává znalosti a osvojuje si jednotlivé dovednosti. V některých kurzech může být žádoucí, postupné zpřístupňování jednotlivých materiálů nebo zadání úloh. Toto postupné zpřístupňování je realizováno v příslušném
modulu vzdáleného vzdělávání a samotná informace o aktuálních přístupových možnostech
uživatele má charakter uživatelských dat z formulářů. Vzhledem k množství těchto jednotlivých stavů k každém možném kurzu, které mohou navíc probíhat paralelně, není vhodné
diskriminovat tato data jako autorizační, neboť by to vedlo na značné množství uživatelských sub-rolí, které by byly závislé na daném kontextu (kurzu).
4.3
Profil
Součástí profilu jsou hodnoty příslušných proměnných, které jsou uživatelskou volbou
a vystihují charakter uživatele. Tyto proměnné jsou nastaveny při vytváření uživatele,
během jeho registrace. Je jisté, že ne všichni uživatelé budou chtít tyto hodnoty sami
nastavovat, neboť nemusejí nutně znát jejich význam. Základní nastavení proměnných je
proto přirozeně provedeno jako jistý kompromis, se snahou vyhověti co nejširší uživatelské
základně.
44/217
Označení
guest
novice
intermediate
advanced
expert
master
developer
SyRoTek - V003.1
Popis
Neregistrovaný uživatel, návštěvník systému SyRoTek
a jeho potenciální uživatel.
Registrovaný uživatel
Začínající uživatel.
Pokročilý uživatel.
Zkušený uživatel.
Velmi zkušený uživatel.
Uživatel, který je vývojářem systému SyRoTek.
Tabulka 4.6: Rozlišení uživatelů podle zkušeností.
Uživatelský profil je specifický webovému rozhraní, kde lze nastavit vlastnosti zobrazování a interpretace (rendering) stránek. Při práci uživatele s řídicím počítačem je součástí profilu například nastavení příkazového interpretru, atd. Kromě čistě uživatelských
nastavení jsou také součástí profilu systémová nastavení, respektive omezení. Typickým
příkladem je nastavení maximálního velikosti diskového prostoru, který může uživatel alokovat. V případě spouštění uživatelské aplikace to může být dále omezení na paměť nebo
dostupný strojový čas procesoru.
Tabulka 4.9 shrnuje základní data jednotlivých modulů a uživatelských služeb systému
SyRoTek, která jsou součástí profilu.
Modul/Služba
řídicí počítač (aplikace)
XDMCP
svn
datové soubory
webové rozhraní
vizualizace prostředí
uživatelská stanice
Popis
Nastavení prostředí vzdáleného systému (shell, přístupové
cesty), limity uživatele.
Nastavení vzdálené plochy, okenního manažeru, typicky
je součástí konfiguračních souborů/adresářů v domovském
adresáři uživatele.
Maximální kapacita repositáře.
Maximální počet/velikost datových souborů.
Natavení stylu zobrazování, komunikační jazyk, doplňkové
identifikační znaky (např. avatar, IMS).
Preferovaná kvalita on-line zobrazení plochy arény, pozice
polohovacího mechanismu kamery.
Nastavení komunikace s vývojovým prostředím uživatele a
řídicím počítačem.
Tabulka 4.9: Základní data profilu uživatele jednotlivých modulů/služeb systému SyRoTek.
45/217
4.4. REZERVACE
4.4
SyRoTek - V003.1
Rezervace
Uživatelský přístup k rezervačnímu systému je součástí webového rozhraní, kromě realizace samostatnou aplikací. Systém řešení přístupu k omezeným zdrojům, které v systému
SyRoTek představují roboty a plocha arény, je hlavní činností rezervačního systému. Kromě
časového údaje, kdy bude uživatel chtít se systémem pracovat jsou součástí rezervace také
informace o plánovaném využití robotů, jejich požadovaném vybavení, žádost o rezervování
plochy arény a její konfigurace.
Vlastní rezervační systém je kromě registrování a uchovávání rezervačních informací
doplněn a mechanismus generování událostí. Nejdůležitější událostí je okamžik, před rezervovaným časem, kdy dochází k přípravě systému pro konkrétního uživatele. Tehdy také
dochází k interakci ostatních částí systému SyRoTek s databází o rezervacích, jinak do
databáze rezervací přistupují především moduly webového rozhraní, resp. přístupové aplikace.
V systému rezervací mohou mít uživatelé rezervovaný čas i několik týdnu dopředu. Může
se však stát, že z důvodů nějaké závady nebude rezervovaný robot k dispozici, v takovém
případě je nutné příslušného uživatele upozornit, případně mu nabídnout alternativní termín rezervace. Přirozeně musejí být plánované odstávky systému v souladu s rezervacemi,
přesto mohou nastat výjimečné situace, které budou vyžadovat exkluzivní přístup k systému z administrativních důvodů.
Události, které může rezervační systém generovat jsou shrnuty v tabulce 4.10. Vedle
událostí, které vznikají při přístupu uživatele k systému rezervací, jsou generovány události
související s počátečním a koncovým časovým okamžikem rezervace.
Událost
add
delete
before start
start
before end
end
timeout
Popis
přidání rezervace.
smazání rezervace.
nastává v definovaném časovém předstihu před počátkem rezervovaného času.
nastává při počátku rezervovaného času.
nastává v definovaném časovém předstihu před konce rezervovaného
času.
nastává při konci rezervovaného času.
v případě, že uživatel nevyužil rezervovaného času, po uplynutí definovaného časového intervalu po začátku rezervovaného času.
Tabulka 4.10: Události generované přístupem do rezervačního systému a vytvořenými rezervacemi.
Řada úloh, které uživatel řeší jsou nezávislé na konkrétním robotu. Uživatel však mohl
v rámci předchozího sezení zanechat řešenou úlohou rozpracovanou, včetně příslušné konfigurace na robotu. Případně může uživatelské sezení vyžadovat jinou konfiguraci překážek
46/217
SyRoTek - V003.1
na ploše arény. Z těchto důvodu jsou generovány události před počátkem vlastního rezervovaného času, aby mohlo dojít k přípravě systému pro příslušné uživatelské sezení.
Podobně je před koncem rezervovaného času vhodné uživatele upozornit na blížící se
konec rezervovaného přístupu. Je-li to možné, může být uživateli nabídnuto prodloužení
rezervovaného času nebo naopak může být zahájenou pokud možno korektní ukončování
uživatelského sezení (běžících aplikací) tak, aby nedošlo ke zbytečné ztrátě dat.
Realizace generátoru události, které vznikají na základě již uložených rezervací, lze chápat jako součást uživatelské databáze. Jedná se však o samostatnou komponentu, která
musí být v systému aktivována, respektive dochází k periodickému probouzení komponenty na základě časových okamžiků nebo uživatelského přístupu do databáze rezervací.
Vlastní mechanismy rezervování času v systému SyRoTek mohou být realizovány velmi
jednoduše bez žádného explicitního omezení. Některý uživatel by si tak mohl rezervovat
systém pro sebe na několik týdnu dopředu. Zavedení limitu na rezervovaných čas uživatele
bude v takových případech nevyhnutelné. Možná omezení a mechanismy rezervace mohou
být dále rozšířena o sledování aktuálního využívání systému uživatelem. Konkrétní strategie a omezení na rezervace systému je však vhodné definovat až v okamžiku, kdy budou
známy první konkrétní hodnoty o využívání systému. Podle skutečného využívání systému
je vhodné tuto strategii vhodně modifikovat s cílem co možná největšího využití systému.
V této fázi vývoje systému SyRoTek je postačující, respektování různých strategií rezervací,
při návrh dílčích komponent, které s rezervačním systémem interagují. Konkrétní implementaci vhodné strategie bude provedena v okamžiku znalosti skutečných potřeb uživatelů
systému.
4.5
Datové a pracovní soubory
Datové a pracovní soubory vznikají při běhu uživatelské aplikace na řídicí nebo palubním počítači. Aplikace může být také spuštěna na uživatelské stanici, ty však nejsou pod
přímou kontrolou systému SyRoTek a s ohledem možnou technickou realizaci, není bez
explicitního způsobu označení souboru možné takové soubory zahrnout do mechanismu
kontroly systémem SyRoTek.
Soubory fyzicky vytvářené na robotu jsou přímo uživateli nedostupné, uživatel má
k těmto souborům přístup voláním příslušného rozhraní na řídicím počítači. Vhledem
k omezenému datovému prostoru na palubním počítači jsou všechny soubory příslušné
uživateli po každém ukončení práce s robotem přesunuty na řídicí počítač, kde se stanou
součástí datové oblasti uživatelova domovského adresáře. Tvoří tam prostor pracovního
prostředí pro konkretní robot. Uživatel může najednou pracovat s více roboty nebo během nějakého období pracovat s různými pracovními prostředími robota (konfiguracemi).
Vlastní organizace těchto souborů je ponechána na uživateli, který je sám osobně zodpovědný, jak vyžívá přidělený datový prostor. Systém SyRoTek je mu v této organizaci nápomocen podpůrnými nástroji. Funkcionality těchto nástrojů jsou uvedeny v tabulce 4.11.
47/217
4.5. DATOVÉ A PRACOVNÍ SOUBORY
Název
create
upload
download
sync
check
SyRoTek - V003.1
Popis
Vytvoření uživatelského pracovního prostředí pro běh
aplikací na palubním počítači.
Vytvoření kopie z aktuálního uživatelského pracovního
prostředí palubního počítače na řídicí počítač.
Aktualizace uživatelského pracovního prostředí na palubním počítači z vybraného prostředí z databáze (souborového systému).
Synchronizace vybraného uživatelského pracovního
prostředí pro palubní počítač s aktuálním prostředí na
palubním počítači.
Kontrola kopie uživatelského pracovního prostředí pro
běh aplikací na palubním počítači.
Tabulka 4.11: Podpůrné nástroje pro správu uživatelského prostředí na robotu.
Tyto nástroje patří do množiny nástrojů pro práci s robotem. Množina mimo jiné dále
obsahuje nástroje pro spuštění a zastavení příslušného programu na palubním počítači,
ty jsou však součástí jiného funkčního objektu systému SyRoTek a z pohledu objektu
uživatelské databáze nejsou důležité.
Pojem databáze v tabulce 4.11 představuje příslušný adresář s kopií prostředí. Uchovávání konkrétního prostředí má kromě opakovaného použití uživatelem také důležitý důsledek pro ladění funkčnosti systému SyRoTek. Například pokud uživatel detekuje chybu
nebo dospěje k názoru, že systém nefunguje tak jak má, může ohlásit chybu, kterou podpoří
konkrétní instancí použitého pracovního prostředí. Odpovědný pracovník technické podpory tak má k dispozici relevantní informace k tomu, aby mohl případný problém efektivně
řešit.
Při běhu aplikace vzniká také záznam o průběhu příslušného experimentu, tím může
být video záznam, který je spravován modulem vizualizace, ale také datový soubor s údaji
o pozici robotu a informacemi ze senzorů. V neposlední řadě může být výsledkem experimentu vytvořený datový soubor, který obsahuje požadovaný výstup konkrétní úlohy, např.
vytvořenou mapu. Aby mohl učitel (nebo systém sám) experiment vyhodnotit, je nutné
tyto datové soubory uložit. Pro důvěryhodné ověření správnosti výsledků je však vhodné
doplnit soubory vytvořené uživatelem o nezávislá data, poskytována systémem SyRoTek.
Na příklad pro zhodnocení úspěšnosti vytvoření mapy prostředí pouze z dálkoměrných senzorů, je to konkrétní konfigurace plochy arény, včetně snímku reálné scény. Tyto informace
mohou být také uloženy v souborech příslušného domovského adresáře uživatele, ten však
nesmí disponovat právem zápisu do těchto souborů, pro případ vytvoření falzifikátů.
Situace s věrohodností uživatelských výstupních souborů je komplikovanější v případě,
že vytvoření těchto souborů probíhá off-line, například na uživatelské stanici. Alternativou
je v takovém případě vytvoření příslušného uživatelského pracovního prostředí pro řídicí
počítač a jeho spuštění na řídicím počítači s definovanými vstupními a výstupními soubory,
48/217
SyRoTek - V003.1
které jsou však aplikaci vytvořeny s právy uživatele (studenta) pouze pro čtení. Modifikaci
může provést pouze uživatel s rozšířenými přístupovými právy, typicky učitel, ke kterému
student patří. Aplikace generující příslušné výsledky však bude typicky pracovat s daty ze
senzorů, které jsou vytvořeny při reálné jízdě robotu. V rámci zachování důvěryhodnosti
výsledků jsou tato data vytvořena také s omezenými právy. Uživatel však musí systému
nějakým způsobem sdělit, že odevzdání chce provést s konkrétními daty z robotu, ty jsou
tvořeny kopií příslušného uživatelského pracovního prostředí palubního nebo řídicího počítače. Pro podporu odevzdávání úloh, tj. vytvoření důvěryhodných výstupních souborů
jsou podpůrné nástroje pro správu pracovních uživatelských prostředí rozšířeny o nástroje
(příkazy) uvedené v tabulce 4.12.
Název
inherit
execute
Popis
Zahrnutí vybraného prostředí jako součást vstupu jiného prostředí. Například prostředí z palubního počítače s daty ze senzorů se stane součástí prostředí řídicího počítače, které slouží k off-line zpracování naměřených dat.
Spuštění vybraného prostředí s vytvořením důvěryhodných výstupních dat.
Tabulka 4.12: Nástroje správy uživatelského prostředí pro podporu vytvoření důvěryhodných dat.
Z předchozích odstavců je zřejmé, že pro vytvoření a uložení příslušných důvěryhodných
souborů v uživatelské databázi je nutné, aby součástí zadání, byl také jasné definovaný
výstup uživatelské aplikace. Tento požadavek se týká především úloh, které vyžadují vytvoření uživatelské aplikace, která taková data vytvoří. Data musí být vytvořena na řídicím
nebo palubní počítači bez interakce s jinými programy běžícími mimo vyhrazené výpočetní
prostředky.
Je třeba zdůraznit, že mechanismus vytváření důvěryhodných dat je nutné zavádět pouze
tehdy, je-li uživatelské prostředí nedůvěryhodné. Na druhou stranu by však zvýšená organizační náročnost neměla zbytečně komplikovat vlastní proces vývoje uživatelské aplikace,
která je součástí řešení příslušné úlohy.
4.6
Logy
Logy jsou záznamy o činnosti jednotlivých částí systému SyRoTek v průběhu interakce
uživatele se systémem. Primárně příslušejí tyto záznamy konkrétnímu modulu a z hlediska
hledání informací o uživateli jsou relevantní pouze vybrané typy událostí. Ty části softwarových komponent, které jsou pro příslušného uživatele spouštěny jako nové instance
v rámci jeho uživatelského prostředí lze rozdělit na dvě kategorie:
49/217
4.7. E-MAILOVÉ ZPRÁVY A ZÁZNAMY KOMUNIKACE
SyRoTek - V003.1
• uživatelské - logy jsou ukládány v rámci prostoru uživatelského pracovního prostředí,
• systémové - logy nejsou přímo přístupné uživateli.
Význam první skupiny záznamů je podpora ladění vyvíjené aplikace. Jedná se převážně
o pracovní výpisy, které svým charakterem připomínají pracovní data, jsou však vytvářena
pro uživatele systémovými nástroji, které nemůže přímo měnit. V případě problému jsou
tyto záznamy podpůrným prostředkem pro komunikaci se správci a vývojáři systému SyRoTek. Uživatel by však v těchto záznamech měl najít důvod, chybného běhu své aplikace.
Druhou skupinou jsou záznamy, které jsou primárně určeny pro analýzu používání systému SyRoTek a vyhodnocování efektivity jednotlivých částí.
Vedle těchto záznamů jsou v rámci systému SyRoTek vytvářeny čistě systémové záznamy, které jsou příslušné severům poskytující příslušné služby. Formát těchto záznamu
je zpravidla definován autory příslušného serveru. Význam těchto záznamu je především
v monitorování případných bezpečnostních útoků, korekci softwarových nastavení (např.
změna limitů) a detekci hardwarových poruch. Přístup k údajům v těchto záznamem není
přímý a v případě hledání některé události může vyžadovat sekvenční zpracování. Vzhledem k charakteru těchto záznamů je příslušné vyhledávání relevantních informací řešitelné
standardními nástroji operačního systému, např. vyhledání počtu nebo data posledního
přístupu uživatele do systému přes webové rozhraní.
4.7
E-Mailové zprávy a záznamy komunikace
Nedílnou součástí uživatelských informací jsou e-mailové zprávy, které obsahují komunikační dialogy mezi uživatelem a systémem SyRoTek, případně učitelem resp. správcem.
Většina systémů LMS podporuje komunikaci formou diskuzních fór nebo též nabízí formuláře pro zasílání e-mailů.
Samotná komunikace mezi studentem a učitelem (správcem) však může probíhat prostřednictvím přímého e-mailu mimo systém LMS. Tyto e-maily mezi uživatelem a stranou
systému SyRoTek je vhodné uchovávat, neboť mohou být zdrojem řešení případných nedorozumění. Mnohdy však mohou také být zdrojem cenných informací, ze kterých v průběhu
používání systému mohou vznikat odpovědi na často kladené otázky (FAQ) nebo být vodítkem co zlepšit v dokumentaci nebo v systému samotném.
V případě osobně adresovaných e-mailů, může dojít k situaci, kdy daný učitel nebo
operátor nemá přístup k systému SyRoTek, například je dlouhodobě nemocen nebo se
z nějakého důvodu přestal podílet na provozu systému. Příslušnou agendu v takových
situacích přebírá jiná osoba. Zastupitelnost osob je vhodné podpořit definovanými způsoby
ukládání informací o uživatelích, proto komunikace probíhající mezi uživatelem a osobou
reprezentující systém SyRoTek musí splňovat pravidla pro snadný přístup a vyhledávání.
Ačkoliv pravidla mohou vést k jistému odosobnění během komunikačního aktu, poskytuje
benefit v podobě rychlejší reakci na příslušný podnět uživatele.
50/217
SyRoTek - V003.1
Zachování možnosti využívání nezávislého e-mailového přístupu ke komunikaci mezi
správci nebo učiteli a uživateli má hlavní význam v efektivitě používání příslušného emailového rozhraní. Zkušený uživatel dá přednost speciální aplikaci, kterou umí dobře
ovládat, a která mu nabízí jednotný způsob vyřizování elektronické pošty, které může být
každodenně velké množství. Ačkoliv se možnosti webových rozhraní pro práci s poštou neustále zlepšují, nelze očekávat, že v dohledné době budou dosahovat kvalit a možností dedikovaných aplikací. Z hlediska možné implementace je dnes nejvhodnější formou realizace
této nezávislosti vytvoření specializovaných e-mailových účtu pro správce/učitele, případně
ostatní uživatele systému SyRoTek a rozesílání zpráv dedikovaný SMTP serverem. Takový
server může automaticky ukládat zprávy pro pozdější dohledávání komunikace. Použití jiné
adresy pro doručení mailové zprávy není omezeno, neboť server může příslušnou zprávu
automaticky přeposlat.
Vedle diskuzního fóra, které má charakter e-mailových zpráv, je v případě práce na systému mnohem výhodnější interaktivnější forma komunikace. V současné době lze sice prostřednictvím Internetu komunikovat hlasem, bohužel však tuto formou komunikace nelze
uložit pro pozdější snadné použití a také zpravidla umožňuje efektivní komunikaci pouze
mezi dvěma účastníky.
Vhodnou alternativní formou komunikace je například dedikovaný kanál IRC, který
sleduje správce (operátor) systému SyRoTek a může reagovat na případné dotazy. Tato
forma komunikace také operátorovi umožňuje komunikovat s více než jedním uživatelem.
Nespornou výhodou IRC kanálu je možnost připojení a sledování komunikace více účastníky (uživateli), kteří také mohou pomoci řešit případný problém, mnohdy efektivně něž
operátor. Záznam z IRC je také možné snadno uložit a použít závěry z diskuse k vytvoření
příslušné dokumentace (manuál, FAQ, opravný změnový soubor3 ).
4.8
Data z vyplněných formulářů
Hlavním komunikačním rozhraním systému SyRoTek s uživatelem je webové rozhraní,
které je spravováno LMS systémem. V rámci tohoto systému uživatel vyplňuje celou řadu
formulářů, které jsou odesílány serveru. Obsah formulářů je zpravidla ukládán v příslušné
databázi. Pokud jsou tato data používána pouze v rámci webového rozhraní, je přístup
k nim realizován příslušnou LMS funkcí.
V systému SyRoTek je však výukový proces doplněn o praktické experimentování s robotickými platformami, které vyžaduje softwarové části, které jsou mimo rámec běžných
LMS systému. Přístup k datům z formulářů, proto musí být realizovatelný také pro jiné
softwarové komponenty, který neběží v rámci webového LMS.
Z hlediska sledování evoluce v používání systému SyRoTek je nutné vybrané formuláře, které pouze mění obsah hodnot příslušných proměnných, rozšířit o časovou značku,
3
patch
51/217
4.9. ZÁLOHOVÁNÍ UŽIVATELSKÝCH DAT
SyRoTek - V003.1
která zajistí vytváření historie příslušných nastavení. Funkce systému, které pracují s takovými hodnotami je nutné rozšířit o používání poslední hodnoty v historii nebo poslední
hodnotu v databázi duplikovat zachováním předchozího záznamu a vytvářením historie
hodnot mimo původní obsah.
4.9
Zálohování uživatelských dat
Z hlediska funkčnosti systému SyRoTek a jeho aktivního používání je zálohování uživatelských dat nejdůležitější zálohovací aktivitou. Vlastní systém lze vždy nainstalovat
znovu z příslušných zdrojových souborů. Případná konfigurace vychází typicky ze základního přednastavení jednotlivých modulů s případnými změnami, které jsou však typicky
závislé na konkrétním prostředí, kde je systém instalován.
Z hlediska údržby systému jsou důležité dva aspekty zálohování:
1. zálohování pro případ poruchy,
2. zálohování pro případ modernizace.
Pro spolehlivého uložení dat je nedůležitější komponentou počítačového systému pevný
disk. V případě poruchy pevného disku je z hlediska rychlosti obnovení plné funkcionality
systému nejvýhodnější použití zrcadlení dat, připojením redundantního počtu pevných
disků (pole RAID). V souvislosti z neočekávaným přerušením činnosti počítače však může
dojít k chybě integrity dat, způsobené nekorektním ukončením příslušné datové transakce.
V takové případě prostá redundance dat není postačují a je nutné provést zotavení systému, především však musí jednotlivé softwarové části být připravené pro korektní opětovné
spuštění (zotavení).
Druhým aspektem zálohování je modernizace počítačového systému, která může probíhat na hardwarové, ale především softwarové úrovni. V případě nové hardwarové komponenty může být nutná re-instalace některé softwarové komponenty, například procesor
s nekompatibilní instrukční sadou. Běžnějším případem je však aktualizace softwarové komponenty z důvodů nové opravené verze, která typicky obsahuje řešení objevené bezpečností
chyby. Zálohování uživatelských dat, které využívá příslušná komponenta musí být proto
v takovém případě provedeno na úrovni komponenty, neboť prostá kopie dat nemusí být
v nové verzi programu funkční.
Příkladem může být například databáze MySQL [14], která vyžadovala při aktualizaci
z verze serveru 4.x na verzi 5.x nové vytvoření příslušných tabulek v databázi. Nutnost
znovu-vytvoření uživatelských dat v instanci konkrétního programu je ještě patrnější při
přechodu na konkurenční program. V těchto situací je vhodné zálohovat data v některém
z univerzálních datových formátů, které nejsou vázané na konkrétní program nebo jeho
verzi. Může také nastat situace, kdy vhodný konverzní nástroj není k dispozici a je nutné jej
52/217
SyRoTek - V003.1
vytvořit, v takovém případě je otevřenost příslušných datových formátů klíčová k vyřešení
problému.
Při aktualizaci softwarové komponenty je velmi důležité ověřit správnou funkci všech
části systému, které s komponentou interagují. V některých případech může nová verze
programu interpretovat příslušné konfigurační nastavení jinak, nebo je ignoruje. Mohou
také nastat případy, kdy některé části systému SyRoTek bude nutné re-implementovat,
neboť závažná bezpečnostní chyba není řešena pro příslušnou verzi programu a nová verze
není kompatibilní s předchozí verzí. I když je to nepravděpodobné, může taková situace
nastat například u použitého skriptovacího jazyka a samotné zálohování dat není postačující.
V tabulce 4.13 jsou uvedeny potřebné funkcionality systémů pro práci s uživatelskými
daty, které jsou použity pro zálohování a údržbu systému. Více je problém zálohování a
údržby popsán v kapitole 9.
Funkcionalita
záloha dat
obnovení
zotavení
test
Popis
Vytvoření pokud možno nezávislé datové reprezentace
uživatelských dat.
Vytvoření instance uživatelských dat z vytvořené zálohy pro použití v konkrétní verzi příslušné softwarové
komponenty.
Soubor podmínek pro správnou činnost programu
spolu se souborem akcí programu, které jsou vykonány
v případě, že není některá podmínka pro bezchybné
spuštění programu splněna.
Postup, který ověřuje prostředí běhu komponenty,
zejména korektnost příslušných uživatelských dat.
Tabulka 4.13: Funkcionality modulu uživatelských dat pro potřeby zálohování a údržby.
4.10
Vazby na ostatní části systému
Uživatelská data jsou distribuována v různých modulech systému SyRoTek. Tato distribuce dat je v několika případech nevyhnutelná z důvodu podstaty vzniku dat (například
logy, zdrojové soubory). Pro přístup k jednolitým uživatelským datům je však nutné specifikovat sadu přístupových funkcí, které zajistí snadný přístup k datům a jejich případnou
opravu. To je zvláště důležité při administraci systému a řešení možných problému. Vedle
tohoto využití jsou tyto funkce vhodné pro zálohování a případné obnovení systému.
V předchozích odstavcích byly popsány jednotlivé části databáze uživatelů, která je
chápána jako soubor všech uživatelských dat resp. metod přístupů k uživatelským datům.
Správná činnost jednotlivých komponent systému SyRoTek, kterou uživatel přímo využívá,
53/217
4.10. VAZBY NA OSTATNÍ ČÁSTI SYSTÉMU
SyRoTek - V003.1
vyžaduje koordinaci jednotlivých částí. V tabulce 4.14 jsou shrnuty nejdůležitější návaznosti jednotlivých modulů systému SyRoTek využívající některé funkcionality komponenty
uživatelského databáze. Informace uvedené v tabulce jsou výchozími daty pro specifikaci
funkcionality příslušných komponent, modulů a jejich částí. Konkrétní realizace mohou být
implementovány různými technologiemi, avšak měly by obsahovat implementaci příslušné
funkcionality, aby byly naplněny požadované vlastnosti celého systému SyRoTek.
Uživatelská
databáze
autentizace
autorizace
Modul
webové rozhraní
webové rozhraní
rezervace
webové rozhraní
profile
webové rozhraní
vizualizace prostředí
datové a pracovní soubory
webové rozhraní
logy - uživatelské
webové rozhraní
Popis
Přístup uživatele k LMS.
Přihlášení k řídicímu počítači, vzdálená
práce na počítači, spouštění uživatelské
aplikace, komunikace s robotem, simulátorem, přístup k uživatelským souborům.
Zpřístupnění příslušných částí webového
rozhraní podle role.
Práva uživatele k přístupu do systému,
robotu, ovládání vizualizace a přístup
k souborům.
Registrace, modifikace a rušení rezervace
času a prostředku systému SyRoTek.
Příprava rezervovaných prostředků, potvrzení využití rezervovaného času.
Osobní nastavení preferencí způsobu
zobrazování webového rozhraní.
Základní konfigurace ovládané kamery
a nastavení kvality poskytovaného záznamu.
Nastavení prostředí pro práci a vzdálenou práci s/na řídicím počítači.
Vizualizace přístupu k datovým souborům, základní operace pro správu uživatelského prostředí robotu/řídicího počítače.
Přístup a manipulace se soubory, operace
pro správu uživatelského prostředí robotu/řídicí aplikace, spouštění uživatelské
aplikace.
Vizualizace přístupu a základní zobrazení uživatelských logů.
Logy mohou být směrované do příslušného souboru nebo pouze zobrazeny.
54/217
Uživatelská
databáze
logy - systémové
email zprávy
webové rozhraní
data formulářů
webové rozhraní
SyRoTek - V003.1
Modul
Popis
Logy jsou vytvářeny v datovém prostoru
pro běžného uživatele nepřístupném.
Komunikační zprávy rozesílané/doručované v rámci LMS systému jsou přístupné jednotným rozhraním jako záznamy komunikace probíhající mimo
LMS.
Data, které mají podobu formulářů nebo
je vhodné je jako formuláře prezentovat
jsou zobrazitelná prostřednictvím webového rozhraní. Především se jedná o řešení úloh, které mají praktický charakter.
Tabulka 4.14: Vazby databáze uživatelů na moduly systému SyRoTek.
Funkcionality objektu uživatelské databáze jsou shrnuty v tabulce 4.15. První sloupce
obsahuje jméno příslušné funkcionality, ve druhém sloupci je pak uveden modul, resp. prostředí, které danou funkcionalitu využívá. Hodnota shell reprezentuje pracovní prostředí
uživatele administrátora nebo vývojáře systému SyRoTek. Přístup k takové funkcionalitě
musí být ze strany příslušné aplikace umožněn. V závislosti na použité technologii realizace příslušné funkcionality musí být k dispozici programové rozhraní, které lze použít pro
vytvoření vlastní aplikace4 . V řadě případů, kdy funkcionalitu využívá modul řídicí počítač přistupuje k funkcionalitě speciální aplikace vytvořena pro systém SyRoTek. Poslední
sloupec tabulky 4.15 obsahuje popis nebo důvod přístupu.
Funkcionalita
autentizace
autorizace
profil
Modul/Přístup
webové rozhraní
webové rozhraní
webové rozhraní
webové rozhraní
rezervace
Popis
Ověření identity uživatele.
Ověření přístupových práv uživatele pro
konkrétní kontext.
Přístup k uživatelskému nastavení pří-.
slušných proměnných
Vytvoření a modifikace uživatelské rezervace.
Konfigurace systému podle parametrů
uvedených v příslušné v rezervaci.
4
V praxi tento požadavek znamenána především nároky na znalosti programátora, neboť v případě
open source softwarových technologií je příslušné rozhraní téměř vždy k dispozici a jediným omezující
faktorem je časová náročnost realizace konkrétním programátorem.
55/217
4.10. VAZBY NA OSTATNÍ ČÁSTI SYSTÉMU
Funkcionalita
datové/pracovní
soubory
Modul/Přístup
shell
webové rozhraní
shell
logy
shell
mailové zprávy
webové rozhraní
uživatelská data
(formuláře)
webové rozhraní
zálohování
shell
shell
obnova
shell
svn repozitář
SyRoTek - V003.1
Popis
Generování událostí souvisejících s rezervací.
Manipulace s prostředím pro spouštění
uživatelských aplikaci.
Prezentace výsledku řešení úlohy.
Ověření výsledků, podpora uživateli ze
strany administrátorů/vývojářů systému
SyRoTek.
Manipulace s prostředím pro spouštění
uživatelských aplikaci.
Vytváření a přístup k záznamům uživatelem.
Přístup k záznamům o používání systému uživatelem.
Vytváření, čtení, vyhledávání v databázi
mailových zpráv.
Pořízení a zobrazení příslušného formuláře.
Analýza vyplněných údajů.
Zálohování příslušných dat dílčích částí
uživatelské databáze.
Obnovení příslušných dat dílčích částí
uživatelské databáze ze zálohy.
Správa zdrojových souborů uživatele.
Tabulka 4.15: Základní funkcionality objektu uživatelské databáze.
Přístup k objektům uživatelské databáze, kterou mohou být data samotná nebo funkcionality, resp. služby, z ostatních částí systému SyRoTek definují příslušné rozhraní, které
musí uživatelská databáze poskytovat. Minimalizace počtu těchto rozhraní snižuje náklady
na jejich implementaci a údržbu. Příslušné rozhraní však musí být v ostatních modulech
implementovatelné, obzvláště u těch částí, které jsou tvořeny samostatnými softwarovými
balíky (například systémy LMS), jedná se zde především o autentizační, autorizační a databázové protokoly. Jednotlivé funkce, resp. přístup k datům jsou poskytovány jako serverové
služby. Serverové řešení však má smysl pouze tehdy, je-li příslušná služba poskytována přes
síťové rozhraní, tedy přístup ke službě je také nutný z jiného počítače. V případě přístupu
k databázi pouze lokálně v rámci jediného hostitelského počítače, je mnohdy výhodnější
přistupovat k datovým souborům prostřednictví dedikovaného programu (resp. sady knihovních funkcí), který zajišťuje konzistentní přístup s mnohem nižšími nároky na výpočetní
56/217
SyRoTek - V003.1
prostředky. Příkladem je realizace databáze Berkeley DB [15] nebo SQLite [16].
Nejjednodušší formou databáze jsou textové soubory, které se stále například používají
uložení seznamu uživatelů nebo skupin v běžných operačních systémech, typicky jsou to
soubory /etc/passwd a /etc/group, pokud počet záznamů není veliký (desítky). Přístup
k těmto souborům je řešen voláním standardních služeb operačního systému.
57/217
SyRoTek - V003.1
Kapitola 5
Řídící počítač
Řídící počítač je hlavním objektem přístupu uživatele k reálném hardwaru systému
SyRoTek. Jeho hlavní činností je realizace uživatelského přístupu ke sdíleným robotům a
běh příslušných uživatelských aplikací. Z hlediska poskytovaných služeb řídicím počítačem
lze rozlišit dvě kategorie aplikací.
• Systémové aplikace, které jsou nezbytné pro správnou funkčnost systému SyRoTek.
• Uživatelské aplikace, které jsou spouštěny přihlášenými uživateli.
Vlastní implementace řídicího počítače nemusí být fyzicky realizována na jediném výpočetním prostředku. Z hlediska dostatečného oddělení uživatelského prostoru od systémového prostoru lze uvažovat o samostatném aplikačním serveru pro studenty, který může
být využíván mnohem intenzivněji, než vlastní systémový server, na kterém běží časově
kritické aplikace související s řízením robotů.
Z technického pohledu je však rozdělení spíše záležitostí dostatečného výpočetního výkonu počítače a příslušného operačního systému. V současné době jsou již běžně dostupné
více jádrové procesory, které disponují vysokým výpočetním výkonem a problémem se spíše
stává efektivní rozdělení strojového času mezi uživatele. Z hlediska řízení a komunikace řídicího počítače s roboty jsou limitujícím faktorem spíše počty komunikačních rozhraní
počítače spolu s jejich obsluhou. Při komunikaci jsou to právě časová zpoždění při obsluze
jednotlivých přerušení od komunikačních rozhraní, které mohou značným způsobem snižovat efektivní výkon celého systému, diskuze této problematiky v souvislosti s operačními
systémy reálného času je uvedena ve zprávě [3] v části Softwarové technologie.
Z pohledu minimalizace nákladů na správu systému SyRoTek je přirozené koncentrovat
systémové aplikace na jediný řídicí počítač. Mezi takové aplikace patří rozhraní pro ovládání
pohyblivých překážek. Přirozeně je vhodné řídicí počítač využít také jako prostor pro
administraci systému a servisní přístup k robotům, neboť lze s výhodou využít instalované
softwarové prostředky, které jsou potřebné pro běh uživatelských aplikací.
58/217
KAPITOLA 5. ŘÍDÍCÍ POČÍTAČ
SyRoTek - V003.1
Ve zprávě [1] byly identifikovány následující základní objekty řídicího počítače:
• verifikace příkazů,
• komunikace s roboty,
• stavy robotů,
• evaluace úlohy,
• senzorická data,
• simulátor,
• uživatelské komponenty a rozhraní.
V této kapitole je koncept řídicího počítače dále rozšířen a specifikován. Celková architekturu řídicího počítače je zásadním způsobem ovlivněn snahou o co možná největší
využití v současné době nejpoužívanějšího systému pro řízení mobilních robotů v univerzitním prostředí, kterým je systém Player/Stage, jak bylo uvedeno v oddíle 3.1.1 [3].
Minimální požadovaná vlastnost systému SyRoTek je kompatibilita komunikačních protokolů systému Player na takové úrovni, aby aplikace vyvinuté pro řízení robotu v systému
Player bylo možné spustit v systému SyRoTek a řídit příslušný robot.
Vedle zprostředkování přístupu uživatele k robotu jsou dalšími hlavními úlohami řídicího
počítače podpora simulovaného prostředí a podpora evaluace úlohy. Tyto tři hlavní úlohy
řídicího počítače tvoří relativně samostatné celky, které je však nutné podpořit dílčími
funkcionalitami. Základní funkcionality řídicího počítače jsou shrnuty v tabulce 5.1.
Název
uživatelská komunikace s roboty
systémová komunikace s roboty
uživatelské prostředí
uživatelské prostředí na robotu
vzdálené sezení
vývoj
vzdálený vývoj
simulátor
Popis
Realizace komunikace s roboty (řízení) a čtení senzorických dat.
Komunikace s roboty, servisní zásahy, sběr událostí, reakce na výjimečné stavy.
Prostředky pro práci s prostředím na řídicím počítači.
Prostředky pro práci s prostředím na robotu.
Uživatel vzdáleně pracuje na řídicím počítači ze
své uživatelské stanice.
Podpora vývoje uživatelských aplikací.
Podpora uživatele pracujícího na své uživatelské
stanici a spouštějícího program na robotu nebo
řídicím počítači.
Podpora simulace reálného robotu.
Tabulka 5.1: Základní funkcionality objektu řídicí počítač systému SyRoTek.
59/217
5.1. SOFTWAROVÁ ARCHITEKTURA ŘÍDÍCÍHO POČÍTAČE
SyRoTek - V003.1
Potřebné funkcionality jsou realizovány souborem softwarových nástrojů a aplikací. Základní softwarová architektura je popsána v následujícím oddíle 5.1. Kompletní softwarové
prostředí lze rozdělit na tři části: systémové aplikace, uživatelské aplikace a vlastní operační
systém. Operačnímu systému je věnován samostatný oddíl 5.2, ve kterém jsou popsány
hlavní požadavky související nejen s nezbytnou podporou potřebného hardwaru příslušných komunikačních rozhraní, ale především podpora vývojových nástrojů a podpůrných
knihoven.
5.1
Softwarová architektura řídicího počítače
Koncept softwarové architektury vychází z hardwarového propojení řídicího počítače
s ostatními částmi systému SyRoTek. Tato propojení jsou realizována na administrativní,
systémové a uživatelské úrovni. Administrativní úroveň je chápana jako množina aplikací související s provozem operačního systému, autentizační/autorizační server, přístup
k diskovým prostorům. Systémová úroveň reprezentuje aplikace systému SyRoTek, které
zajišťují bezchybný chod systému a poskytují příslušné funkcionality pro uživatele. Do
této skupiny patří také systémové aplikace, které jsou spouštěny uživatelem a běží v rámci
jeho uživatelského prostoru. Uživatelskou úrovní se pak rozumí aplikace vyvíjené uživatelem, které využívají rozhraní systémových aplikací zpřístupňující uživateli funkcionality
systému SyRoTek.
Na obrázku 5.1 jsou zobrazeny jednotlivé části systému SyRoTek, které jsou spojeny
s řídicím počítačem. Uživatel připojený prostřednictvím sítě Internet přímo komunikuje
pouze s vizualizačním serverem, webovým serverem a uživatelskou části řídicího počítače.
Jednotlivé servery a řídicí počítač jsou propojeny privátní vysokorychlostní sítí. Autorizační
server spolu s lokalizačním systémem jsou na obrázku zobrazeny odděleně, přestože fyzicky
mohou být součástí webového serveru resp. řídicího počítače. Řídící počítač je dále připojen
k systému rádiové komunikace s roboty, která slouží pro přenos systémových údajů z/do
robotu s definovaným maximálním dopravním zpožděním. Lokální WiFi síť slouží pro
komunikaci uživatelské aplikace s robotem a pro přenos dat velkých objemů. V závislosti
na provedení dokovací stanice je k řídicímu počítači připojeno její ovládání, které obsahuje
především servisní rozhraní pro hlášení stavu zadokování, aktuálně odebíraný proud a
napětí při nabíjení, případně vysokorychlostní komunikační rozhraní Ethernet. K řídicímu
počítači je také připojena jednotka ovládání pohyblivých překážek.
V následujících oddílech jsou popsány jednotlivé systémové 5.1.1 a uživatelské aplikace 5.1.2. Aplikace administrativní úrovně jsou popsány společně s požadavky na operační
systém v části 5.2.
60/217
SyRoTek - V003.1
robot
robot
autentizační /
autorizační
server
privátní
síť
aréna
lokalizace RF
ovládání
dokovacích
míst
Ethernet
Switch
ovládání
překážek
Visual
SyRoTek
Video
vizualizační
server
lokální
wifi síť
webový
server
řídicí
počítač Internet
Obrázek 5.1: Propojení objektů systému SyRoTek s řídicím počítačem.
61/217
5.1.1
SyRoTek - V003.1
Systémové aplikace
Systémové aplikace zapouzdřují přímý přístup k hardware robotu. Jedná se především
o tyto aplikace:
• abstrakce ovládání robotu a vyčítání senzorů,
• simulace reálného prostředí,
• konfigurace arény,
• abstrakce přístupu k palubnímu počítači robotu,
• podpora evaluace úlohy,
• podpora vzdáleného vývoje a ladění,
• monitorování stavu jednotlivých robotů.
Jednotlivé systémové aplikace jsou popsány v následujících oddílech.
Abstrakce ovládání robotu a vyčítání senzorů
Hlavní uživatelské rozhraní přístupu k robotu a senzorům je realizováno prostřednictvím
protokolu kompatibilního se systémem Player/Stage. Pravděpodobně nejvýhodnější implementace rozhraní k robotu je proto realizace specializovaných ovladačů pro systém Player/Stage. S ohledem na zajištění spolehlivého provozu a respektování povolených senzorů
při realizaci konkrétní úlohy je nutné respektovat spouštění serveru Player v uživatelském
prostoru. Zároveň je nutné monitorovat, případně ovládat roboty i v případě, kdy žádný
uživatelský program Player neběží.
Základní architektura softwarové abstrakce je zobrazena na obrázku 5.2. Uživatelská
aplikace běžící v rámci uživatelského prostoru na řídicím počítači je realizována jako klientská aplikace serveru Player. Uživatel před spuštěním své aplikace musí nejdříve spustit
instanci serveru Player. Ten je spuštěn s příslušnou uživatelskou konfigurací, která definuje jaké senzory bude uživatelská aplikace používat. Kromě modulů, případně ovladačů
ze základní instalace systému Player používá server speciální ovladače systému SyRoTek,
které poskytují příslušné kompatibilní rozhraní se základními rozhraními systému Player.
Tyto ovladače však nekomunikují přímo s hardware robotu, jak je tomu v případě běžných
ovladačů systému Player, místo toho se připojují k přístupovému modulu robotu.
SyRoTek modul ovladače pro robotickou platformu systému SyRoTek implementuje
příslušné rozhraní senzorů a robotu. Vzhledem k plánované senzorické výbavě robotu se
jedná o téměř všechna rozhraní systému Player přistupující k přímo k hardware. Rozhraní
jsou uvedena v tabulce 5.2.
62/217
SyRoTek - V003.1
Modul komunikace s roboty
konfigurace
aktuálního
uživatelského
sezení
Přístupový
modul
robotu
uživatelský prostor
Player server
moduly
ovladače
SyRoTek
moduly
ovladače
uživatelská
aplikace
Obrázek 5.2: Abstrakce uživatelského přístup k robotu a senzorům.
63/217
Rozhraní
position2d
localize
power
bumper
ir
laser
camera
blobfinder
map
sonar
SyRoTek - V003.1
Popis
Rozhraní poskytuje informace o poloze robotu z odometrie a slouží
k ovládání robotu.
souřadnice robotu z globálního systému lokalizace
informace o spotřebě a kapacitě akumulátoru robotu
rozhraní pro vyčítání nárazníků
pole infračervených dálkoměrů
laserový dálkoměr
rozhraní kamery umístěné na robotu
rozhraní rozpoznávání obrazu realizované inteligentní kamerou
mapa prostředí (globální lokalizace a konfigurace překážek)
pole ultrazvukových dálkoměrů
Tabulka 5.2: Poskytovaná rozhraní SyRoTek ovladačů systému Player.
Tato rozhraní je však možné využít pouze v případě, že je robot příslušně nakonfigurován
a uživatel má v rámci řešení úlohy oprávnění rozhraní používat. V závislosti na technické
realizaci robotické platformy systému SyRoTek, lze dále uvažovat o rozhraních uvedených
v tabulce 5.3.
Rozhraní
aio
dio
log
camera
ptz
wifi
Popis
analogové vstupy/výstupy
digitální vstupy/výstupy
ovládání logování
rozhraní k vizualizační kameře
ovládání kamery, případně ovládání vizualizační kamery.
informace o signálu WiFi
Tabulka 5.3: Rozšířená rozhraní SyRoTek ovladačů systému Player.
64/217
SyRoTek - V003.1
Na obrázku 5.3 je zobrazena jedna z variant řešení přístupového modulu robotu.
lokalizace
RF
rozhraní
konfigurace
aktuálního
uživatelského
sezení
WiFi
rozhraní
Ethernet
rozhraní
vizualizace
Přístupový modul robotu
příkazy
senzorická
data
pozice
robotu
IPC
SyRoTek
moduly
ovladače
Obrázek 5.3: Přístupový modul robotu.
V této konfiguraci přístupový modul robotu odděluje přístup k hardware, resp. komunikaci s robotem. Podle příslušné konfigurace aktuálního uživatelského sezení je přístup
k jednotlivým komponentám umožněn pouze konkrétnímu uživateli. Komunikace mezi přístupovým modulem robotu a uživatelským prostorem, ve kterém je spuštěna konkrétní
instance serveru Player, probíhá prostřednictvím mechanismu IPC (mezi-procesové komunikace) [17]. Samotný přístupový modul využívá rádiové rozhraní, případně WiFi rozhraní
pro komunikaci s robotem. Údaj o absolutní pozici robotu je vyčítán z modulu lokalizace,
který je napojen na řídicí počítač, případně je realizován samostatnou aplikací běžící na
řídicím počítači. V případě podpory rozhraní ptz a camera pro ovládání kamery a zobrazení (zpracování) obrazu z některé z vizualizačních kamer komunikuje přístupový modul
se systémem vizualizace. V závislosti na technické realizaci vlastní komunikace mezi řídicím a palubním počítačem, je modul komunikace s roboty implementován jako obálka
zapouzdřující komunikaci se všemi roboty nebo s příslušným robotem 1 .
Ovladače serveru Player mohou být, kromě výše uvedené možnosti propojení technologií
IPC, také realizovány jako takzvané passthrough ovladače, které slouží jako proxy ovladače pro komunikaci mezi různými Player servery, obrázek 5.4. Tyto ovladače vystupují
1
Především se jedná o realizaci komunikace po RF rozhraní, pro které může být výhodné implementovat vlastní mechanismus řízení přístupu k transportnímu médiu v případě, že je sdíleno pro komunikaci
s několika roboty.
65/217
SyRoTek - V003.1
lokalizace
konfigurace
aktuálního
uživatelského
sezení
RF
rozhraní
WiFi
rozhraní
Ethernet
rozhraní
vizualizace
Palubní počítač
pozice
robotu
příkazy
IPC
senzorická
data
TCP/IP
SyRoTek
moduly
ovladače
Player
passthrough
ovladače
Obrázek 5.4: Přístupový modul robotu.
v roli klienta jiné instance serveru Player a zajišťují přenos dat klientské aplikaci, která se
připojuje k jedinému Player serveru. Přístupový modul robotu je proto realizován distribuovaně. Část poskytující pozice robotu z globálního lokalizačního systému je spuštěna na
řídicím počítači, neboť je zde předpoklad menšího dopravního zpoždění. Část poskytující
rozhraní s hardwarem robotu běží na palubním počítači v rámci instance serveru Player,
ve které jsou nataženy příslušné SyRoTek ovladače.
Na palubním počítači mohou být ovladače serveru Player realizovány podobně jako na
obrázku 5.3, kde komunikují se systémovou aplikací rozhraním IPC. Alternativně mohou
ovladače přistupovat přímo k hardware robotu, což však vyžaduje příslušná oprávnění pro
zápis a čtení z příslušných zařízení. Architektura softwarových komponent na palubním
počítači robotu je diskutována ve zprávě [2] a v kapitole 6 této zprávy. V případě potřeby
komunikace s hardwarem je však nutné mít spuštěnu instanci server Player nebo nějakým
jiným způsobem vyřešen problém exkluzivního přístupu na hardware. Dále je nutné zmínit
fakt, že passthrough ovladače jsou ve verzi Player 2.x označené jako deprecated, neboť
vzdálené ovladače je možné přímo adresovat z příslušného konfiguračního souboru serveru
Player běžícího na palubním počítači.
Volba vhodného způsobu implementace přístupového modulu robotu je závislá především na komunikační dostupnosti a kapacitě přenosového kanálu. Implementace nezávislé
aplikace pro vlastní komunikaci s hardwarem robotu a napojení ovladače serveru Player
66/217
SyRoTek - V003.1
rozhraním IPC má následující výhody:
• Servisní rozhraní není závislé na serveru Player, komunikuje přímo s komunikační
aplikací nebo s hardwarem.
• Přístupová práva jsou řešena v rámci operačního systému, IPC transportní vrstva je
vytvořena pro přístup konkrétní skupinou uživatelů2 .
• SyRoTek ovladače pro server Player jsou identické pro řídicí počítač i pro palubní
počítač. Zásadní rozdíl je v realizaci přístupového modulu robotu, který na palubním
počítači komunikuje přímo s hardwarem a navíc poskytuje rozhraní pro komunikaci
s řídicím počítačem. Na řídicím počítači přístupový modul robotu využívá rozhraní
modulu komunikace s robotem.
Hlavní výhodou realizace ovladačů serveru Player, které komunikují přímo s hardwarem
robotu, je potencionální použití robotické platformy systému SyRoTek mimo vlastní systém SyRoTek. Další výhodou může být pravděpodobně jednodušším implementace, neboť
nevyžaduje realizaci další komunikační vrstvy. Toto řešení však významných způsobem
omezuje kontrolu přístupu k hardware robotu.
V případě, kdy uživatelé spolupracují na řešení společné úlohy, mohou si řešení úlohy
rozdělit také tak, že jednotlivé uživatelské programy pro vzájemnou spolupráci vyžadují komunikaci. Systém Player k tomu účelu poskytuje rozhraní opaque, které slouží jako obecný
nástroj pro zasílání uživatelských zpráv nebo rozhraní mcom pro komunikaci mezi klienty
serveru Player. V obou případech však efektivní komunikace může nastat pouze tehdy,
může-li se uživatelská aplikace jednoho uživatele připojit k instanci serveru Player jiného
uživatele. Je jisté, že mezi konkrétními uživateli musí existovat domluva, aby nedocházelo
k nežádoucím efektům. Z hlediska restrikce možných připojení ke konkrétní instanci serveru Player je možné využít příslušných pravidel nastavení firewall, které však může být
příliš restriktivní a kontraproduktivní. Pravděpodobně bude plně dostačující vytvoření příslušné instance serveru Player na konkrétním číslu portu dedikovaném pro konkrétní sezení
a více-násobné připojování uživatelských programů k serveru Player nechat plně v režii samotných uživatelů a jejich domluvě. Přesto je vhodné v rámci příslušného uživatelského
sezení garant využití dedikovaného portu spuštění serveru Player konkrétním uživatelem.
Simulace reálného prostředí
Vývoj robotické aplikace přímo na reálném hardwaru bývá často velmi zdlouhavý, obzvláště v prvních fázích vývoje. Pro začínajícího uživatele je proto výhodné začít vývoj
aplikace s využitím simulátoru. Dalším důvodem je omezený počet reálných robotů, uživatelé mohou testovat své aplikace i v době, kdy jiní uživatelé využívají přístupu k reálnému
hardwaru.
2
Exkluzivní přístup příslušného uživatele bude pravděpodobně nutné realizovat dynamickým přidělováním uživatelů do skupin, podle rezervovaného času.
67/217
SyRoTek - V003.1
Jelikož uživatelská aplikace řídí robot a získává data ze senzorů protokolem kompatibilním se systémem Player, je nejvýhodnější využít simulátor Stage, který je součástí balíku
Player/Stage. Stage je 2D simulátor prostředí s mobilním robotem. Součástí simulátoru
Stage je grafické rozhraní, které umožňuje s robotem manipulovat a dává jistou představu
o prostředí, ve kterém se robot pohybuje, viz například obrázek 3.2 v [3]. 3D rozšíření je
realizováno přidruženým projektem Gazebo [18], simulace také rozšiřuje podporou dynamických modelů.
S ohledem na systém SyRoTek je nutné vytvořit příslušné konfigurační soubory pro
simulátor Stage, který je nahráván do serveru Player jako samostatný ovladač.
Z hlediska uživatelské aplikace komunikující se serverem Player prostřednictvím příslušných komunikačních protokolů (například v C++ instancemi příslušných tříd odvozených
od PlayerCc::ClientProxy klientské knihovny libplayerc++) není rozdílu při testování
aplikace vůči ovladači simulátoru nebo příslušným SyRoTek ovladačům. Jediný zásadní
rozdíl je v charakteru dat, který je v reálném prostředí vždy alespoň trochu odlišnější než
většinou deterministická simulace.
Z hlediska komfortu vývoje je příjemnější mít simulátor spuštěn na lokální pracovní stanici, na které uživatel pracuje, neboť grafická prostředí zpravidla vyžadují vysokou míru
interaktivity a s tím související náročnost na komunikační kapacitu. Pro spuštění systému
Player, zvláště pak Stage jsou nutné softwarové závislosti, které mohou být obtížně řešitelné nezkušeným uživatelem3 . Z tohoto důvodů je vhodné, aby bylo možné server Player,
včetně ovladače simulátoru Stage spustit také vzdáleně na řídicím počítači s přenášeným
zobrazováním na uživatelovu pracovní stanici. Alternativou je implementace nezávislého
zobrazování simulačního prostředí, které může běžet na uživatelské stanici, takovou implementaci lze také s výhodou použít při vizualizaci arény systému SyRoTek při nedostačující
přenosové kapacitě pro zobrazování reálné scény. Jistou alternativou je použítí grafické
knihovny OpenGL [19], kdy jsou jednotlivé objekty vytvořeny přímo v paměti grafické
karty a přenáší se pouze transformační parametry zobrazované scény. V této oblasti lze
s výhodou navázat na projekty, které se snaží rozšířit vizualizační možnosti systému Player [20].
3
Toto může být zvláště časté u stolních počítačů, určených k jednoúčelovému používání, které stále
bývají velmi často vybaveny okénkovým systémem.
68/217
SyRoTek - V003.1
Obrázek 5.5: Vizualizační prostředí ARDev, obrázek převzat z [21].
Jedním z nich je projekt ARDev, který poskytuje vizualizaci dat v prostředí augmented
reality [21]. Na obrázku 5.5 je zobrazena ukázka vizualizace laserových dat do reálné scény.
Obrázek 5.6: Vizualizace algoritmu sledování lidí rozhraním Player Viewer 3D.
Dalším vizualizačním klientem je Player Viewer 3D z projektu mirian, který využívá
rozhraní knihovny OpenGL. Cílem projektu je vývoj prostředí pro navigaci robotů [22].
Příklad vizualizace funkce algoritmu sledování lidí z laserového dálkoměru je zobrazen na
obrázku 5.6.
69/217
SyRoTek - V003.1
Jedním z potencionálních nedostatků simulátoru Stage, je jeho velmi jednoduchý fyzikální model. Model je však plně postačující pro základní seznámení se s řízením mobilního
robotu s diferenciálním podvozkem a základním zpracováním dat ze senzorů, které se používají v mobilní robotice. Jednotlivé modely robotu a senzorů je vhodné nakonfigurovat,
případně re-implementovat tak, aby co možná nejvěrněji odpovídaly parametrům robotů
systému SyRoTek.
Plocha arény systému SyRoTek obsahuje konfigurovatelné překážky, proto je vhodné
podpořit příslušnou konfiguraci překážek také odpovídajícím simulačním prostředím.
V tabulce 5.4 jsou shrnuty jednotlivé funkce a vlastnosti simulace reálného prostředí.
Funkce / Vlastnost
Vzdálená simulace
Lokální vizualizace simulace
Lokální simulace
Simulační prostředí
Simulační aktuálního prostředí
Model robotu a senzoru
Více-uživatelské prostředí
Popis
Uživatel spouští simulaci na řídicím počítači, grafické rozhraní je zobrazováno na uživatelské stanici.
Simulace je spuštěna na řídicím počítači, grafické
rozhraní je spuštěno na uživatelské stanici.
Na uživatelské stanici je spuštěn simulátor (server
Player) včetně vizualizačního rozhraní.
Konkrétní úloha je kromě příslušného zadaní prostředí (konfigurace arény) doplněna o odpovídající
simulační prostředí
V rámci aktuální konfigurace arény je pro uživatele přístupné odpovídající simulační prostředí,
které respektuje aktuální rozmístění překážek na
ploše arény.
Simulační prostředí obsahuje příslušné moduly a
konfigurace robotu a senzorů přístupných v systému SyRoTek.
Pro podporu řešení úloh, které vyžadují spolupráci více uživatelů je vhodné umožnit společné
využití konkrétní instance simulačního prostředí
více uživatelů.
Tabulka 5.4: Základní funkce a vlastnosti simulace reálného prostředí.
Konfigurace arény
Na ploše arény systému SyRoTek jsou kromě robotů také umístěny překážky. Překážky
jsou dvojího typu, pohyblivé a pevné. Pohyblivé překážky je možné vzdáleně ovládat a
měnit tak konfiguraci plochy arény. Pevné překážky vyžadují pro své přestavení lidskou
70/217
SyRoTek - V003.1
obsluhu, z tohoto důvodu nebude tento typ překážek modifikován tak často jako překážky
pohyblivé.
Různé konfigurace arény souvisí s řešením příslušné úlohy. S ohledem na časovou náročnost manuálního umístění pevných překážek, bude konfigurace arény vždy pro nějaké
období zafixována. Případné rekonfigurace budou možné pouze změnami pohyblivých překážek. Lze předpokládat, že konfigurace arény budou tématické, například kancelářské
prostředí nebo bludiště na obrázku 5.7 (a), resp. (b). Příslušné konfigurace budou vybírány s ohledem na aktuálně probíhající hlavní výukový kurz, respektive související řešení
příslušných úloh.
(a) Kancelářské prostředí
(b) Bludiště
Obrázek 5.7: Příklady tématické konfigurace arény, pevné překážky jsou zobrazeny šedou
barvou, pohyblivé překážky červenou.
Aktuální konfigurace arény je vždy doplněna o příslušný model světa pro simulátor.
V některých případech může být součástí úlohy dynamické prostředí, případně uživatel
může po spuštění své úlohy modifikovat prostředí, ve kterém se robot pohybuje. Dynamické
prostředí lze vytvořit prostřednictvím pohyblivých překážek nebo také vhodným umístěním
robotu. Typickým příkladem je například simulace otevřených a zavřených dveří zasunutou,
resp. vysunutou překážkou, případně vhodným přesun robotů. Pohybující se robot také
může reprezentovat náhodně se pohybující objekt, případně může být jeho role součástí
zadání, například v úloze typu pursuit-evader. Pohyblivé překážky, například reprezentující
dveře, mohou být automaticky ovládané v závislosti na pohybu robotu. V součinnosti
s modulem evaluace úlohy mohou takové dveře být otevřeny až po splnění příslušného
úkolu, například robot byl na definovaných místech prostředí.
71/217
SyRoTek - V003.1
Konfigurace arény
úloha
simulace
zadání
úlohy
ovládání
robotu
model
prostředí
ovládání
překážek
validace
HW
evaluace úlohy
interakce uživatele
pozice a rychlost robutu
Obrázek 5.8: Funkční bloky konfigurace arény.
Jednotlivé funkční bloky konfigurace arény jsou zobrazeny na obrázku 5.8. Zadání úlohy
obsahuje nejen vlastní rozmístění překážek, ale také informaci o případném řídicím algoritmu pro ovládání robotu jako překážky či jako součást úlohy. Znalost o poloze pohyblivých
překážek může být užitečná při vytváření modulu prostředí pro simulátor v součinnosti
s lokalizačním systémem, neboť obraz z lokalizační kamery je vhodné použít pro automatické generování prostředí pro simulaci. Pohyb robotu, resp. překážek vyžaduje přístup
k hardware, který může být v případě překážek realizován přímo. V případě řízení pohybu robotu je využit příslušný přístupový modul robotu, který byl popsán v předchozích
odstavcích. Pohybové akce může uživatel ovládat, například povel k zasunutí/vysunutí
překážky, případně povolení či přerušení dynamické změny prostředí během jízdy robotu
řízeného uživatelskou aplikací.
Ovládání pohyblivé překážky, zvláště pak její vysunutí, je nutné provádět s ohledem na
pozici robotů na ploše. Proto je nezbytnou součástí modulu ovládání překážky validace
žádaných příkazů řízení překážek, případně robotů jako pohyblivých překážek. V případě
možné kolize není žádaný povel proveden. V závislosti na příčině možné kolize je příslušný
povel pozastaven nebo odmítnut, není-li povel interaktivní žádostí uživatele, je příslušná
možná kolize (resp. odmítnutí požadavku) zaznamenána, neboť za normálního provozu by
nemělo docházet ke vzniku potenciálních kolizí.
72/217
SyRoTek - V003.1
Základní vlastnosti a funkce modulu konfigurace arény jsou shrnuty v tabulce 5.5.
Funkce / Vlastnost
Ovládání překážek
Robot jako překážka
Dynamické prostředí
Interakce uživatele
Podpora simulace
Validace
Popis
Nastavení polohy pohyblivých překážek podle předepsané konfigurace.
Robot je použit jako statická překážka umístěná
na příslušnou pozici.
Pohyblivé překážky nebo roboty jsou ovládány
podle zadání úlohy.
Uživatel může konfigurovat příslušné překážky
nebo modifikovat chování dynamických překážek.
Aktuální konfigurace arény je použita pro vytvoření příslušného modelu prostředí.
Ovládání překážek musí být bezpečné a nesmí
způsobit kolize.
Tabulka 5.5: Základní funkce a vlastnosti konfigurace arény.
Abstrakce přístupu k palubnímu počítači robotu
Přístup k palubnímu počítači není uživateli systému SyRoTek povolen přímo. Důvodem
proč není vhodné umožnit uživateli sezení v rámci operačního systému palubního počítače je především propojení řídicího a palubního počítače a softwarové vybavení a výkon
palubního počítače.
Přestože je robot vybaven rozhraním WiFi, není z bezpečnostních důvodů robot připojen do veřejné sítě Internet. Technickou realizaci přímého přístupu uživatele protokolem
IP verze 4, je možné založit na přesměrování příslušného portu [23] na řídicím počítači
na konkrétní robot. Uživatel by se v takovém případě hlásil na adresu řídicího počítače a
specifický port (například ssh sezení), který by jej však spojil s konkrétním robotem. Uživatelské sezení na palubním počítači nutně vyžaduje bezproblémové spojení s autentizačním
a autorizačním serverem. Takové spojení včetně vlastní uživatelské interakce s operačním
systémem robotu vyžaduje nízké odezvy, které mohou být na úkor celkové přenosové rychlosti v rámci WiFi sítě.
Druhým významným důvodem omezení přímého přístupu na palubní počítač je dostupná výpočetní kapacita na robotu a značně omezený uživatelský prostor na palubním
počítači. Ačkoliv lze předpokládat, že nutné softwarové nástroje a knihovny pro běh a
kompilaci uživatelské aplikace budou na robotu k dispozici, doba kompilace uživatelské
aplikace na řídicím počítači bude v porovnání s dobou kompilace na palubním počítači
zanedbatelná.
73/217
SyRoTek - V003.1
Přítomnost nezkušeného uživatele na palubním počítači zvyšuje riziko uvedení uživatelského prostředí do neprovozuschopného stavu. Pro uživatele, resp. správce, může být velmi
obtížné najít v takových případech chybný krok, což v praxi vede na vytvoření prostředí
nového. Nezkušený uživatel, zvláště pak ten, který se učí pracovat se způsobem ovládání
a vytváření uživatelské aplikace v systému SyRoTek, může být navíc zpočátku zmaten
z různých uživatelských prostředí.
Zkušený uživatel, zvyklý pracovat vzdáleně i na několika systémech současně, by přímý
přístup na palubní počítač uvítal. Přesto jsou výpočetní prostředky palubního počítače
v porovnání s řídicím počítačem limitující a uživatelské prostředí je proto minimalistické.
Výše uvedené odstavce popisují hlavní důvody proč je vhodné abstrahovat přímý přístup
uživatele k palubnímu počítači. Navíc hlavní (a v podstatě i jedinou) činností, kterou uživatel na palubním počítače může provozovat je spouštění své uživatelské aplikace. Vyvíjená
uživatelské aplikace jistě nebude v řadě případů fungovat bezchybně hned po prvním překladu. Přestože základní odladění aplikace provádí uživatel vůči simulovanému prostředí,
je spuštění aplikace na reálném hardwaru téměř vždy doprovázenou nutností dalšího ladění, neboť v reálném prostředí nastávají situace, které uživatel nepředpokládal. Z tohoto
důvodu je nutné podpořit vzdálené ladění aplikace.
Spouštění uživatelské aplikace probíhá vždy z nějakého prostředí, které definuje používané knihovny, případně virtuální stroj pro spuštění aplikace (např. Java, Lua) výstupní
soubory a další parametry. Základem abstrakce přístupu k palubnímu počítači je prostředí
uživatelské aplikace, které představuje soubor nutných podmínek a definic, které umožní
bezchybné spuštění aplikace v systému palubního počítače. Toto prostředí je reprezentované adresářovou strukturou, kterou mohou mít uživatelé ve svých domovských adresářích
na řídicím počítači v několika instancích, jejichž počet je omezen pouze kapacitou jejich
diskového prostoru. Mohou tak mít prostředí pro své aplikace realizující různé úlohy. Přístup k palubnímu počítači je realizován systémovými aplikacemi, které pracují s prostředí
uživatelské aplikace. Základní příkazy této aplikace jsou uvedeny v tabulkách 4.11 a 4.12
odstavce 4.5. V tabulce 5.6 jsou shrnuty všechny základní příkazy této aplikace.
Příkaz
create
upload
download
sync
check
inherit
execute
delete
stop
halt
Popis
Vytvoření prostředí.
Vytvoření kopie prostředí z palubního počítače na řídicí počítač.
Vytvoření kopie prostředí z řídicího počítače na palubní počítač.
Synchronizace dvou prostředí (na řídicím, palubním počítači).
Kontrola prostředí (na řídicím, palubním počítači).
Zahrnutí prostředí, nad lokálními prostředími (adresáři)
Spuštění prostředí (na řídicím, palubním počítači).
Vymazání prostředí na palubním počítači. Prostředí na řídicím počítači lze odstranit prostým smazáním příslušného adresáře.
Ukončení běhu spuštěné aplikace, aplikace zachytí žádost o ukončení
a pokusí se korektně ukončit svoji činnost.
Násilné ukončení běhu aplikace.
74/217
Příkaz
compile?
look
SyRoTek - V003.1
Popis
Kompilace aplikace, pokud jsou zdrojové soubory aplikace součástí
prostředí.
Přístup k jednotlivým částem prostředí, abstrakce na adresářovou
strukturou.
Tabulka 5.6: Příkazy aplikace pro správu prostředí uživatelské aplikace.
Jednotlivé příkazy mají své argumenty, které mohou upravovat chování příkazu, například spuštění aplikace v režimu pro ladění.
Spuštěná aplikace může využívat uživatelské interakce pro změnu svého chování. Tyto
interakce musí být realizovány standardizovaným rozhraním, které je v případě spuštění
aplikace na palubním počítači přesměrováno na uživatelovo pracovní prostředí. Podobně
může aplikace vytvářet záznamy (logy) o své činnosti, které mohou být zobrazovány uživateli v reálném čase, případně ukládány lokálně do datového prostoru palubního počítače.
Obecně tedy mohou jednotlivé vstupy a výstupy uživatelské aplikace být ukládány v rámci
příslušného prostředí aplikace nebo pracovního prostředí uživatele. Definice přesměrování
dílčích vstupů a výstupů je jedním z parametrů spuštění aplikace a může být součástí
prostředí uživatelské aplikace.
Základním prostředím uživatelské aplikace, které bude vždy spouštěno na palubním
počítači souvisí s vlastní abstrakcí přístupu k hardwaru robotu, která je realizována spuštěním instance serveru Player v rámci uživatelského prostředí na palubním počítači. Vedle
této aplikace bude na robotu spuštěna vlastní uživatelská aplikace, která komunikuje se
serverem Player.
S ohledem na paralelní běh více uživatelských aplikací se nabízí otázka podpory řízení
běhu více než jedné aplikace v rámci jediného uživatelského prostředí. Za současného stavu
rozpracovanosti systému SyRoTek je nejvýhodnější ponechat případné další funkcionality
jako rozšíření, které využívá základních příkazů, neboť potenciální nové funkcionality jsou
přímo určené uživatelům a bez jejich zpětné vazby, by mohlo dojít k přílišné komplikovanosti používání nástrojů pro spouštění aplikací.
V tabulce 5.7 jsou shrnuty základní parametry a data, která jsou součástí prostředí
uživatelské aplikace.
Parametr / Data
aplikace
spuštění aplikace
argumenty aplikace
pracovní adresář aplikace
Popis
Binární spustitelný obraz aplikace, příslušný zdrojový kód
skriptovacího jazyka nebo byte-kód.
Definice prostředí pro spuštění aplikace, například definice
verze Java Virtual Machine.
Argumenty se kterými je aplikace spuštěna.
Pracovní adresář, ze kterého je aplikace spuštěna, musí být
v rámci příslušné adresářové struktury prostředí.
75/217
Parametr / Data
proměnné prostředí
vstupy
výstupy
zdrojové soubory
předpis kompilace
úloha
SyRoTek - V003.1
Popis
Proměnné prostředí (shell), ze kterého je aplikace spuštěna.
Požadavek na přesměrování vstupů aplikace.
Požadavek na přesměrování výstupů aplikace.
Nezbytné zdrojové soubory aplikace.
Specifikace jak aplikaci přeložit (zkompilovat), případně sestavit binární obraz (linkovat).
Informace o zadání úlohy a podmínkách odevzdání (definice
výstupů).
Tabulka 5.7: Základní parametry a data v prostředí uživatelské aplikace.
Jednotlivé příkazy mají své argumenty, které mohou upravovat chování příkazu, například spuštění aplikace v režimu pro ladění.
Podpora evaluace úlohy
Jednou z výhod systému pro vzdálené vzdělávání je nezávislost na aktuální dostupnosti
konkrétního učitele. Typickou z rolí učitele je kontrola správnosti úloh řešených uživatelem (studentem). V případě robotické úlohy je řešením příslušné chování robotu, které lze
v mnoha případech reprezentovat vhodným souborem popisující pohyb robotu. Robotické
úlohy zaměřené na zpracování dat jsou typicky implementace algoritmů, které na základě
vstupního souboru dat vytvářejí výstupní data, například výsledkem úlohy explorace je
mapa. Přestože usilovat o plně automatizovanou evaluaci úloh by bylo pošetilé, je vhodné
podpořit uživatelovo snažení o správné řešení včasnou indikací chybného výsledku a učitelovo rozhodnutí o správnosti výsledku vhodným a důvěryhodným uživatelským výstupem.
Včasnou indikaci chyby lze podpořit vhodnými kontrolními body při řešení úlohy, která se
v řadě případů bude skládat z jednotlivých dílčích úloh.
Podpora evaluace úlohy se skládá ze tří částí:
1. definice výstupu a mechanismu kontroly úlohy jako součásti specifikace úlohy,
2. spuštění uživatelské aplikace tak, aby vytvořené výstupní soubory byly důvěryhodné.
3. evaluace vytvořených výstupních datových souborů.
Pro evaluaci úlohy je naprosto nezbytná definice výstupů a také mechanismů kontroly.
Kontrolní mechanismy může rozdělit do dvou základních skupin.
• On-line kontrola uživatelské aplikace.
• Off-line kontrola výstupů uživatelské aplikace.
76/217
Palubní počítač
SyRoTek - V003.1
Uživatelská
aplikace
Uživatelská
aplikace
Player server
Player server
SyRoTek
ovladače
SyRoTek
ovladače
Systémová aplikace
řízení
čtení
robotu
senzorů
Přístupový
modul robotu
Evaluace úlohy
Aplikace
on−line
evaluace
,,monitor’’
Algoritmy
evaluace
Definice
úlohy
uživatelská interakce
Obrázek 5.9: Schematické propojení uživatelských aplikací a evaluačního monitoru.
On-line kontrolu je možné implementovat jako pozorovatele chování uživatelské aplikace,
resp. ovládaného robota/ů. To je možné téměř vždy, kdy je možné z pozice robotu na
ploše arény odvodit správné chování robotu, například cílem úlohy je přesunout robot ze
startovního bodu do cílového. Při evaluaci jsou tedy spuštěny minimálně 3 aplikace:
1. uživatelská instance serveru Player,
2. vlastní uživatelská aplikace řešící příslušnou úlohu,
3. evaluační monitor.
Spuštěné aplikace, pro případ uživatelské aplikace na palubním i řídicím počítači jsou
schematicky zobrazeny na obrázku 5.9. Na obrázku objekt evaluace úlohy obsahuje modul
algoritmů evaluace, který reprezentuje množinu algoritmů, které mohou být použity pro
evaluaci více než jedné úlohy. S rostoucím počtem úloh a jejich různých variant lze očekávat také zvyšující se množství evaluačních aplikací, které však budou typicky složeny
z jednotlivých dílčích algoritmů evaluace.
Podle konkrétních úloh, může být proto vhodné založit aplikace on-line evaluace na
některém vhodném skriptovacím nástroji, který může výrazně snížit časové náklady na
implementaci konkrétního evaluačního monitoru.
Evaluační monitor může běžet v uživatelském prostoru, vytvořená data by však měla
být důvěryhodná. Uživatel, který se nesnaží podvádět, zpravidla ze zadání pochopí co je
77/217
SyRoTek - V003.1
cílem úlohy a pozorováním chování jeho aplikace sám usoudí jestli dosáhl žádaného řešení
nebo nikoliv. Naproti tomu uživatel, který chce úlohu vyřešit podvodem by neměl mít
možnost zasahovat do procesu evaluace.
Při návrhu vhodného mechanismu vytváření důvěryhodných výsledků je vhodné uvážit, jak moc takový mechanismus bude zatěžovat poctivé uživatele, kteří by používání
systému mělo být komplikováno co nejméně. Problém vytváření důvěryhodných výsledků
může být značně komplikovaný, podle míry důvěry uživatelům. Při plánovaném nasazení
systému SyRoTek je riziko podvržených řešení minimální, neboť uživatelé se budou rekrutovat převážně z řad nadšených uživatelů, kteří budou systém používat dobrovolně. Zcela
jiná situace však nastává při nasazení libovolného e-learnigového systému jako nezbytné
součásti výuky, kdy systém musejí používat i studenti, kteří by se jinak uživateli nestali.
V takové komunitě uživatelů je také možné narazit na problém plagiátorství. Pro dosažení vysoké úrovně vzdělávacího procesu e-learnigovým systémem je proto nutné co možná
nejvíce potlačit vliv podvržených výsledků a plagiátorství.
Problém plagiátorství lze částečné potlačit využitím výpočetní techniky pro záznam
postupného řešení úlohy. Dobrým příkladem jsou kurzy programování, na kterých musejí
studenti odevzdat několik samostatně vytvořeních aplikací. Systematické používání verzovacího systému pro uchovávání zdrojových kódů dává učiteli velmi dobrý odhad o práci
studentů. Pokud se v repozitáři najednou objeví zdrojový kód, který chce student odevzdat,
může to být příznak toho, že se studentovi podařilo získat program od někoho jiného. Navíc
je v případě přístupu ke zdrojovým souborům všech uživatelů možné provádět automatická
porovnání zdrojových souborů programu jednotlivých studentů a hledat podobnosti.
Pro vytvoření důvěryhodného výstupu příslušného programu je nutné, aby spouštěný
program příslušel konkrétnímu uživateli a byl spuštěn v prostředí, které nemůže uživatel
ovlivnit. Vhodným řešením je použití verzovacího systému pro zdrojové soubory a prostředí uživatelské aplikace. Pro odevzdání příslušné úlohy (programu) uživatel připraví
příslušné prostředí uživatelské aplikace v repozitáři včetně historie zdrojových kódů, tím je
jednoznačně definován čas vytvoření příslušných souborů. Proces vytváření důvěryhodných
výsledků (dat) je poté následující:
1. Uživatel prostřednictvím systémové aplikace ohlásí, kterou verzi prostředí uživatelské
aplikace z repozitáře chce odevzdat.
2. V rezervovaném čase uživatele pro odevzdání úlohy, dojde ke stáhnutí příslušného
prostředí a kompilaci. Tento proces probíhá v rámci systémového prostoru a uživatel
nemá možnost do něj zasáhnout.
3. Byla-li kompilace úspěšná, dojde k přesunu příslušné aplikace na palubní počítač.
4. Dojde ke spuštění příslušné instance serveru Player na robotu a řídicím počítači.
5. Dojde ke spuštění monitoru, který bude nezávisle ukládat průběh experimentu.
6. Dojde ke spuštění uživatelské aplikace na robotu, případně řídicím počítači.
78/217
SyRoTek - V003.1
7. Uživatelská aplikace skončí svůj běh (uživatel by ve své aplikaci měl poznat, že úkol
splnil) nebo je ukončena časovým limitem na řešení, případně přerušena technickým
problémem.
8. Prostředí uživatelské aplikace jsou zkopírována do uživatelského prostoru a do chráněného prostoru odevzdaných úloh.
9. Je-li možné evaluovat výsledek řešení úlohy je vytvořen příslušný záznam o výsledku.
10. Uživatel je informován o ukončení odevzdávání, případně je informován příslušný
tutor.
Hlavní rozdíl mezi odevzdáním a laděním aplikace je v kroku 10, který není při ladění
proveden.
Z předcházejících odstavců vyplývají vazby na dílčí části systému SyRoTek. Jedná se
především o definici úloh, které kromě vlastního zadání a definice vstupů a výstupů mohou obsahovat algoritmy pro evaluaci úlohy. Druhou významnou vazbou je mechanismus
sběru dat, který musí podporovat přesměrování do různých destinací (uživatelská aplikace,
evaluační monitor).
Podpora vzdáleného vývoje a ladění
Mechanismy vzdáleného vývoje a ladění uživatelské aplikace jsou využity pro palubní
počítač nebo řídicí počítač. Vzhledem k abstrakci přístupu uživatele k palubnímu počítači je vývoj i ladění nutné provádět vzdáleně. Také s ohledem na architekturu použitého
procesu v palubním počítači (ARM) a omezeným výpočetním schopnostem je vhodné realizovat překlad zdrojových souborů takzvaným křížovým překladačem (cross-compiler).
Křížový překlad není nutný v případě vývoje aplikace v některém ze skriptovacích jazyků
(lua, python,ruby) nebo při interpretaci byte-kódu (např. Java).
Vývoj může probíhat z řídicího počítače, kdy je uživatel přihlášen k řídicímu počítači,
na kterém provádí veškerou činnost, jeho uživatelská stanice vystupuje pouze v roli takzvaného tenkého klienta, jehož úkolem je pouze zobrazovat příslušná rozhraní a akceptovat
uživatelské vstupy, které jsou přeposílány aplikacím spuštěným na řídicímu počítači. V této
konfiguraci uživatel využívá mechanismu vzdáleného vývoje a ladění pouze pro aplikaci,
kterou bude spouštět na palubním počítači.
Rozdíl mezi řídicím a palubním počítačem je v architektuře použitého procesoru, x86
nebo amd64 procesor v řídicím počítači a ARM procesor v palubním počítači. Také softwarové vybavení a výpočetní výkon řídicího počítače je větší. Hlavní omezení na vývoj
aplikace pro palubní počítač vychází především z možnosti použití podpůrných knihoven, které nemusejí být pro platformu ARM k dipozici. Je-li aplikace vyvíjena s ohledem
na specifikaci softwarového vybavení palubního počítače a s využitím abstrakce přístupu
k hardware robotu prostřednictvím serveru Player, bude hlavní rozdíl běhu aplikace na
79/217
SyRoTek - V003.1
řídicím a palubním počítači4 především v dopravních zpožděních, které jsou způsobeny
přenosem dat z robotu do řídicího počítače.
Vývoj aplikace přímo z uživatelské stanice může v zásadě nastat z následujících důvodů:
• uživatel není připojen k řídicímu počítači komunikačním kanálem o dostatečné přenosové rychlosti,
• uživateli z nějakého důvodu nevyhovuje práce na vzdálené ploše,
• uživatel nemá potřebné softwarové vybavení pro práci na vzdáleném systému.
Základními softwarovými nástroji pro vývoj aplikace jsou příkazy příkazového interpretru. Nad těmito základními nástroji jsou uživateli poskytována interaktivní rozšíření.
Integrovaným řešení je zahrnutí těchto nástrojů do komplexního vývojové prostředí jakým
je například rozhraní Eclipse [24] nebo Netbeans5 [25], které poskytují podporu několika
programovacích jazyků. Pro systém Player je takovým rozšířením Eclipse Robot IDE Plugin [26].
Hlavní rozdíl mezi spuštěním vývojového prostředí na řídicím počítači a uživatelské
stanici je v realizaci napojení na ostatní části systému SyRoTek. Zde můžeme rozlišit
několik případů použítí vzdáleného vývoje, ty jsou shrnuty v tabulce 5.8
Konfigurace
1.
2.
3.
4.
5.
4
5
Popis
Zdrojové soubory jsou uloženy na uživatelské stanici, po překladu
je aplikace spuštěna na uživatelské stanici a komunikuje se simulátorem spuštěným také na uživatelské stanici. Uživatel přitom (ne
nutně) využívá knihovny a modely systému SyRoTek.
je aplikace spuštěna na uživatelské stanici a komunikuje s řídicím
počítačem, na kterém běží příslušná instance serveru Player.
je aplikace zkopírována na řídicí počítač, kterou uživatel spouští
v rámci svého sezení na řídicím počítači (ssh, x-session).
Zdrojové soubory jsou na řídicím počítači, příslušný adresář je připojen k uživatelské stanici, po překladu aplikaci uživatel spouští
v rámci svého sezení na řídicím počítači (ssh, x-session).
Zdrojové soubory jsou na uživatelské stanici, po překladu aplikaci
uživatel spouští z vývojového prostředí, které zajistí přenos a spuštění aplikace na řídicím počítači.
Softwarové vybavení palubního počítače tvoří podmnožinou softwarového vybavení řídicího počítače.
Verze Netbeans 6.0 již mimo jiné podporuje C/C++.
80/217
Konfigurace
6.
SyRoTek - V003.1
Popis
Zdrojové soubory jsou na uživatelské stanici, po překladu aplikaci
uživatel spouští z vývojového prostředí, které zajistí přenos aplikace
na řídicí počítač a následně palubní počítač, kde je aplikace spuštěna.
Tabulka 5.8: Možnosti použití IDE a jeho propojení se systémem SyRoTek.
Ladění aplikace lze rozdělit na dvě kategorie, ladění krokováním a ladění výpisy. První
kategorie ladění je obzvláště oblíbená u začínajících programátorů, je však efektivní pouze
v případech implementace algoritmů, které nejsou závislé na reálném čase. V závislosti
na typu zdrojového souboru uživatelské aplikace lze využít příslušné nástroje pro konkrétní skriptovací jazyky nebo JVM. V případě jazyka C/C++ je možné použít debugger
gdb [27], který umožňuje krokovat program spuštěný na vzdáleném stroji. K takovému
ladění je však nutné mít instalované příslušné podpůrné knihovny, včetně příslušného křížového překladače. Nutnost podpůrných knihoven spolu s přístupem k palubnímu počítači
pouze z prostoru řídicího počítače je hlavním důvodem, proč bude tato možnost primárně
podporována pouze v rámci uživatelského sezení na řídicím počítači a příslušném palubním
počítači.
V případě konfigurace, při které probíhá vzdálený vývoj přímo z uživatelské stanice a
řídicího počítače, je způsob vzdáleného krokování podmíněn zkušeností uživatele a příslušnou softwarovou výbavou na jeho uživatelské stanici.
Při ladění krokování, kdy aplikace čte reálná data, je v případě pozastavení běhu programu nutné vyřešit také pozastavení příjmu, resp. vysílání dat. V případě SyRoTek ovladačů v serveru Player je to možné provést dálkovým povelem příslušné systémové aplikaci
(přístupový modul robotu) nebo přímo příslušnému ovladači. Této možnosti lze využit
jak při ladění aplikace v rámci uživatelského sezení na řídicím počítači tak z uživatelské
stanice. Schematicky je situace znázorněna na obrázku 5.10.
Podpora vzdáleného ladění výpisy spočívá v přesměrování příslušných výstupů laděné
aplikace na uživatelské rozhraní, které uživatel využívá pro vývoj, ať už se jedná o řídicí
počítač nebo jeho uživatelskou stanici. V případě off-line zpracování výpisů se pak jedná
pouze o přesun příslušných souborů.
Monitorování stavu jednotlivých robotů
Zajištění maximální připravenosti robotických platforem systému SyRoTek je nutné
podpořit neustálým monitorováním a vyhodnocováním jejich stavu. Vzhledem k výše uvedené základní struktuře uživatelského přístupu k hardware je toto monitorování pro uživatele skryto, neboť ten komunikuje s robotem prostřednictvím komunikačního rozhraní
serveru Player.
81/217
Palubní počítač
Uživatelská
aplikace
Uživatelská
aplikace
Player server
Player server
SyRoTek
ovladače
SyRoTek
ovladače
řízení
čtení
robotu
senzorů
Přístupový
modul robotu
SyRoTek - V003.1
Uživatelská stanice
Integrované vývojové
prostředí
SyRoTek IDE
zásuvné moduly
break, step
uživatelská interakce
Obrázek 5.10: Mechanismus vzdáleného krokování aplikace na robotu.
Kritickým okamžikem při řešení uživatelské úlohy je případ, kdy jsou z nějakého důvodu hodnoty sledovaných veličin měřených na robotu příznakem hardwarového selhání.
Pro uživatele to znamená, že dojde k přerušení spuštěné úlohy a pokud je to možné k automatické výměně robotu. Vzhledem k úplné hardwarové výměně robotu je příslušné aktuální
prostředí uživatelské aplikace na palubním počítači přeneseno na alternativní robot. Pokud není náhradní robot k dispozici, je možné pokračovat v řešení úlohy v simulovaném
prostředí, které je nakonfigurováno podle aktuálního stavu arény. V případě, že je pro uživatele provedení reálného experimentu klíčové, je možné registraci uživatelského sezení pro
dokončení experimentu upřednostnit.
Základní rozlišení stavu robotu je uvedeno v tabulce 5.9.
Stav
Připraven
Nabíjení
Výstraha
Kritická výstraha
Popis
Robot je připraven k používání nebo je již aktivně používán. Všechny jeho kritické systémy jsou v provozu schopném stavu.
Všechny kritické systémy robotu jsou funkční, robot je připojen k nabíjecímu systému.
Robot je připraven k používání nebo je již aktivně používán, některý z jeho systémů je mimo běžný provozní stav,
avšak stále je v toleranci pro používání.
Některý z kritických systémů robotu hlásí překročení povolených limitů. Je-li robot používán, je jeho současná činnost
přerušena a robot zajíždí do dokovací stanice.
82/217
Stav
SyRoTek - V003.1
Popis
Některý z kritických systémů robotu hlásí překročení povolených limitů, robot je zadokován, není-li důvodem chyby
nedostatek energie, je informován správce systému a robot
přechází do stavu kritické chyby.
Kritická chyba nastává v případě, že robot není zadokován
a není schopen se dostat do dokovací stanice. Případně je
zadokován, není nabíjen a některý z jeho kritických systémů hlásí překročení povolených limitů . O výskytu kritické chyby je informován správce systému.
Chyba
Kritická chyba
Tabulka 5.9: Základní stavy robotu.
Na obrázku 5.11 jsou zobrazeny základní části systémové aplikace monitorování stavů
robotů. Z každého robotu jsou měřené systémové hodnoty přenášeny do řídicího počítače,
Palubní počítač
řízení
čtení
robotu
senzorů
Přístupový
modul robotu
Monitorování
Hlášení
stavu
Přístupový
modul robotu
Zpracování
záznamů
správce
systému
Algoritmy
zpracování
Palubní počítač
řízení
čtení
robotu
senzorů
Přístupový
modul robotu
Databáze
záznamů
Obrázek 5.11: Modul monitorování stavu robotů.
kde jsou vyčítány aplikací monitorování prostřednictvím přístupového modulu každého
robotu. Aplikace zpracovává příchozí nové hodnoty příslušnými algoritmy pro konkrétní
sledovanou veličinu. O stavu robotů jsou periodicky vytvářeny zprávy, které jsou zasílány
správci (například každý den je zasílán základní stav robotů). Kromě těchto rutinních zpráv
jsou v případě kritického stavu některého robotu generovány zprávy vyšší priority, např.
SMS zprávy.
Z hlediska vývoje, respektive ladění provozu systému může být užitečné zaznamenávat
dodatečné informace v případě některé výjimečné situace. Například je-li některý robot
83/217
Modul / Funkce
Konfigurace
hlášení
chyb / zpráv.
Mechanismy hlášení
chyb / zpráv.
Algoritmy zpracování.
Mezní hodnoty.
Databáze záznamů.
SyRoTek - V003.1
Popis
Definice jaké informace jsou hlášeny. Součástí konfigurace
je komu, kdy, jak jsou informace hlášeny, včetně formátu
samotné zprávy.
Definice rozhraní pro hlášení chyb (SMS, IM, e-mail, www).
Sada základních algoritmů využívaných pro zpracování záznamů.
Předpis mezních hodnot sledovaných veličin.
Zaznamenané hodnoty jsou uchovávány pro dlouhodobé
sledování a vyhodnocování činnosti robotů.
Tabulka 5.10: Základní části a vlastnosti aplikace monitorování robotů.
v kritickém stavu a dochází k návratu robotu do dokovací stanice, je kromě vlastních
sledovaných veličin ukládán záznam reálné scény na ploše arény prostřednictvím vizualizačního modulu systému SyRoTek. Dojde-li k uváznutí robotu při návratu nebo běžné
činnosti, může být pro odhalení příčiny výhodné, mít k dispozici záznam reálné scény několik okamžiků před zjištěním problému. Pořízení takového záznamu však vyžaduje průběžné
ukládání záznamu z vizualizačního systému.
Základní části a vlastnosti aplikace monitorování robotů jsou shrnuty v tabulce 5.10.
Kromě samotného monitorování stavu robotů je vhodné funkčnosti robotů a systémových aplikací rozšířit o testovací rutiny, které provedou ověření vlastního mechanismu měření sledovaných veličin.
5.1.2
Uživatelská aplikace
Uživatelská aplikace tvoří spolu se základními systémovými aplikacemi soubor částí řídicího počítače, se kterými uživatel systému SyRoTek přímo interaguje. Řešení příslušné
úlohy uživatel realizuje vlastní implementací algoritmů v rámci své aplikace, která je následně spuštěna na řídicím, respektive palubním počítači. Aplikace může být realizována
v některém vhodném programovacím jazyku. Volba programovací jazyka je v zásadě omezena pouze jedinou podmínkou, kterou je dostupnost rozhraní pro server Player.
Pro začínající uživatele je kromě podmínky existenci rozhraní pro server Player, také
důležitá podpora programovacího jazyka ze strany provozovatelů systému SyRoTek, resp.
příslušné uživatelské komunity. Bude-li začínající uživatel realizovat aplikaci v některém
jazyku, který není příliš používán při realizaci klientské aplikace serveru Player nebo při
řešení úlohy v systému SyRoTek, vystavuje se riziku, že bude zdlouhavě samostatně řešit
nějaký problém, neboť nebude mít možnost efektivně na řešení problému s někým spolupracovat.
84/217
SyRoTek - V003.1
Uživatelskou aplikaci může uživatel realizovat v zásadě v libovolném programovacím
jazyku, pro který je na řídicím počítači připraveno odpovídající prostředí (kompilátor, virtuální stroj, apod.). V případě spouštění aplikace na palubním počítači, je vhodné dále
omezit programovací jazyk podle prostředí palubního počítače, na který nemusí být technicky možné instalovat požadované softwarové nástroje pro spuštění příslušné aplikace6 .
Z hlediska provozu systému SyRoTek a poskytování podpory uživatelům je vhodné omezit
množinu oficiálně podporovaných programovacích prostředí. V případě vyhraněné skupiny
uživatelů může být podpora jiného programovacího jazyku realizována příslušnou komunitou uživatelů.
Základním podporovaným programovacím jazykem je C resp. C++, který je implementačním jazykem serveru Player. Jazyk C/C++ je také dosud nejpoužívanějším implementačním prostředím v robotické komunitě, což je také patrné z jednotlivých rozšíření systému
Player/Stage. Tento jazyk však nemusí být vhodný pro konkrétní cílovou skupinu uživatelů,
neboť jazyk C není například na FEL ČVUT v Praze vyučován v základním kurzu programování. Z tohoto pohledu je vhodné zahrnout mezi podporované programovací jazyky
také jazyk Java.
Pro začínajícího uživatele systému SyRoTek, který se chce seznámit se základy a principy řízení mobilních robotů, je vhodné věnovat samotné implementaci co nejméně času
a naopak se soustředit na porozumění základním principům. Základní úlohy řízení mobilního robotu a senzorické zpracování jsou z pohledu výpočetní kapacity současných běžných výpočetních prostředků velmi malé. V souvislosti se zjednodušením implementace
je vhodné nabídnout uživatelům, kteří nemají zkušenosti z programováním, některý alternativní skriptovací programovací jazyk, které mají typicky velmi jednoduchou syntax.
Vhodnými skriptovacími jazyky jsou ruby [28], Python [29] a lua [30], který patří mezi
nejrychlejší skriptovací jazyky [31, 32].
5.2
Operační systém řídicího počítače
Systémové i uživatelské aplikace jsou spuštěny v rámci operačního systému řídicího
počítače. Volba vhodného operačního systému musí respektovat tato základní kritéria:
• škálovatelnost,
• spolehlivost a robustnost,
• náklady na údržbu,
• vzdálená práce uživatelů.
6
Obzvláště jazyky vysoké úrovně abstrakce nejsou na platformu arm portované.
85/217
5.2. OPERAČNÍ SYSTÉM ŘÍDICÍHO POČÍTAČE
SyRoTek - V003.1
Škálovatelnost souvisí s počtem uživatelů systému SyRoTek. Ačkoliv dnešní moderní
operační systémy podporují víceuživatelské, víceprocesové prostředí na víceprocesorových
systémech, systémy nevyužívají výpočetní prostředky stejně efektivně. Řídící počítač musí
obsluhovat kritické systémové aplikace i v případě 100% zatížení uživatelskými aplikacemi.
Spolehlivost a robustnost jsou nezbytnými vlastnosti pro serverové nasazení řídicího počítače, ke kterému se přihlašují uživatelé nebo na řídicím počítači dlouhodobě vzdáleně
pracují. Náklady na údržbu zahrnují nejen bezpečnostní aktualizace hlavních přístupových
serverových aplikací, ale také celou řadu podpůrných vývojových softwarových nástrojů,
které jsou instalovány z různých zdrojů.
Zmíněné požadavky splňují velmi drahé specializované serverové systémy, na které však
zpravidla nejsou portovány potřebné vývojové softwarové nástroje. Proto jsou vhodnými
kandidáty operační systémy řady BSD nebo operační systémy s jádrem Linux. Z hlediska
softwarové podpory je z řady BSD systému nejvhodnějším kandidátem operační systém
FreeBSD [33]. Co se týče operačních systémů s jádrem Linux jsou zásadní rozdíly mezi jednotlivými distribucemi operačního systému především v systému konfigurace, umístěním
příslušných konfiguračních souborů a pojmenováním konfiguračních nástrojů. Volbu konkrétního operačního systému řídicího počítače je proto vhodné učinit podle zkušeností a
znalostí konkrétního operačního systému správci řídicího počítače systému SyRoTek, kteří
jsou zodpovědní za bezproblémový provoz systému a jeho funkci.
V následující části tohoto oddílu jsou uvedeny tabulky s předpokládanými hlavními
funkcemi operačního systému, tabulka 5.11 a potřebnými vývojovými nástroji pro vývoj
systémových a uživatelských aplikací, tabulka 5.12.
Funkce
LDAP
SSH
XDMCP
SMP
QUOTA
POSIX
ACL
Popis
Propojení autentizace a autorizace s LDAP databází.
Terminálové vzdálené sezení.
Grafické vzdálené sezení.
Podpora více-jádrových procesorů a více-procesorových výpočetních systému.
Podpora uživatelských limitů diskového prostoru.
Kompatibilita s běžnými POSIX standardy (1003, 1e).
Přístup k souborovému systému s technologií Access Control List.
Tabulka 5.11: Předpokládané hlavní funkce/vlastnosti operačního systému řídicího počítače systému SyRoTek.
Některé softwarové nástroje jsou v tabulce uvedeny s údajem o předpokládané verzi,
která může být v době realizace řídicího počítače vyšší, pokud to bude vhodné. Z důvodů
kompatibility je někdy vhodné používat již odzkoušené starší verze knihoven, neboť nejnovější knihovny nebo softwarové nástroje mohou mít skryté, dosud neodladěné, vlastnosti,
86/217
SyRoTek - V003.1
které se mohou projevit při kombinaci s některou z nových (starých) knihoven.
Software
gcc
java
Player
boost
opencv
gmake
scons
cgal
gsl
gaul
libxml
expat
ruby
python
eclipse
netbeans
vim
gdb
svn
Popis
Kompilátor C a C++, pravděpodobně verze 4.2.x nebo
vyšší.
Java kompilátor a virtuální stroj, verze 1.5 nebo vyšší.
Player server verze 2.x nebo vyšší.
Sada knihoven pro C++, verze 1.34 nebo vyšší.
Open Source Computer Vision Library from Intel, verze 1.x
nebo vyšší.
GNU verze nástroje pro sestavování programů, verze 3.81.
Alternativní program k programu make verze 0.97 nebo
vyšší.
C++ knihovna pro geometrické výpočty, verze 3.3.1 nebo
vyšší.
Matematická knihovna pro numerické výpočty, verze 1.1
nebo vyšší.
Knihovna pro podporu implementace genetických algoritmů.
Knihovna pro podporu práce s XML.
Knihovna pro podporu práce s XML.
Interpret jazyka ruby, verze 1.8 nebo vyšší.
Interpret jazyka python, verze 2.5 nebo vyšší.
Integrované vývojové prostředí.
Integrované vývojové prostředí.
Oblíbený textový editor.
Ladící nástroj GDB.
Nástroj pro správu verzí zdrojových souborů, Subversion
verze 1.4 nebo vyšší.
Tabulka 5.12: Softwarové nástroje pro vývoj systémových a uživatelských aplikací pro
řídicí počítač systému SyRoTek.
87/217
SyRoTek - V003.1
Kapitola 6
Roboty a senzory
Objekt roboty a senzory reprezentuje vlastní robotické platformy systému SyRoTek
včetně příslušných senzorů. Z pohledu přístupu uživatele představuje robot palubní počítač, na kterém spouští svou uživatelskou aplikaci. Ve zprávě [2] je uvedena základní
architektura palubního počítače, propojení a návaznosti na jednotlivé hardwarové periferie robotu. Vlastní softwarová architektura palubního počítače je z hlediska uživatelské
aplikace velmi podobná architektuře řídicího počítače. Proto jsou v této kapitoly popsány
základní funkční rozdíly, které souvisí především s abstrakcí přístupu uživatele na palubní
počítač, neboť přímý přístup běžného uživatele do prostoru operačního systému palubního
počítače není povolen.
Vlastní softwarové koncepci palubního počítače je věnován oddíl 6.1. Následující oddíly
jsou věnovány popisu propojení jednotlivých mikroprocesorů (MCU), které slouží k ovládání robotické platformy a sběru dat ze senzorů. V závěru této kapitoly jsou uvedeny
poznámky k implementaci dílčích softwarových částí palubního počítače a příslušných řídicích programů jednotlivých MCU.
6.1
Softwarová koncepce palubního počítače
Základní vymezení prostoru pro uživatelské a systémové aplikace v rámci operačního
systému palubního počítače je identické s prostorem na řídicím počítači. Na palubním počítači jsou spuštěny systémové aplikace realizující vlastní komunikaci s hardwarem robotu
a komunikaci s řídicím počítačem. V uživatelské části je spuštěn server Player, ke kterému
se připojuje vlastní uživatelská aplikace, obrázek 6.1.
Hlavní rozdíl v uživatelském prostoru řídicího a palubního počítače je však v identifikaci
uživatele. Na palubním počítači je reprezentován univerzálním uživatelským účtem a to
především z důvodu možných výpadků síťového připojení k autentizačnímu / autorizačnímu serveru. Celá řada systémových volání vyžaduje přístup k serveru i během uživatelského sezení, v při výpadku by v takovém případě systémové aplikace vyvolaly snahu
88/217
KAPITOLA 6. ROBOTY A SENZORY
SyRoTek - V003.1
o připojení a pozastavily svou činnost do doby navázání spojení se serverem nebo uplynutí
časového limitu. Výhodou nezávislosti na autentizačním / autorizačním serveru je také
možnost přístupu k robotu i mimo vlastní systém SyRoTek, což může být zvláště vhodné
v počátečních fázích realizace projektu SyRoTek, kdy nejsou všechny potřebné funkcionality systému dosud implementovány. Během provozu systému SyRoTek může být také
robot velmi snadno laděn mimo vlastní systém a po odladění není nutné žádné speciální
konfigurace operačního systému pro začlenění robotu zpět do systému SyRoTek.
Na obrázku 6.1 je vyznačeno propojení uživatelské aplikace s jednotlivými hlavními
částmi systémových aplikací. V rámci uživatelského prostoru je spuštěna vlastní uživatelská aplikace, která přistupuje k hardware robotu prostřednictvím instance serveru Player
Server Player je spuštěn s příslušnou konfigurací, dle řešené úlohy. Přístup k samotnému
hardware robotu je realizován SyRoTek moduly a ovladači, které komunikují s přístupovým
modulem robotu.
Servisni rozhraní
Ethernet
Komunikace s
řídicím
počítačem
Console
Modul
řízení
spotřeby
čtení senzorů
řízení robotu
Komunikace s
HW platformou
robotu
WiFI
konfigurace aktuálního
uživatelského sezení
cMCU
RF
obsluha uživatelské
interakce
senzorická
sběrnice
Player server
moduly
ovladače
SyRoTek
moduly
ovladače
uživatelská
aplikace
Obrázek 6.1: Přístupu uživatelské aplikace ke komunikačním rozhraním palubního počítače.
Hlavní funkcí přístupového modulu robotu je řízení přístupu k hardwarovým rozhraním
vlastní robotické platformy, neboť kromě přístupu k hardware samotné uživatelské aplikace,
89/217
6.2. MIKROKONTROLÉRY ROBOTU
SyRoTek - V003.1
dochází k systémové komunikaci mezi hardwarovou platformou, palubním počítačem a
řídicím počítačem. Systémová komunikace souvisí s monitorování stavu robotu, případně
s evaluací řešené úlohy.
Dle aktuální konfigurace uživatelského sezení, která souvisí s konkrétní řešenou úlohou,
je uživateli umožněn přístup k vybraným senzorům. Příslušné SyRoTek ovladače získávají
data ze senzorů pouze tehdy, jsou-li tyto senzory součástí konfigurace uživatelského sezení.
Konkrétní uživatel nemá přímý přístup k palubnímu počítači, proto jsou jeho požadavky na spuštění konkrétní instance serveru Player, případně jeho uživatelské aplikace,
zprostředkovávány samostatnou aplikací, která je na obrázku 6.1 reprezentována modulem obsluha uživatelské aplikace. Tato aplikace realizuje příkazy pro práci s prostředím
uživatelské aplikace, které jsou uvedené v tabulce 5.6.
Nedílnou součástí přístupového modulu je komunikace s řídicím počítačem prostřednictvím dedikovaného rádiového spojení, v obrázku označeno RF. Toto spojení slouží především pro přenos dat z lokalizačního systému systému SyRoTek, neboť jeho hlavní výhodou
je vyšší stabilita dopravního zpoždění, než je tomu u komunikace po rozhraní WiFi. Další
použití tohoto rozhraní je pro monitorovací a servisní účely. Vzhledem k mnohem nižší
energetické náročnosti komunikace tímto rozhraním je toto rozhraní využíváno v úsporných režimech řízení spotřeby. Řízení spotřeby je popsáno v oddíle 6.3.
Palubního počítač je propojen s vlastní robotickou platformou prostřednictví dvou rozhraní. Spojení s hlavním řídicím procesorem robotu (cMCU), je realizováno dedikovaným
komunikačním kanálem. Ostatní procesory a inteligentní senzory jsou připojeny k palubními počítači prostřednictvím senzorické sběrnice, viz [2].
Další rozhraní, které slouží především k servisním účelům je dedikované rozhraní RS232
pro připojení terminálu (Konzole), Komunikační rozhraní Ethernet je využito při ladění,
instalaci a konfiguraci operačního systému palubního počítače.
6.2
Mikrokontroléry robotu
Robotická platforma je kromě palubního počítače (OBC) také vybavena následujícími
mikrokontroléry (MCU):
• hlavní řídicí procesor (cMCU),
• procesor řízení napájení (power MCU),
• procesor komunikace RF (RF MCU),
• inteligentní senzory připojené k senzorické sběrnici.
Základní připojení těchto procesorů je zobrazena na obrázku 6.2.
90/217
RF MCU
SyRoTek - V003.1
OBC
RS232
cMCU
RS232
senzorická
sběrnice
Inteligentní
senzor
Inteligentní
Power MCU
senzor
Obrázek 6.2: Základní připojení mikrokontrolérů robotu k OBC.
S ohledem na minimalizaci nákladů při vývoji a realizaci jednotlivých mikrokontrolérů
je vhodné definovat společný komunikační protokol, který slouží pro unifikovanou komunikaci všech MCU připojených k robotu. Základní koncept tohoto protokolu je popsán
v dokumentu [34]. Tento protokol respektuje jednosměrný režim komunikace na sběrnici
I2 C. Navazujícím dokumentem koncepce komunikačního protokolu bude jeho plná specifikace.
Připojení OBC k senzorické sběrnici je na obrázku 6.2 realizováno prostřednictvím rozhraní I2 C. Toto rozhraní však nemusí být na OBC plně přístupné, současná implementace
ovladače tohoto rozhraní je v operačním systému Linux realizována pouze pro režim Master. Režim, při kterém inteligentní senzor připojený k I2 C rozhraní automaticky zasílá
zprávu s naměřenými daty, není v takového případě možný, neboť vyžaduje, aby OBC byl
v režimu Slave.
Z hlediska vývojového procesu jednotlivých inteligentních senzorů je vhodné podpořit
vývoj také běžnými výpočetními prostředky, které typicky nejsou vybaveny rozhraním I2 C.
Proto je výhodné implementovat překladový modul bridge, který je vybaven běžným rozhraním UART a rozhraním kompatibilním se senzorickou sběrnicí. Realizace tohoto modulu
navíc umožňuje efektivně využít rozhraní OBC pro připojení dílčích MCU komunikačním
kanálem o vhodné přenosové kapacitě, která závisí na typu konkrétních přenášených dat.
Robotická platforma systému SyRoTek je vybavena řadou senzorů. Tyto senzory lze
rozdělit na dvě kategorie: základní senzory a rozšiřující senzory. Hlavním kritériem pro
toto rozdělení je připojení, resp. umístění těchto senzorů. Základní senzory jsou nedílnou
součásti konstrukce robotu a je jimi vybaven každý robot. Tyto senzory tvoří nezbytnou
množinu senzorů pro bezpečný autonomní pohyb robotu pro ploše arény. Jelikož je každý
robot vybaven mikrokontrolérem pro řízení motorů (cMCU) jsou tyto senzory připojeny
přímo k tomuto mikrokontroléru. Řídící program cMCU využívá jednotlivých senzorů nejen
pro základní řízení pohybu robotu, ale také pro detekci překážek. V případě zapojení
robotu do systému SyRoTek je možné pro bezpečné řízení využít informace z globálního
lokalizačního systému. Informace o absolutní pozici robotu na ploše arény je předávána
z řídicího počítače do palubního počítače a následně do cMCU. Podobně jsou senzorická
91/217
SyRoTek - V003.1
OBC
RF MCU
cMCU
Bridge
senzorická
/ I 2C
sběrnice
senzorická
sběrnice
Inteligentní
senzor
Inteligentní
senzor
Power MCU
motory,
enkodéry
základní senzory
Inteligentní
senzor
senzor
rozšiřující senzory
Obrázek 6.3: Propojení jednotlivých MCU a senzorů na robotické platformě systému SyRoTek.
měření ze základních senzorů předávána z cMCU palubnímu počítači a následně řídicímu
počítači, na kterému může běžet uživatelská aplikace, která řídí pohyb robotu. Z těchto
důvodů je komunikace mezi OBC a cMCU intenzivní a je vhodné realizovat propojení OBC
a cMCU samostatným rozhraní, tak jak je zobrazeno na obrázku 6.2.
Druhou skupinou senzorů robotické platformy SyRoTek jsou rozšiřující senzory, které
mohou být na robotu umístěny v závislosti konkrétní řešené úloze. Tyto senzory se připojují k senzorické sběrnici jako takzvané inteligentní senzory, které komunikují unifikovaným způsobem. Alternativně mohou být senzory připojeny jiným rozhraním. Například
prostřednictvím USB rozhraním při vyšší požadavcích na přenosové rychlosti.
Obrázek 6.3 schematicky zobrazuje základní propojení jednotlivých MCU a senzorů na
robotické platformě systému SyRoTek.
6.2.1
Unifikace přístupu k MCU
Vzhledem k počtu jednotlivých MCU, případně možných inteligentních senzorů, je
vhodné unifikovat přístup, respektive popis funkcionality jednotlivých MCU. Jednotný
komunikační protokol je základem snadné spolupráce jednotlivých MCU, definuje však
pouze mechanismus přenosu vlastní zpráv (dat). V konceptu komunikačního protokolu [34]
jsou data přenášena v zásadě dvěma mechanismy: vyčítáním hodnot registrů a přenosem
92/217
SyRoTek - V003.1
datových zpráv. Tento transportní mechanismus je vhodné doplnit o specifikaci významu
jednotlivých registrů a specifikaci datových zpráv pro přenos konkrétních typů senzorických dat. Praktický význam těchto specifikací je především v jednotném návrh zpracování
dílčích zpráv, jehož důsledkem je jednodušší implementace, kterou je mnohem snazší ladit
a dále rozšiřovat. Z hlediska dlouhodobého užívání systému SyRoTek bude případné rozšíření senzorického vybavení spočívat především v realizaci rozhraní senzorické sběrnice.
Je-li charakter dat stejný (např. dálkoměrné senzory) je takový senzor možné pouze připojit k robotické platformě a využít již realizovaných transportních mechanismu a aplikací.
Neméně zanedbatelný přínos v unifikaci MCU a přístupu k nim je kromě vlastního vývojové
procesu, také v ladění a monitorování jejich funkce za provozu systému (údržbě systému).
Unifikace přístupu k jednotlivým MCU vede zpočátku na časově náročnější proces specifikace, avšak vlastní implementační fázi lze očekávat mnohem méně časově náročnější než
pří ad-hoc přístupu. Doporučený postup realizace unifikace je uveden v tabulce 6.1.
Krok
1
2
3
4
5
6
7
8
9
Popis
Specifikace transportního komunikačního protokolu.
Definice rozhraní registrů s obecným významem.
Specifikace hodnot registrů s obecným významem.
Klasifikace MCU do tříd inteligentních senzorů.
Definice mechanismu vyčítání jednotlivých senzorů (také těch, které inteligentní senzor zapouzdřuje).
Specifikace datových formátů jednotlivých kategorií dat.
Specifikace registrů pro řízení vyčítání dat ze senzorů (a jejich možných
hodnot).
Implementace obecných komunikačních vrstev.
Implementace firmware konkrétních MCU.
Tabulka 6.1: Dílčí kroky realizace unifikace přístupu k MCU robotické platformy.
Implementace řídicího software každého mikrokontroléru není jediným potřebným softwarem pro realizaci vyčítání senzorů a řízení robotu. Mezi nezbytné softwarové implementace patří realizace příslušných komunikačních protokolů v palubním počítači, který
reprezentuje nadřazený počítač v rámci hierarchie jednotlivých MCU. Palubní počítač tak
slouží jako prostor pro ukládání data a další zpracování, případně přeposílání dat uživatelské aplikaci, resp. řídicímu počítači.
Z hlediska přenosu dat z jednotlivých MCU, palubnímu a následně řídicímu počítači
jsou možné dvě přenosové cesty. První je přenos dat do palubního počítače, kde jsou data
převedena v rámci přístupového modulu robotu a předána příslušným SyRoTek ovladačům
serveru Player, odkud jsou vyčítána uživatelskou aplikací spuštěnou na palubním nebo
řídicím počítači.
Druhá přenosová cesta je realizována nezávisle na protokolu serveru Player. Data z příČVUT FEL, Gerstner Laboratory, ProTyS a.s.
93/217
SyRoTek - V003.1
stupového modulu robotu na palubním počítači jsou přenesena prostřednictvím RF spojení
nebo WiFi spojení do přístupového modulu robotu, který je spuštěn na řídicím počítači.
Data, která mají servisní a monitorovací charakter (jako jsou například chybová hlášení), jsou přenášena RF spojením. Ostatní data pak prostřednictvím lokální WiFi sítě.
Ačkoliv lze pro přenos typických senzorických dat využít protokolů serveru Player, vzhledem k propojení systémových aplikací, jejichž data nejsou přímo přístupné uživateli, je
vhodné realizovat přenos efektivnější mechanismem než je protokol zpráv serveru Player,
který musí respektovat zpětnou kompatibilitu.
Přenos dat mezi palubním a řídicím počítačem lze založit přímo na přenosu zpráv vycházející z komunikace mezi jednotlivými MCU. S výhodou lze také využít stejného mechanismu přenosu mezi přístupovým modulem robotu a SyRoTek ovladači serveru Player
jako při přenosu mezi jednotlivými přístupovými moduly robotu na palubním a řídicím
počítači. Alternativní implementace může vycházet z použití vhodného middleware, který
však musí být přeložitelný jak pro řídicí počítač, tak pro platformu palubního počítače.
Použití vhodného middleware softwaru také musí respektovat komunikační rozhraní RF,
nedosahuje přenosové rychlosti řádu jednotek kb za sekundu.
Vytvoření příslušného firmware MCU ze zdrojových kódů vyžaduje příslušný kompilátor, který je v těchto případech vždy křížovým kompilátorem. S každým novým typem
MCU je také zpravidla nutné vytvořit příslušné vývojové prostředí, které musí být instalované na příslušné vývojářské stanici. S ohledem na údržbu systému SyRoTek je vhodné
kompletní vývojové prostředí, pro vývoj všech softwarových komponent systému SyRoTek
realizovat na dedikovaném počítači. Přirozenou volbou je v systému SyRoTek řídicí počítač. V tabulce 6.2 jsou uvedeny předpokládané kompilační prostředí. Použité kompilátory
jsou příslušnými derivaci GCC kompilátorů pro konkrétní cílovou platformy, resp. křížový
překlad.
Název
gcc-arm
gcc-avr
gcc-coff
gcc (FreeBSD)
gcc (Linux)
Popis
Křížový překladač pro kompilaci zdrojových souborů pro palubní
počítač.
Křížový překladač pro kompilaci zdrojových souborů pro MCU s mikrokontroléry Atmel.
Křížový překladač pro kompilaci zdrojových souborů pro cMCU,
platforma H8S.
Překladač pro platformu FreeBSD.
Překladač pro platformu Linux.
Tabulka 6.2: Předpokládané kompilátory pro vývoj software robotu.
V tabulce jsou pro úplnost také uvedeny kompilátory pro řídicí počítač, neboť příslušné
komunikační knihovny využívají stejných zdrojových kódů.
94/217
SyRoTek - V003.1
Implementace firmware mikrokontroléru
Řídící software jednotlivých MCU je zpravidla tvořen relativně malým programem, neboť mikrokontroléry jsou typicky vybaveny pamětí pro uložení programu v řádu desítek
nebo stovek kB. Realizace software pro MCU je však obtížnější z hlediska konkretizace programu pro cílový mikrokontrolér, neboť v řadě případu je program závislý na konkrétních
registrech periférií, které nemusí být na všech variantách MCU stejné řady stejné, mnohdy
je program závislý na konkrétní hodnotě použitého oscilátoru, který definuje rychlost procesoru. Z těchto důvodů je vhodné omezit počet různých typů MCU, které jsou na robotu
použity a definovat vývojové prostředí, které respektuje kompilaci téhož programu pro
různé konkrétní typy MCU.
Dalším neméně důležitým specifikem vývoje software pro mikrokontroléry je aktualizace programu, která typicky vyžaduje přeprogramování FLASH paměti prostřednictvím
dedikovaného rozhraní. Současné MCU již podporují takzvaný BootLoader režim již od
nejjednodušších typů. Výhodou tohoto režimu je umístění velmi krátkého programu na
vyhrazené místo v programové paměti. Tento program je při startu spuštěn a slouží pro aktualizaci nového hlavního programu. Tímto mechanismem lze aktualizovat firmware MCU,
které jsou již připojeny k senzorické sběrnici, případně jinému rozhraní. Pro plné využití
tohoto mechanismu je vhodné příslušné rozhraní, kterým je MCU připojen k OBC doplnit
o signál reset MCU a signál pro aktivaci BootLoader režimu, kterými je možné příslušný
MCU uvést do režimu BootLoader a provést aktualizaci firmware na dálku prostřednictvím
vzdáleného připojení k palubnímu počítači.
V tabulce 6.3 jsou shrnuty dílčí kroky pro definici vývojového prostředí a implementaci
softwarového vybavení jednotlivých MCU robotické platformy systému SyRoTek.
Krok
1
2
3
4
5
6
Popis
Definice a konfigurace vhodného vývojového prostředí pro implementaci
software všech MCU použitých na robotické platformě systému SyRoTek.
Definice (jednotného) způsobu aktualizace firmware příslušného MCU.
Definice mechanismu uvedení MCU do režimu BootLoader, pro každé
konkrétní rozhraní OBC, ke kterému mohou být MCU připojeny.
Implementace podpůrné aplikace pro OBC, která uvede příslušný MCU
do režimu BootLoader.
Implementace BootLoader programu pro dílčí MCU.
Realizace aplikace (firmware) pro příslušné MCU, s využitím režimu BootLoader.
Tabulka 6.3: Dílčí kroky realizace software MCU robotické platformy.
95/217
6.3. ŘÍZENÍ SPOTŘEBY
6.3
SyRoTek - V003.1
Řízení spotřeby
Mobilní robot je vybaven akumulátory o kapacitě umožňující několika hodinový nepřetržitý provoz. Lze předpokládat, že robot má nejvyšší spotřebu při pohybu, neboť jsou
zapnuty pohony a pokud je řízení robotu realizováno vnímáním okolního prostředí robotu
senzory a zpracováním dat, jsou aktivovány všechny části robotického systému. Tento stav
je však podmíněn bezchybnou funkcí příslušné uživatelské aplikace. Při vývoji aplikace
uživateli, kteří se s robotickým systém teprve seznamují, lze však spíše předpokládat, že
aplikace nebudou bezchybně odladěné. Typický scénář nejspíše bude časově krátký pohyb
robotu s následným pádem uživatelské aplikace z důvodu nějaké chyby. Robot tedy bude
umístěn na ploše arény, avšak uživatel bude řešit problém selhání jeho aplikace. V těchto
případech lze s výhodou výrazně snížit spotřebu vlastního robotu, neboť motory nemusejí
být v takové situaci aktivovány, podobně jako palubní počítač může přejít do režimu snížení
spotřeby. Rozdíl aktuálního odběru tak může být několikanásobný.
V tabulce 6.4 jsou uvedeny dílčí periferie robotu, u kterých je předpoklad výrazného
snížení příkonu, je-li aktivován úsporný režimu provozu nebo jsou-li plně odpojeny od
napájení.
Periférie
WiFi
PXA270
Motory
Senzory
MCU
Popis
Při plné komunikaci je spotřeba srovnatelná s příkonem hlavního procesoru palubního počítače.
Hlavní procesor palubního počítače při nečinnosti může dynamicky snížit
frekvenci a tím výrazně snížit spotřebu.
Vzhledem k charakteru řízení motoru PWM signálem mají motory nenulový odběr pokud jsou blokovány. Nepohybuje-li se robot, ani není
možné, že by byl robot vystaven nežádoucímu pohybu (například nárazem jiného robotu) mohou být motory plně deaktivovány.
Není-li spuštěna uživatelská aplikace, která by zpracovávala vyčítané
hodnoty měřených dat, může být toto měření pozastaveno.
Neaktivní MCU mohou přecházet do úsporného režimu, který je ukončen přerušením například příchozí komunikací. Neefektivní implementace často bývá realizována jako prázdné čekaní ve smyčce, které však
plně zatěžuje procesor. V úsporném režimu, mají moderní mikrokontroléry spotřebu zanedbatelnou v porovnání s režimem plného výpočetního
výkonu. Například MCU řady ATmega mají spotřebu řádu desítek až
stovek µA. Na druhou stranu je však nutné respektovat například vliv
úsporných režimu na přesnost vyčítání A/D převodníku
Tabulka 6.4: Periférie robotu a režimy sníženého příkonu.
96/217
6.4
SyRoTek - V003.1
Charakteristiky a servisní procedury robotu
Z hlediska údržby každého dílčího robotu je vhodné udržovat profil každého robotu,
který obsahuje informace o jeho konkrétních částech. Nejpatrnější je z tohoto pohledu stav
akumulátoru každého robotu, neboť ten se mění v závislosti na tom, jak je robot používán. Akumulátory svým používání mění své vlastnosti, což vedena na jiné charakteristiky
závislosti aktuální kapacity na napětí akumulátoru. Jelikož je přesný odhad kapacity akumulátoru klíčový pro plánovanou operační dobu provozu robotu, která by měla být pokud
možno vždy co možná nejdelší, je nutné převodní charakteristiku pro odhad kapacity akumulátoru v průběhu provozu robotu aktualizovat. Toho lze dosáhnout plný nabíjecím a
vybíjecím cyklem, případně sledováním odhadu aktuální spotřeby robotu.
Akumulátor robotu je složen z několik samostatných článků, které jsou zapojeny v sériové kombinaci pro dosažení potřebného palubního napětí. Vlastnosti akumulátoru jako
celku jsou tak ovlivněny jednotlivými články. Z měření průběhu napětí při nabíjení, resp.
vybíjení, dílčích článků lze odhadnout stav jednotlivých akumulátorů. V případě poškození
jediného článku je nutné vyměnit celý akumulátorový balíček robotu a provést příslušnou
kalibraci měření kapacity akumulátoru. Dle charakteru poškození, lze vyjmutý balíček repasovat výměnou příslušného článků a tím snížit náklady na provoz systému a ekologickou
likvidaci poškozeného akumulátoru.
V průběhu provozu systému může také dojít k poruše některé elektronické části, jejíž
oprava bude provedena nahrazení poškozené části kompatibilním prvek, který však může
vyžadovat drobné modifikace firmware příslušného MCU. V takových případech je naprosto
nezbytné dokumentování a identifikace příslušné modifikované verze.
Příslušný servisní zásah by měl trvat co nejkratší dobu, proto je vhodné realizovat
podpůrné servisní procedury, které jsou snadno spustitelné a pokud možno automatické.
Servisní procedury lze s výhodou použít již při sestavování robotu a jeho testování před
uvedením do plnohodnotného provozu. Správná konfigurace robotu a jeho palubního počítače je nezbytná, neboť případná chyba vyžadující lidský zásah, nemůže být řešena na dálku
a vyžaduje fyzický přístup správce systému k aréně systému SyRoTek. Roboty v systému
SyRoTek je vhodné identicky konfigurovat, aby bylo možné využít jiný robot v případě
poruchy. Příslušné změny konkrétního robotu je proto vhodné provádět systematicky tak,
aby bylo možné změnu replikovat na jiný robot.
Během provozu systému SyRoTek může dojít k aktualizaci některé softwarové knihovny
palubního počítače, před provedením aktualizace na všech robotech je vhodné novou verzi
nejdříve otestovat. V takové případě může být nový software instalovaný na konkrétním robotu, který je v důsledku odlišně konfigurovaný, proto je nezbytné vést o této konfiguraci
dokumentaci. Tyto testy je možné provádět mimo veřejně přístupnou část systému SyRoTek, avšak uživatelské aplikace mohou využít části, které nejsou pokryty prováděnými
testy. Na nové verze software by měli být příslušní uživatelé upozorněni a v případě problému při běhu jejich aplikace, mohou takový problém ohlásit, případně požádat o výměnu
robotu s původním software. Toto testování za běhu vyžaduje informace o příslušných
97/217
6.4. CHARAKTERISTIKY A SERVISNÍ PROCEDURY ROBOTU
SyRoTek - V003.1
verzích instalovaných softwarových části pro každý robot.
V tabulce 6.5 jsou shrnuty informace, které jsou součásti profilu robotu.
Název
Senzory
Firmware
OS
Libs
Aku
History
Popis
Aktuální konfigurace senzorů, které jsou k robotu připojeny. Seznam
senzorů může být použit pro testy funkčnosti / přítomnosti senzorů.
Verze firmware jednotlivých MCU, každá konkrétní verze je vztažena
k seznamu vlastností (případně chyb), které mohou být použity při
ladění nebo plánování servisních úkonů.
Verze operačního systému definuje množinu použitelného software.
Verze příslušných knihoven definují kompatibilitu uživatelské aplikace.
Informace o aktuálním stavu akumulátoru jsou specifické pro každý
akumulátor a způsob jeho používání.
Informace o stáří jednotlivých komponent lze využit při analýze jejich
životnosti (např. pneumatiky) a plánování servisních úkonů.
Tabulka 6.5: Základní informace profilu každého robotu.
Tabulka 6.6 obsahuje základní testovací a servisní procedury robotu.
Název
Instalace OS
Instalace Libs
Test aplikace
Firmware upgrade
Aku test
Senzor test
Senzor module
Aku
Senzor
HW
Pneu
výměna
výměna
výměna
výměna
RF test
WiFi test
App test
Popis
Instalace operačního systému palubního počítače.
Instalace nezbytných knihoven pro běh uživatelských aplikaci.
Ověření funkčnosti prostředí uživatelské aplikace.
Procedura ověření a aktualizace firmware každého dílčího MCU
připojeného k palubnímu počítači.
Provedení úplného nabití, vybití akumulátoru, kalibrace převodní charakteristiky napětí na kapacitu akumulátoru.
Test ověření propojení senzoru a palubního počítače, ověření
správné činnosti senzoru (kalibrační charakteristiky).
Montáž / demontáž rozšiřujícího senzoru, test funkčnosti připojení senzoru.
Procedura výměny akumulátoru.
Procedura výměny základního senzoru.
Postup při výměně a ověření činnosti dílčí hardwarové části.
Postup při výměně pneumatik.
Ověření rádiové komunikace.
Ověření komunikace po WiFi, test správné konfigurace v rámci
sytému SyRoTek.
Ověření správné funkce příkazů pro práci s prostředím uživatelské aplikace.
98/217
Název
Bin test
SyRoTek - V003.1
Popis
Postup pro ověření správné funkce křížového překladače.
Tabulka 6.6: Základní testovací a servisní procedury pro ověření činnosti a konfiguraci
robotu .
99/217
SyRoTek - V003.1
Kapitola 7
Uživatelská stanice
Uživatelská stanice tvoří základní rozhraní uživatele se systémem SyRoTek. Zpráva [1]
definuje čtyři základní objekty uživatelské stanice:
• webové rozhraní (prohlížeč),
• vizualizační rozhraní (aplikace),
• vývojové nástroje,
• podpůrné vývojové nástroje.
Tyto základní objekty přímo souvisí s ostatními částmi systému SyRoTek z uživatelského
pohledu na tyto části. Tento pohled musí respektovat nároky na uživatelskou stanici a
s tím související kompatibilitu jednotlivých softwarových komponent systému SyRoTek.
Vzhledem ke vzdálenému přístupu uživatele k systému SyRoTek je většina části objektu
uživatelské stanice součástí Internetového přístupu k systému SyRoTek, jehož návrh je náplní cíle V007 Návrh koncepce internetového přístupu k systému. V této kapitole jsou proto
popsány pouze ty části objektu uživatelské stanice, které bezprostředně souvisí s řídicím
počítačem. Pouze okrajově jsou popsány části, které jsou závislé na konkrétní realizaci
Internetového přístupu a to převážně požadavky na vybavení uživatelské stanice.
7.1
Webové rozhraní
Webové rozhraní tvoří přirozenou vstupní bránu k systému vzdáleného vzdělávání, neboť
služba WWW stránek je dnes chápána jako synonymum k sítí Internet. Také proto lze
předpokládat instalovaný webový prohlížeč na uživatelské stanici, která je připojena k sítí
Internet. Současný trend směřuje k opravdové standardizaci webových stránek a prohlížečů
tak, aby byly stránky pokud možno zobrazovány korektně. V souvislosti s uživatelskou
100/217
KAPITOLA 7. UŽIVATELSKÁ STANICE
SyRoTek - V003.1
stanicí je nutné specifikovat požadavky na hardwarové a softwarové vybavení počítače,
který bude sloužit jako uživatelská stanice pro webový přístup k systému SyRoTek.
Mezi základní hardwarové požadavky patří základní rozlišení zobrazovací jednotky (monitoru), pro které jsou webové stránky optimalizovány, aby zobrazovaly přehledně maximální množství informací. Přestože stále pokračuje trend ve zvyšování plochy a rozlišení
monitorů, lze očekávat, že pro běžného uživatele rozměr monitoru příliš nepřekročí úhlopříčku o velikosti 19”, resp. 20”. Větší rozměry monitorů vyžadují také fyzicky více místa,
které může být limitujícím faktorem současných počítačových učeben a laboratoří. Rozměry těchto monitorů (spolu s technologií realizace zobrazování) definují maximální rozlišení, které je přibližně v rozmezí od 1024x768 do 1680x1024. Ze současného pohledu je
také vhodné optimalizovat webové stránky pro rozlišení 1024x768, které je dnes stále nejčastějším rozlišení přenosných počítačů typu notebook. Výhledově lze uvažovat o rozlišení
1280x1024.
S rozlišením zobrazovacího zařízení uživatelské stanice souvisí také možnost přístupu
k systému SyRoTek z takzvaných mobilních zařízení typu PDA. V těchto případech není
možné nabídnout uživateli plnou funkcionalitu systému, přesto základní zobrazení výsledku
provedeného experimentu, testu nebo přístup k systému rezervací lze i pro tato malá zařízení realizovat. Webové rozhraní pro malá mobilní zařízení bude dále označováno jako
webové rozhraní LITE.
Typické WWW stránky jsou přenášeny jako dokumenty zapsané v textových souborech
jazykem HTML, případně XML spolu s předpisem pro zobrazení, typicky zapsaným v jazyku CSS. Tyto formáty je vhodné rozšířit o formát, který definuje vzhled dokumentu více
jednoznačně a je tak vhodným například pro vytvoření tištěné podoby dokumentu. Mezi
tyto formáty v současné době patří PDF, PS a DVI. Vzhledem k dostupnosti prohlížeče
PDF souborů pro nejrozšířenější systémy typu Linux, Windows a Mac OS X bude tento
formát použit pro prezentaci ucelených dokumentů systému SyRoTek. Tyto dokumenty
mají charakter návodu a příruček.
V tabulce 7.1 jsou uvedeny jednotlivé specifikace webového rozhraní, které kladou požadavky na vybavení uživatelské stanice.
Název
Základní rozlišení
WWW stránky
Samostatné dokumenty
Popis
Základní rozlišení webového rozhraní je 1024x768, případně
vyšší.
WWW stránky jsou realizovány jako soubory HTML verze
4.1, případně jako XML soubory verze 1.1 doplněné o definici vzhledu kaskádovými styly (CSS) verze 2.1, případně
verze vyšší podle aktuálního stavu implementace v nejrozšířenějších WWW prohlížečích (Opera, Firefox, Safari).
Samostatné dokumenty budou prezentovány jako přístupné
PDF soubory, které je možné zobrazit prohlížečem Adobe
Acrobat Reader verze 7.
101/217
7.2. VIZUALIZAČNÍ ROZHRANÍ
Název
Webové rozhraní LITE
Vizualizace
SyRoTek - V003.1
Popis
Webové rozhraní je přizpůsobeno menšímu rozlišení PDA
zařízení, minimální podporované rozlišení je 240x240.
V závislosti na způsobu realizace vizualizace arény systému
SyRoTek může být implementován přístup přímo z webového prohlížeče. V takovém případě se bude pravděpodobné
jednat o rozšíření příslušného prohlížeče ve formě zásuvného modulu (plug-in) nebo podporu externí aplikace.
Tabulka 7.1: Specifikace požadavků webového rozhraní na vybavení uživatelské stanice
systému SyRoTek.
Konkrétní úplné hardwarové požadavky pro přístup k webovém rozhraní souvisí především se spuštěním konkrétního webového prohlížeče. Tyto parametry se nepochybně
v následujících letech vývoje systému SyRoTek změní, nicméně přesto lze předpokládat,
že tyto požadavky splňuje většina současných běžných používaných počítačů.
7.2
Vizualizační rozhraní
Vizualizační aplikace tvoří uživatelské rozhraní k vizualizačnímu systému projektu SyRoTek. V závislosti na konkrétní technologii realizace on-line sledování situace na ploše
bude vyvinuta uživatelská aplikace. S ohledem na přehled možných technologií v kapitole 11 bude aplikace realizována jako takzvaná stand-alone aplikace nebo jako aplikace
Java Virtual Machine (JVM). Ve druhém případě lze očekávat mírně vyšší nároky na operační paměť způsobené nároky JVM, přesto lze očekávat, že nároky na operační paměť
samotné aplikace vizualizace nebudou vyšší než například nároky nové verze operačního
systému Windows.
Součástí vizualizačního rozhraní je kromě přehrávání a on-line sledování dění na ploše
arény také vizualizace měřených dat ze senzorů umístěných na robotu. Moderní trendy
zobrazovaní jsou postaveny na technologiích 3D vizualizace s využitím akcelerovaného zobrazování realizovaného grafickou kartou. Z důvodů kompatibility a přenositelnosti aplikace
na různé platformy bude toto rozhraní využívat knihovny OpenGL, výhodou tohoto řešení je možnost emulace schopností grafické karty výpočetním výkonem hlavního procesoru
počítače 1 . Vizualizace senzorických dat, případně klíčování těchto dat do obrazu reálné
scény, tak jak je vidět například na obrázku ??, nevyžaduje sofistikované funkce moderních
grafických karet, proto bude postačující grafická karta podporující rozhraní OpenGL 1.5.
V případě vzdáleného spuštění vizualizační aplikace se nejvíce uplatní technika ukládání
zobrazovaných objektů přímo v paměti grafické karta, kdy je celková scéna počítána na
1
Takzvaný softwarový rendering je například součástí implementace OpenGL Mesa [35].
102/217
SyRoTek - V003.1
uživatelské stanici což nejen, že snižuje nároky na výpočetní výkon řídicího počítače, ale
také výrazně snižuje nároky na přenosovou kapacitu komunikačního spojení mezi řídicím
a uživatelským počítačem. Možnost vzdáleného spuštění vizualizační aplikace na řídicím
počítači a vizualizace na uživatelském počítači vyžaduje, z důvodu X11 protokolu pro
přenos dat k zobrazení, běžící X-server na uživatelské stanici. Pro systémy unixového typu
s grafickým terminálem je X-server samozřejmostí avšak v případě operačních systému
Windows je nutné spustit aplikaci realizující X-server, například volně dostupnou aplikaci
Xming [36]. Alternativou pro systémy Windows je spuštění unixového prostředí (například
instalace některé distribuce operačního systému Linux) ve virtuálním prostředí Virtual
PC [37] nebo VMware [38], které jsou volně dostupné.
Hlavní podporované uživatelské grafické prostředí je typu X-server, neboť operačních
systémů s X-serverem je k dispozici velké množství, jsou volně dostupné a nevyžadují dodatečné náklady na uživatelskou stanici v podobě nákladů na pořízení drahého operačního
systému. Přesto nelze opominout fakt, že v řadě vzdělávacích institucí, jejichž studenti mohou být potenciálními uživateli systému SyRoTek, jsou počítače vybaveny jediným operačním systémem. Kromě toho, že není volně přístupný, také není kompatibilní se zavedenými
a léty prověřenými standardy. Z tohoto důvodu je vhodné realizovat příslušné aplikace systému SyRoTek multiplatformně, tak aby byli přímo spustitelné na požadované platformně
nebo snadno portovatelné.
V případě stand-alone vizualizační aplikace lze s výhodou využít multiplatformních
knihoven, které zajišťují kompatibilitu aplikací na různých platformách operačních systémů. Mezi vhodné podpůrné knihovny pro realizaci vizualizační aplikace patří grafické
toolkity typu Qt [39], FLTK [40], wxWidgets [41] a multimediální knihovna SDL [42].
Alternativou také mohou být aplikace pro JVM, které však zpravidla vyžadují případné
rozšiřující knihovny v binární nativním formátu pro konkrétní platformu a výhoda přenositelnosti Java kódu přestává být tak významná. Uživatelská stanice musí být vybavena
potřebnými instalovanými knihovnami, případně nezbytnými nástroji pro kompilaci knihoven ze zdrojových kódů. Přímá kompilace ze zdrojových kódů je z hlediska kompatibility
jedním z nejvhodnějších způsobů řešení, neboť uživatel má možnost instalovat konkrétní
verzi knihovny, vůči které byla testována vizualizační aplikace systému SyRoTek, kterou
je také možné instalovat ze zdrojových kódu a vytvořit tak binární spustitelný soubor.
Více informací o kompilace aplikací na uživatelské stanici je uvedené v následující části
zabývající se vývojovými nástroji.
103/217
7.3. VÝVOJOVÉ NÁSTROJE
SyRoTek - V003.1
Předpokládané požadavky na uživatelskou stanici z hlediska vizualizačního software
systému SyRoTek jsou shrnuty v tabulce 7.2.
Název
3D vizualizace
3D akcelerace
Vzdálená vizualizace
Vizualizační aplikace
Popis
Podpora zobrazování bude knihovnou OpenGL 1.5.
Grafická karta s hardwarovou podporou zobrazování
podle OpenGL 1.5
X Window System, Version 11, X11, testováno bude na
X.Org Release 6.7. Parciálně bude testován X-Server
Xming [36] pro platformu Microsoft Windows XP.
Potřebné binární soubory podpůrných knihoven. Přednostně bude zvážena implementace aplikace, která
bude využívat multimediální a grafických knihoven pro
platformy FreeBSD, Linux a Windows.
Tabulka 7.2: Předpokládané požadavky vizualizačního software systému SyRoTek na uživatelskou stanici.
7.3
Vývojové nástroje
Nedílnou součástí výukového kurzu mobilní robotiky v systému SyRoTek je uživatelská
implementace aplikace, která řídí robot. Aplikace je vyvíjena v konkrétním programovacím
jazyku. Základní množina podporovaných jazyků je tvořena překládanými jazyky C, C++,
Java a některým ze skriptovacích jazyků Ruby, Python nebo Lua.
Z hlediska vlastního vytvoření zdrojových kódu lze použit libovolný textový editor dostupný na uživatelské stanici. Pro samotné spuštění uživatelské aplikace na řídicím nebo
palubním počítači je nejdůležitější přenositelnost spustitelného souboru nebo bezproblémová kompilace zdrojových souborů pro cílovou platformu na řídicím, respektive palubním
počítači. Jedním ze základních pravidel realizace přenositelné aplikace je definování podporované verze příslušného jazyka. V případě programovacího jazyka C/C++ je to také
podporovaný překladač. V tabulce 7.3 jsou uvedeny předpokládané verze podporovaných
programovacích jazyků.
Název
C
C++
Java
ruby
Popis
Zdrojové soubory by měly být kompatibilní s kompilátorem GCC verze
4.2.
Zdrojové soubory by měly být kompatibilní s kompilátorem GCC verze
4.2.
Java 1.5, případně 1.6 dle aktuálního vývoje.
Verze 1.8.
104/217
Název
python
Lua
SyRoTek - V003.1
Popis
Python verze 2.5, vzhledem k plánované verzi 3.0, která nebude plně
zpětně kompatibilní bude podporována verze 3.0 podle aktuálního stavu
portace podpůrných Python knihoven na verzi 3.0.
Verze 5.1
Tabulka 7.3: Předpokládané verze podporovaných programovacích jazyků uživatelské aplikace.
Základní vývojové nástroje
Uživatelská aplikace překládaná ze zdrojových kódů může složena z několika zdrojových
souborů. V takovém případě je vhodné předepsat způsob překladů, případně linkování. Jeli aplikace závislá na podpůrných knihovnách, musí být tyto informace součástí zdrojových
souborů. Vedle samotných souborů zdrojových kódů uživatelské aplikace je proto nedílnou
součástí zdrojových souborů předpis pro překlad, sestavení, případně spuštění uživatelské
aplikace. Zdrojové soubory tvoří část takzvaného prostředí uživatelské aplikace, které je
popsáno v oddíle 5.1.1, neboť přímo souvisí s abstrakcí přístupu k řídicímu počítači.
S ohledem na minimalizaci vzniku potenciálních problémů s překladem uživatelské aplikace na řídicím počítači bude pro každý podporovaný programovací jazyk připravena šablona s definovanou strukturou adresáře zdrojových souborů spolu se základním souborem
pro předpis překladu. Struktura tohoto předpisu se bude skládat z definování hodnot konkrétních proměnných. Soubor s uživatelem definovanými proměnnými se následně použije
pro sestavení aplikace některým z nástrojů uvedených v tabulce 7.4.
Název
gmake
ant
SCons
Popis
Překlad uživatelské aplikace v C a C++, verze gmake 3.81 [43].
Překlad uživatelské aplikace v programovacím jazyku Java, verze
ant 1.7 [44].
Překlad uživatelské aplikace v C, C++ nebo Java, verze 0.97 [45].
Tabulka 7.4: Základní podporované nástroje pro překlad uživatelské aplikace.
Uživatel může pro sestavení aplikace využít skriptů z poskytované šablony nebo vytvořit
vlastní skripty pro příslušný nástroj pro sestavení.
Vývojový proces uživatelské aplikace se neskládá pouze z kompilace, ale také z ladění a
spouštění aplikace na uživatelské stanice, řídicím nebo palubním počítači.
Součástí základních vývojových nástrojů je aplikace pro přístup ke správci verzí zdrojových souborů Subversion [46]. Instalační program Subversion je dostupný pro základní
105/217
7.3. VÝVOJOVÉ NÁSTROJE
SyRoTek - V003.1
platformy FreeBSD, Linux, MAC OS X a Windows. V tabulce 7.5 jsou uvedeny grafické
rozhraní pro práci s verzovanými soubory tohoto správce verzí.
Název
esvn
tortoisesvn
pysvn
tkcvs
rapidsvn
subclipse
svn netbeans
Popis
Multiplatformní grafické rozhraní využívající grafického toolkitu
Qt, [47].
Grafické rozhraní pro systémy Windows [48].
Multiplatformní grafické rozhraní napsané v programovacím jazyku
Python, [49].
Multiplatformní grafické rozhraní pro správu verzí systémem CVS
s Subversion (SVN) implementované v jazyku Tcl/Tk, domovská
stránka [50].
Multiplatformní grafické rozhraní realizované knihovnou wxWidges,
domovská stránka [51].
Rozšíření IDE Eclipse o podporu správy verzí zdrojových souborů
systémem Subversion [52].
Rozšířující balíček pro IDE Netbeans [53].
Tabulka 7.5: Grafická rozhraní správce verzí systémem Subversion.
Grafické vývojové nástroje
Začínající uživatelé rádi využívají grafických rozhraní, neboť ty poskytují intuitivně informace, které si začínající uživatel ještě plně neosvojil. Z tohoto hlediska je proto velmi
vhodné využit pro vývoj aplikace takzvaných integrovaných vývojových prostředí (IDE).
Ačkoliv zkušený uživatel raději použije prostředí, které ho minimálně obtěžuje již známými
informacemi (například v podobě veselých grafických symbolů), je při ladění aplikace spuštěné na robotu vhodné kromě samotného zdrojového kódu využít vizualizace scény na ploše
arény, případně grafické vizualizace dat ze senzorů. Integrované prostředí může v tomto případě poskytnout jednotný způsob práce s příslušnými daty z palubního a řídicího počítače,
vizualizace scény a dat ze senzorů.
Vhodnými IDE rozhraními jsou Eclipse [24] a Netbeans [25], neboť obě tyto prostředí
podporují řadu programovacích jazyků (Java, C/C++, Ruby, Python) buď přímo v základní instalaci nebo v podobě rozšiřujícího balíčku. Otevřenost těchto prostředí umožňuje
integrovat do nich podporu pro vývoj uživatelské aplikace systému SyRoTek. Přestože konkurenční výhodou prostředí Eclipse je již existující rozšíření podporující Player [26], není
v současném stádiu vývoje systému SyRoTek vhodné definovat potenciální podporu konkrétního prostředí, neboť odhad předpokládané časové náročnosti takové implementace by
byl velmi nepřesný.
Případný rozšiřující modul pro konkrétní IDE bude realizován jaká obálka nad základními vývojovými prostředky, které tvoří vhodné adresářové struktury souborů, definiční
106/217
SyRoTek - V003.1
soubory a základní aplikace a knihovny pro komunikaci s řídicím počítačem. V tabulce 7.6
jsou uvedeny základní aplikace s grafickým rozhraním pro komunikaci s řídicím počítačem
a podporu vývoje.
Název
remote admin - syrram
reservation - syrres
remote visualization - syrris
visualization - syrvis
simulation - syrsim
Popis
Grafické rozhraní pro správu prostředí uživatelské
aplikace na řídicím/palubním počítači.
Aplikace s grafickým rozhraním pro přístup k rezervačnímu systému, definici konfigurace robotu a
arény.
Aplikace pro řízení záznamů plochy arény.
Aplikace pro přehrávání záznamů plochy arény a
zobrazování souborů s daty ze senzorů.
Simulátor prostředí systému SyRoTek.
Tabulka 7.6: Aplikace s grafickým rozhraním pro podporu vývoje uživatelské aplikace.
Ačkoliv jsou výše uvedené aplikace grafické, jsou tyto aplikace realizovány jako grafické
nadstavby základní funkcí, je tedy možné realizovat různá grafická rozhraní, případně přímé
příkazové rozhraní.
Uživatelova volba
Systém SyRoTek je z pohledu vlastního vývojového procesu uživatelské aplikace otevřený a výše zmíněné nástroje nemusí uživatel používat, pokud mu z nějakého důvodu
nevyhovují. Uživatel může v rámci systému SyRoTek využít libovolné možnosti realizace
své aplikace, jedinou omezující podmínkou jsou dostupné softwarové prostředky na řídicím
počítači, případně své uživatelské stanici.
Bude-li například uživatelská aplikace vždy spouštěna pouze z uživatelské stanice, může
uživatel využít libovolné vývojové prostředky. Nutnou podmínkou je však použití komunikačních knihoven pro přípojení k instanci serveru Player na řídicím počítači, který mu
zprostředkuje přístup k senzorům a ovládání robotu. V tomto případě nebude možné využít mechanismu vytvoření důvěryhodných výstupních souborů uživatelské aplikace, viz
oddíl 5.1.1.
Uživatel může také plně vyvíjet na řídicím počítači prostřednictvím vzdáleného sezení,
které může být terminálové nebo grafické. Vzhledem k přítomnosti překladače na řídicím
počítači může uživatel dokonce v rámci svého uživatelského prostoru na řídicím počítači
instalovat své oblíbené vývojové nástroje. Ve svém domovském adresáři může mít instalované novější vývojové verze podpůrných knihoven nebo programovacích jazyků. Vždy však
musí jeho aplikace využívat příslušného komunikačního rozhraní se serverem Player.
107/217
7.4. PODPŮRNÉ NÁSTROJE
SyRoTek - V003.1
Uživatelská aplikace pro palubní počítač může využívat pouze prostředků, které jsou
na palubním počítači k dispozici, neboť uživatel může v rámci palubního počítače aplikaci
pouze spouštět.
Základní vývojové knihovny
Cílem implementace uživatelské aplikace je praktické ověření získaných zkušeností z oblasti mobilní robotiky. Při vývoji aplikace se proto uživatel soustředí na řešení příslušné
úlohy a nezbytné implementační funkcionality využívá v podobě volání knihovních funkcí.
Základní knihovní funkce jsou shrnuty v tabulce 7.7.
Název
Player
Logging
Results
Vdbg
Popis
Základní komunikační rozhraní pro připojení uživatelské aplikace k serveru Player.
Unifikované rozhraní pro vytváření ladících a výstupních výpisů.
Unifikace mechanismu vytváření výstupních souborů uživatelské aplikace jako nezbytného součásti podkladů pro odevzdání (resp. vyhodnocení) správnosti řešené úlohy.
Funkce pro podporu vizuálního ladění, zobrazování dat ze senzorů, vizualizace průběhu algoritmu.
Tabulka 7.7: Základní funkcionality podpůrných vývojových knihoven uživatelské aplikace.
7.4
Podpůrné nástroje
Podpůrné nástroje reprezentují soubor softwarových nástrojů, které může uživatele využít při vývoji své uživatelské aplikace pro systém SyRoTek. Tyto nástroje lze rozdělit do
následujících kategorií:
• nástroje uživatelské podpory,
• knihovní funkce realizující dílčí algoritmy,
• aplikace a nástroje pro zpracování a zjednodušení častých operací.
Předpokladem úspěšného používání systému SyRoTek je vytvoření komunity uživatelů,
v rámci které vzniká potenciál pro další rozšíření a uživatelská vylepšení systému. Důsledkem takového komunitního vývoj je zpětná vazba uživatelů na realizaci nových požadavků
vedoucí ke zvýšení uživatelského komfortu a tím také k potenciálnímu nárůstu uživatelské základny. Nezbytnou podmínkou vytvoření komunity uživatelů je uživatelská podpora
108/217
SyRoTek - V003.1
ze strany vývojářů systému SyRoTek. Součástí této podpory jsou především komunikační
nástroje jako jsou diskuzní fórum, IRC kanál, služby IM, systém pro hlášení chyb a požadavků. Tyto nástroje mají webové rozhraní nebo je možné využít některé specifické aplikace
pro konkrétní platformu uživatelské stanice, neboť tyto komunikační protokoly jsou velmi
dobře definovány.
Podle podoby konkrétního kurzu mobilní robotiky může být výhodné některé nezbytné
části úlohy poskytnout studentům v podobě implementace příslušného algoritmu. Tyto
implementace tvoří základ knihovny algoritmů pro úlohy řešené v rámci problematiky mobilní robotiky. Součástí této knihovny mohou také být povedené implementace uživatelů
systému SyRoTek, případně některé úlohy mohou mít svůj cíl ve vytvoření vhodné implementace algoritmu pro tuto knihovnu (knihovny). Výhodou kolekce základních algoritmů
včetně zdrojových kódu je především ve zjednodušení implementace jiných uživatelských
aplikací.
Další neméně důležitou výhodou otevřeného přístupu k implementovaným algoritmům je
fakt, že recenzované zdrojové kódy jsou velmi cenným studijním materiálem pro studenty,
kteří získají nejen povědomí o teoretickém algoritmu a jeho praktické realizace, ale také
získávají informace o tom jak psát a organizovat zdrojové soubory. Začínající programátoři
zpočátku řeší problémy související se syntaxí příslušného programovacího jazyku a příliš
se nesoustředí na strukturu programu a organizaci zdrojových kódu. Při realizaci komplexnější robotické úlohy pak musí řešit problémy s nevhodnou strukturou a nepřehledností
programu, která vede na obtížné ladění a hledání chyb.
Definicí základního a jednoznačného rozhraní pro vývoj uživatelské aplikace systému SyRoTek je otevřena možnost pro vlastní uživatelské přizpůsobení a nadstavby, které mohou
výrazně zjednodušit práci se systémem. Vzhledem k velmi obtížnému odhadu, co budou uživatelé konkrétní cílové skupiny preferovat, je vhodné základní rozhraní realizovat formou
funkčních primitiv, které mají jednoduchou syntax používání, přestože je typicky nutné
aplikovat několik těchto primitiv pro dosažení požadované operace. Klíčovou vlastností
je pro toto rozhraní definice základního API těchto primitiv, případně nástroje příkazové
řádky, které lze dále rozšiřovat. Integrace funkcionality přímo do grafického rozhraní sice
vede na rychlejší vývoj příslušné aplikace, avšak taková aplikace je samoúčelná a velmi
obtížně rozšiřitelná o meta-nástroje využívající již prověřené funkcionality.
7.5
Plán realizace uživatelské stanice
Realizace dílčích softwarových komponent pro uživatelskou stanici velmi úzce souvisí
s realizací vývojového prostředí řídicího počítače. Při prvotním přiblížení uživatelské stanice je možné ji chápat pouze jako grafický terminál, který je připojen k řídicímu počítači.
Jednotlivé vývojové nástroje pro realizaci uživatelské aplikace lze využít při vlastní realizaci systémových aplikací, které jsou nutnou součástí pro spuštění uživatelské aplikace.
Z tohoto pohledu lze většinu základních funkcionalit vývojových nástrojů uživatelské stanice realizovat při vývoji softwarových komponent řídicího a palubního počítače. Přestože
109/217
7.5. PLÁN REALIZACE UŽIVATELSKÉ STANICE
SyRoTek - V003.1
implementace systémových aplikací s ohledem na možný běh na uživatelské stanici je časově náročnější v celkovém horizontu implementačních prací lze očekávat výrazně nižší
časové náročnosti pro dosažení vytyčených cílů. Odhad časové náročnosti však nemusí být
zcela přesný, proto je vhodné rozdělit implementační části na základní a rozšířené funkcionality tak, aby i v případě implementace pouze základní úrovně bylo možné se systémem
SyRoTek pracovat plnohodnotným způsobem, avšak na úkor omezených variant přístupu
nebo přísnějších požadavků na vybavení uživatelské stanice. Rozšířující úrovně mohou být,
v případě úspěšného provozování systému SyRoTek, realizovány v rámci komunity uživatelů.
V tabulce 7.8 je uveden předběžný plán prací realizace softwarových modulů pro uživatelskou stanici. V první sloupci je uvedeno pořadí realizace ve tvaru A.Bx, kde A reprezentuje úroveň realizace, B udává dílčí pořadí realizace v rámci úrovně a x identifikuje
realizaci, pokud je možné dílčí krok implementovat paralelně v rámci úrovně. Úrovně 1 až
5 tvoří základní úroveň pro dosažení nutných funkcionalit a základní použitelnosti systému
SyRoTek.
Krok
1.1
1.2
1.3
1.4
2.1
2.2
3.1
3.2
4.1a
4.1b
4.1c
4.1d
4.1e
5.1
6.1a
Popis
Identifikace klíčových modulů systémových aplikací.
Definice rozhraní jednotlivých modulů.
Definice základního vývojového prostředí vývoje systémových aplikací.
Specifikace vývojového prostředí pro řídicí počítač a křížovou kompilaci
pro palubní počítač.
Implementace základní modulů a jejich sdružení do knihoven systému
SyRoTek, Player, Logging.
První implementace modulů a jejich sdružení do knihoven systému SyRoTek, Results, Vdbg.
Specifikace základní struktury prostředí uživatelské aplikace.
Generalizace vývojového prostředí (z bodu 1.3) pro překlad a spuštění
Terminálová implementace aplikace syrram.
Základní terminálová implementace aplikace syrres využívaná pro testování rezervačního systému.
První implementace aplikace syrris, terminálová implementace pro základní ovládání systému vizualizace.
První implementace aplikace syrvis, ověření konceptu zobrazování video
(případně audio) proudů spolu s příslušnými daty.
První implementace aplikace syrsim, konfigurace simulátoru Stage pro
prostředí arény systému SyRoTek.
Příprava rozhraní aplikace syrres pro integraci do webového rozhraní.
Implementace základních modulů aplikace syrvis pro použití ve finální
verzi aplikace syrvis.
110/217
Krok
6.2b
7.1
7.2
7.3
7.4
8.1
9.1
9.2
10.1
10.2
10.3
10.4
10.5
10.6
SyRoTek - V003.1
Popis
Oddělení vlastního simulačního jádra a vizualizace simulace aplikace syrsim.
Definice a implementace základních funkčních volání vlastního zobrazovaní aplikace syrvis, zobrazování uživatelské grafiky v rámci zobrazování
video proudů.
Identifikace a implementace základních modulů vizualizace pro aplikaci
syrsim s použitím rozhraní z bodu 7.1.
Integrace modulů vizualizace aplikace syrsim do aplikace syrvis, výstupem je aplikace syrvis PRE-RELEASE.
Rozšíření aplikace syrsim o vizualizaci využívající zobrazování aplikace
syrvis, výstupem je aplikace syrvis.
Implementace rozhraní aplikace syrris pro integraci do webového rozhraní.
Implementace grafického rozhraní aplikace syrram.
Implementace grafického rozhraní aplikace syrres.
Implementace IDE rozhraní rozhraní aplikace syrram.
Implementace IDE rozhraní rozhraní aplikace syrres.
Implementace IDE rozhraní rozhraní aplikace syrris.
Implementace IDE rozhraní rozhraní aplikace syrvis.
Implementace IDE rozhraní rozhraní aplikace syrsim.
Integrace jednotlivých IDE rozhraní do kompaktního rozšiřujícího balíku.
Tabulka 7.8: Dílčí kroky realizace softwarového vybavení uživatelské stanice systému SyRoTek.
111/217
SyRoTek - V003.1
Kapitola 8
Aréna
Aréna tvoří v projektu SyRoTek prostorově nejnáročnější část a spolu s roboty tvoří majoritní část konstrukčních prvků realizovaných v rámci projektu. Z hlediska vlastního konstrukčního řešení arény je důležité respektovat její konkrétní fyzické umístění. Aréna systému SyRoTek bude umístěna v prostorách učebny řešitelského pracoviště. Učebna slouží
pro výuku předmětů studentů bakalářského a magisterského studijního programu, které
vyžadují práci s počítačem. Na obrázku 8.1 je schematicky znázorněno uspořádání učebny.
V učebně je k dispozici 20 studentských pracovišť (SPk ) vybavených osobními počítači.
Dále jsou v učebně tři specializované pracoviště sloužící převážně pro výuku robotiky (
v obrázku označené RPi ), které jsou vybaveny osobním počítačem připojeným k řídicí
jednotce robotického manipulátoru,. Vlastní aréně je vymezen prostor v rohu místnosti o
rozměrech přibližně 3,5 × 3,5 m.
V následujících oddílech je diskutována vlastní konstrukce arény, překážky a dokovací
stanice.
8.1
Konstrukce arény
Konstrukce arény musí respektovat prostředí, ve kterém se nachází, spolu s požadavky
vycházející z požadovaných funkcionalit jednotlivých objektů systému. Vzhledem k umístění arény v učebně, která je volně dostupná studentům, je nutné zabránit vniku nežádoucích předmětů na plochu. Aréna proto bude od zbytku místnosti vymezena oddělující
stěnou, výška této stěny bude až ke stropu.
Pohyblivé překážky na ploše arény budou realizovány výsuvnými překážkami, mechanismus pohybu překážky bude umístěn pod plochou arény. Deska, po které se roboty pohybují,
je proto umístěna ve výšce nejméně 80 cm nad podlahou místnosti. Vzhledem k předpokladu realizace desky z několika částí je nutná podpůrná konstrukce, která bude postupně
montována. S ohledem na pohyb robotu a rozměry jeho kol je nutné, aby jednotlivé desky
byly ve stejné výšce a robot se mohl bezproblémově pohybovat po celé ploše. Při montáži je
112/217
KAPITOLA 8. ARÉNA
SyRoTek - V003.1
tabule
vstup
do
učebny
SP1
SP2
SP3
SP4
SP5
SP6
SP7
SP8
SP9
SP10
SP11
SP12
SP13
SP14
SP15
SP16
SP17
SP18
RP3
SP19
SP20
RP2
SyRoTek
aréna
RP1
Obrázek 8.1: Schematické uspořádání učebny, ve které je umístěna aréna systému SyRoTek.
113/217
8.2. OSVĚTLENÍ
SyRoTek - V003.1
tedy nutné, aby podpůrná konstrukce byla vybavena mechanismem nastavení výšky a roviny jednotlivých desek. Celková konstrukce musí být odolná proti nárazu, aby nedocházelo
k vzájemnému pohybu desek při nárazu do stěny kolem arény.
Prostor pod deskou je vhodné využít pro umístění příslušných podpůrných výpočetních
prostředků systému SyRoTek, jako je například řídicí počítač. Při využití této možnosti je
však nutné zajistit dostatečný odvod tepla z počítačů.
Z hlediska přístupu k ploše arény se musí realizovat dveře ve stěnách arény, které jsou
dostatečné široké pro manipulaci s roboty nebo ostatními konstrukčními prvky.
Hlavní lokalizační kamera bude umístěna nad plochou, přibližně ve středu arény. Vzhledem k výšce umístění kamery nad deskou arény je vhodné, aby nosnost a pevnost vlastní
desky (plochy) arény umožňovala přístup ke kameře pro dospělého člověka na štaflích.
Hlavní vizualizační kamera bude umístěna přibližně ve stejné výšce jako lokalizační kamera,
ostatní vizualizační kamery budou rozmístěny po stranách arény ve výšce minimálně 0,5 m
nad plochou arény. Konstrukce arény musí respektovat přístup ke kamerám a potřebnou
kabeláž pro přípojení kamery k zachytávacímu zařízení, napájení kamery a případnému
přídavnému osvětlení.
Součástí hlavní konstrukce arény je kromě držáků kamer a přídavného osvětlení také
příprava pro vytvoření bezdrátové komunikační infrastruktury. Vhodným umístěním a nastavením výkonu příslušných aktivních prvků lze potlačit vliv rušení bezdrátové sítě WiFi,
která musí respektovat současnou WiFi infrastrukturu v učebně. Vedle WiFi sítě, je součástí robotu nezávislý radiový komunikační systém, který vyžaduje také vhodné rozmístění
aktivních prvků. Ty je navíc vhodné rozmístit tak, aby nedocházelo k nežádoucím interferencím se SyRoTek WiFi sítí.
Vzhledem k uzavřenému prostoru arény a nepřetržitému provozu představují roboty
potenciální riziko vzniku požáru. Proto je vhodné instalovat v prostoru arény požární
hlásiče, případně kouřové detektory.
8.2
Osvětlení
V závislosti na způsobu realizace globálního lokalizačního systému je nutné zajistit konstantní osvětlení. Uživatelé systému SyRoTek mohou přistupovat k vizualizaci plochy arény
také v nočních hodinách, proto je nutné zajistit nezávislé osvětlení plochy arény, které je
oddělené od řízení osvětlení v místnosti.
S ohledem na úsporu elektrické energie při nevyužívání vizualizačního systému je vhodné
systém osvětlení arény vybavit mechanismem automatického zapínání a vypínání osvětlení,
které bude možné ovládat z řídicího počítače.
114/217
KAPITOLA 8. ARÉNA
8.3
SyRoTek - V003.1
Plocha desky arény
Na ploše desky arény se pohybují roboty systému SyRoTek. Deska bude pravděpodobně
vytvořena z dřevotřískového materiálu o tloušťce minimálně 1 cm. Z hlediska pohybu robotu a jeho rozpoznávání globálním lokalizačním systémem je nejdůležitějším parametrem
desky její povrchová úprava. Systém globální lokalizace je založen na sledování plochy arény
shora, proto je důležité, aby povrch byl co nejméně reflexivní a pokud možno difuzní. Pro
spolehlivé rozpoznávání je důležité, aby povrch desky neodrážel dopadající světlo, které
osvětluje celou arénu. Vlastní povrch desky musí být mechanicky odolný vůči možnému
poškrábání způsobené opěrnými koly robotu.
Pro řešení úloh typu sledování čáry je vhodné plochu arény doplnit dvěma nezávislými
typy vodících čar. První typ obsahuje pouze nekřižující se vodící čáru. Druhý typ obsahuje
křižující se vodící čáry. Aby bylo možné čáru jednoduše detekovat senzorem odrazivosti
umístěným ve spodní části robotu, je její barevné provedení výrazně jiné než barva plochy
Tloušťka vodící čáry je nejméně 0,5 cm.
8.4
Překážky
Aréna obsahuje tři základní typy překážek:
• mantinely,
• nepohyblivé překážky,
• pohyblivé překážky.
Mantinely tvoří bariéru vymezující vlastní plochu arény. Hlavním důvodem pro realizaci
nepohyblivých překážek je finanční náročnost pohyblivých překážek spolu s konstrukčním
omezeními umístění příslušné pohybové jednotky. Kombinací pohyblivých a nepohyblivých
překážek lze na ploše arény vytvořit simulaci rozličných prostředí, které by nebylo s malým
počtem pohyblivých překážek možné. Nepohyblivé překážky jsou manuálně demontovatelné
a tak základním prostředím je zcela volná plocha.
Vhodným rozmístění nepohyblivých překážek lze vytvořit prostředí typu bludiště nebo
kancelářské prostředí. Tato prostředí lze dále mírně modifikovat vysouváním, respektive
zasouváním pohyblivých překážek. Pohyblivými překážkami lze také vytvořit dynamické
prostředí, které lze použít při řešení náročnějších robotických úloh.
Hlavními parametry překážek jsou jejich rozměry. Výška mantinelů je o málo (nejvýše
několik centimetrů) vyšší než je výška robotu. Barva mantinelů z boku, ze strany plochy
arény, ve které se pohybují roboty, je výrazně jiná než barva desky, po které se roboty
pohybují. Barva vrchní strany mantinelů je jiná než barva vnitřní strany mantinelů a jiná
než barva desky.
115/217
8.4. PŘEKÁŽKY
SyRoTek - V003.1
Výška nepohyblivých překážek je o málo nižší než výška mantinelů, ne však nižší než
je aktivní výška nejvýše umístěného senzoru na robotu. Barevné provedení překážky je
podobné jako u mantinelů, barvy jsou však zvoleny tak, aby bylo možné jednoznačně
rozlišit mantinel od překážky. Tyto překážky jsou rozmístěny na ploše arény v definovaných
pozicích manuálně správcem systému SyRoTek.
Pohyblivé překážky jsou výškou i barevným provedením identické nepohyblivým překážkám. Hlavní rozdíl je v mechanismu ovládání, který umožňuje z řídicího počítače řídit
vysunutí a zasunutí překážky nejméně ve dvou polohách: plně vysunuto, plně zasunuto.
Tyto dvě polohy jsou indikovány dvěma kontrolními bity1 .
Šířka mantinelů a překážek je nejméně 2,5 cm, délka překážek je závislá na jejich konkrétní realizaci, není však menší než šířka.
Specifické barevné provedení překážek a mantinelů
Barevné rozlišení jednotlivých překážek a mantinelů je motivováno třídou úloh, ve kterých je robot navigován v neznámém prostředí s využitím informace o prostředí poskytované jednoduchou kamerou. Jednoznačné rozlišení mantinelů a překážky je zjednodušením
řešené úlohy, neboť dobře identifikovatelným způsobem omezuje prohledávaný prostor.
Toto rozlišení překážek od mantinelů je možné také realizovat softwarově, prostřednictvím globálního lokalizačního systému. Avšak informaci o klasifikaci překážky jako mantinelu je nutné doručit do uživatelské aplikace. Realizace takového chování bez interakce
uživatele co by autora příslušné aplikace je velmi obtížně realizovatelná.
V souvislosti s barevným rozlišením překážek je vhodné realizovat překážky a mantinely tak, aby je bylo možné doplnit o vhodné symboly, které mohu sloužit k jednoznačné
identifikaci místa na ploše arény a zároveň byly klasifikovatelné jednoduchými algoritmy
rozpoznávání, podobně jako je to v prostředí Rat’s Life [54] na obrázku 8.2.
Alternativním řešením je umístění aktivních a případně pasivních prvků na mantinely
a překážky tak, aby byly dobře viditelné kamerou umístěnou na robotu.
Ovládání překážek
Součástí arény jsou také nezbytné řídicí jednotky pro ovládání pohybu překážek. Pohyblivé překážky jsou vybaveny nejméně dvěma koncovými spínači, detekujícími dosažení
koncové polohy plně zasunuto, plně vysunuto. Rozhraní řídicích jednotek je kompatibilní
s běžně dostupným rozhraním pracovní stanice, která realizuje řídicí počítač. Nejvhodnější je pro tyto účely rozhraní RS232, případně varianta RS422 nebo RS485. Vzhledem
k minimálním nárokům na latenci komunikace řídicího počítače s řídicími obvody ovládání
překážek je možné uvažovat i o převodu RS232 rozhraní na USB.
1
Překážky musí být vybaveny koncovými spínači, které jednoznačně indikují dosažení koncové polohy.
116/217
KAPITOLA 8. ARÉNA
SyRoTek - V003.1
Obrázek 8.2: Snadno rozpoznatelné symboly v reálném prostředí Rat’s Life, obrázek převzat z [54].
Komunikace probíhá prostřednictvím definovaného komunikačního protokolu, který je
vhodné založit na komunikačním protokolu MCU na robotu, viz [34]. Každé pohyblivé
překážce charakterizované svými rozměry a umístění na ploše je přidělena jedinečná identifikační značka.
Alternativní překážky
Na ploše arény mohou být umístěny také alternativní překážky, které typicky souvisí
s řešením úloh s tématikou přemísťování nákladu. Náklad je reprezentován překážkou,
kterou lze volně přemisťovat pohybem robotu tak, že robot tlačí překážku před sebou.
Umístění překážek na plochu je realizováno správcem systému SyRoTek. Použití překážek
tohoto typu však může skrývat potenciální zablokování robotu. Pro bezpečný provoz je
nezbytný volný prostor, který umožňuje bezpečný návrat robotu do dokovací stanice.
8.5
Dokovací stanice
Dokovací stanice jsou místem, kde je robot umístěn, pokud není používán. Základní
rozdělení plochy arény na operační prostor a dokovací prostor je znázorněno na obrázku 8.3.
Každá dokovací stanice vymezuje prostor pro jediný robot. Hlavní úlohou dokovací stanice
je dobíjení akumulátoru robotu.
Mechanismus dobíjení může být kontaktní nebo bezkontaktní. Nabíjecí konektor však
vždy musí být realizován tak, aby nemohlo dojít při nežádoucím kontaktu k poškození
robotu. Přirozeným požadavkem je rozdělení prostoru pro dokovací místa na vlastní prostor
pro zaparkování robotu a přístupový prostor pro zadokování.
117/217
8.5. DOKOVACÍ STANICE
SyRoTek - V003.1
Prostor pro dokovací místa
Operační prostor
Mantinel
Překážky
Pohyblivé překážky
Obrázek 8.3: Rozdělení plochy na dokovací a operační prostor.
Dokovací stanice je vybavena mechanismem pro ověření správného zadokování robotu i
pro detekci robotu v blízkosti dokovací stanice. V případě neúspěšného provedení procedury
zadokování je informován o problému správce systému SyRoTek. Stav dokovací stanice je
vizualizován světelnou signalizací, která je viditelná při pohledu do arény na dokovací
stanice z místnosti, ve které je aréna umístěna.
Nezbytnou součástí dokovací stanice je přívod elektrické energie pro nabíjecí obvody
stanice a robotu. Pro vyhodnocování efektivity přenosu energie z dokovací stanice do robotu
je vhodné monitorovat výstupní energie dokovací stanice a porovnávat ji s aktuální energií
použitou při nabíjení akumulátorů robotu. V případě mechanického nabíjecího konektoru
jsou tyto údaje využity pro plánování výměny nebo čištění.
Alternativním rozhraním dokovací stanice je konektor pro připojení robotu k vysokorychlostní síti typu Ethernet, která umožňuje vyšší komfort při správě softwarových části
palubního počítače a jednotlivých mikrokontrolérů.
118/217
KAPITOLA 8. ARÉNA
8.6
SyRoTek - V003.1
Údržba arény
Přestože je aréna umístěna v místnosti a uzavřena stěnami až ke stropu, lze v průběhu
provozu očekávat usazování prachu na ploše, zvláště v místech, kde se roboty nebudou
pohybovat často. Prach na ploše má vliv na tření mezi koly a plochou, které se projevuje především při řízení pohybu robotu. Vzhledem k relativně malým rychlostem pohybu
robotu nebude vliv změny tření při řízení pohybu robotu se zpětnou vazbou globální lokalizace výrazný.
Změna vlastností povrchu desky může také ovlivnit spolehlivost zpracování obrazu globální lokalizace. Také v tomto případě je předpokládaný vliv z dlouhodobého hlediska
zanedbatelný.
Pravděpodobně nejvyšší vliv prachu je na vlastnosti elektronických zařízení, zvláště pak
na nabíjecí kontakty, které jsou však jejich používáním také částečně očišťovány. Z dlouhodobého hlediska provozu systému SyRoTek je však nutné vzít v úvahu pravidelné čištění
plochy, dokovací stanice a vlastních robotů. Tuto činnost lze spojit s pravidelnou servisní
prohlídkou robotu a dokovacích stanic.
Požadavky na konstrukci arény z hlediska údržby arény jsou především v přístupu k jednotlivým částem. Požadavek snadného přístupu vyplývá především z maximalizace času,
po který je systém připraven k používání uživateli.
Součástí arény mohou být také příslušné počítače pro lokalizaci, webové rozhraní a
vlastní řídicí počítač. Toto umístění je vhodné z hlediska minimalizace zpoždění, resp. kapacity komunikačního rozhraní mezi počítači. Objekty systému SyRoTek z hlediska provozu
systému jsou v takovém případě:
1. webový server,
2. autentizační / autorizační server,
3. řídicí počítač,
4. lokalizační systém,
5. pohyblivé překážky oddělující dokovací a operační prostor,
6. dokovací stanice a roboty,
7. osvětlení,
8. vizualizace,
9. překážky a pohyblivé překážky.
119/217
8.6. ÚDRŽBA ARÉNY
SyRoTek - V003.1
Objekty 1 až 6 lze označit za klíčové objekty, jejichž správná činnost umožňuje používání
systému SyRoTek. Ostatní objekty představují objekty, jejichž funkčnost může být i částečná a nemají zásadní vliv na použitelnost systému. Z tohoto hlediska je tedy vhodné
realizovat konstrukci arény tak, aby případná údržba objektů 7 - 9 mohla probíhat za plného provozu systému. Například oprava (výměna) motoru pohyblivé překážky, která je
zasunuta, může probíhat i v případě, že se po ploše arény pohybuje jeden nebo několik
robotů.
Činností, která bude prováděna i za předpokladu dlouhodobého bezchybného provozu
systému SyRoTek, je modifikace nepohyblivých překážek. Změny charakteru prostředí
arény, například prostředí typu bludiště nebo volný prostor o maximální velikosti, nelze
docílit změnou polohy pohyblivých překážek. Montáž a demontáž nepohyblivých překážek
je proto vhodné podpořit vhodným nástrojem, který umožní modifikaci plochy bez nutnosti odstávky systému SyRoTek. Bezpečnostním požadavkem však může být krátkodobé
zadokování všech robotů na ploše.
Konstrukci arény je také vhodné doplnit o nástroj pro vlastní čištění arény, který umožní
vyčistit plochu arény z prostoru dveří stěn kolem arény. S čištěním plochy arény také souvisí
odstranění nepohyblivého robotu z plochy, které je také vhodné podpořit nástrojem pro
manipulaci s robotem z prostoru dveří arény.
Z předcházejících požadavků na přístupnost k jednotlivým objektům systému SyRoTek
a plánované umístění arény v místnosti, je vhodné umístit dokovací prostor u některé ze
stěn, které sousedí s volným prostorem místnosti. Desku arény je vhodné umístit ve výšce
70 až 90 cm. Prostor pod deskou arény je kromě nezbytných konstrukčních částí využit
pro uložení mechanismů pohyblivých překážek a počítačů. Obě stěny arény jsou doplněny
dveřmi o maximální možné šíři danou konstrukčním řešením, nejméně však 120 cm. Na
obrázku 8.4 je schematicky znázorněno možné rozvržení arény.
120/217
KAPITOLA 8. ARÉNA
SyRoTek - V003.1
SP13
SP14
SP15
SP16
SP17
Dokovací prostor
SP19
SP20
SP18
SyRoTek
aréna
RP1
stěna
dveře
Obrázek 8.4: Rozvržení arény systému SyRoTek.
121/217
SyRoTek - V003.1
Kapitola 9
Servisní rozhraní
Servisní rozhraní (jak bylo naznačeno na obrázku 2.1 zprávy [1]) je propojeno se všemi
základními objekty systému SyRoTek. Hlavním účelem servisního rozhraní je monitorování
a údržba všech softwarových částí systému. Administrativní činnost spojená s údržbou je
velmi podobná instalačnímu procesu, neboť při aktualizace některé softwarové části je
nutné ověřit kompatibility příslušné konfigurace pro starší verze.
V tabulce 9.1 jsou uvedeny základní administrativní úkony.
Název
Instalace
Konfigurace
Aktualizace
Aktualizace HW
Logování
Zpracování logů
Zálohování
Hlášení
Údržba a servis hardware
Popis
Instalace jednotlivých softwarových komponent.
Konfigurace jednotlivých softwarových komponent.
Instalace a konfigurace nové verze softwarové komponenty,
ověření správné funkce.
Výměna některé hardwarové komponenty.
Sběr záznamů o průběhu činnosti jednotlivých částí systému.
Analýza a zpracování logů.
Záloha instalovaných programu a vytvářených dat, obnova
instalace a dat.
Pravidelné vytváření zpráv o stavu příslušných softwarových komponent, případně hardwarových komponent.
Pravidelné kontroly a údržba hardwarových komponent
systému SyRoTek.
Tabulka 9.1: Základní administrativní úkony servisního rozhraní systému SyRoTek.
Hlavní význam rozdělení Instalace a Konfigurace spočívá především v granularitě administrátorských pravomocí jednotlivých správců systému SyRoTek. Instalaci může zpraČVUT FEL, Gerstner Laboratory, ProTyS a.s.
122/217
KAPITOLA 9. SERVISNÍ ROZHRANÍ
SyRoTek - V003.1
vidla provádět pouze super-uživatel, který po základní instalaci může prostředí softwarové
aplikace nastavit tak, že vlastní konfiguraci již může provádět jiný uživatel s omezenými
pravomocemi. Vhodným rozdělení úloh a definování více administrátorských rolí lze snížit
riziko nechtěných konfiguračních zásahů a zároveň snížit závislost na konkrétním pracovníkovi. Super-uživatel je většinou velmi zkušený uživatel, který si je vědom vazeb a závislostí
mezi jednotlivými softwarovými komponentami. Je přirozené, že vhodných pracovníků se
zkušenostmi pro roli super-uživatele je pouze mizivé procento, proto je vhodné realizovat alespoň částečnou zastupitelnost těchto špičkových pracovníků. Dílčí konfigurace může
zvládnout i méně zkušený uživatel, který v rámci své uživatelské role nemůže způsobit
příliš veliké škody v konfigurací ostatních softwarových komponent, jeho činnost je tak do
jisté míry nezávislá na super-uživateli.
Při bezchybné funkci všech hardwarových částí systému SyRoTek lze předpokládat, že
případné chyby jsou způsobeny chybnou konfigurací nebo chybou v software. V praxi je
však přirozeným důsledkem používání hardwarových částí jejich opotřebení, které může
vést k případných chybám, proto je vhodné chybám předcházet pravidelnými servisními
prohlídkami a včasnou výměnou příslušných částí. Z tohoto pohledu probíhá údržba hardwarových části převážně v čase periodicky, naproti tomu údržba softwarových částí je
zpravidla aktivována nějakou událostí, např. nová verze nebo rozšíření funkce příslušného
software1 .
Jednou z nejdůležitějších vlastností všech spouštěných softwarových komponent je jejich
schopnost znovuspuštění v případě, že nebyly korektním způsobem ukončeny. Pokud nelze
aplikaci opětovně bezpečné spustit v případě předchozího pádu, je nutné doplnit start aplikace o hlášení tohoto stavu příslušnému správci. Příklad aplikací, které vyžaduje manuální
asistenci jsou databázové systémy, které ukládají mezi-výsledky prováděných transakcí. Ve
většině případů lze nastavit automatické zotavení po předchozím náhlém ukončení aplikace, autoři těchto systému však tuto vlastnost nepovolují v základní konfiguraci, neboť
nemohou garantovat, že akce provedené při automatickém zotavení jsou v dané chvíli tím
nejlepším řešením.
Přirozenou součástí údržby softwarových komponent je uživatelská podpora, respektive
oprava softwarových částí na základě zpětné vazby od uživatelů.
V následujícím oddíle jsou shrnuty základní informace o údržbě hardwarových komponent systému SyRoTek. V oddíle 9.2 je uveden návrh administrátorských rolí. Přístup
správců systému SyRoTek k servisnímu rozhraní je diskutovány v oddíle 9.3. V následujícím oddíle jsou uvedeny poznámky k logování a zpracování logů. Předposledním oddílem
této kapitoly je zálohování, ve kterém jsou definovány základní principy zálohování v systému SyRoTek, která navazuje na oddíl 4.9 zabývající se zálohováním uživatelských dat.
V závěru jsou shrnuty základní požadavky na dílčí softwarové komponenty systému SyRoTek z hlediska jejich údržby.
1
Výjimku samozřejmě tvoří pravidelné zálohování, neboť zálohovat až po chybě zpravidla nepřináší
očekávaný efekt.
123/217
9.1. ÚDRŽBA HARDWAROVÝCH KOMPONENT
9.1
SyRoTek - V003.1
Údržba hardwarových komponent
Pravidelná údržba hardwarových částí se týká v systému SyRoTek převážně objektů
arény, robotů a senzorů. Součástí údržby arény je také údržba mechanických části systémů
vizualizace a lokalizace. Základní úkony údržby těchto objektů jsou diskutovány v oddíle 8.6, neboť souvisí s arénou, resp. konstrukcí arény.
Ostatní hardwarové vybavení systému SyRoTek je tvořeno výpočetní technikou. Ta
obsahuje řadu mechanických částí, mezi které převážně patří ventilátory a pevné disky.
V případě ventilátorů dochází během používání ke snižování účinnosti vlivem opotřebení a
prachu. Pravidelné čištění v intervalu 6-ti až 12-ti měsíců je dostačující. Případná výměna
je typicky nutná v horizontu 2 až 4 let provozu, v závislosti na periodě čištění a technologii
použitých ložisek ventilátorů. Z pohledu plánované doby provozu systému SyRoTek je
opotřebení těchto částí zanedbatelné.
Pevné disky mají výrobcem specifikovanou střední dobu bezporuchového provozu. Navíc
jsou standardně vybaveny technologií S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) [55], která poskytuje dodatečné indikátory spolehlivosti disku. Indikaci
blížícího se selhání lze využít pro naplánování odstávky, případně on-line výměnu disku.
V případě poruchy (výměny) disku je v závislosti na mechanismu zálohování nutné obnovit instalaci aplikací a uživatelských dat nebo pouze disk fyzicky vyměnit je-li využito
redundantního zapojení disků (např. RAID-5 nebo RAID 1).
Ostatní hardwarové komponenty počítače typicky morálně zastarají dříve než se u nich
projeví chyby způsobené používáním. V případě výměny některé komponenty ať už z důvodu chyby nebo posílení výkonu je nutné příslušný počítač odstavit a provést vlastní
fyzickou výměnu. Přestože současné komponenty běžného počítače jsou více standardizované a kompatibilní než tomu bylo před několika lety, stále existuje riziko vzájemné
nekompatibility jednotlivých částí. Nejčastěji se to stává při kombinaci starší komponenty
s novější (např. základní deska a grafická karta), kdy přestože jsou vzájemné rozhraní kompatibilní starší komponenta nerozpozná novější. Tyto situace představují vážným problém,
pokud výrobce starší komponenty neposkytuje opravný, resp. aktualizační, firmware. V takových případech je nutné vyměnit více komponent. Samozřejmostí v takových případech
bývá přizpůsobení příslušného operačního systému. Velkou výhodou operačních systému
typu FreeBSD a Linux je, že v těchto případech není nutné systém znovu instalovat. Operační systém je zpravidla možné běžně spustit (případně spustit v režimu administrace2 ) a
upravit příslušnou konfiguraci nebo ovladač.
Potenciální problémy uvedené v předchozím odstavci je možné částečně eliminovat specializovaným (serverovým) hardwarem, u kterého dostupnost resp. zaměnitelnost komponent
garantuje výrobce nebo dodavatel. Ceny těchto řešení jsou však typicky řádově vyšší než
u běžných komponent, případně vyšší než u komponent vyššího standardu nebo exkluzivní
kategorie3 .
2
3
Single user mode.
Top, High End
124/217
9.2
SyRoTek - V003.1
Administrátorské role
V úvodu této kapitoly byly vysvětleny důvody definování dílčích administrátorských
rolí. Jedním z těchto důvodů je vzájemná zastupitelnost jednotlivých správců systému
SyRoTek. Návrh jednotlivých administrátorských rolí je uveden v tabulce 9.2.
Role
Hlavní administrátor systému
SyRoTek
super-uživatel
serveru
autentizačního
super-uživatel webového serveru
super-uživatel
serveru
vizualizačního
super-uživatel lokalizačního počítače
super-uživatel řídicího počítače
Popis
Administrátor má přístup ke všem částem systému, je zodpovědný za funkčnost systému SyRoTek jako celku.
Administrátor je především zodpovědný za správu
operačního systému a instalaci příslušného autentizačního / autorizačního serveru (LDAP).
Administrátor je zodpovědný za správu operačního systému a instalaci příslušného webového serveru, včetně všech příslušných modulů a závislosti.
Součástí webového serveru je také přístup k uživatelským repositářům se zdrojovými kódy.
Administrátor je zodpovědný za správu operačního systému a instalaci potřebného software vizualizačního serveru, zejména instalace (konfigurace) ovladačů a nastavení přístupových práv odpovídajících abstraktních zařízení operačního systému.
Administrátor je zodpovědný za správu operačního systému a instalaci potřebného software lokalizačního serveru, zejména instalace (konfigurace)
ovladačů a nastavení přístupových práv odpovídajících abstraktních zařízení operačního systému.
Administrátor je zodpovědný za správu operačního systému řídicího počítače, jeho napojení na
autorizační server a přístup k domovskému adresáři, propojení s webovým serverem a serverem
poskytující repositáře. Dále administrátor zajišťuje konfiguraci propojení řídicího počítače s lokalizačním a vizualizačním serverem a zapojení
řídicího počítače do lokální WiFi sítě. Součástí administrace je také připojení dílčích periferií k řídicímu počítači, ovládání překážek, RF komunikace
s roboty, spolu s příslušným nastaveními přístupových práv abstraktních zařízení reprezentující
tato rozhraní.
125/217
9.2. ADMINISTRÁTORSKÉ ROLE
Role
super-uživatel palubního počítače
správce autentizačního serveru
správce webového serveru
správce vizualizačního software
správce uživatelského prostoru
správce programového vybavení
řídicího počítače.
správce programového vybavení
robotu
správce systémových aplikací řídicího počítače
správce systémových aplikací
palubního počítače
správce webového rozhraní
hlavní správce zdrojových kódů
systému SyRoTek
SyRoTek - V003.1
Popis
Administrátor je zodpovědný za správu operačního systému palubního počítače a replikaci instalace na všechny roboty, konfiguraci připojení periferií k robotu a zapojení robotu do WiFi sítě. Administrátor také nastavuje přístupová práva abstraktních zařízení reprezentující dílčí rozhraní.
Je zodpovědný za obsah databáze uživatelů,
funkčnost rozhraní pro ostatní aplikace.
Je zodpovědný za instalaci, resp. konfiguraci
webového serveru spolu s příslušnými podpůrnými
moduly, např. php, dav pro svn. Součástí administrace je také konfigurace podpůrných databázových serverů, resp. přístupů příslušných webový
aplikaci k databázím.
Správce je zodpovědný za konfiguraci a běh aplikace pro vizualizaci.
Správce je zodpovědný za využívání uživatelského
prostoru, především za podpůrné soubory pro uživatele a základní konfigurace uživatelského prostředí.
Správce je zodpovědný za programové vybavení řídicího počítače, konfigurace křížových překladačů
a podpůrných knihoven pro příslušné cílové platformy.
Správce je zodpovědný za programové vybavení
robotu, především verze příslušných firmware jednotlivých MCU.
Správce je zodpovědný za provoz systémových
aplikací na řídicím počítači, jejich automatické
spuštění. Je také zodpovědný za vyřizování požadavků na vlastnosti systémových aplikací ze
strany uživatelů.
Správce je zodpovědný za provoz systémových
aplikací na palubním počítači, jejich automatické
spuštění.
Správce je zodpovědný za konfigurace a funkčnost
příslušných modulů hlavního přístupového webového rozhraní.
Správce je zodpovědný za zdrojové soubory systému SyRoTek jako celku, přístup k repositáři (repositářům).
126/217
Role
správce zdrojových kódů systému SyRoTek
SyRoTek - V003.1
Popis
Správce je zodpovědný za dílčí části zdrojových
kódů. Základní kategorie zdrojových kódů jsou:
• systémové aplikace pro řídicí a palubní počítač,
• řídicí software MCU robotu, spolu s příslušným firmware inteligentních senzorů,
• lokalizační aplikace,
• vizualizační aplikace,
• podpůrné knihovny a aplikace pro uživatele.
Tabulka 9.2: Role administrátorů systému SyRoTek.
Jednotlivé role super-uživatele mohou splynout v závislosti na realizaci jednotlivých serverů, resp. počítačů. Super-uživatelé jsou také zodpovědní za zálohování příslušné instalace
operačního systému na nejvyšší úrovni, viz ??. Součástí jejich zodpovědnosti je také příslušný hardware, resp. ověření správné činnosti, případně doporučení na výměnu / koupi
alternativního hardware.
Jednotlivé role správců, případně super-uživatelů mohou být přiděleny více než jedinému pracovníkovi. Při změně příslušné konfigurace je proto vhodné vytvářet záznamy
o provedených změnách, které je vhodné ukládat některým systémem pro správu verzí. Při
verzování konfigurační souborů je však nutné zajistit dostatečné zabezpečení, neboť konfigurační soubory mohou obsahovat citlivá data jako jsou například přístupová hesla pro
některé služby (např. php skripty používají typicky konfigurační soubor s uloženým uživatelským jménem a heslem pro přístup do databáze). Z tohoto hlediska použití verzovacího
systému Subversion nemusí být vhodné. Alternativou je použití lokálního verzování systémem RCS [56]. Je-li přístup konkrétního správce realizován prostřednictvím univerzálního
administrátorského účtu je vhodné při změně konfigurace, doplnit záznam o provedené
změně ve verzovacím systému údajem o skutečném jméně správce.
9.3
Administrátorské rozhraní
Administrátorské rozhraní je přístupovým bodem správce k systému SyRoTek. Hlavní
rozhraním je služba bezpečného vzdáleného přihlášení k systému ssh, kterou lze využít
pro téměř libovolný administrativní zásah. Výjimku tvoří administrativní zásahy, které
127/217
9.4. LOGOVÁNÍ A ZPRACOVÁNÍ LOGŮ
SyRoTek - V003.1
nějakým způsob souvisejí s přerušení síťového připojení a jeho manuálním obnovením až
po odpojení. Z pochopitelných důvodů po odpojení síťového připojení již není možné se
vzdáleně připojit.
Vzdálený přístup k palubnímu počítači je nutné realizovat přípojení na řídicím počítač,
ze které je možné se připojit do privátní WiFi sítě, ke které jsou připojeny roboty.
Z bezpečnostních důvodu je základem konfigurace ssh serveru zakázaní přihlašování privilegovaného uživatele root, proto se příslušný super-uživatel musí nejdříve do systému
přihlásit svým běžným uživatelským účtem a následně změnit svoji identitu na uživatele
root. Výhodou tohoto mechanismu je množnost zaznamenávání jednotlivých administrátorských přístupů.
Hardwarové úpravy a administrátorské zásahy související s restartem příslušného počítače jsou prováděny prostřednictvím dedikovaného terminálu, tzv. konzole (respektive skutečné konzole), který je přímo připojen k počítači. Terminál může být realizován klávesnici
a monitorem, tak jak je běžné v případě stolních počítačů. Z hlediska instalace více počítačů je vhodné tuto možnost realizovat jedinou klávesnici a jediným monitorem, který je
součástí příslušného uspořádaní počítačů v rámci konstrukce arény a přístup k jednotlivým
počítačům řešit přepínačem, který volí vstup/výstup konkrétního počítače. Alternativním
řešením je konfigurace příslušných počítačů tak, že základním rozhraní konzole je sériový
port počítače. Tento způsob přístupu je v případě palubního počítače jediným možný, neboť ten není vybaven grafickým rozhraním, resp. výstupem pro monitor. Rozhraní konzole
je textové. Výhodou tohoto přístupu je možnost připojení k příslušnému počítače z notebooku, na kterém mohou být zobrazovány dodatečné informace, např. příslušné systémové
příručky. Při této variantě realizace hardwarového servisního rozhraní je vhodné doplnit
konstrukci arény o panel s příslušnými porty konzole každého počítače umístěného v rámci
konstrukce arény.
Hardwarové servisní rozhraní cMCU a MCU reprezentují konektory pro plné přeprogramování robotu, v běžné případě bude využíváno režimu BootLoader. Popis principu tohoto
režimu je součástí oddílu 6.2.1.
Kromě základního přímého přístupu a vzdáleného přístupu prostřednictvím ssh, je
vhodné v některých případech realizovat webové administrátorské rozhraní. To je výhodné
především pro dílčí administrativní zásahy jako je správa aplikací nebo zdrojových kódů.
Toto rozhraní je však nezbytné pro správu webového rozhraní příslušného systému pro podporu vzdáleného vzdělávání (LMS), neboť již z podstaty je tato aplikace aplikací webovou.
9.4
Logování a zpracování logů
Logování představuje soubor mechanismů vytváření a uchovávání záznamů z průběhu
činnosti dílčích aplikací spuštěných na počítačích systému SyRoTek. Z hlediska typu aplikace, která vytváří log, lze v systému SyRoTek rozlišit tři základní kategorie logů (aplikací):
128/217
SyRoTek - V003.1
• logy systémových aplikací operačního systému,
• logy systémových aplikací SyRoTek,
• logy uživatelských aplikací.
9.4.1
Logy systémových aplikací operačního systému
Systémové aplikace typicky využívají hlavní systémový mechanismu logování (logger),
který je součástí základního aplikačního rozhraní operačního systému, tak zvaný syslog,
viz man syslog, resp. man logger. Systémový logger bývá zpravidla bohatě konfigurovatelný,
včetně možnosti vzdáleného logování. Tento logger mohou využít základní systémové služby
jako je například přihlašování uživatelů. Výhodou tohoto mechanismu je centralizované nastavení v rámci konkrétní instalace operačního systému. V případě více počítačového prostředí lze systémový logger konfigurovat tak, že jednotlivé systémové logy jsou ukládány
centrálně na jediný server a tím zjednodušují přístup k příslušným logům. Je-li v takovém
prostředí však použito více typů (druhů) operačního systémů, které používají různé implementace loggerů, může být realizace správné konfigurace každé konkretní implementace
náročná. Z aplikačního hlediska, resp. uživatelského hlediska, není multiplatformnost zásadním problémem, neboť funkční volání jsou většinou kompatibilní s normou IEEE Std
1003.2.
V případě systémových aplikací, jako je například webový server apache, vzniká velmi
velké množství záznamu, neboť je vhodné ukládat všechny příchozí požadavky a to nejen
z bezpečnostních důvodů, ale především z hlediska vyhodnocování přístupů uživatelů. Tyto
záznamy jsou však typicky zpracovávaný dávkově a je možné je ukládat do specializovaných souborů mimo hlavní systémový logger. Výjimku tvoří chybové výstupy samotného
webového serveru, případně dílčích modulů serveru, které mohou být oddělené od hlavního
chybového výstupu webového serveru jako je tomu v případě php modulu serveru apache.
Zpracovávání záznamů může probíhat on-line nebo dávkově. On-line zpracování má význam pouze pro kritické služby a to zpravidla pouze v případě kritické chyby. Výsledek
tohoto zpracování je hlášení příslušnému správci v podobě e-mail, IM nebo SMS zprávy.
Takto jsou hlášeny chyby, které souvisí s detekcí nefunkčnosti některé aplikace způsobené
jejím pádem a chybou při opětovném restartu nebo systémové chybě typu nedostatek místa
v souborovém systému. Z hlediska průběžného sledování systému je vhodné zasílat každý
den správci (správcům) informační e-mail se popisem stavu jednotlivých částí výpočetní
systému a operačního systému. Součástí těchto denních zpráv mohou být následující informace:
• počet restartů,
• počet pokusů o neoprávněný přístup,
• aktuální stav souborových systémů (volné místo),
129/217
SyRoTek - V003.1
• průměrné zatížení procesorů,
• informace o změnách připojených jednotek,
• informace o změnách systémových aplikací (nastavení takzvaného setuid bitu),
• počet přihlášení super-uživatele,
• informace o potenciálních zdrojích útoků (vyhodnocení firewall záznamů).
Kromě denních hlášení je vhodné zasílat správci (správcům) souhrnné informace o používání jednotlivých počítačů v průběhu delšího časového intervalu. Tato hlášení mohou
obsahovat informace typu:
• počet přihlášení jednotlivých uživatelů,
• průměrné zatížení počítače,
• počet přenesených bytů po síťových rozhraní.
Průběžné vyhodnocování využívání systému SyRoTek je vhodné doplnit statistikou počtu přístupu k webovému rozhraní a řídicímu počítači. Součástí této statistiky jsou informace o uživatelské stanici (např. platforma, země původu, webový prohlížeč), preferovaný
způsob přihlašování. Pro vytváření těchto statistik je vhodné kombinovat již existující aplikace pro zpracování standardizovaných formátů logů, jako je například program webalizer
pro zpracován logů webového serveru [57].
Mezi významné systémové logy patří specifické záznamy o používání vlastního systému
pro podporu vzdálené výuky (LMS), který je vhodné oddělit od vlastního logu webového
serveru, který zaznamenává pouze jednotlivé dotazy webového serveru bez interpretace.
Dalším důležitým systémových logem je vyhodnocování používání verzovacího systému,
resp. přístup k repositářům s podpůrnými zdrojovými souboru pro uživatele systému SyRoTek.
Pro každou systémovou aplikace je z hlediska logování vhodné definovat:
1. formát logu,
2. mechanismus logování (výstupní soubor),
3. mechanismus zpracování,
4. interval vyhodnocení a mechanismus hlášení výsledků zpracování logu.
Na základě těchto definic je možné vytvořit unifikovaný přístup k jednotlivým záznamům
průběhu činnosti dílčích systémových aplikací.
130/217
9.4.2
SyRoTek - V003.1
Logy systémových aplikací SyRoTek
Logy těchto systémových aplikací jsou hlavním zdrojem informací užitečných při odhalování případných implementačních chyb. Tyto logy jsou zdrojem podstatných informací o používání systému SyRoTek zejména řešení úloh formou implementace uživatelské
aplikace. Průběžné vyhodnocování činnosti uživatele lze využít pro zlepšení uživatelského
rozhraní a celkové efektivity systému.
Zvláštní skupinu tvoří logovací záznamy palubního počítače, resp. jednotlivých MCU
robotu, tyto záznamy jsou přenášeny do prostoru řídicího počítače, kde mohou být použity pro další vyhodnocování, případně on-line vyhodnocování kritických stavů robotu.
S ohledem na kapacitu komunikačního spojení je vhodné některé záznamy přenášet v době
komunikačního klidu, kdy nejsou roboty aktuálně využívány nebo v době mezi jednotlivými registrovanými sezeními, kdy probíhá konfigurace prostředí a robotů pro konkrétní
úlohu.
Výše uvedené úvahy vedou na požadavek unifikace logovacího mechanismu v rámci
všech systémových aplikací SyRoTek. Unifikaci lze provést využitím hlavního systémového
loggeru a však z hlediska předpokladu partikulárního on-line zpracování logů z robotu
spolu s dávkovým vyčítaní záznamů je vhodné realizovat hlavní SyRoTek systémový logger odděleně od hlavního systémového loggeru operačního systému, neboť tak lze dosáhnout mnohem větší flexibility s ohledem na multiplatformnost prostředí dílčích počítačů
v systému SyRoTek.
Konfigurace logovacího prostředí systému SyRoTek se skládá z dílčích konfigurací jednotlivých palubních počítačů spolu s příslušnými MCU. Součástí tohoto logovacího prostředí jsou i aplikace související s podporou uživatelské práce v rámci řídicího počítače.
Dílčí logovací záznamy proto musejí obsahovat kromě informace o zdroji záznamu (modul,
aplikace, počítač) a záznamu o úrovni chyby (ladění, varování, chyba) také informaci o konkrétním uživateli, který příslušnou službu systémové aplikace využívá. Základní informace
každého záznamu logu jsou uvedeny v tabulce 9.3.
Kategorie
Čas
Podkategorie
Rok
Měsíc
Den
Hodina
Minuta
Sekunda
Milisekunda
Host
Popis
Čas vzniku události dle systémového času příslušného počítače.
V případě časově kritických událostí je
vhodné zaznamenat také milisekundy pro
přesnější vyhodnocení průběhu činnosti.
Identifikace počítače, na kterém je aplikace
spuštěna.
Místo
131/217
Kategorie
Podkategorie
Aplikace
Modul
Vlákno
Soubor
Řádek
DEBUG
INFO
Typ
WARNING
ERROR
STATUS
Úroveň
0-9
SyRoTek - V003.1
Popis
Identifikace aplikace, která generuje příslušný
záznam.
Bližší specifikace modulu v rámci spuštěné
aplikace.
Bližší specifikace konkrétního vlákna v rámci
jehož činnosti záznam vzniká.
Informace o jménu zdrojového souboru, ve
kterém je voláno příslušné vytváření záznamu, tento údaj je vhodný především z hlediska ladění aplikace.
Informace o konkrétní řádku zdrojového souboru, ve kterém je vytvářen příslušný záznam, tento údaj je vhodný především pro
ladící účely.
Záznam zejména pro ladění.
Informativní záznam doprovázející standardní běh aplikace.
Upozornění na chybu, která však není kritická, chyba byla zachycena a aplikace může
pokračovat v činnosti.
Závažná chyba, aplikace nemůže pokračovat v činnosti, konkrétní vykonávaná operace
bude přerušena.
Záznam obsahuje statistické informace a průběhu činnosti aplikace.
Umožňuje dílčí řízení úrovně logovacích záznamů, vhodné především pro ladící výpisy
při testování správné funkce aplikace.
Tabulka 9.3: Základní informace záznamu logu systému SyRoTek.
V souvislosti s on-line vyhodnocením je příslušného záznamu je vhodné definovat reakci
na příslušný záznam. Reakci lze přiřadit příslušné kategorii (resp. podkategorii) záznamu
dle místu vzniku, typu a úrovně příslušné události. V případě přeposlaných logů z palubního
počítače je tato konfigurace uveden jak na palubním počítači, tak na řídicím počítači.
Konfigurace loggeru pro příslušnou množinu záznamu obsahuje:
• způsob uložení (okamžité přeposlání, lokální uložení nebo dávkové přeposlání),
• algoritmus on-line zpracování,
132/217
SyRoTek - V003.1
• algoritmus dávkového zpracování.
Součástí algoritmů zpracování je také předpis pro vytvoření zprávy hlášení a konfigurace
příslušného mechanismu hlášení podobně jako v případě systémových logů operačního systému, tedy e-mail, IM nebo SMS zpráva.
Výsledky zpracování některých logů, zvláště stavových (statistických), je vhodné zahrnout do webového rozhraní systému SyRoTek, neboť tvoří základní přístupový bod uživatele k systému. Například informace o právě probíhající odstávce systému se mohou on-line
aktualizovat v závislosti na aktuálním stavu dílčích podsystémů a případní uživatelé jsou
tak včas informováni.
9.4.3
Logy uživatelské aplikace
Mezi logy uživatelské aplikace patří nejen výstup vlastní uživatelské aplikace, ale také
výstup serveru Player. Uživatelská aplikace může využít mechanismu logování ze systému
Player nebo mechanismus logování systémových aplikací SyRoTek. Vzhledem k možnosti
vytváření těchto logů na uživatelské stanici nejsou tyto záznamy zahrnuty do hlavního
logovacího systému SyRoTek. Z hlediska údržby jsou tyto uživatelem vytvořené logovací
záznamy použity pouze v rámci uživatelské podpory při řešení problému systémové nebo
9.5
Zálohování
Nedílnou součástí komplexního systému SyRoTek je zálohování. Hlavní hardwarovou
komponentou systému jsou roboty, které budou na ploše (resp. v dokovacích místech)
arény v redundantním počtu. V případě poruchy některého robotu, bude tento robot zastoupen libovolným robotem připraveným k použití, který má odpovídající konfiguraci.
Paralelní zálohování ostatních hardwarových komponent není uvažováno. Při poruše některé hardwarové části systému SyRoTek bude alternativně řešena oprava substitucí nebo
částečným omezením provozu. Například při poruše lokalizační kamery, může být kamera
nahrazena alternativní kamerou, která se na řešitelském pracovišti používá při řešení jiných
výzkumných aktivit souvisejících s autonomní navigací robotu.
Z hlediska systémových a uživatelských aplikací lze rozlišit dva základní typy zálohování:
• zálohování systémových aplikací,
• zálohování uživatelských dat.
Detailní diskuse zálohování uživatelských dat je uvedena v oddílu 4.9 kapitoly 4. Zálohování
systémových aplikací jsou uvedeny v následujících odstavcích.
Z jiného úhlu pohledu lze zálohování rozlišit podle úrovně zálohování:
133/217
9.6. SOFTWAROVÉ POŽADAVKY Z HLEDISKA ÚDRŽBY
SyRoTek - V003.1
• zálohování na úrovni souborového systému,
• zálohování na úrovni aplikací a dat.
Zálohování prováděné na úrovni souborového systému je kompletní zálohou operačního
systému jako celku (včetně všech souborů). Je také nejvíce náročné na potřebný diskový
prostor. Realizace tohoto zálohování může probíhat na hardwarové úrovni redundantním
zapojení disků, například RAID 1 nebo RAID-5. Alternativou je zálohování souborových
systému na softwarové úrovni. V tomto případě probíhá nejdříve vytvoření obrazu aktuálního stavu souborového systému, takzvaný snapshot, který je následně použit pro vytvoření
plné (případně inkrementální) zálohy souborového systému běžnými nástroji operačního
systému, např. dump v operačním systému FreeBSD. Tuto technologií například podporují
souborové systémy UFS [58] a ZFS [59]. Tento typ zálohování je vhodný pro vytváření pravidelných záložních kopií, pouze některých souborových systému. Jistou výhodou tohoto
přístupu může být také možnost více záloh z různých časových okamžiků. Při praktické realizaci je vhodné vytváření příslušných záloh souborových systému hlavního pevného disku
provádět v pravidelných intervalech (např. jednou denně) a ukládat soubor se zálohou na
jiný pevný disk, nejlépe externí, případně disk umístěný v jiném počítači.
Zálohování systémových aplikací lze rozdělit na zálohování instalace příslušné aplikace
a zálohování příslušných konfiguračních souborů. Systémové aplikace jsou v moderních
operačních systémech typicky instalované v rámci příslušného systému pro správu instalovaných aplikací. Tedy obnovení aplikace spočívá pouze v její přeinstalování a konfiguraci.
Řada aplikací využívá konfigurační soubory umístěné ve vyhrazeném adresáři operačního
systému, proto je velmi snadné konfiguraci zálohovat na úrovni příslušných souborů, resp.
adresářů. Rozšíření tohoto způsobu zálohování lze chápat jako vytvoření instalačních souborů, ze kterých je možné softwarovou část systému SyRoTek obnovit. Jsou-li tyto instalační soubory doplněny o pravidelné zálohování uživatelských dat a dat vytvářených
systémovými aplikace, lze tímto způsobem realizovat kompletní systém zálohování.
9.6
Softwarové požadavky z hlediska údržby
Z hlediska údržby jsou na dílčí softwarové komponenty systému SyRoTek kladeny požadavky, které souvisí především s dokumentací příslušné části a snadným přístupem. V tabulce 9.4 jsou uvedeny dílčí požadavky na jednotlivé aplikace (software části) použité
v rámci systému SyRoTek.
Požadavek
Závislosti
Konfigurace
Popis
Definice nutných softwarových závislosti pro spuštění aplikace.
Popis základní konfigurace aplikace, umístění konfiguračního souboru/ů a popis závislosti pro správný chod aplikace.
134/217
Požadavek
Logování
Zotavení
Start
Stop
Rekonfigurace
Dokumentace
Bezpečnost
SyRoTek - V003.1
Popis
Popis konfigurace logování, logovacích souborů a základní
příznaků správné/špatné funkce aplikace.
Automatické zotavení aplikace při nečekaném ukončení,
případně indikace nutnosti manuálního řešení problému
znovuspuštění aplikace.
Definice mechanismu explicitního ověření správného startu
aplikace.
Mechanismus korektního ukončení aplikace, aktivovaný například při zachycení standardního signálu SIGTERM.
Podpora rekonfigurace aplikace za běhu, případně znovu
načtení konfiguračního souboru, v minimální verzi lze řešit
sekvencí stop, start.
Dokumentace k příslušné aplikaci.
Stručný popis potenciálních bezpečnostních rizik při spuštěné aplikaci.
Tabulka 9.4: Základní požadavky na jednotlivé softwarové části systému SyRoTek z hlediska údržby.
Na software implementovaný v rámci řešení projektu SyRoTek je dále kladen důraz
na vhodný kódovací styl příslušných zdrojových souborů, umístění zdrojových souboru
v repositáři a dokumentaci komplexních částí zdrojových souborů, případě explicitní forma
dokumentace používání a základního principu (architektury) software. Tento požadavek má
praktický význam při údržbě aplikací, kdy je nutné zasahovat do zdrojových kódů, které
musejí být dobře čitelné.
135/217
SyRoTek - V003.1
Kapitola 10
Lokalizační systém
Úkolem lokalizačního systému je poskytovat údaje o poloze robotů na ploše arény v čase.
S ohledem na přenosová zpoždění, je nutné uvažovat data o poloze jako o historických
údajích a využívat predikce současné, resp. budoucí polohy. Údaje o absolutní pozici robotu
v čase jsou důležité nejen při řešení navigačních úloh, ale také slouží jako základní údaj pro
evaluaci úloh, které řeší účastníci robotického výukového kurzu. Neméně podstatnou částí
je řízení bezpečnosti pohybu robotu. Při pohybu musí robot respektovat pozice dalších
robotů, které nemusejí být přímo detekovatelné lokálními senzory, v těchto případech je
systém globální lokalizace jediným použitelným senzorem. V případě vizualizace založené
na trojrozměrném modelu jsou potřebná data o všech robotech. Z těchto důvodu můžeme
o lokalizačním systému hovořit jako o globálním lokalizačním systému, který má vždy údaje
o všech robotech na ploše arény.
Systém globální lokalizace ve vnitřní prostředí lze založit na různých technologií. Výběr
vhodné způsobu řešení je ovlivněn především faktem, že plocha arény je v systému SyRoTek
omezena a je požadována přesnost v řádu jednotek centimetrů. Možné dostupné technologie
pro realizaci lokalizačního systému je možné založit na sonarových systémech, rádiových
systémech nebo kamerových systémech.
Sonarové systémy dosahují přesnosti řádu centimetrů [60]. Lze uvažovat o konfiguraci,
ve které je každý robot vybaven sonarovým vysílačem a pozice je počítána trilaterálním
algoritmem z doby letu ultrazvukového signálů k několika pevným přijímací stanicím [61].
Nevýhodou tohoto systému je sekvenční odpalování ultrazvukového signálu z každého robotu a možné problémy s odrazy.
Rádiové systémy je možné rozdělit na detekci značek a měření síly radiového signálu. Detekce využívá technologie RFID a v mobilní robotice se používá jako podpůrná metoda pro
navigaci ve vnitřním prostředí [62]. Lokalizace měřením síly radiového signálu se používá
v síťových infrastrukturách WIFI nebo GSM, případně lze využít nízko-příkonových senzorových sítí, například typu ZigBee [63]. Autoři v [64] porovnávají různé přístupy a shrnují
principiální omezení dosažitelné přesnosti lokalizace těchto systému, uvádějí dosažitelnou
přesnost v řádu desítek centimetrů.
136/217
KAPITOLA 10. LOKALIZAČNÍ SYSTÉM
SyRoTek - V003.1
Přístup založený na detekci laserového paprsku uvádějí autoři v [65]. Tato metoda poskytuje přesnost polohy řádově v jednotkách centimetrů, avšak lokalizace je řádově v desítkách sekund, což je způsobeno především opakovaným měřením a výpočtem odhadu
střední hodnoty.
Lokalizační systém NorthStar [66] je komerčně dostupný systém pro lokalizaci ve vnitřních prostorech. Systém se skládá z projektorů (obrázek 10.1) a detektorů (obrázek 10.2),
které mohou tvořit různé konfigurace.
Obrázek 10.1: NorthStar projek- Obrázek 10.2: NorthStar detektor.
tor.
V typické konfiguraci projektory promítají obrazce na strop. Detektor umístěný na
robotu přijímá odražené obrazce a z pozorovacích úhlů vypočítavá pozici robotu [67].
Projektory mohou být také použity jako přímé zdroje modulovaného světelného signálu
emitovaného LED. V [68] autor popisuje kalibrační postup a závislosti určení polohy na
vzdálenosti a úhlu detektoru od projektoru. Tento systém dosahuje přesnosti určení polohy
v řádu jednotek centimetrů podle konkrétní konfigurace projektor/detektor.
Výše zmíněně možnosti lokalizace vždy vyžadují aktivní prvek na robotu nebo je lokalizace robotu realizována na vlastním robotu. V obou těchto případech je nutný energetický
zdroj na robotu, pro napájení senzoru, zpracování nebo pro komunikační modul. Ve výjimečných případech, kdy je robot z nějakého důvodů bez energie nebo komunikace, není
možné při těchto způsobech lokalizace získaný údaj o poloze robotu přenést ostatním robotům, respektive do řídicího počítače odkud může být distribuován k uživatelským stanicím.
Z těchto důvodů je vhodné uvažovat o globální lokalizaci všech robotů založené na pasivní
účasti robotů v procesu lokalizace. Toto řešení lze realizovat kamerovým systém, který sleduje plochu shora. Tento způsob realizace se úspěšně používá v systémech robotické kopané
FIRA MiroSot [69]. Typická konfigurace kamerového systému je zobrazena na obrázku 10.3.
Z rozlišení obrazového snímače kamery vyplývá i očekávaná přesnost lokalizace, kterou
lze uvažovat v obrazových souřadnicích 1 pixel, což přibližně odpovídá řádově jednotkám
centimetrů. Hrubá hodnota absolutní přesnosti polohy robotu odpovídá transformaci rozměrů plochy do rozlišení snímače kamery. V současně době jsou již běžně dostupné kamery
s rozlišení 1024x768 a vyšším. Značný vliv na přesnost má radiální zkreslení objektivu,
které způsobuje nerovnoměrné rozložení přesnosti určení polohy robotu. Rozlišení snímaného obrazu úzce souvisí s potřebným datovým tokem nutným k přenesení hrubého obrazu
do jednotky pro jeho zpracování. Propojení kamery s počítačem je možné běžným rozhraním IEEE1394 nebo specializovanými rozhraními pro kamerové systémy. V souvislosti se
137/217
10.1. ZPŮSOBY KAMEROVÉ LOKALIZACE ROBOTU
SyRoTek - V003.1
lokalizační
kamera
plocha s roboty
Obrázek 10.3: Typická konfigurace kamerového systému lokalizace MiroSot.
zpracováním velkých objemů dat jsou dostupné karty určené pro zpracování obrazu, které
kromě vysokorychlostního rozhraní obsahují specializovaný procesor (typicky DSP) a tím
značně snižují nároky na výpočetní výkon procesoru počítače. Pro vysoká rozlišení lze s výhodou použít takzvaných inteligentních kamer, které obsahují specializovanou výpočetní
jednotku pro zpracování obrazu umístěnou co možná nejblíže snímacímu čipu. S nadřazeným počítačem je pak tato inteligentní kamera propojena běžným rozhraním (např. RS232
nebo Ethernet).
Pro zajištění spolehlivé globální lokalizace všech robotů je nejvhodnějším kandidátem
realizace kamerovým systémem s jednou nebo více kamerami umístěnými nad plochou
snímající pohybující se roboty. S ohledem na tuto preferenci jsou v následujících oddílech
popsány možnosti realizace (oddíl 10.1) a možné technologické přístupy spolu s příklady
konkrétních produktů dostupných na trhu (oddíl 10.2).
10.1
Způsoby kamerové lokalizace robotu
Tento oddíl popisuje možné způsoby lokalizace robotů v projektu SyRoTek, které vycházejí ze základní konfigurace používané v robotické kopané, obrázek 10.3. Lokalizace robotu
v projektu SyRoTek je postup identifikující pozici robotu na ploše arény. Pozice na ploše
je s ohledem na rovinný tvar plochy arény vektor [x, y, θ], kde θ je úhel natočení robotu.
Tyto údaje o absolutní pozici v čase lze rozšířit o prvních derivace těchto souřadnic (případně druhé derivace), které jsou vhodné v úloze predikce pozice robotu. Vedle vlastních
souřadnic robotu je také nutno roboty vzájemně rozlišit.
138/217
SyRoTek - V003.1
Identifikaci robotu je možné realizovat umístěním unikátních identifikačních plošek na
robot. Alternativním přístupem je takzvaný tracking, tedy sledováním pohybujícího se identifikovaného robotu. Nejjednodušším způsobem automatické inicializace je pohyb vždy jediného robotu a detekce pohybu robotu v obraze kamery. Pohybující se obrazec je asociován
s konkrétním robotem a při dalším pohybu obrazu robotu se využívá známé korespondence.
Zjištění úhlu natočení robotu lze realizovat ploškou, která obsahuje grafické symboly
pro zjištění natočení, například ploška s šachovnicí na obrázku 10.4. V případě sledování
Obrázek 10.4: Ploška s šachovnicí pro jednoznačné zjištění natočení robotu.
pohybu robotu je odhad úhlu natočení robotu úměrný vektoru rychlosti robotu.
Maximální rychlost robotu ovlivňuje minimální rychlost snímání kamery pro dostatečně
přesné určení polohy robotu. V souvislosti s pohybem robotu je výhodné predikci polohy
robotu podpořit modelem robotu a simulací pohybu [70].
Velikost plochy arény a rozlišení snímače kamery definuje přesnost určení polohy robotu.
V případě větších ploch je možné uvažovat o více kamerách, které sledují různé části polohy
arény nebo o použití kamery s velmi vysokým rozlišením.
Kamera může být barevná s různou barevnou hloubkou nebo černobílá, která typicky
snímá obraz v 256 odstínech šedi. Výhoda barevné kamery je v použití barevných identifikačních značek pro rozlišení konkrétního robotu. Identifikaci robotu je možné založit na
barevné segmentaci obrazu a identifikaci barevného schematu v blízkých barvených segmentech, které relativně málo výpočetně náročná. Barevné rozlišení je však více citlivé na
změnu osvětlení, které mění barevné podání. Je nutné uvažovat kompenzaci změny světelných podmínek a časovou stálost barev, která je ovlivněna použitým barevným materiálem
a sytostí barev, které často vede na blednutí barev v průběhu stárnutí materiálu. Černobílé
identifikační značky jsou stálostí osvětlením ovlivněny mnohem méně. Konkrétní identifikace robotu však vyžaduje unikátní tvar značky. Výhoda černobílých kamer je nižší datový
tok, proto zpravidla tyto kamery nabízejí vyšší rozlišení případně více snímků za sekundu.
Identifikační značky mohou být pasivní nebo aktivní. Lze uvažovat o barevných LED
diodách. ačkoliv není spotřeba LED diody vysoká (desítky mW), z důvodů zmíněných výše,
je vhodné lokalizaci založit pouze na pasivních identifikačních značkách.
Konfigurace kamerového systému může být složena z jedné nebo více kamer pro pokrytí
větší plochy. Případně lze uvažovat o kombinaci barevné kamery sloužící k identifikace
139/217
10.2. TECHNOLOGIE REALIZACE LOKALIZACE
SyRoTek - V003.1
robotu a černobílé kamery pro určení polohy robotu. Kamery lze také rozdělit podle typu
rozhraní, kterým se připojují k počítači, to může být analogové nebo digitální. V případě
analogového signálu je nutné obraz převést do digitální podoby vhodné pro zpracování na
číslicovém počítači. Toto řešení vyžaduje zachytávací zařízení, zpravidla v podobě zásuvné
karty, které zvyšuje výpočetní nároky na zpracování obrazu. V následujícím textu je kamera
vždy uvažována jako kamera s digitálním přenosem.
Možné způsoby kamerového systému jsou shrnuty v tabulce 10.1.
Hledisko
Identifikační značky
Identifikace robotu
Typ kamery
Počet kamer
Kombinace kamer
Způsob
Pasivní identifikační plošky.
Aktivní identifikační značky.
Jednoznačné identifikační značky.
Sledování pohybu robotu.
Barevná kamera.
Černobílá kamera (stupně šedi).
Jediná kamera (vysoké rozlišení).
Více kamer (nižší rozlišení).
Jeden typ kamery (černobílá nebo barevná).
Kombinace barevné a černobílé kamery.
Tabulka 10.1: Způsoby kamerového systému.
10.2
Technologie realizace lokalizace
V tomto oddíle popsány jsou možné realizace kamerového systému z pohledu různých
technologií především úrovní použití specializovaného hardware. Ve všech případech je však
nutné zajistit časovou synchronizaci snímků zjištěné pozice robotů, aby tyto údaje mohli
být použity v úloze predikce a kompenzaci případných dalších dopravních zpoždění.
V souvislosti s výpočetní náročností zpracování obrazu, které vyplývá ze značného objemu dat, se nabízí možnost využití specializovaných zařízení, typicky specializovaných
výpočetních procesorů. Nejjednodušším způsobem je realizace běžným stolním počítačem
se standardními vstupními rozhraními. Standardní rozhraní limitují objem zpracovatelných dat, proto se při zpracování obrazu o velkých rozlišeních a vysokých obnovovacích
frekvencí často používají specializované vysokorychlostní rozhraní, které však vyžaduje
doplňkové zásuvné karty pro počítačové periferní sběrnice typu PCI nebo PCI-E. Dalším
krokem je použití specializovaných procesorů optimalizovaných pro efektivní vykonávání
programů pro zpracovávání obrazu. Tyto procesory mohou být součástí zásuvné karty
s rozhraním pro připojení kamery nebo jsou dnes stále častěji umisťovány blíže vlastnímu
snímacímu čipu kamery a tvoří tak Inteligentní kamery. Velkou výhodou tohoto řešení je
použití standardního rozhraní pro komunikaci inteligentní kamery s počítačem. Na toto
140/217
SyRoTek - V003.1
rozhraní nejsou kladeny takové nároky na šířku přenosového pásma, neboť komunikace
s inteligentní kamerou probíhá pouze na řídicí úrovni.
10.2.1
IEEE1394 rozhraní a běžný stolní počítač
Rozhraní IEEE1394 (FireWire) je dnes již běžnou součástí stolních počítačů. Přenosová
kapacita je 400MBps, respektive 800MBps pro verzi 1394b. Způsob realizace rozhraní limituje používanou délku kabelu na 4,5m v případě běžných kabelů nebo až 10m pro velmi
kvalitní kabel. Pro delší vzdálenosti je nutné použít opakovačů signálu, které přidávají další
dopravní zpoždění. Maximální rychlost limituje rozlišení a snímkovou frekvenci. Dostupné
kamery pro rozhraní 400MBps dosahují rozlišení 640x480 a 30fps s barevným kódováním
YUV 4:2:2. S rozhraním 800MBps je možné dosáhnou vyšších rozlišení.
Tabulka 10.2 obsahuje seznam kamer společnosti Basler [71] s rozhraním FireWire IEEE
1394a (400MBps), tabulka 10.3 pak kamery téže společnosti, avšak s rychlejším rozhraním
IEEE 1394b (800MBps). Nabídka kamer společnosti SONY je zobrazena v tabulce 10.4, ve
které jsou uvedeny jak kamery s rozhraním IEEE 1394a tak IEEE 1394b. Uvedené tabulky
jsou převzaty ze stránek společnosti Total Turnkey Solutions [72].
Typ
A601f
A601fc
A602f
A602fc
A311f
A311fc
A312f
A312fc
A622f
A631f
A631fc
A641f
Popis
Monochrome 1/2” CMOS, 659 x 480 pixels, 60 FPS, 8-bit output
Colour 1/2” CMOS, 659 x 480 pixels, 60 FPS, Digital YUV 4:2:2
or Raw Bayer output
Monochrome 1/2” CMOS, 659 x 480 pixels, 100 FPS, 8-bit output
Colour 1/2” CCD, 659 x 480 pixels, 100 FPS, Digital YUV 4:2:2 or
Raw Bayer output
Monochrome, 1/2” CCD, 659 x 494 Pixels, Digital 8/12-bit output,
73f/s
Colour, 1/2” CCD, 659 x 494 Pixels, Digital 8/12-bit Raw; YUV
4:2:2 output, 73f/s
Monochrome, 1.2”, 782 x 582 Pixels, Digital 8/12-bit output, 53f/s
Colour, 1/2” CCD, 780x 580 Pixels, Digital 8/12-bit Raw;YUV
4:2:2 output, 53f/s
Monchrome, 1/2” CMOS, 1280 x 1024 Pixels, Digital 8/12-bit output, 25 f/s
Colour, 1/2” CMOS, 1388 x 1038 Pixels, Digital 8/12-bit output,
17 f/s
141/217
Typ
A641fc
A102f
A102fc
SyRoTek - V003.1
Popis
Colour, 1/2” CMOS, 1624 x 1234 Pixels, Digital 8/12-bit output,
14 f/s
High Sensitivity Monochrome, Sony ExView CCD 2/3” Sensor,
1392 x 1040 Pixels, Digital 8/10-bit output, 15 f/s
High Sensitivity Colour, Sony ExView CCD 2/3”, 1388 x 1038 Pixels, Digital 8/10-bit output; YUV 4:2:2, 15 f/s
Tabulka 10.2: Řada kamer společnosti Basler s rozhraním 1394a, převzato z
nabídky společnosti Total Turnkey Solutions [73].
Typ
scA640-70fm
scA640-70fc
scA640-74fm
scA640-74fc
scA750-60fm
scA750-60fc
scA780-54fm
scA780-54fm
scA1000-30fm
scA1000-30fm
scA1400-17fm
scA1400-17fc
Popis
Monochrome 1/3” CCD, 659 x 490 pixels, 71 fps, 8/12-bit output
Colour 1/3” CCD, 659 x 490 pixels, 71 fps, 8/12/16-bit output
Monochrome 1/3” CCD, 659 x 490 pixels, 74 fps, 8/12-bit output
Colour 1/3” CCD, 659 x 490 pixels, 74fps, 8/12/16-bit output
Monochrome, 1/3” CMOS, 752 x 480 Pixels, 8/12-bit output, 63fps
Colour, 1/3” CMOS, 752 x 480 Pixels, 8-bit output, 63fps
Monochrome, 1/2”, 782 x 582 Pixels, 8/12-bit output, 54f/s
Colour, 1/2” CCD, 780x 580 Pixels, 8/12-bit output, 54f/s
Monchrome, 1/3” CCD, 1034 x 779 Pixels, Digital 8/12-bit output,
26 fps
Monchrome, 1/3” CCD, 1034 x 779 Pixels, Digital 8/12/16-bit output, 26 fps
High Sensitivity Monochrome, Sony ExView CCD 2/3” Sensor,
1392 x 1040 Pixels, Digital 8/12-bit output, 17 f/s
High Sensitivity Colour, Sony ExView CCD 2/3”, 1388 x 1038 Pixels, Digital 8/12/16-bit output, 17 f/s
Tabulka 10.3: Řada kamer společnosti Basler s rozhraním 1394b, převzato z
nabídky společnosti Total Turnkey Solutions [73].
Typ
DFW-X710
Popis
Colour, CCD 1/3”, 1024 x 768 Pixels, Digital YUV 4:2:2, 15 f/s
142/217
Typ
XCD-X710CR
XCD-X710
DFW-SX910
XCD-SX910CR
XCD-SX910
XCD-V50
XCD-V50CR
SyRoTek - V003.1
Popis
Colour, CCD 1/3”, 1024 x 768 Pixels, Digital 8/10-bit, Raw Bayer
output, 30 f/s
Monochrome, CCD 1/3”, 1024 x 768 Pixels, Digital 8/10-bit output, 30 f/s
Colour, CMOS 1/2”, 1392 x 1040 Pixels, Digital 8/10-bit output,
7.5 f/s
Colour, CCD 1/2”, 1392 x 1040 Pixels, Digital 8/10-bit, Raw Bayer
output, 15 f/s
Monochrome, CCD 1/2”, 1392 x 1040 Pixels, Digital 8/10-bit output, 15 f/s
Monochrome, CCD 1/3”, 640 x480 Pixels, Digital 8/14-bit, 60fps.
IEEE 1394.b-2002
Colour, CCD 1/3”, 640 x480 Pixels, Digital 8/14-bit, 60fps. IEEE
1394.b-2002
Tabulka 10.4: Řada kamer společnosti SONY s rozhraní IEE1394a a IEE1394b,
převzato z nabídky společnosti Total Turnkey Solutions [73].
Alternativním běžným rozhraním je USB 2.0 (480MBps), pro které dnes existují kamery,
které dokáží využít datové propustnosti tohoto rozhraní. Například firma Matrix Vision [74]
nabízí řadu kamer pro toto rozhraní, viz tabulka z [74] na obrázku 10.5.
143/217
SyRoTek - V003.1
Obrázek 10.5: Řada USB kamer firmy Matrix Vision.
144/217
SyRoTek - V003.1
Společnost Unibrain má ve své nabídce kromě kamer SONY a BASLER také vlastní
kamery v řadě Unibrain Industrial compact, Unibrain Fire-i industrial a Unibrain Fire-i.
Kamera Fire-i, obrázek 10.6, je FireWire kamera určená především pro domácí aplikace.
Jedná se v podstatě o FireWire alternativu webové kamery, které jsou běžně vybaveny
Obrázek 10.6: Firewire kamera Unibrain Fire-i.
USB rozhraním. Hlavní výhoda této kamery je možnost propojit několik kamer do řetízku.
Rozlišení je 640x480 se snímkovací frekvencí 30 Hz.
Unibrain compact, jsou průmyslové kamery v kompaktním obalu, obrázek 10.7. Rozlišení
Obrázek 10.7: Firewire kamera Unibrain compact.
těchto kamer je 640x480 pro sérii 5xx, 1024x768 pro model 620 a 1600x1200 u modelu 820.
Všechny modely využívají rozhraní IEEE1394a s limitem přenosové rychlosti 400MBps.
Kamera Unibrain Fire-i industrial je zobrazena na obrázku 10.8, tato kamera se liší
od řady Unibrain compact především menšími rozměry. Tato řada obsahuje modely 501
Obrázek 10.8: Firewire kamera Unibrain Fire-i.
a 511 s rozlišením 640x480, model 601 s rozlišením 1024x768, dále pak modely 701 a 702
145/217
SyRoTek - V003.1
s rozlišením 1280x960 a model 810 s rozlišením 1600x1200. Kamery se liší především je
v použitém snímacím čipu. Všechny kamery mají rozhraní IEEE1394a.
10.2.2
Počítač pro zpracování obrazu
Počítačem pro zpracování obrazu se rozumí řešení, které je podobné běžnému stolnímu počítači, je však dodáván jako plně nakonfigurovány počítač spolu se základním softwarovým vybavením pro zpracování obrazu. Hlavní výhodou tohoto řešení je především
odladěná sestava různých komponent spolu s příslušnou kamerou a ovladači pro příjem
obrazových dat.
Příkladem toho řešení je Matrox 4Sight M systém, který obsahuje stolní procesor Intel
a běžný operační systém typu Windows. Počítač je vybaven rozhraním IEEE1394, Camera
Obrázek 10.9: Matrox 4Sight M, počítač pro zpracování obrazu.
Link a vstupem pro analogový video signál spolu se zachytávací kartou. Součástí programového vybavení je knihovna MIL (Matrox Image Library) pro zpracování obrazu. Cena
těchto systémů spolu s kamerou se pohybuje kolem 5000$.
146/217
10.3
SyRoTek - V003.1
Zásuvné karty s vysokorychlostním rozhraním
pro přenos obrazu
Kamery s vyšším rozlišení vyžadují datové rozhraní s širokým přenosovým pásmem.
Používaná průmyslových rozhraní jsou Channel Link a Camera Link. Channel Link nabízí
propustnost až 2.38 Gbit/s, tedy šířku pásma až 297.5 Mbytes/sec. Camera Link vycházející
z Channel Link nabízí šířku pásma 800-900 MB/sec v případě, že komunikace probíhá
na rychlosti 85MHz [75]. Rozšiřující desky s tímto rozhraním vyžadují PCI-E sběrnice,
případně PCI (32/64bitů). Toto rozhraní je v několika verzích, lišící se maximální datovou
propustností, které také odpovídá použitý komunikační čip na desce.
Nabídky kamer s rozhraním Camera Link výrobců Basler [71], Sony, Hitachi a Mikrotron [76] jsou uvedeny v tabulkách 10.5, 10.6, 10.7, 10.8. Informace byly převážně čerpány
z nabídky společnosti Total Turnkey Solutions [77].
Typ
A102/kc
A202k/kc
A401k
A403k
A404k
A501k/kc
A504k/kc
Popis
Monochrome/Colour 2/3”, 1392 x 1040 pixels, 15 FPS, 8/10-bit
Camera Link output
Monochrome/Colour 2/3”, 1004 x 1004 pixels, 48 FPS, 8/10-bit
Camera Link output
Monochrome 1”, 2350 x 1720 pixels, 24 FPS, 8/10-bit Camera Link
output
output
output
Monochrome/Colour 1”, 1280 x 1024 pixels, 75 FPS, 8/10-bit Camera Link output
Monochrome/Colour 1”, 1280 x 1024 pixels, 500 FPS, 8/10-bit Camera Link output
Tabulka 10.5: Řada kamer společnosti Basler s rozhraním Camera Link.
147/217
10.3. ZÁSUVNÉ KARTY PRO PŘENOS OBRAZU
Typ
XCL-V500
XCL-X700
XCL-U1000
XCL-U1000C
SyRoTek - V003.1
Popis
Monochrome 1/3”, 648 x 494 pixels, 60 FPS, 8/10-bit Camera Link
Monochrome 1/1.8”, 1600 x 1200 pixels, 15 FPS, 8/10-bit Camera
Link
Colour 1/1.8”, 1600 x 1200 pixels, 15 FPS, 8/10-bit Camera Link
Tabulka 10.6: Řada kamer společnosti SONY s rozhraním Camera Link.
Typ
KP-F200CL
KP-F120CL/C
KP-F100BCL
Popis
Monochrome 1/1.8”, 1628 x 1236 pixels, 24 FPS, 10-bit Camera
Link output
Monochrome/Colour 2/3”NIR, 1392 x 1040 pixels, 30 FPS, 10-bit
Camera Link output
Monochrome 2/3”, 1392 x 1040 pixels, 15 FPS, 10-bit Camera Link
output
Tabulka 10.7: Řada kamer společnosti Hitachi s rozhraním Camera Link.
Typ
MC1302/03
MC1310/11
Popis
Monochrome/Colour 1”, 1280 x 1024 pixels, 100 FPS, 8/10-bit Camera Link
Monochrome/Colour 1”, 1280 x 1024 pixels, 500 FPS, 8/10-bit Camera Link
Tabulka 10.8: Řada kamer společnosti Miktrotron s rozhraním Camera Link.
Pro připojení kamery s rozhraním Camera Link k stolnímu počítači nebo pracovní stanici
je nutná zásuvná karta. Společnost Euresys [78], nabízí karty řady GrabLink, které jsou
určeny pro sběrnici PCI 32-bitů, resp. PCI 64-bitů. Tabulka nabízených karet je zobrazena
148/217
SyRoTek - V003.1
Obrázek 10.10: Zásuvné PCI karty řady GrabLink společnosti Euresys s rozhraním Camera
Link.
na obrázku 10.10. Řada GrabLink je rozšířena o dvě zásuvné karty, které jsou doplněny
o možnost základního předzpracování obrazu. První kartou je GrabLink QuickPack CFA,
která nabízí operátory pro barevné operace, jako je například Bayerův filtr nebo vyvažování
bílé složky obrazu. Karta GrabLink QuickPack ColorScan je určena pro úlohy inspekce
založené na řádkovém zpracování barevného obrazu. Jednou z neméně důležitých vlastností
karet společnosti Euresys je softwarová podpora, která je pro všechny karty řady GrabLink
poskytována pro operační systémy typu Windows a Linux.
Karta DT3145 od Data Translation [79] zobrazená na obrázku 10.11 s rozhraním Camera
Link je určena pro PCI sběrnici 32-bitů. Sběrnice PCI 32-bitů limituje šířku přenosového
pásma této karty na 132MB/s. Tato karta je nabízena za 895$.
Obrázek 10.11: Zásuvná karta DT3145 s rozhraním Camera Link společnosti Data
Translation.
149/217
SyRoTek - V003.1
Rozšíření počítačového rozhraní o Camera Link realizované jako PCI Express nabízí
společnost Matrix Vision pod označením mvHYPERION-CLe [80]. Vzhledem k použití
sběrnice PCI Express je šířka přenosového pásma vyšší než u klasické PCI 32-bitů a činí
250MB/s. Karta je zobrazena na obrázku 10.12
Obrázek 10.12: Zásuvná karta mvHYPERION-CLe s rozhraním Camera Link společnosti
Matrix Vision.
Společnost EPIX [81] nabízí kromě samostatných zásuvných desek s Camera Link rozhraním pro PCI a PCI Express sběrnice také kity s kamerami. Řada kamera kitů Silicon
Video je zobrazena v tabulce 10.9. Kity obsahují kameru, PCI zásuvnou kartu a software.
Uvedené ceny jsou orientační, neboť se mohou lišit podle konkrétního obsahu kitu. Součástí
kitu není objektiv kamery.
Typ
SILICON VIDEO 5C10
SILICON VIDEO 642
SILICON VIDEO 9T001C
SILICON VIDEO 9M001
SILICON VIDEO 1281
SILICON VIDEO 1310
SILICON VIDEO 2112C
Popis
SV9T001C CMOS, 12-bit, 2592x1944, 10
FPS
SV642 CMOS, 640x480, 200 FPS
SV9T001C CMOS, 12-bit, 2592x1944, 10
FPS
SV9M001C CMOS, 10-bit, 1280x1024, 30
FPS
SV1281 CMOS, 1280x1024, 30 FPS
SV1310 CMOS, 10-bit, 1280x1024, 14 FPS
SV2112C CMOS, 10-bit, 1288x1032, 26FPS
Cena
1100$
1600$
1000$
1095$
1400$
1300$
1100$
Tabulka 10.9: Řada kamera kitů SILICON VIDEO společnosti EPIX.
150/217
SyRoTek - V003.1
Výrobce digitálních kamer Prosilica [82] nabízí kromě kamer s rozhraním IEEE 1394
také kamery s rozhraním Gigabit Ethernet. Přehled IEEE1394 kamery je zobrazen v tabulce 10.10.
Typ
EC640
EC640C
EC650
EC650C
EC655
EC655C
EC750
EC750C
EC1020
EC1020C
EC1280
EC1350
EC1350C
EC1380
EC1380C
EC1600
EC1600C
CV640
CV640C
CV1280
Popis
very small, 97 fps at 640x480, light weight, CMOS
small size , 659x493, color, standard resolution, CMOS
compact, high sensitivity, 659x493, 1/3” CCD, 90 fps
light weight, color, 1/3” CCD camera, 1394
very small, CCD camera, 1/2” CCD, 90 fps
light weight, color camera, 1/2” CCD, 659x493
60 fps, 752x480, small size, CMOS firewire camera
small size, economical, 752x480, color, CMOS
1024x768, compact Firewire CCD camera
XGA resolution, 30 fps, color CCD camera
1280x1024, 24 fps, monochrome, CMOS
ultra compact CCD camera, 1.4 Megapixel
color CCD camera, firewire interface, fast
high sensitivity, 1360 x1024, 20 fps CCD
very small, light weight, color CCD camera
High resolution, 1620x1220, 2 megapixel CCD, 15 fps
2 Mpixel, color CCD camera, ultra-compact, fast
120 fps, 659x493, IEEE-1394 camera
color camera, YUV modes, RGB & bayer output
29 fps, 1280x1024, IEEE-1394, megapixel
Tabulka 10.10: Kamery Prosilica s rozhraním IEEE 1394.
Řadu EC tvoří kompaktní lehké kamery. Kamery řady CV jso vybaveny snímacím čipem
založeným na technologii CMOS.
Typy kamer s rozhraním Gigabit Ethernet jsou uvedeny v tabulkách 10.11 a 10.12.
Typ
GC640
GC640C
GC650
GC650C
Popis
Ultra-compact, 200 fps, 659x480, GigE, 1/2” CMOS
Very small, VGA color camera with Gigabit Ethernet interface
Lightweight, 90 fps , sensitive, compact, GigE camera, CCD
Economical, Color, 1/3” CCD sensor, C-mount, 659x493, RGB
151/217
Typ
GC655
GC655C
GC750
GC750C
GC1020
GC1020C
GC1350
GC1350C
GC1380
GC1380C
GC1600
GC1600C
SyRoTek - V003.1
Popis
659x493, 90 fps, 1/2” CCD camera
VGA Gigabit Ethernet camera, 1/2” color CCD
752x480, 60 fps, ultra-compact CMOS, near-IR enhanced
small size, economical, 752x480, color, CMOS
1024x768, 30 fps, CCD, ultra-compact GigE Vision camera
XGA color CCD camera, RGB output, 30 fps
1360x1024, 1/2” Sony CCD, 18 fps, GigE camera
1.4 Megapixel, color CCD camera, small size
High Sensitivity, 1360x1024, ICX285 CCD sensor, Exview
Excellent sensitivity and color, 1.3 Mpix, 2/3” CCD ICX-285
2 megapixel, 1620x1220, Sony CCD, 15 fps
Very small, High-resolution color camera, 1/2” CCD
Tabulka 10.11: Kamery Prosilica řady GC s rozhraním Gigabit Ethernet.
Typ
GE640
GE640C
GE650
GE650C
GE680
GE680C
GE1350
GE1350C
GE1380
GE1380C
GE1600
GE1600C
GE1650
GE1650C
GE1900
GE1900C
GE2040
GE2040C
Popis
Very fast, 200 fps, 659x480, GigE, 1/2” CMOS
VGA color camera with Gigabit Ethernet interface
90 fps , sensitive, compact, GigE camera, CCD
Color, 1/3” CCD sensor, C-mount, 659x493
Fast, 200 fps VGA-resolution, high-sensitivity, CCD camera
High-speed color CCD camera, 200 fps, RGB output
1360x1024, 1/2” Sony CCD, 18 fps, GigE
1.4 Megapixel, color CCD camera, small size
High Sensitivity, 1360x1024, ICX-285 CCD sensor
Excellent sensitivity and color, 1.3 Mpix, 2/3” CCD
2 megapixel, 1620x1220, Sony CCD, 15 fps
High-resolution color camera, 1/2” CCD
2 megapixel, 1600x1200, Kodak CCD, 30 fps
High-resolution color camera
2-megapixel, HD resolution, 30 fps
High definition resolution, fast frame rate, color camera
4-Megapixel, 15 fps, very high resolution, KAI-4021 CCD
High-resolution, ultimate performance, 1.2” CCD
Tabulka 10.12: Kamery Prosilica řady GE s rozhraním Gigabit Ethernet.
152/217
SyRoTek - V003.1
Řadu GC tvoří malé kompaktní kamery.
Dalším výrobcem kamer s vysokorychlostním rozhraním je společnost DALSA Digital
Imaging [83]. Nabídka vysokorychlostních ne-řádkových kamer řady Pantera je uvedena
v tabulce 10.13.
Typ
4M30 Stop Action CMOS Camera (PT-21-04M30)
Falcon 4M60 Stop Action CMOS Camera (PT-41-04M60)
Pantera SA 2M30 Camera (DS-25-02M30 colo)
Pantera SA 2M30 Camera (DS-21-02M30 mono)
Pantera SA 2M30 Camera (DS-24-02M30 mono)
Pantera SA 2M30 Camera (DS-22-02M30 color)
Pantera SA 4M15 Camera (DS-2x-04M15)
Pantera TF (DS-21-01M60)
Pantera TF (DS-1A-01M30)
Pantera TF 11M4 (PT-2x-11M04)
Pantera TF 6M8 (PT-2x-06M08)
Popis
2352x1728 31 fps 160
2352x1728 62 fps 320
1920x1080 30 fps 80
1600x1200 34 fps 80
1920x1080 30 fps 80
1600x1200 34 fps 80
2048x2048 16 fps 80
1024x1024 60 fps 80
1024x1024 30 fps 40
4008x2672 4.4 fps 72
3072x2048 7.5 fps 72
MHz
MHz
MHz
MHz
MHz
MHz
MHz
MHz
MHz
MHz
MHz
Tabulka 10.13: Kamery společnosti DALSA.
Kamera Pantera 11M4 je zobrazena na obrázku 10.13. Kamera serie 2M30 je zobrazena na
obrázku 10.14.
Obrázek 10.13: Vysokorychlostní kamera Pantera 11M4.
153/217
SyRoTek - V003.1
Obrázek 10.14: Vysokorychlostní kamera Pantera série 2M30.
10.3.1
Zásuvné karty pro zpracování obrazu
Rozšiřující karty s vysokorychlostním rozhraním pro přenos obrazu, které jsou vybaveny
procesorem pro zpracování obrazu umožňují realizovat proces rozpoznávání mimo hlavní
procesor počítače a tím výrazně snížit nároky na jeho výpočetní výkon. Nedílnou součástí
těchto řešení je základní programové vybavení, které dovoluje programovat procesor na
takové desce.
Společnost Matrix Vision nabízí řadu karet mvTITAN (obrázek 10.15, které jsou určeny
do pro sběrnici PCI a vedle Camera Link rozhraní mají procesor pro zpracování obrazu
typu PNX 1300 s 3.9 GOPS nebo PNX 1311 4.5 GOPS. Přehled vlastností karet je na [84].
Ovladače jsou k dispozici pro systémy typu Windows a Linux. Softwarová podpora je
realizován mvIMPACT knihovnou.
Obrázek 10.15: Zásuvné karty pro zpracování obrazu řady mvTITAN společnosti Matrix
Vision.
Společnost Alacron [85] se specializuje na zachytávací karty, které jsou vybaveny výpočetním výkonem pro zpracování přijímaného obrazu. Součástí nabídky jsou karty pro
zpracování analogových vstupů i digitálních vstupů. Zásuvné karty FastImage1303 (obrázek 10.16) a FastFrame1303 (obrázek 10.17) využívají výpočetní výkon procesoru Philips
154/217
SyRoTek - V003.1
Obrázek 10.16: Zásuvná karta FastImage1303.
Obrázek 10.17: Zásuvná karta FastFrame1303.
Nexperia (TriMedia) PNX1302, který se pohybuje rozsahu 667-770 MFLOPS a 833-900
MIPS. Karta FastImage1303 umožňuje zpracovávat data až ze 3 analogových kamer nebo
až 4 digitálních kamer. Karta obsahuje 3 Camera Link porty a může obsahovat až 4 procesory TriMedia. Karta FastFrame1303 obsahuje pouze 2 porty Camera Link a může obsahovat 1 procesor PNX1302. Součástí nabídky společnosti Alacron je také karta Fast-X,
obrázek 10.18, která obsahuje 3 Camera Link porty, 4 Gigabit Ethernet porty a procesor
STRECH 5610. Rozšiřující karta pro PCMCIA slot s procesorem TriMedia je nabízena
pod názvem FastFrame-CB a obsahuje jediný port Camera Link, obrázek 10.19. Karty od
společnosti Alacron jsou v provedení pro PCI sběrnici a softwarová podpora je poskytovány
pro systémy typu Windows i Linux.
Společnosti ARVOO [86] je dalším zástupce společností, které mají ve své nabídce zásuvné karty pro zpracování video signálu. Jejich typová řada Leonardo obsahuje modely
leonardo PCI64-CL-P-DB a leonardo PCI64-CL-P-FL, lišící se typem podporovaného rozhraní (DB-Camera Link Base, FL-Camera Link Full). Karty jsou určeny pro sběrnici PCI
64-bitů (kompatibilní s 32-bitovou verzí), mohou obsahovat až 1GB paměti. Pro uživatelské
155/217
SyRoTek - V003.1
Obrázek 10.18: Zásuvná karta Fast-X.
Obrázek 10.19: Zásuvná karta FastFrame-CB.
komunikační rozhraní je možné využít 2 RS-232 sériové porty nebo 2 digitální vstupy/výstupy. Výpočetní výkon je poskytován procesorem PMC Sierra RM7000C, který dosahuje
výkonu 1600 MFLOPS při 600MHz. Mezi podporované systémy patří Windows, Linux,
RTLinux a QNX.
Obrázek 10.20: Zásuvná karta řady leonardo.
156/217
SyRoTek - V003.1
Společnost Matrox [87] nabízí řadu zásuvných karet Odyssey, které kombinují vlastní
ASIC procesory spolu s G4 PowerPC procesory. Karty Odyssey eCL/XCL, Odyssey Xpro
a Odyssey Xpro+ disponují rozhraním Camera Link. Verze Xpro umožňuje až 2GB dedikované operační paměti na kartě. Všechny karty jsou podporovány v operačních systémech
typu Windows a Linux. Softwarová podpora je zahrnuta v Matrox Imaging Library (MIL),
Matrox Odyssey Native Library (ONL) a Matrox Odyssey Developer’s Toolkit, která je
poskytována separátně. Na obrázku 10.21 je zobrazena karta Odyssey XCL.
Obrázek 10.21: Zásuvná karta řady Odyssey XCL.
Alternativou k zásuvným kartám je vývojový kit DMEK642/DMDK642 společnosti
Kane Computing [88]. Verze DMDK se od verze DMEK liší přítomností IDE rozhraní
pro připojení pevného disku a FPGA procesorem pro další zpracování obrazu. Deska vývojového kitu je zobrazena na obrázku 10.22 a blokové schema na obrázku 10.23. Mezi
základní komunikační rozhraní patří linka RS232 a Ethernet. Jelikož je deska určena pro
zpracování multimediálních signálu, obsahuje kromě video vstupů také výstupy a audio
vstupy/výstupy. Hlavní výpočetní jádro je postaveno na procesoru TMS320DM642 taktovaného na 600MHz. Softwarová podpora obsahuje vývojové prostředí Code Composer
Studio, které je podporováno pro operační systémy typu Windows.
10.4
Inteligentní kamery
Takzvané inteligentní kamery jsou tvořeny vlastní kamerou a procesorem pro zpracování umístěným co možná nejblíže snímacímu čipu. S počítačem jsou tyto kamery spojeny
Obrázek 10.22: Deska vývojového kitu DMEK642.
157/217
10.4. INTELIGENTNÍ KAMERY
SyRoTek - V003.1
Obrázek 10.23: Blokové schema kitu DMEK642.
některým běžným „pomalým” rozhraním jako je například USB, Ethernet nebo RS232.
Jedná se o řešení podobné rozšiřující kartě s procesorem, avšak není nutné osazovat slot
počítače a celé řešení je realizováno externě. Hlavní výhodou tohoto řešení je externí realizace a možnost přípojení této kamery k řídicímu počítači systému SyRoTek bez nutnosti
dedikovaného počítače pro zpracování obrazu. Navíc v případě Ethernet nebo RS232 rozhraní a plné samostatné funkčnosti kamery odpadají problémy se softwarovou podporou
specializovaného hardware. Inteligentní kamera může být naprogramována na dedikované
pracovní stanici a poté připojena k řídicímu počítači, potřebné parametry mohou být nastaveny běžným rozhraním. Tento přístup je však nutné podpořit dostatečně obecným
(z hlediska parametrizace) programem pro lokalizaci, který dovolí parametry nastavit z externího počítače prostřednictvím řídicího rozhraní. V následujících odstavcích jsou uvedeny
některé dostupné inteligentní kamery předních společností zabývajících se zpracováním a
rozpoznáváním obrazu.
Společnost Matrox nabízí inteligentní kamery série Iris P.
Typ
Iris E300
Iris E300C
Iris E300H
Iris E700
Iris E1200
Popis
640x480, 30 FPS, monochrome
640x480, 30 FPS, color
1280x1024, 7.5 FPS monochrome
Tabulka 10.14: Řada inteligentních kamera Iirs B společnosti Matrox.
158/217
SyRoTek - V003.1
Obrázek 10.24: Inteligentní kamera Matrox Iris.
Tyto kamery obsahují procesor Intel ULP Celeron s taktem 400MHz, rozhraní RS232 a
Ethernet. Jsou dodávánu ve verzi s oddělenou kamerou nebo v jediném kompaktním těle,
které obsahuje jak vlastní snímací čip tak jednotku pro zpracování, obrázek 10.24. Nabízené
modely jsou uvedeny v tabulce 10.14. Softwarová podpora je realizována prostřednictvím
Matrox Design Assistant IDE pro operační systémy typu Windows.
Produktová řada mvBlueLYNX reprezentuje nabídku inteligentních kamer společnosti
Matrix Vision [89] s 64MB SDRAM a 36MB FLASH paměti pro operační systém a aplikace. Nejnovější série 6XX nabízí 400MHz PowerPC procesor spolu s 64MB SDRAM a
36MB FLASH paměti pro operační systém. Nechybí sériové rozhraní a Ethernet rozhraní.
Podle použitého čipu rozlišení kamery od 640x480 pixelů po 1600x1200 pixelů pro CCD
snímače. Frekvence je do 40MHz Pixel Clock, což odpovídá přibližně 100 snímkům za
sekundu pro rozlišení 640x480, 49 snímkům za sekundu pro 1024x768 a 18 snímkům za
sekundu při rozlišení 1600x1200. Všechny kamery podporují úrovně šedi a RGB s Bayer rozložením barevných elementů. Kamery s CMOS snímačem jsou nabízeny ve variantě
640x480 s 30 snímky za sekundu a 1280x1024 s 18 snímky za sekundu. V nabídce je též takzvaný „StarterKit”, obrázek 10.25. Součástí StarterKitu je základní programové vybavení
mvIMPACTBase. Jednotlivé části jsou zobrazeny na obrázku 10.26. Vývojové prostředí
mvIMPACT-SDL je k dispozici pro operační systém typu Linux. Embedded verzí inteligentní kamery je mvBlueLYNX-M, obrázek 10.27, který představuje kompletní počítač pro
zpracování obrazu.
159/217
SyRoTek - V003.1
Obrázek 10.25: Inteligentní kamera mvBlueLYNX1.
Obrázek 10.26: Komponenty balíku mvIMPACT.
Obrázek 10.27: Deska se snímacím čipem pro zpracování obrazu mvBlueLYNX-M.
160/217
SyRoTek - V003.1
Apollo Imaging Technologies [90] nabízejí jeden z nejlevnějších vývojových kitů pro inteligentní kamery s cenou cca 2500$. Všechny inteligentní kamery této společnosti využívají
procesor Texas Instruments TMS320DM642, který dosahuje 4000 MIPS při taktu 500MHz,
nabízené kamery mají procesory s taktem 500-720MHz. Kamery obsahují operační paměť
64-256MB, 32 FLASH paměť, rozhraní RS232 a Ethernet, součástí výstupů kamery je také
PAL signál. Nabízené modely se liší použitým snímacím čipem:
• AIT100HS - rozlišení 640x480, 250 FPS1 ,
• AIT130S - CMOS, rozlišení 1280x1024, 18FPS,
• AIT300 - rozlišení 2048x1536, 12 FPS.
Kamera AIT100HS je zobrazena na obrázku 10.28.
Obrázek 10.28: Kamera Apollo AIT100HS..
1
FPS - Frames Per Second, počet snímků za sekundu.
161/217
SyRoTek - V003.1
Společnost Basler [71] má ve své nabídce inteligentní kamery z řady eXcite. Produktová
nabídka je zobrazena v tabulce 10.15.
Typ
exA650-60c
exA650-120c
exA650-180c
exA1390-19c
exA1600-14c
Popis
CMOS, 656x490, 60 FPS
CMOS, 656x490, 132 FPS
CMOS, 656x490, 176 FPS
CCD, 1388x1039, 18.7 FPS
CCD, 1624x1234, 14 FPS
Tabulka 10.15: Inteligentní kamery eXcite Basler.
Všechny kamery jsou vybaveny procesorem taktovaným na 1 GHz s operační pamětí 128MB
a pamětí typu FLASH také o velikosti 128MB. Operační systém kamery je typu Linux
(Kernel 2.6). Základní vstupně výstupní rozhraní tvoří:
• 2 porty USB 2.0,
• Ethernet 10,100 a 1000 MBit,
• RS-232,
• 4 digitální vstupy a výstupy.
Základním vývojové nástroje tvoří Eclipse, GNU Tools a coLinux. Podporované operační
systémy jsou Windows a Linux. Tělo kamery je zobrazeno na obrázku 10.29.
Specializací společnosti Vision Components [91] jsou inteligentní kamery. V jejich nabídce jsou základní modely kamer s procesorem Texas Instruments s taktem 400MHz a
výkonem 3200 MIPS, tabulka na obrázku 10.30. Modely vyšší řady obsahují procesor TI
s taktem 1GHz a výkonem 8000 MIPS, tabulka na obrázku 10.31. Softwarová podpora je
poskytována pro operační systémy typu Windows jako balík VC SDK-TI.
Inteligentní kamery s rozlišením 640x480 má ve své nabídce společnost Neuricam [92].
Kamery NC5100 a NC5300 používají CMOS snímací čip a jsou nabízeny v barevné i monochromatické verzi. Obsahují Ethernet a RS 232 rozhraní. Kamera NC5100, obrázek 10.32,
obsahuje 32 bitový RISC procesor (ARM) taktovaný na 70MHz. Vzorkovací frekvence je
25 snímků za sekundu. Softwarovou podporu tvoří Linuxový vývojový balík NC5151-SDK
obsahující distribuci Linuxu, ovladače a knihovny pro zpracování obrazu, včetně zdrojových kódů. Kamera NC5300 tvoří kompletní počítač třídy x86 s procesorem NS Geode
SC2200 s taktem 266MHz. Operační systém kamery je typu Linux.
162/217
SyRoTek - V003.1
Obrázek 10.29: Tělo kamery řady eXcite..
Obrázek 10.30: Inteligentní kamery Vision Components s výkonem 3200 MIPS..
163/217
SyRoTek - V003.1
Obrázek 10.31: Inteligentní kamery Vision Components s výkonem 8000 MIPS..
Obrázek 10.32: Inteligentní kamera NC5100.
164/217
SyRoTek - V003.1
PPT Vision je název společnosti zabývající se počítačovým viděním více než 20 let.
V jejich nabídce jsou inteligentní kamery v řadě IMPACT. Kamera IMPACT A-10, obrázek 10.33, je založena na snímacím čipu CMOS s rozlišením 752x480 a snímkovou frekvencí
až 60 Hz. Součástí kamery je procesor s výkonem 700 MIPS s 256 MB operační paměti a
Obrázek 10.33: Kamera IMPACT A-10.
256 MB paměti typu FLASH. Komunikační rozhraní je Ethernet a sériová linka. Dalšími
produkty společnosti PPT Vision jsou série IMPACT T-Series Intelligent Cameras (obrázek 10.34) a IMPACT C-Series Machine Vision Micro-Systems, obrázek 10.35. Kamerové
Obrázek 10.34: Kamera IMPACT T série.
Obrázek 10.35: Kamera IMPACT C série.
systémy série T a C jsou nabízeny v kombinaci s různými snímacími čipy, tabulka 10.16.
T série je vybavena procesorem s výkonem 1320 MIPS, C série pak s procesorem s výkonem 2000 MIPS. Operační paměť je ve velikosti 256 MB, paměť typu FLASH má kapacitu
128 MB. Softwarová podpora je zahrnuta v balíku IMPACT Software Suite, který obsahuje grafický nástroj pro realizaci softwaru zaměřeného na inspekci produktů. Software se
skládá z částí KICKSTART, Vision Program Manager (VPM) a Control Panel Manager
(CPM). Komunikace s jinými programy je možná prostřednictvím protokolu TCP/IP.
165/217
Typ
Černobílé
Barevné
Rozlišení
640x480
640x480
640x480,
1024x768
1280x1024
1600x1200
640x480
1024x768
1600x1200
SyRoTek - V003.1
Popis
1/3” CCD 60 FPS,
1/3” CCD, 60 FPS, Remote Head,
1/2” CCD, 60 FPS,
1/3” CCD, 16 FPS,
2/3” CMOS, 12 FPS,
1/1.8” CCD, 12 FPS,
1/3” CCD, 60 FPS,
1/3” CCD, 16 FPS,
1/1.8” CCD, 12 FPS.
Tabulka 10.16: Rozlišení a typ snímacího čipu řady IMPACT série T a C.
Obrázek 10.36: Aplikace inteligentní kamery TAG Plus společnosti Tattile.
166/217
SyRoTek - V003.1
Obrázek 10.37: Inteligentní kamera TAG Plus.
Obrázek 10.38: Kamera systém XP TAG.
TAG Plus je inteligentní kamera společnosti Tattile [93]. Kamera je určena pro průmyslové aplikace jako inteligentní senzor, obrázek 10.36. Kamera je zobrazena na obrázku 10.37.
Snímací čip kamery podporuje rozlišení 1600x1200 při 15 snímcích za sekundu. Při rozlišení 640x480 je možné provozovat kameru v režimu 60 snímků za sekundu. Mezi základní
komunikační rozhraní patří Ethernet a RS 232. Operační systém kamery je Real time operační systém typu Linux nebo Tattile OS. Vývoj zákaznické aplikace je podpořen grafickým
prostředím Anares Explorer, knihovnou Tattile Image Library pro Ansi C, jejíž součástí je
též prostředí pro ARM Assembler. Základní výměna dat probíhá po protokolu TCP/IP,
respektive UDP/IP.
Součástí nabídky společnosti Tattile je také kompletní počítač pro zpracování obrazu
umístěný v těle kamery. Tento produkt nese označení XP TAG. Tělo kamery je zobrazeno
na obrázku 10.38. Technické specifikace vycházejí z inteligentní kamery TAG Plus. Základní komunikační rozhraní je Gigabit Ethernet spolu s RS 232. Možné operační systémy
jsou Linux, TOS (Tattile Multitasking Operating System) nebo Windows XP Embedded.
Aplikace systému XP TAG je v nahrazení klasického přístupu připojené digitální kamery
k osobnímu počítači pouze jediným tělem inteligentní kamery, které je připojena do sítě
LAN, obrázek 10.39.
Leutron Vision [94] je společnost, která nabízí inteligentní kamery ve své řadě PicSight
Smart, které jsou vybaveny rozhraním Gigabit Ethernet. Produktová nabídka této řady je
zobrazena v tabulce 10.17.
Typ
T33I-GigE-Smart501
T33I-GigE-Smart501-H
P34M-GigE-Smart501
Popis
1/3” CCD, 658x496, 31 FPS, global shutter, infrared
1/3” CCD, 658x496, 31 FPS, global shutter, infrared
1/4” CCD, 659x494, 60 FPS, global shutter, monochrome
167/217
Typ
P34M-GigE-Smart501-H
P34B-GigE-Smart501
P34B-GigE-Smart501-H
P33M-GigE-Smart501
P33B-GigE-Smart501
P32M-GigE-Smart501
P32B-GigE-Smart501
G32M-GigE-Smart501
G32M-GigE-Smart501-H
G32B-GigE-Smart501
G32B-GigE-Smart501-H
G43M-GigE-Smart501
G43M-GigE-Smart501-H
G43B-GigE-Smart501
G43B-GigE-Smart501-H
P52M-GigE-Smart501
P52B-GigE-Smart501
P83M-GigE-Smart501
P83B-GigE-Smart501
SyRoTek - V003.1
Popis
1/4” CCD, 659x494, 60 FPS, global shutter, color
1/2” CMOS, 659x494, 200 FPS, global shutter, monochrome
1/2” CMOS, 659x494, 200 FPS, global shutter, color
168/217
Typ
P133B-GigE-Smart501
P142M-GigE-Smart501
P142B-GigE-Smart501
P142AM-GigE-Smart501
P142AM-GigE-Smart501-H
P142AB-GigE-Smart501
P142AB-GigE-Smart501-H
P141M-GigE-Smart501
P141B-GigE-Smart501
P202M-GigE-Smart501
P202B-GigE-Smart501
P203B-GigE-Smart501
R312AB-GigE-Smart501
R312AB-GigE-Smart501-H
R492B-GigE-Smart501
R492B-GigE-Smart501-H
SyRoTek - V003.1
Popis
1/2.7” CCD, 1300x968, 10 FPS, global shutter, color
1/1.8” CCD, 1620x1220, 12 FPS, global shutter, monochrome
1/1.8” CCD, 1620x1220, 12 FPS, global shutter, monochrome
1/2” CMOS, 2048x1536, 12 FPS, rolling shutter, color
1/2” CMOS, 2048x1536, 12 FPS, rolling shutter, color
1/1.8” CMOS, 2542x1944, 4 FPS, rolling shutter, color
1/1.8” CMOS, 2542x1944, 4 FPS, rolling shutter, color
Tabulka 10.17: Řada inteligetních kamer PicSight společnosti Leutron Vision.
PicSight inteligentní kamery obsahují vlastní procesor, operační paměť o velikosti 64 MB
a 32 MB paměť typu FLASH. Operační systém kamery je Real-time systém PSOS. Vývoj aplikace je možný cross kompilačním prostředím pro systém typu Windows, který je
169/217
10.5. ZÁVĚR
SyRoTek - V003.1
Obrázek 10.39: Schema použití systému XP TAG.
součástí balíku LV-SDS pro všechny kamery PicSight-Smart. Základní rozhraní pro práci
s kamerou tvoří knihovny Image Acquisition API, Camera Control, File System, Communication (Gigabit Ethernet + RS232) a Drawing Library. Kompilační prostředí kamery
je C,C++. Software nadřazeného osobního počítače tvoří rozhraní pro C,C++, OCX a
.Net. Základní konfigurace kamery je realizována webovým rozhraním. Softwarová podpora pro komunikaci mezi kamerou a uživatelskou aplikací (Daisy, Video Capture Library
of LV-SDS) je poskytována pro operační systémy typu Windows, Linux a VXWorks.
10.5
Závěr
Počet způsobů a možných realizací kamerového systému je několik. Navíc je možné zvolit
různé technologické realizace. Výběr vhodného způsobu řešení je nutné zvolit především
na základě následujících faktorů:
• velikost arény,
• rychlost robotu,
• požadovaná přesnost určení polohy robotu.
Při výběru je také nutné respektovat specifikace snímacích čipů a způsob přenosu obrazu a jeho zpracování. U většina barevných kamer je udávané rozlišení jako počet aktivních prvků snímače. Barevného obrazu je však dosaženo barevnou maskou, která určuje
170/217
SyRoTek - V003.1
Obrázek 10.40: Bayerova maska barevných snímacích čipů.
body snímače budou snímat příslušnou barvu, typicky používaná maska je Bayerova, obrázek 10.40. Rozlišení takové kamery pak neznamená, že obraz obsahuje udaný počet bodů,
kde každý bod může reprezentovat libovolnou barvu.
Podobně je nutné respektovat formát obrazu. Například kamery s rozhraním IEEE1394a
mají režimy s rozlišením 640x480 a vyšší při snímkové frekvenci 25 Hz. V těchto režimech
však obraz není přenášen v RGB režimu, ale často se používá komprese YUV 4:1:1 nebo
YUV 4:2:2, které snižují barevné rozlišení kamery, neboť využívají sdílení jasových složek.
Tyto komprese jsou vhodné pro vizualizaci obrazu, neboť lidské oko není na tyto změny
citlivé, to však neplatí pro strojové zpracování obrazu. Princip komprese je schematicky
zobrazen na obrázku 10.41. Z těchto důvodů je vhodné zpracovávat obraz v režimu RGB
nebo RAW.
Obrázek 10.41: Komprese obrazu sdílením jasových složek, obrázek převzat z [95].
V souvislosti s požadavkem přesnosti určení polohy robotu souvisí rozlišení snímacího
čipu, rozměr arény, ale také použitá optická soustava. Na obrázku 10.42 je zobrazena tabulka s maximálními rozměry snímané plochy v závislosti na parametrech optické soustavy. Maximální rozměry plochy zabírané kamerou, která je umístěna ve vzdálenosti 5m
171/217
10.5. ZÁVĚR
SyRoTek - V003.1
Obrázek 10.42: Ilustrace rozměrů plochy snímané kamerou v závislosti na parametrech
optické soustavy, obrázek převzat z [96].
od plochy, dosahují hodnot 10,8mx8,1m. Tabulka je převzata z dokumentace ke kameře
Basler A60x ze stránek společnosti Unibrain [96] a obsahuje údaje o dostupných optických
soustavách k této kameře. Z požadavků kladených na systém SyRoTek [1] je minimální
plocha arény 10m2 . S vhodnou optickou soustavou, lze proto uvažovat pouze o jediné kameře, která snímá celou plochu s poměrem stran 1:1 nebo 2:3, pokud prostorové podmínky
umožní umístit kameru ve výši nejméně 4m nad úrovní plochy arény. Z hlediska vhodného
rozlišení snímací čipu lze vyjít z empirického vzorce pro přepočet rozměrů plochy na počet
172/217
SyRoTek - V003.1
pixelů:
d=
l 1 1
· · ,
n ρ β
(10.1)
kde l je příslušný rozměr plochy arény, n je počet bodů snímače v příslušném směru, ρ je
parametr zohledňující radiální zkreslení a β je vliv barevné masky barevné kamery (Bayer
vzor). Empirický odhad parametrů ρ a β je ρ = 0.8 a β = 0.5. Tabulka 10.18 obsahuje
odhad přesnosti robotu pro rozměry plochy 4m × 3m a různá rozlišení snímacího čipu. Při
výpočtu přesnosti je uvažována přesnost určení polohy robotu na 1 pixel, odhad neobsahuje
přesnost určení natočení robotu. Z tabulky vyplývá, že i s VGA rozlišením snímače, lze
Rozlišení
640x480
1024x768
1280x1024
1600x1200
Odhad přesnosti
(dl , dw ) v [cm]
(1.5, 1.5)
(1.0, 1.0)
(0.8, 0.7)
(0.6, 0.6)
Tabulka 10.18: Odhad přesnosti určení pozice robotu na ploše 4m × 3m.
očekávat přesnost určení polohy robotu v řádu jednotek centimetrů.
Volba vhodné snímací rychlosti je podmíněna maximální rychlostí robotu. Při uvažované
maximální rychlosti robotu 0.25m·s−1 a předpokladu zanedbatelného dopravního zpoždění
při přenosu a zpracování obrazu robot změní pozici mezi dvěma snímky o vzdálenost 0.25
,
f
kde f je frekvence snímání obrazu. Pro základní frekvenci 25 snímku za sekundu odpovídá
vzdálenost mezi dvěma snímky 1cm, lze tedy očekávat přesnost určení pozice robotu opět
v řádu jednotek centimetrů. V souvislosti s nezanedbatelným dopravním zpožděním je však
vhodné doplnit lokalizaci robotů o predikci pozice robotu [70].
V případě černobílé kamery lze očekávat vyšší přesnost určení polohy robotu, neboť není
nutné kompenzovat vliv barevné masky snímacího čipu. Rovněž zpracování černobílého obrazu nevyžaduje nároky na konstantní osvětlení plochy arény a to jak v čase tak v prostoru
na ploše. V závislosti na způsobu osvětlení může být intenzita světla na ploše nehomogenní,
což může vést na různé barevné podání identifikačních plošek robotu v různých částech
plochy.
Důležitou vlastností je snadnost integrace kamerového systému do celého systému SyRoTek. Bez ohledu na technologické způsoby realizace (speciální zásuvné karty, inteligentní
kamery) je nutné respektovat navržené rozhraní kamerového systému. Součástí toho rozhraní nejsou pouze periodické poskytované informace o pozicích robotů na ploše v konkrétním časovém okamžiku, ale také možnost konfigurace, které může být například nutná
v případě výměny robotu, resp. jeho identifikační značky.
Z hlediska nejjednoduššího propojení kamerového systému, respektive lokalizačního systému, s ostatními částmi systému SyRoTek je nejvhodnější realizace samostatným systém
173/217
10.5. ZÁVĚR
SyRoTek - V003.1
pro rozpoznávání, který je připojitelný k řídicímu počítači rozhraním Ethernet. Komunikaci se systémem rozpoznávání je vhodné realizovat nad některým komunikačním protokolem z rodiny TCP/IP. Pro zajištění kompatibility je vhodné, aby vlastní komunikační
protokol nevyžadoval speciální knihovny a byl dobře dokumentovatelný. Pouze v takovém
případě, lze uvažovat o případné náhradě lokalizačního systému jiným řešení, v případech kdy výrobce specializovaného hardware přestane příslušný produkt podporovat. Tyto
nároky splňují inteligentní kamery nebo ještě lépe kamery, které sledují současný trend
v inteligentních kamerových systémech a to kamery, které integrují kompletní počítač a
komunikují s okolím po rozhraní Ethernet. Inteligentní kamery zároveň poskytují výpočetní výkon pro realizaci úlohy rozpoznávání a není nutné dedikovat pro zpracování obrazu
speciální počítač nebo realizovat sdílení strojového času s jinými procesy, které může být
komplikované, neboť lokalizaci lze pokládat za časové kritickou aplikaci. Hlavní nevýhodou
inteligentních kamer je obtížná rozšiřitelnost v případě, kdy je výpočetní výkon kamery
nedostatečný, proto je nutné dobře odhadnout náročnost zpracování obrazu.
S ohledem na preferenci operačního systému typu Linux (unix) ostatních softwarových
komponent projektu SyRoTek je vhodné uvažovat též o kamerové systému, který tento systém podporuje, neboť taková volba minimalizuje nutné náklady na spravování a konfiguraci
různých operačních systémů.
174/217
KAPITOLA 11. VIZUALIZACE
SyRoTek - V003.1
Kapitola 11
Vizualizace
Uživatelé systému SyRoTek budou řešit úlohy s mobilními roboty, které se budou pohybovat po ploše arény. Tito uživatelé budou pracovat vzdáleně a budou přistupovat k systému prostřednictvím veřejné sítě Internet. Pro realizaci robotických úloh budou využívat
dat ze senzorů umístěných na robotech, jejichž data budou distribuována uživatelelsým
aplikací na robotu, řídicím počítači nebo vzdálené uživatelské stanici. Součástí těchto dat
jsou pozice robotů z globálního lokalizačního systému, který tvoří etalon pozic robotů
v systému SyRoTek. Vedle těchto informací je vhodné řešení robotických úloh podpořit názornou vizualizací reálné scény, která pomůže lepé si představit co robot na ploše
provádí. Vizualizace v tomto kontextu znamená přenos obrazu reálné scény k uživateli,
prostřednictvím sítě Internet. Přenos obrazových dat je náročný na šířku přenosového kanálu, proto je nutné uvážit limitované kapacity koncových uživatelů, kteří nemusejí být
vybaveni vysokorychlostním připojením. S ohledem na koncové uživatele je vhodné najít
takové technické řešení, které umožní uživatelů systému SyRoTek zvolit vhodný datový
tok. Technických způsobů realizace vhodného datového toku video souborů je možné najít
několik, od systémů využívající pouze běžný stolní počítač až po profesionální techniku pro
realizaci obrazových přenosů v reálném čase. V následujících oddílech jsou proto popsány
některé možné způsoby řešení přenosu video signálu.
11.1
Kódování
Základem snížení datového toku video souboru je kódování souboru, které je založené
na ztrátové kompresy. Kompresní algoritmy jsou založeny na snižování úrovně viditelných
detailů, rekonstrukcí obrazu ze změn mezi jednotlivými snímky a dalších technologií využívajích mimo jiné charakteristiky vnímání lidského zraku. Video soubory jsou kódovány,
některým vhodným kodekem, který výrazně snižuje datový tok. Samotné kódované video je
však přenášeno v obálce (kontejneru), která může obsahovat více datových toků, například
audio nebo jiné informace (často jsou součástí například textové titulky). Technologických
175/217
11.1. KÓDOVÁNÍ
SyRoTek - V003.1
možností jak video kódovat a přenášet je několik. Mezi současné nejznámější patří technologie Real Media, Flash Video, Microsoft Video, QuickTime. Tyto technologie jsou komerční
a většinou vzájemně nekompatibilní, proto volba některé této technologie definuje nejen
příslušný kodek, obálku, ale také streamovací server. V případě, lze použit samostatný kodek je možné využít streamovacího serveru případně obálky z jiného řešení. V následujících
odstavcí je uveden stručný popis technologií a kodeků nejrozšířenější streamovacích řešení.
11.1.1
Windows Media
Windows Media Video (WMV) je kodek, který je vyvíjen společností Microsoft. Samotný kodek je podporován na systémech Windows, Mac OS a Linux, avšak podpora pro
streamování je dostupná pouze pro platformu Windows.
11.1.2
Flash
Kodek VP6, je kodek určený pro kódování videa, který je součástí Flash 8 společnosti
Macromedia, v současné době vlastněné společností Adobe [97]. Mezi hlavní výhody přenášení videa technologií Flash je především široká multiplatformní podpora přehrávačů Flash.
Průzkumy uvádějí, že Flash přehrávač má procentuálně nejvyšší zastoupení (v počtu instalací), dokonce vyšší než Windows Media Player [98]. Kvalita kodeku VP6 je srovnatelná
s H.264 avšak s menší náročností na hardware. Flash Media Server je serverové řešení poskytování video souborů uživatelům. Jeho cena se pohybuje v řádu desítek tisíc až miliónu
korun podle počtu současně nabízených proudů. Flash nenabízí žádný externí přehrávač,
ten si každý distributor videa musí implementovat sám. Vývoj je však poměrně jednoduchý, neboť Flash je skriptovací jazyk a je možné snadno realizovat přehrávač žádaných
vlastností. Tuto technologii poskytování video adaptovala například společnost Google, což
může být chápáno jako signál o kvalitách toho řešení. Je však nutné zmínit, že tato technologie je používán především pro poskytování video souborů, které si uživatel přehrává
ze streamů po připojení k serveru.
11.1.3
QuickTime
QuickTime je řešení pro video soubory používáne společností Apple. V současné době
není tento formát omezen pouze pro platformu Mac OS, ale je široce multiplatformní.
QuickTime má dlouholetou historii a stal se například také inspirací pro H.264. Serverové
řešení pro poskytování video proudu ve formátu QuickTime je nabízeno pod názvem Xserve
a softwarem včetně kompletního hardware (1U rack) od 80 000Kč. Na stejného základu jako
Xserve je založen Darwin Streaming Server [99], který je uvolněn pod open source licencí
a je možné jej provozovat na systémech typu Windows, Linux, Solaris nebo FreeBSD.
176/217
11.1.4
SyRoTek - V003.1
RealVideo
Jedním z nejznámějších formátu přenosu videa v sítí Internet je RealVideo společnosti
RealNetworks [100]. Tento formát původně využíval kodeky založené na H.263. V současné
verzi jsou však již používaný proprietární kodeky RV30 a RV40. Výhodou toho formátu je
multiplatformní podpora přehrávače, který je k dispozici v podobě binárních balíčku pro
systémy Mac OS, Linux a Windows. Ačkoliv se jedná o uzavřené komerční řešení, včetně
serverové řešení. společnost RealNetworks uvolnila některé kódy pod open source licencí a
dala tak impuls pro vznik komunity Helix [101]. Jedním z cílů projektu Helix je realizace
open source přehrávače a serveru. Kromě proprietárních kodeků RealVideo formátu jsou
podporovány také H.264 a Ogg Theora [102].
11.1.5
H.264
Standard H.264 AVC definuje širokopásmový formát pro přenos videa. Standardizován
byl ITU pod názvem H.264 ve spolupráci s ISO/IEC Moving Picture Experts Group, kde
byl pojmenován MPEG-4 Part 10 [103]. Za použití kodeku H.264 je nutné platit poplatky.
Do roku 2010 jsou od nich osvobozena vysílání po Internetu (pouze streaming), jaké budou poplatky po roce 2010 se zatím neví [103]. Kodeky nejsou s výjimkou Mac OS X
v ostatních operačních systémech k dispozici v základní instalaci. H.264 podporuje například multiplatformní open source přehrávač VLC [104]. Open source implementace kodeku
H.264 jsou x264 [105] a Hdot264 [106]. VLS [107] je open source řešení pro realizaci streamovacího serveru, které je součástí projektu VideoLan [108], ze které pochází přehrávač
VLC a implementace kodeku x264. Na obrázku 11.1 je ilustrace funkcionality serveru VLS.
Implementace kodeků H.264 se liší převážně efektivitou. Obecně však lze říci, že tento kodek patří mezi výpočetně náročné a to jak na straně kódování, tak na straně dekódování
(přehrávání) [109]. Výkon stolních počítačů je možné podpořit speciálním kódovacím a
dekódovacími kartami. V případě přehrávání je dnes možné využít hardwarové podpory,
pro přehrávání souborů s vysokým rozlišením, implementované na nejnovějších grafických
čipech současných běžně dostupných grafických karet (akcelerátorů).
11.1.6
Theora
Kodek Theora je open source kodek, který je založen na uvolnění patentovaného kodeku
VC3. Theora je video protějšek svobodného audio kodeku Ogg Vorbis. Obálka je typicky
tvořena formátem Ogg, kde Theora je kodek pro video a Vorbis pro audio. Tyto svobodné
kodeky vznikají v rámci iniciativy xiph.org [110]. Theora je však stále v alfa stádiu, proto
se pro produkční nasazení zatím nehodí.
Ačkoliv existuje několik kodeků, které jsou určeny pro streamování videa prostřednictvím sítě Internet, jejich kvality jsou víceméně rovnocenné. Jedná se především o proprietární řešení, které je součástí kompletního systému (serveru) pro streamování videa.
177/217
11.2. STREAMOVACÍ SERVERY
SyRoTek - V003.1
Obrázek 11.1: Ilustrace funkčnosti VLS serveru, obrázek převzat z [107].
Důležitým aspektem vhodné volby technologického řešení vizualizace v systému SyRoTek
je koncový uživatel. Z tohoto pohledu je důležité definovat hlavní rozdíl mezi běžnými služebami streamování video souborů a streamováním (publickací) videou souborů v systému
SyRoTek, který je především v účelu přenášeného videa. V projektu SyRoTek slouží video
obraz reálné scény jako podpůrný prostředek k řešení zadané úlohy a získání lepší představy o chování robotu, jedná se tedy o doplněk k zobrazení dat ze senzorů. Blíže běžným
službám streamovacích serverů jsou video soubory sloužící k prezentaci práce se systémem.
11.2
Streamovací servery
Hlavní úlohou streamovacího serveru je poskytovat video proudy jednotlivým uživatelům. S ohledem na provoz a základní funkcionality systému SyRoTek lze očekávát následující typy proudů:
1. On-line proudy aktuálního dění na ploše arény.
2. Přehrávání archivovaných video záznamů.
178/217
SyRoTek - V003.1
3. Přehrávání připravených video záznamů demonstrující práci se systémem SyRoTek.
V přpadě prvního typu video proudu se jedná o přenos v reálném čase. Tento typ videa
vyžaduje proudový přenos, neboť jeho obsah vzniká během přehrávání. Spolu s požadavkem
na co možná nejmenší dopravní zpoždění je další klíčovou vlastností streamování tohoto
proudu synchronizace s ostatními daty.
Další dva typy nevyžadují nutně přenos streamováním a je možné uvažovat o distribuci těchto video záznamu v podobě stažitelných souborů (například protokolem HTTP).
Archivované video záznamy jsou vlastně kopie přenášených on-line proudů. Tyto kopie
se mohou překódovávat do některého klasického formátu video souboru. Případně kvalita
těchto záznamu může být řádově vyšší (datový tok, rozlišení). Vyšší kvalita může může
vyžadovat ukládání dat v některém z kodeků s nízkym kompresením poměrem a následným
off-line kodováním do finálního kodeku. V případě velkého množství potenciálních uživatelů systému SyRoTek, kteý budou požadavat archivace video záznamů průběhu svých
experimentů může nastat situace, kdy bude průběžně docházet k archivaci v každém okamžiku a nároky na kódování videa tak mohou být značné. Z tohoto důvodu je výhodnější
uvažovat o archivovaných souborech, jako o kopiích video proudů, které jsou poskytovány
buď jako samostatné soubory nebo jako streamované video.
Hlavní výhodou distribuce video záznamů formou proudu je „okamžité” přehrávání bez
nutnosti downloadu celého souboru. Přestože lze i běžné video soubory přehrávat prostřednictvím takzvaného http streamování je nutné použít vhodný přehrávač, neboť je
základním rysem streamovaného přehrávání je možnost pohybu v záznamů, při kterém je
možné záznam okamžitě spustit od libovolného okamžiku doby záznamu.
Záznamy demonstrující práci se systémem SyRoTek je vhodné realizovat v co možná
nejvyšší kvalitě, neboť se jedná o instruktážní videa. V řadě případů lze očekávat kromě
záznamu reálného prostředí také záznam s obsahem počítačové obrazovky. Detailní zobrazení počítačové obrazovky vyžaduje značný datový tok v případě běžných kodeků, neboť ty
jsou navrhovány pro reálné scény, je proto vhodné využít některéch speciálního kodeku pro
tyto účely, například kodek TechSmith [111]. Tyto instruktážní videa budou připravovaná
v off-line režimu, proto nekladou významné nároky na výpočetní kapacitu pro kódování.
Dalším neméně podstatným aspektem je download video souborů, neboť lze očekávat, že
někteří uživatelé si budou chtít video soubory opakovaně přehrát i na pracovních stanicích,
které nebudou připojené k síti Internet. Stažitelné soubory také přinášejí výhodu v možném
automatickém ukládání souborů v mezi pamětech na přenosové cestě ze serveru systému
SyRoTek k uživateli. V případě vysokého počtu uživatelů jedné instituce, tak může dojít
k výraznému snížení vyžadované přenosové kapacity na straně serveru systému SyRoTek.
V případě streamovaného doručovaní nemusí být toto ukládání do mezi paměti snadno
realizovatelné, neboť může vyžadovat specifické softwarové produkty a konfigurace.
179/217
11.3. KAMERY
11.3
SyRoTek - V003.1
Kamery
Kamery pro vizualizaci mohou být z nabídek společností, které jsou uvedeny v oddíle
lokalizace 10. Pro vizualizace však typicky nevyžadujeme vysoké rozlišení, proto je možné
uvažovat maximálním rozlišení VGA 640x480, případně o rozlišení signálu PAL 752x582.
Mezi užitečné kamerové systémy patří takzvané PTZ (Pan-Tilt-Zoom) kamery, které
umožňují otáčet a naklápět pohled kamery, případě měnit zvětšení kamery. Tyto kamery
jsou častou součástí systému pro realizaci tele-konferenčních přenosů. Příkladem těchto
kamer jsou výrobky společnosti SONY nabízené pod označením EVI-D100P a EVI-D70P
zobrazené na obrázcích 11.2 a 11.3, které jsou vhodné pro vnitřní prostředí. Obě kamery
mají video výstup ve formátu S-VIDEO. Parametry jsou uvedeny v tabulce 11.1, respektive 11.2.
Obrázek 11.2: PTZ kamera EVI-D100P
Obrázek 11.3: PTZ kamera EVI-D70P
Výhodou kamery SONY EVI-D70P je uchycení na strop při, kterém může kamera snímat
libovolné místo na ploše arény spolu s optickým přibližením.
Pro pomocné snímání, například ze strany arény, je možné uvažovat o levných webových
kamerách, které jsou typicky určeny pro rozhraní USB. Na obrázku 11.4 je zobrazena
180/217
Parametr
Obrazový prvek
Minimální osvětlení
Rozsah automatické závěrky
Odstup signál - šum
Optický zoom
Ohnisková vzdálenost
Světelnost objektivu
Horizontální rozsah
Horizontální rychlost
Vertikální rozsah
Vertikální rychlost
Rozměry
Hmotnost
Cena
SyRoTek - V003.1
Hodnota, popis
1/4” CCD
3.5 lux (F1.8)
1/3 až 1/10.000 s
> 50 dB
10x
3.1 až 31 mm
F1.8 až 2.9
100◦
300◦ /s
25◦
125◦ /s
113 x 120 x 132 mm
860 g
33 300 Kč
Tabulka 11.1: Parametry kamery EVI-D100P.
Parametr
Obrazový prvek
Minimální osvětlení
Rozsah automatické závěrky
Odstup signál - šum
Optický zoom
Ohnisková vzdálenost
Světelnost objektivu
Horizontální rozsah
Horizontální rychlost
Vertikální rozsah
Vertikální rychlost
Příkon
Rozměry
Hmotnost
Cena
Hodnota, popis
1/4” EXview HAD CCD
1 lux / F1.4
1 až 1/10.000 s
> 50 dB
18x
4.1 až 73.8 mm
F1.4 až 3.0
170◦
100◦ /s
-30 - +90◦
90◦ /s
12 W
132 x 144 x 144 mm
950 g
33 300 Kč
Tabulka 11.2: Parametry kamery EVI-D70P.
webová kamera Logitech QuickCam Express pro rozhraní USB 2.0. Tato kamera poskytuje
obraz s rozlišením 320x240. Cena této kamery se v současné době pohybuje okolo 400 Kč.
Webová kamera s fyzickým rozlišením snímače 1.3M pixelů je zobrazena na obrázku 11.5.
Poskytované rozlišení video dat je 640x480 při 30 snímcích za sekundu. Maximální rozlišení
181/217
11.4. HARDWARE PRO PŘEVOD VIDEO DAT
SyRoTek - V003.1
Obrázek 11.4: Webová kamera Logitech QuickCam Express.
statického obrázku je 1280x960 bodů. Cena této kamery je okolo 3000 Kč.
Obrázek 11.5: Webová kamera Logitech QuickCam Ultra Vision.
11.4
Hardware pro převod video dat
Převod video dat do formátu vhodného pro streamování je výpočetně náročná úloha
zvláště tehdy, je-li vytvářeno několik proudů z více zdrojů a každý proud pro různé kvality
obrazu v režimu on-line. Speciálně navržené kódovací procesory mohou značně redukovat
potřebný výkon stolního počítače. Před samotným kódování je však potřebné digitalizovat
obraz z analogových zdrojů. Digitalizaci lze realizovat zásuvnou kartou do stolního počítače, na kterém je pak prováděno samotné kódování video dat. Mezi průkopníky v nabídce
zásuvných karet do stolních počítačů je společnost ViewCast [112]. Jejich karty řady Osprey
jsou považovaný za de facto standard. Tyto karty jsou nabízeny pro tři kategorie použití od
základní „entry-level” přes profesionální až po studiové. Karty jsou nabízeny jako zásuvné
karty do PCI (PCI-X) sběrnice nebo jako externí USB zařízení. V základní verzi se jedná
o zachytávací karty, vyšší modely pak obsahují hardwarovou podporu kódování.
Karty Osprey doplňuje streamovací software Osprey SimulStream určený pro systémy
Windows 2000 a Windows XP. Tento software realizuje kódování videa z karet Osprey do
více proudů, schematicky je princip činnosti zobrazen na obrázku 11.13.
Nároky na výpočetní výkon hlavního procesoru počítače při kódování video proudů lze
snížit speciální zásuvnou kartou s hardwarovou podporou příslušných kodeků. Společnosti
182/217
Typ
Osprey-50
Osprey-100
Osprey-210
Osprey-230
Osprey-300
Osprey-440
Osprey-530
SyRoTek - V003.1
Popis
USB zachytávací zařízení, vstupy: 1 kompozitní video, 1 S-Video,
podpora pro Windows 2000, Windows Media Encoder a RealProducer Plus.
PCI zachytávací karta, vstupy: 3x kompozitní video, S-Video, podpora pro Windows XP, Windows 2000, Video for Windows API a
OPI (Osprey Programming Interface).
PCI zachytávací karta, vstupy: kompozitní video BNC, S-Video,
audio, podpora Windows 2000, Windows XP, Linux.
PCI/PCI-X zachytávací karta, vstupy: kompozitní video BNC, SVideo, audio, podpora Windows 2000, Windows XP, Linux.
PCI/PCI-X zachytávací a streamovací karta , vstupy: kompozitní
video BNC, S-Video, IEEE 1394a, 1394b, audio, podpora Windows
2000, Windows Server 2003, Windows XP, RealProducer Basic.
PCI/PCI-X zachytávací a streamovací karta , 4 nezávislé vstupy
kompozitní video BNC, audio, podpora Windows Server 2003, Windows XP, Osprey SimulStream.
PCI/PCI-X zachytávací a streamovací karta , vstupy: SDI, kompozitní video BNC, S-Video, audio, podpora Windows Server 2003,
Windows XP, Osprey SimulStream.
Obrázek 11.6: Zachytávací USB zařízení Obrázek
11.7:
Osprey50.
Osprey100.
Zachytávací
karta
ViewCast nabízí kódovací karty Osprey-1000 (obrázek 11.14) a Osprey-2000, obrázek 11.15.
Karta Osprey1000 nabízí podporu pro kódování video streamů založené na kodeku H.261
a H.263. Podpora je poskytována pro systémy Windows NT. Karta Osprey2000 je určena
pro kódování a dekódování formátu MPEG.
V nabídce společnosti ViewCast jsou také kompletní systémy pro řešení streamování.
183/217
SyRoTek - V003.1
Obrázek
11.8:
Osprey210.
Zachytávací
karta Obrázek
11.9:
Osprey230.
Zachytávací
karta
Obrázek 11.10:
Osprey300.
Zachytávací
karta Obrázek 11.11:
Osprey440.
Zachytávací
karta
Obrázek 11.12: Zachytávací karta Osprey530.
R
Obrázek 11.13: Princip činnosti software Osprey SimulStream.
Produktová řada Niagra obsahuje několik modelů serveru (většinou ve velikosti 1U resp.
2U), které jsou vybaveny zachytávacími kartami Osprey a předinstalovaným operačním
systémem spolu se software pro streamování.
184/217
SyRoTek - V003.1
Obrázek 11.14: Kódovací karta Osprey1000.
Obrázek 11.15: Kódovací karta Osprey2000.
Jedním ze základních modelů je Niagra 4100, obrázek 11.16, který obsahuje procesor
Pentium4 s taktem 3GHz, 512MB RAM. Systém je schopen obsluhovat několik streamů
vytvářených z 1 analogového video vstupu.
Obrázek 11.16: Systém Niagara 4100.
Systém Niagara 7224, obrázek 11.17, který je schopen streamovat 8 proudů v plném
R je
rozlišení (Windows Media Streams) nebo 16 proudů (Windows Media 9, RealVideo)
vybaven dvojicí dvou-jádrových procesorů Intel Xeon s taktem 2.33GHz a dvojicí karet
Osprey440. Součástí systému je 2x250 SATA pevný disk, 2GB RAM, napájecí zdroj 600W
a 2 x rozhraní Gigabit Ethernet.
Specializací společnosti Ituner Networks Corporation [113] jsou řešení pro streamování
185/217
SyRoTek - V003.1
Obrázek 11.17: Systém Niagara 7224.
audio/video obsahu a realizace tele-konferenčních systémů. V jejich nabídce lze nalézt audio/video kódovací server MediaBox VS-2601, obrázek 11.18. Zdroj video signálu může
Obrázek 11.18: Kódovací server MediaBox VS-2601.
být 3x kompozitní video a 1x S-video. Podporovaná rozlišení jsou v rozsahu 160x120 až
po 640x480 (případně vyšší), snímková frekvence je 30 snímků za sekundu. Video chipset
je BookTree 878. Server je schopný streamovat video v režimu multicast nebo unicast,
podporuje formáty MPEG4, RealAudio, Vorbis a QTSS (QuickTime). Základní softwarová architektura je zobrazena na obrázků 11.19. Operační systém je typu Linux. Cena je
přibližně 5000$.
V nabídce společnosti Ituner je také zachytávací karta Spectra8, obrázek 11.20, která
umožňuje simultánně zachytávat video signál až z 8-mi nezávislých zdrojů. Karta je založena na čipu Conexant BT878, podpora ovladačů je poskytována pro systémy typu Windows, Linux (2.2, 2.4, 2.6). Jsou podporovány aplikace typu Helix Producer a Windows
Media Encoder 9. Při zachytávání 8 vstupů se vzorkovací frekvence pohybuje v rozmezí
10-15 snímků za sekundu. Plných 30 snímků za sekundu je možné využit při zachytávání
4 vstupů. Pro zachytávání 8 vstupů je nutné vytvořit vlastní aplikace dodávaným SDK
(Software Development Kit). Cena karty je přibližně 400$.
Společnost Turnkey Solution [72] nabízí software pro zachytávání a ukládání video StreamPix. Verze StreamPix 4 již podporuje zachytávání z více kamer. Tento software je určen
pro záznam video dat v reálném čase do paměti RAM počítače nebo na pevný disk. Vstupem jsou digitální kamery s rozhraním IEEE 1394, Camera Link, USB2 nebo analogové
kamery. Výstupní formát video souborů je AVI. Kodek je závislý na konkrétní softwarové
konfiguraci (Windows kompatibilní kodek). Tento softwarový balík poskytuje řešení pro
sběr video dat spolu s dalšími údaji. Mezi další vlastnosti patří podpora časový značek
(absolutní, relativní) a událostmi řízené snímaní. StreamPix podporuje skriptovací jazyk
pro definování způsobu zachytávání. Událost může být generována na vstupu kamery (trigger vstup), zachytávací karty, klávesnici nebo na vstupu USB portu. StreamPix je využívá
rozhraní Hermes API, které reprezentuje C++ knihovnu. Rozhraní je k dispozici ke všem
186/217
SyRoTek - V003.1
Obrázek 11.19: Softwarová architektura Open Platform serveru MediaBox VS-2601.
Obrázek 11.20: Zachytávací karta Spectra8.
StreamPix podporovaným kamerám a zachytávacím kartám. Další součástí je zásuvný SDK
modul, který umožňuje ukládat data z jiných zdrojů, jsou uváděny například aplikace ukládání teploty, tlaku nebo GPS souřadnic synchronizovaně s obrázky v ukládané sekvenci.
Kodek H.264 patří mezi jedny z nejefektivnější z hlediska poměru kvality přenášeného
videa a požadovaného datového toku. Na druhé straně však také patří mezi kodeky výpočetně nejnáročnější. Zásuvné karty pro hardwarovou podporu kódování H.264 jsou typicky
založené na DSP čipu PNX1500 společnosti Philips. Ceny těchto karet se pohybují v rozsahu 180$ až po 500$, například podle ceníku společnosti GAO Tek Inc.[114], v závislosti
na počtu nezávislých video vstupů. Tyto karty zároveň slouží jako zachytávací karty. VýČVUT FEL, Gerstner Laboratory, ProTyS a.s.
187/217
SyRoTek - V003.1
hodou dražších modelů je možnost synchronizace externím vstupem, například karta DRCStream 500 z nabídky společnosti Digital Rapids [115]. Podpora je většinou poskytována
pro systémy typu Windows.
11.5
Streamovací servery
Jak již bylo zmíněno výše poskytování video souborů prostřednictvím proudů má následující výhody:
• Uživatel nemusí stahovat nejdříve celý obsah, ale může dané video začít ihned sledovat.
• Uživatel má možnost přistupovat k libovolnému časovému okamžiku video záznamu.
• Uživatel může sledovat záznam pořizovaný v reálném čase1 .
V případě, že je video záznam opakovaně přehráván, může být sledování prostřednictvím
poskytovaného proudu dat nakonec mnohem náročnější z hlediska celkového množství přenesených dat (v závislosti na mechanismu využívání mezi-paměti na přenosové cestě). Technologie streamování může být realizována různě v závislosti na obálce a kodeku video
souborů, viz popis způsobů kódování oddíl 11.1, neboť proprietární řešení typicky obsahuje kompletní technologii. V tomto odstavci popíšeme některé dostupné technologie pro
realizaci streamovacího serveru.
11.5.1
HTTP Streaming
HTTP Streaming je nejjednodušší a nejdostupnější streamovací technika. Přestože se
nejedná o streamování v pravém slova smyslu, je vhodná pro poskytování obsahu video
souborů malému počtu uživatelů. Soubor je poskytován webovým serverem a uživatel po
zadání URL adresy může (při správné konfiguraci prohlížeče) ihned sledovat video. Tímto
mechanismem je možné velice jednoduše poskytovat video soubory. Jelikož se jedná poskytování souborů, uživatel může tyto soubory přímo uložit na lokální pevný disk protokolem
HTTP. S vhodným přehrávačem je možné přistupovat k libovolnému místo záznamu2 .
Mezi nevýhody tohoto jednoduchého řešení patří absence mechanismu zjištění rychlosti
připojení uživatele a tím poskytnutí vhodného datového toku (souboru) video záznamu.
Rovněž není možné tímto způsobem efektivně poskytovat video záznamy, které vznikají
v reálném čase. V případě vyššího počtu uživatelů vede HTTP Streaming na zvýšené
zatížení serveru a neefektivní využití dedikovaných zdrojů.
1
Záznamy pořizované v reálném čase čase nelze posouvat dopředu a většinou není možné záznam ani
vrátit.
2
Ověřeno v konfiguraci s webovým serverem Apache 2.0 [5], webový prohlížeč Firefox 2.0.0.1 [116]
a přehrávačem mplayer 0.99.10 2 [117].
188/217
11.5.2
SyRoTek - V003.1
Streamování a další metody
Mezi hlavní výhody streamování patří minimální doba zpoždění od požadavku na přehrávání do samotného přehrávání video záznamu. Záznam může být uložen v souboru
nebo může být zachytáván a streamován v reálném čase. Streamování je možné založit na
některém z protokolu:
• RTP -Real Time Transport Protocol, RFC 3550, RFC 3551, RFC 3711 [118, 119, 120],
• RTSP - Real Time Streaming Protocol, RFC 2326 [121],
• RDT - Real Data Transport, RTMP - Real Time Messaging Protocol společnosti
Adobe Systems [97] používaný technologií Flash.
Výhodou specializovaného protokolu je možnost detekce kvality spojení a tak ovlivňovat velikost datového toku během přehrávání nebo případně zvolit vhodný formát pro
přehrávání. Streamované video je možné také přenášet technologií multicast a tím snížit
datový tok, v případech vícenásobného přijení uživatelů ze stejné sítě, RFC 3710 [122],
RFC 3711 [120]. Je ovšem nutné podotknout, že současný stav sítě Internet neumožňuje
provozovat multicast v plné šíři, neboť řada směrovačů jej nepodporuje.
Progresivní stahování je technika, která je označována jako hybridní streamování. Příslušný soubor je běžným způsobme downloadován ze serveru, ale přehrávač začne přehrávat
příslušnou část ihned, jakmile je stažena ze serveru. Tento způsob simuluje „pravé streamování, avšak neposkytuje všechny výhody pravého streamování pro jehož realizaci je
vždy nutné využít specializovaného streamovacího serveru.
11.5.3
Helix Server
Helix server je streamovací řešení společnosti RealNetworks Inc. Některé zdrojové kódy
tohoto řešení byly uvolněny a staly se základem pro aktivity Helix Community [101], která
vyvíjí open source řešení postavené na Real Media technologiích. Schema Helix DNA platform je zobrazeno na obrázku 11.21. Helix DNA Producer je kódovací engine a API, které
umožňuje konvertovat video do digitální podoby vhodné pro streamování. Hlavním úkolem
Helix DNA Server je doručit streamovaný obsah k uživateli. Helix DNA Client je univerzální přehrávací engine, cílem vývojářů je podpora různých formátů a mnoha operačních
systémů.
Helix DNA zdrojový kód tvoří základ pro komerčně nabízené streamovací řešení společnosti RealNetworks, obrázek 11.22.
189/217
SyRoTek - V003.1
Obrázek 11.21: Platforma Helix DNA .
Obrázek 11.22: Zdrojové kódy Helix DNA a software společnosti RealNetworks.
11.5.4
Darwin Streaming Server
Podobně jako společnost RealNetworks uvolnila zdrojové soubory svého streamovacího
serveru společnost Apple. Balík zdrojových kódů se jmenuje Darwin Streaming Server.
Komerční verze streamovacího serveru QuickTime Streaming Server (QTSS) je součástí
operačního systému Mac OS X Server. Jádro QuickTime i Darwin Streaming serveru je
společné. QTSS navíc obsahuje uživatelské rozhraní s rozšířenými administračními nástroji.
Darwin Streaming Server je volně ke stažení v podobě zdrojových souborů nebo v podobě
binárních balíčků pro systémy Mac OS X, Linux a Windows [99].
11.5.5
Flash Media Server
Flash Media Server je streamovací server společnosti [97], který je podporován na operačních systémech Windows 2000 Server, Windows 2003 Server - Standard Edition a Linux
190/217
SyRoTek - V003.1
Red Hat Enterprise Version 3.0 a Linux Red Hat Enterprise Version 4.0. Minimální hardwarové požadavky jsou Pentium4 3.2 a 1GB RAM, přičemž dvou a více procesorové řešení je
doporučeno. Flash Media Server je kompletní řešení pro distribuci video souborů a přenosů
v reálném čase. Konfigurace seznamů nabízených proudů je založena na XML technologii.
Vedle předem připravených video souborů je možné streamovat v reálném čase. Je podporováno více pozorovacích míst, ze kterých si uživatel může vybrat. Uživatelský přehrávač je
realizován skriptem v jazyce Flash. Hlavní výhoda tohoto řešení je rozšiřitelnost Flash přehrávače, který je standardní součástí mnoha operačních systémů. V souvislosti s vývojem
softwarového balíku Apollo [123], který přestavuje multiplatformní vývojový kit pro tvorbu
uživatelského prostředí, se nabízí možnost vytvoření kompletního uživatelského rozhraní
vizualizačního prostředí systému SyRoTek v prostředí Flash.
11.5.6
VideoLan
VideoLan je softwarový projekt zaměřený na vývoj svobodného softwaru pro video. Součástí tohoto projektu je přehrávač, server a kodeky, které byly popsány v oddíle 11.1. Na
tomto místě stojí za zmínku některé zajímavé vlastnosti přehrávače VLC. Na obrázku 11.23
je v pravé části ukázka zobrazení 3 simultánně přehrávaných video souborů na jediné
HTML stránce. Tímto způsobem lze realizovat jednoduché uživatelské rozhraní s podporou několika pohledů na plochu arény. V levé části je zobrazen výstup s použitím knihovny
Obrázek 11.23: Přehrávání více video záznamů na jediné HTML stránce.
libcaca [124], která zobrazuje bitmapový obrázek textovými symboly. Obrázek 11.24 zobrazuje vlastnost VLC mosaic, která realizuje funkci obraz v obraze. Zároveň je na obrázku
vidět textový filtr, který vkládá do přehrávaného videa textové informace. Tyto vlastnosti,
vzhledem k open source licenci, mohou být použity při tvorbě speciální přehrávače pro
záznamy dění na ploše arény systému SyRoTek.
191/217
11.6. ARCHIVACE VIDEO DAT
SyRoTek - V003.1
Obrázek 11.24: Zobrazení 2. video záznamu na ploše přehrávaného 1. videa.
11.6
Archivace video dat
V souvislosti s přenosem dat souvisí také archivace záznamů. Provoz systému je uvažován v režimu 24/7, při tomto režimu by bylo archivování všech pořízených záznamů
v plné kvalitě velmi náročné na diskovou kapacitu. Rovněž archivace v tomto rozsahu není
opodstatněná. Archivaci však můžeme rozdělit podle účelu na dva typy.
První typ archivace slouží uživatelům, kteří si mohou off-line prohlédnout záznam průběhu svého experimentu. Záznam může být součástí odevzdání vyřešené úlohy nebo se může
jednat o záznam provedení naplánovaného experimentu v době, kdy uživatel neměl přístup
k systému a nemohl expermient sledoval v reálném čase. Pro tento účel je možné přímo
zaznamenat generované video proudy, případně pouze ty, které uživatel zvolit. S ohledem
na omezenou úložnou kapacitu, je vhodné video soubory zahrnout do přiděleného prostoru
uživatele a tím zajistit, že nebude docházet k nadměrnému ukládání video souborů, neboť
bude v uživatelově zájmu zajistit dostatečně velkou volnou kapacitu přiděleného úložného
prostoru. Podle počtu uživatelů je vhodné dimenzovat kapacitu úložného zařízení. Vzhledem k předpokladu, že nebude pravděpodobně možné dostatečný úložný prostor realizovat
jediným pevným diskem a především s ohledem na robustnost a škálovatelnost řešení, je
nejvhodnější uvažovat o realizaci úložného prostoru diskovým polem typu RAID5. Podle
konkrétního způsobu realizace ukládání a archivování dat je nutné zvolit vhodnou sběrnici.
V případě, že diskové pole slouží pouze k archivaci a přístupu uživatelů v off-line módu je
postačující řešení postavené na sběrnici SATA (SATAII) nebo externí řešení připojitelné
rozhraním IEEE 1394. Pokud bude diskové pole sloužit také přímo k ukládání zachytávaného proudu, je vhodnější datová sběrnice s vyšší propustností, například Ultra320 SCSI.
Druhý typ archivace je určen pro ladící a logovací účely. V případě, že došlo k nečekané
nežádoucí akci, například k převržení robotu nebo jeho uvíznutí, je tento záznam využit
k analýze příčiny vzniklého problému. Tento záznam je archivován po určitou dobu, napříČVUT FEL, Gerstner Laboratory, ProTyS a.s.
192/217
SyRoTek - V003.1
klad 7 dní, po té době již není aktuální a není třeba jej archivovat. Pro tento druh záznamu
lze s výhodou využít více-násobné analogové výstupy kamer pro vizualizace.
Řešení toho záznamu je možné realizovat nezávislým digitálním rekordérem, který je
v současné době již běžně dostupný v ceně okolo 10 000 až 15 000 Kč se záznamovou kapacitou přesahující 440 hodin. Výhodou toho řešení je nezávislost na vlastním vizualizačním
systému určeného pro uživatele.
Rozšířenou alternativou tohoto přístupu jsou kompletní dohledové systémy, které umožňují automatický záznam z více kamer. Příkladem takového systému jsou video servery
společnosti Axis Communications [125]. Ten realizuje převod analogového signálu na příslušný digitální proud dat. Software na stolním počítači pak slouží k záznamu proudu dat,
včetně případného přehrávání. Samozřejmostí tohoto řešení je také vzdálený přístup. Nevýhodou specializovaných řešení pro dohledové účely je absence nebo velmi obtížná realizace
návaznosti na události v systému SyRoTek.
11.7
Vizualizace v systému SyRoTek
V předcházejících oddílech byl uveden popis různých technologií, které je možné použít
při realizaci vizualizace v systému SyRoTek. Byly vyjmenovány současné hlavní technologie vizualizace video záznamů založené na streamování souborů. Lze očekávat, že tyto
technologie se budou dále vyvíjet, avšak pravděpodobně nedojde k výraznému průlomu
uvedením nového revolučního řešení. Vzhledem k plánované době realizace vizualizačního
systému není účelné v součásné etapě prací na systému SyRoTek zvolit konkrétní technologii. V tomto oddíle je proto uvedena detailní specifikace koncepce vizualizace, jak bude
později implementována vhodnými technologickými nástroji.
Proces vizualizace se skládá ze snímání plochy vytváření proudů, které jsou přenášeny
k uživateli. Další částí systému vizualizace je archivace vytvářených proudů. Nedílnou součástí vizualizace je též podpora uživatelského přehrávání, která souvisí s volbou vhodného
kodeku a formátu videa pro přenos proud video dat, ale především definuje uživatelské rozhraní přehrávání. Vedle základního přehrávání videa je nutné zohlednit, že uživatel bude se
systémem pracovat a bude sledovat dění na ploše zpravidla spolu s dalšími údaji, jako jsou
data ze senzorů a logovací výpisy jeho programu. Z tohoto pohledu je klíčová synchronizace
video proudu s údaji a událostmi související s průběhem programu, který řídí robot.
Základní koncepce je zobrazena na obrázku 11.25.
Základní části systému vizualizace jsou:
• Řízení pohyblivé kamery.
• Zachytávání signálů z kamer.
• Synchronizace obrazového signálu s daty ze senzorů.
193/217
11.7. VIZUALIZACE V SYSTÉMU SYROTEK
systémový čas
zachytávání
Pan−Tilt−Zoom
synchronizace
konfigurace
zachytávání data ze senzorů
přihlášený
uživatel
SyRoTek - V003.1
systémová konfigurace
kódování
připravené
záznamy
kódování
publikování
konfigurace
kódování
plánovač
archivace
záznamů
uživatelský
prostor
uživatelské
nastavení
uživatel
Obrázek 11.25: Koncepce vizualizace v systému SyRoTek.
• Kódování video souborů.
• Plánovače archivace záznamů.
• Uživatelského prostoru pro ukládání archivovaných záznamů.
• Publikování záznamů kódovaných v reálném čase a připravených záznamů.
Přístup k řízení pohyblivé kamery
Systém vizualizace zpracovává několik kamer, které sledují plochu arény. Přihlášený
uživatel, který má v systému rezervovaný čas, může ovládat pohyblivou vizualizační kameru
(Pan-Tilt-Zoom). V případě, že není přihlášen uživatel, který by měl rezervovaný čas práce
s roboty na ploše, může kameru ovládat jiný uživatel.
Model ovládání je následující. Uživatel, který chce modifikovat pohled kamery, získá
exkluzivní přístup k ovládání po definovanou dobu. Pokud se během této doby objeví
žádost o změnu natočení kamery od jiného uživatele, je takovému uživatele předáno řízení
v následující periodě.
V případě, že dojde k přihlášení uživatele, který má rezervovaný čas, resp. konfigurace
jeho sezení obsahuje též ovládání kamery, je mu řízení pohybu kamery předáno. Je-li přihlášeno více uživatelů, kteří mají registrované sezení s pohybem robotů po ploše, mohou
požádat uživatele, který má momentálně přidělené řízení kamery, o předání řízení. Příslušný
194/217
SyRoTek - V003.1
uživatel může, ale nemusí žádost akceptovat. Řízení kamery může být autoritativně předáno uživateli v roli SyRoTek System Developer 3 . Závislosti modulu řízení pohybu kamery
na ostatních částech systému SyRoTek jsou uvedeny v tabulce 11.3,
Funkce/Stav
Přihlášení uživatele
Přihlášený uživatel
Odebrání řízení pohybu kamery
Vstupy
Výstupy
Návaznost
Databáze registrovaných sezení
Rozhraní uživatele
Řízení
přístupu
k ovládání kamery
Rozhraní uživatele
Řízení přístupu k systému
Uživatelské rozhraní
Zachytávání
Logger
Popis
Kontrola konfigurace sezení uživatele,
předání řízení.
Žádost o předání řízení pohybu kamery.
Předání řízení pohybu kamery.
Žádost o přiřazení časového intervalu
pro řízení pohybu kamery.
Odebrání řízení pohyblivé kamery, uživatelem s vyššími právy (Administrátor, Course Tutor, SyRoTek System
Developer).
Přihlášení a odhlášení uživatele.
Události generované uživatelem.
Video a audio signály.
Logovací informace o událostech v modulu a funkčnosti jednotlivých částí.
Tabulka 11.3: Řízení pohyblivé kamery, návaznosti na ostatní moduly.
Zachytávání audio a video signálů
Zachytávání obrazu z kamer může podle konkrétních typů kamer obsahovat vedle vlastní
zachytávací karty také případné převodníky analogového signálu na digitální. Převod na
digitální signál může mít například smysl tehdy, pokud by docházelo k nežádoucímu rušení
analogového signálu. Lze spíše počítat se zachytávací kartou s několika analogovými vstupy,
případně připojením kamer rozhraním IEEE 1394 nebo USB2.
Zachytáván není pouze video signál, ale také audio signál. Zvuky pohybujícího se robotu po ploše arény systému SyRoTek spolu se zvuky případného nárazu robotu do bariér
a překážek umožní uživateli věrnější kontakt se zprostředkovanou realitou prostředí.
Konfigurace zachytávání obsahuje systémové údaje, které souvisí s konkretním nastavením systému SyRoTek. V závislosti na konkrétní hardwarové konfiguraci, jsou zvoleny
3
Samozřejmě, že v systému existuje role hlavní administrátor (root), uživatelská role je Honza.
195/217
SyRoTek - V003.1
vhodná rozlišení a snímkové frekvence zachytávání video a audio signálů. Návaznosti na
ostatní moduly jsou uvedeny v tabulce 11.4.
Funkce/Stav
Parametry zachytávání
Vstupy
Výstup
Návaznost
Systémová
konfigurace
Parametry zachytávání
Video signály
Audio signály
Proud Audio/Video
dat
Hodnoty dopravního
zpoždění jednotlivých
proudů
Logger
Popis
Nastavení přípustných parametrů jednotlivých kanálu zachytávání.
Systémové nastavení, které může být
modifikovatelné uživatelem s rolí Administrátor systému SyRoTek.
Přenášené video po příslušném médiu.
Přenášené audio pro příslušném médiu.
V závislosti na konkrétní hardwarové
konfigurace mohou být proudy dat
předzpracované, případně již nějakým
způsobem kódované. V zásadě však video data představují posloupnost jednotlivých snímků. Proud audio dat je
reprezentován posloupností bloků dat,
který reprezentuje určitou časovou periodu o konstantní velikosti.
V závislosti na konkrétní konfiguraci
jsou dílčí proudy časově zpožděny a odpovídají různým reálným časovým okamžikům.
Logovací informace o událostech v modulu a funkčnosti jednotlivých jeho
komponent.
Tabulka 11.4: Zachytávání video/audio signálů, návaznosti na ostatní moduly.
Synchronizace audio,video a datových proudů
V modulu synchronizace je provedeno časové označení jednotlivých snímků jednotným
systémovým časem, (případně bloků audio dat). Ačkoliv lze uvažovat o možné změně rozlišení nebo vzorkovací periodě zachytávaných video signálů, je nutné pro konkrétní konfigurace zjistit dopravní zpoždění dílčích snímků. V případě kontinuálního zachytávání lze
předpokládat, že toto zpoždění bude dále konstantní. Senzorová data tvoří samostatný
proud dat, který je následně zpracováván. Všechny proudy dat jsou však synchronizované,
196/217
SyRoTek - V003.1
resp. obsahují příslušné časové značky. Návaznosti na ostatní moduly jsou uvedeny v tabulce 11.5.
Funkce/Stav
Vstupy
Návaznost
Systémový čas
Proudy audio/video
dat
Informace o zpoždění
jednotlivých proudů
Data ze senzorů
Výstupy
Synchronizované
proudy dat.
Logger
Popis
Hlavní čas systému SyRoTek.
Data přicházejí jako jednotlivé snímky
a bloky dat.
Tyto informace jsou použity pro časovou synchronizaci.
Data ze senzorů přicházejí s příslušnými časovými značkami. Tyto data
pocházejí ze sdílených senzorů: globální
lokalizace, stav ovládaných elementů
arény a data ze senzorů robotů.
komponent spolu s případnými výpadky dat.
Tabulka 11.5: Synchronizace proudů dat, návaznosti na ostatní moduly.
Kódování audio,video a datových proudů
Modul kódování realizuje vlastní kódování video dat do příslušného kodeku. Součástí
kódování je zabalení proudu dat do zvolené obálky (kontejneru). V tomto modulu jsou
příslušné proudy dat kódovány v reálném čase nebo v případě kódování pro účely archivace
je vybraný časový interval kódován v režimu off-line.
Off-line kódování vyžaduje nejdříve uložení proudu dat na záznamové medium a následnou kompresi. Off-line kódování je nutné v případě nedostatečné výpočetní kapacity,
na druhé straně však vyžaduje dostatečný datový prostor a přenosovou kapacita úložného
zařízení.
Každý vstupní proud dat může být kódována do několika výstupních proudů. Například
v různých rozlišeních a v různých formátech a datových tocích. V závislosti na použitém
kontejneru obsahujícím video soubor je součástí také audio a datový proud. S ohledem
na možnou konfigurovatelnost uživatelského rozhraní je vhodné nechat na uživatelském
nastavení, které proudy chce sledovat.
197/217
SyRoTek - V003.1
Archivační záznamy jsou připravovány podle uživatelské konfigurace. Tyto záznamy jsou
určeny pro sledování v off-line režimu, a proto má v tomto případě smysl hovořit o vytváření
jediného souboru, který obsahuje všechny zvolené proudy.
Vstupem modulu kódování jsou také data ze senzorů. Současným vhodným formátem
pro zápis dat je XML, ačkoliv obsahuje tento formát mnoho redundantních znaků, je tento
formát dostatečně univerzální a rozšiřitelný. Případné zvýšené nároky na datový tok lze
snížit vhodnou kompresí tohoto textového formátu, případně speciálním kódováním do
binární podoby. Výchozí formát pro archivaci však musí být dostatečně čitelný, přenositelný
a rozšiřitelný.
Návaznosti na ostatní moduly jsou uvedeny v tabulce 11.6.
Funkce/Stav
Ukládání záznamů
Návaznost
Uživatelský
datový
prostor
Vstupy
Systémová
konfigurace kódování
Konfigurace kódování
Popis
Záznamy jsou vytvářeny pouze pokud
uživatelský datový prostor má dostatečnou volnou kapacitu. Kontrola kapacity probíhá před spuštěním vytváření archivu záznam, je-li kapacita dostatečná je rezervováno předpokládaný
úložný prostor. Záznam je nejdříve uložen v systémovém prostoru a po úplném vytvoření archivu záznamu je uložen v uživatelské části. Toto je zvláště
vhodné v případě off-line kódování záznamu.
Je součástí konfigurace systému SyRoTek a obsahuje údaje o vytvářeních
proudech v reálném čase, nastavení formátů a kodeků.
Uživatelská konfigurace archivace záznamů, obsahuje údaje o pořízením záznamu, čas a dobu trvání, konfigurace
proudů a nastavení kódování jednotlivých proudů. Tyto konfigurace může
měnit uživatel s rolí Administrátor Systému SyRoTek.
198/217
Funkce/Stav
Výstupy
Návaznost
Chyba, pád systému
Proudy
vytvářené
v reálném čase.
Archivované uživatelské záznamy
Logger
SyRoTek - V003.1
Popis
V případě výpadku systému dochází
také k výpadku v pořizovaných archivních záznamech. Případný výpadek musí být propagován do dalších
modulů jako je plánovač archivace záznamů a publikování, kde musí dojít
k informování uživatele o výpadku, případně s uvedením o důvodu výpadku
a plánovaném obnovení vizualizace.
Mohou být tvořeny off-line soubory
nebo uživatelsky definovanými proudy.
komponent spolu s případnými výpadky dat, zatížením kódovacích procesorů, události o změnách kódování,
příchozí nové požadavky a aktuální dostupné úložné kapacitě.
Tabulka 11.6: Kódování výstupních audio, video a datových proudů, návaznosti
na ostatní moduly.
Plánovač archivace záznamů
Plánovač archivace záznamů obsahuje registrované požadavky na pořízení záznamu
spolu s parametry uživatelských záznamů. Archivní uživatelské záznamy jsou ukládány do
uživatelského prostoru, který má přidělen každý uživatel systému SyRoTek. V závislosti
na řešených úlohách je uživateli přidělen další úložný prostor tak, aby mohl z určité úlohy
pořídit záznam v dostatečné kvalitě, který pak bude sloužit pro vyhodnocení řešení úlohy
tutorem. Systém musí být nakonfigurován tak, aby byl přidělený datový prostor dostatečný
pro požadované záznamy související s řešením úloh. Záznamy jsou však vytvářeny pouze
tehdy, je-li v uživatelském prostoru dostatek úložné kapacity. Před provedením finálního
experimentu s vyžadovaným záznamem, musí uživatel zajistit, že přidělený datový prostor
je volný. Předáním zodpovědnosti za správu přiděleného datového prostoru na uživatele
umožňuje definovaným způsobem řídit přidělování úložných kapacit.
199/217
Funkce/Stav
Návaznost
Uživatelský
datový
prostor
Plánované pořizování
záznamů.
SyRoTek - V003.1
Popis
Před spuštění pořizování záznamu je
nejdříve alokován prostor pro uložení
záznamu. Pořízení je spuštěno pouze
pokud uživatelský datový prostor obsahuje dostatečnou volnou kapacitu.
V případě nečekané události (např. pád
systému) je toto místo zpět uvolněno.
V souvislosti s případným ukládáním záznamu do systémového prostoru a následnému off-line kódování
je nutné zajistit také dostatečný systémový uložný prostor. Uživatel si proto
může nastavit parametry pořizovaného
záznamu pouze s ohledem na plánované
využití systémových kapacit. V nejnepříznivějším případě je záznam pořízen
jako kopie proudu vytvářeného v reálném čase. Z hlediska efektivního využití
systémových zdrojů je tato kopie ukládána pouze v jediné kopii. Po kompletním pořízení záznamu je tato kopie uložena do dalších uživatelských prostor.
Pro správnou funkčnost musí být zajištěno, že ačkoliv je soubor „fyzicky”
v uživatelském prostoru, nemůže uživatel soubor smazat do doby než je pořízena příslušná další kopie. V souvislosti s omezeným prostředky je nutné
zajistit správnou funkčnost pořizování
záznamů a to především pro uživatele, kteří mají rezervovaný čas pro řešení úloh. Ostatní uživatelé tak mohou být omezeni v možnosti pořizování
záznamů mimo svůj registrovaný čas
v systému SyRoTek.
200/217
Funkce/Stav
Registrace
požadavků na pořízení
záznamů.
Návaznost
Uživatelské role
Vstupy
Uživatelská nastavení.
Výstupy
Konfigurace kódování.
Logger
SyRoTek - V003.1
Popis
Uživatel může zvolit nastavení a registrovat požadavek na pořízení záznamů
podle aktuálního plánovaného vytížení
modulu kódování a podle své dynamické role v době pořizování záznamu.
Má-li uživatel rezervovaný systémový
čas (přístup k ploše a robotu/ům) v žádané době pořízení záznamu je tento
uživatel privilegovaným uživatel, který
je upřednostňován.
Nastavení pořízení záznamů běžnými
uživateli a uživateli, kteří monitorují
správný chod systému SyRoTek.
Podle plánovaných záznamů jsou konfigurovány dílčí moduly kódování a ukládání záznamů.
Logovací informace o událostech v modulu, události o změnách v požadavcích
záznamů, statistiky požadovaných záznamů a informace o kolizích a nedostupnosti služeb v souvislosti s omezením konfigurace systému.
Tabulka 11.7: Plánovač archivace záznamů, návaznosti na ostatní moduly.
11.7.1
Publikování audio, video a datových proudů a souborů
Část publikování vizualizačního systému představuje prezentační modul, jehož úkolem
je distribuovat audio, video a datové proudy uživatelům. Prezentování může probíhat formou nabízených proudů dat nebo přímo stažitelných souborů. Pro záznamy vytvářené
v reálném čase je nutné uvažovat proudový přenos dat. Přímo stažitelné soubory mohou
být archivované záznamy nebo předem připravené záznamy, které tvoří výukový materiál
jako jsou demonstrační video ukázky práce se systémem nebo ukázkové provedení některé
úlohy. Tyto soubory, zvláště pak video soubory je vhodné také nabízet ve formě proudů.
S ohledem na situace, kdy lze očekávat zvýšený počet žádostí o přehrávání určitého
proudu je vhodné doplnit mechanismus doručování o vyrovnávací mezipaměť. Realizace
mezipaměti může být velice náročná a v akademickém prostředí provozu systému SyRoTek
201/217
SyRoTek - V003.1
těžko proveditelná, je proto vhodné uvažovat o jiném způsobu doručování v některých
situacích.
Typickou situací, při které je požadován stejný proud doručovaný více klientům, jsou
případy, kdy v rámci výuky některého robotického předmětu je využíván systém SyRoTek.
V případě individuálního přístupu n uživatelů je potřebný datový tok nejméně n násobkem
dílčího datového toku. Tuto situaci lze řešit tak, že uživatel s rolí Tutor vybere příslušný
proud a následně jej spustí. Uživatelé tak budou simultánně sledovat příslušný proud tak,
jako by byl v režimu přenášení v reálném čase. V tomto případě lze vyžít technologie
multicast a vzhled k předpokladu, že většina uživatelů přistupuje ze stejné sítě jsou data
přenášena pouze jednou, navíc všichni uživatelé vidí týž časový okamžik záznamu. Alternativou je pak místní konfigurace a prezentace například z počítače Tutora bez aktivní
účasti systému SyRoTek.
Základním přístupovým bodem do systému SyRoTek je webové rozhraní, proto také
základní přístup k přehrávání video souborů je tvořen webovým rozhraním. V případě
přehrávaní video souborů je však nutné počítat se doplňkovým softwarem k vlastnímu
prohlížeči.
Všechny současné technologie podporují vkládání streamovaného obsahu na webové
stránky, v minimální verzi vložením odkazu. Po aktivaci příslušného odkazu dojde buď
přímo k přehrávání video souboru v rámci prohlížeče nebo je spuštěn externí program.
Vedle prezentování obsahu formou webových stránek je v případě streamů možné také
přistupovat přímo k nabízeným proudům z některé konkrétní aplikace. Informace o dostupných zdrojích (souborech) tak mohou být v jiném formátu, například v podobě „playlist”
souborů pro přehrávač. Univerzálním formátem pro přenos dat je XML, který může být
výchozím formátem pro export takových dat. Aktuální nabídka dostupných materiálů však
vyžaduje dynamické generování v závislosti na kontextu přihlášeného/nepřihlášeného uživatele. Je tedy nutné ošetřit stavy, kdy je požadován některý ze souborů, který již není
k dispozici.
Část publikování je propojena s moduly kódování, obsahem výukových materiálu, ale
také prezentuje obsah uživatelského prostoru. Tyto soubory jsou nejen čteny, ale také modifikovány a vytvářeny. V modulu vizualizace jsou však tyto soubory chápany v režimu
pouze pro čtení a nabízeny uživatelům podle jeho aktuálního kontextu. Zápis do uživatelského rozhraní je řešen v modulu správy uživatelského prostoru. Modifikace výukových
materiálů je realizována v modulu úloh a návodů. Součástí prezentace je také informace
o plánovaných výpadcích nebo informace o aktuálním (neplánovaném) výpadku. Návaznosti na ostatní moduly jsou shrnuty v tabulce 11.8.
202/217
Funkce/Stav
Virtuální přehrávač
Návaznost
Uživatelské rozhraní
Vstupy
Kódování
Uživatelský prostor
Připravené záznamy
Výstupy
Obsah
Webové rozhraní
SyRoTek - V003.1
Popis
Tutor může připravit a odstartovat
streamování příslušné záznamu, což
vede na snížení nároků na přenosovou kapacitu při vícenásobné simultánním sledování více uživateli (např.
v rámci výuky nějakého předmětu) využitím technologie multicast.
On-line kódované proudy vznikající
v reálném čase.
Soubory, které reprezentují archivované záznamy, mohou být publikovány
přímo jako soubory nebo technologií
streamováním.
Výukový materiál, reprezentovaný audio/video nebo jinými datovými soubory, které mohou být přístupné přímo
nebo streamovány vhodnou technologií.
Obsah nabízených služeb (souborů)
vizualizačního modulu je dynamický
v závislosti na kontextu profilu přihlášeného (případně nepřihlášeného) uživatele. Tento obsah je nabízen ve formě
XML souboru a přístupný z podporovaných uživatelských rozhraních (web,
vývojové prostředí, informační aplikace).
Základním přístupovým bodem k systému SyRoTek je webové rozhraní, ve
kterém jsou zobrazeny prezentované
výstupy vizualizačního modulu.
203/217
Funkce/Stav
Návaznost
Serverové služby
Logger
SyRoTek - V003.1
Popis
Streamování je realizováno streamovacím serverem a přímé poskytování souborů pak webovým serverem. V obou
případech se jedná o realizaci síťové
služby, které je přístupná z veřejné části
Internetu, proto je nutné realizovat
vhodnou uvažovat o vhodně formě zabezpečeného přístupu. Je nutné povolit příslušné serverové služby v případě
lokálního firewall, přístup ke službě je
vhodné realizovat technologií zabezpečeného protokolu SSL. Tato návaznost
také souvisí s konkrétní technickou realizací síťového propojení systém SyRoTek a příslušnou uživatelskou stanicí, např. možnost použití technologie
multicast pro streamování nebo využití
protokolu IPv6 (RFC 3019 [126], RFC
3513 [127]).
Jsou logovány jednotlivé přístupy uživatelů a jejich požadavky pro vyhodnocení efektivity publikování.
Tabulka 11.8: Publikování audio, video a datových souborů.
Uživatel
Část vizualizačního systému, která je na obrázku 11.25 vyznačena blokem uživatel, reprezentuje uživatelské rozhraní vizualizačního systému. Tento blok reprezentuje definici
vzhledu webového rozhraní, ale především uživatelskou aplikaci pro přehrávání záznamů.
Záznamy obsahují audio a video soubory, ale také data ze senzorů.
Audio a video soubory je možné přehrávat některým z přehrávačů příslušné technologie streamování, případně běžným přehrávačem multimédií. V případě více video záznamů
je však již nutné poskytnout uživateli podporu pro simultánní přehrávání, neboť video
záznamy jsou synchronizovány a přehrávání ve více nezávislých instancích aplikace přehrávače zpravidla neumožňuje pohodlný pohyb ve všech záznamech najednou. Přehrávání
může probíhat ve streamovacím režimu, kdy jsou data přenášena ze streamovacího serveru
systému SyRoTek k uživateli.
204/217
SyRoTek - V003.1
Druhý režim přehrávání se odehrává pouze za účasti uživatelské stanice, na které jsou
uloženy soubory se záznamy. Nejjednodušším způsobem přehráváním je realizace lokálního
streamovacího serveru, který streamuje příslušnou sadu souborů. Výhoda toho řešení je
jednotný přístup pro přehrávání postavený na přijmu streamu. Z tohoto úhlu pohledu je
důležitým aspektem zvoleného řešení licenční politika příslušné technologie.
Nejdůležitější funkcionalitou systému vizualizace je však vizualizace dat ze senzorů a jejich synchronizace s obrazem reálné scény. Motivace toho přístupu je spočívá v podpoře
ladění řešených úloh robotiky, ve kterých je reálný svět vnímán senzory založenými na různých principech. Obraz reálné scény spolu s příslušnými hodnotami naměřených hodnot
senzorů pomáhá lepé interpretovat data, a navrhnout vhodný algoritmus. Zobrazení dat
vyžaduje vlastní specifickou implementaci přehrávače.
V souvislosti s požadavkem možnosti řešení příslušné úlohy i bez přímého připojení
k systému SyRoTek je vhodné realizovat přehrávání dat ze senzorů jako simulátor, který
interpretuje data. V případě dat ze senzorů na robotu je klíčovou hodnotu skutečná pozice
robotu, která v tomto případě bude získávána z globálního lokalizačního systému.
Kombinace simulátoru, resp. vizualizace simulátoru a přehrávače video záznamů v jediné
aplikaci umožňuje synchronizovaný posun v záznamu. Samotný přehrávač dat ze senzorů
implementovaný jako 3D model prostředí arény je vizualizace dění na ploše, které poskytuje
interaktivní vizualizaci s velmi malým datovým tokem a jeho použití je vhodné v případech
připojení k síti Internet komunikačním kanálem s velmi malou kapacitou.
Vzhledem k poskytování proudu dat, který obsahuje data ze senzorů spolu s údaji
o pozici robotů z globálního lokalizačního systému, je vhodné zajistit, aby tato data nebyla
zneužitelná při řešení a odevzdávání úlohy, například lokalizace. Odevzdávání úloh bude
probíhat spuštěním uživatelského programu na robotu a řídicím počítači.
Při této konfiguraci je postačující, aby běžící program v uživatelském prostoru konkrétního uživatele nemohl vytvořit spojení s jiným programem nebo počítačem, než který je
povolen. V případě více-procesorové verze programu je nutné realizovat komunikaci mezi
programy tak, aby nebylo možné přenášet nežádoucí data. Tento relativně komplikovaný
proces, má však smysl řešit pouze v případě automatického vyhodnocování úlohy. Zkušený
Tutor pohledem do zdrojového kódu pozná, zda algoritmus neobsahuje podezřelé části.
Přehrávač záznamů tvoří samostatná aplikace, která zobrazuje streamována data ze serveru systému SyRoTek nebo soubory z lokálního pevného disku (či jiného záznamového
média). Jádro tohoto přehrávače je použito pro vytvoření zásuvného modulu pro podporované integrované vývojové prostředí. Tak lze přímo z prostředí, ve kterém uživatel píše
příslušný algoritmus a ladit vytvářenou aplikaci spolu s grafickou vizualizací vstupních dat
a obrazem reálné scény.
205/217
Funkce/Stav
Přehrávač dat
Návaznost
Zobrazení záznamů
Webový prohlížeč uživatelské stanice
Vizualizační aplikace
Vývojové nástroje
Řízení přístupu
Bezpečnostní politika
systému SyRoTek
Uživatelské
ponenty v
počítači
komřídicím
SyRoTek - V003.1
Popis
Součástí řídicího počítače je také simulátor hardwarových částí robotů, senzorů a arény. Tento simulátor tvoří výpočetní jádro přehrávače, který interpretuje záznam dat ze senzorů a zobrazuje 3D model arény, robotů a senzorů.
Přehrávání
audio/video
záznamu
z webového prohlížeče vyžaduje
konkrétní zásuvný modul, který je
součástí balíku softwarové podpory
uživatele systému SyRoTek. Přehrávání datových proudů je realizováno
implementovaným zásuvným modulem, resp. voláním externí aplikace.
Vizualizační aplikace je samostatný
program pro přehrávání záznamů. Součástí této aplikace je simulátor.
Vizualizační aplikace je realizována
jako zásuvný modul do podporovaného integrovaného vývojového prostředí (IDE).
Vzdálený přístup k datům, zvláště pak
k uživatelským datům, je možný pouze
pro autentizovaného uživatele. Ověření
identity uživatele probíhá po zabezpečeném komunikačním kanále.
Uživatelská aplikace spuštěna na řídicím počítači má omezené možnosti komunikace po jiných než vyhrazených
komunikačních kanálech.
Tabulka 11.9: Uživatelské rozhraní systému vizualizace, návaznosti na ostatní
moduly.
11.7.2
Závěr
Dílčí části systému vizualizace jsou zapojeny do systému logování, které obsahuje informace o činnosti jednotlivých částí systému SyRoTek. Rovněž je každý dílčí modul moČVUT FEL, Gerstner Laboratory, ProTyS a.s.
206/217
SyRoTek - V003.1
nitorován, zda jeho činnost probíhá správně. Ze získaných dat jsou vytvářeny informace
o činnosti, které jsou dále využity k analýze výkonu systému.
Velmi důležitou funkcionalitou systému vizualizace je automatické zotavení po pádu/havárii některé z částí. Například v případě restartu hlavního kódovacího počítače musí
dojít k automatického nastartovaní všech častí tak, aby byl systém vizualizace po restartu
uveden automatický do plně funkčního stavu.
Rozsah poskytovaných služeb modulu vizualizace jsou ovlivněny hardwarovou realizací
a počtem uživatelů pracujících se systémem SyRoTek. Kvalita služeb je tedy přímo úměrná
hardwarovým prostředkům a nepřímo úměrná počtu uživatelů. Pro zajištění dostupnosti
služeb jsou definovány role a dynamické role uživatelů, které jim určují priority k přístupu
ke sdíleným prostředkům.
Nedílnou součástí provozu systému je vyhodnocování výkonnosti jednotlivých částí a
identifikace problémových míst (bottle-neck ) systému a příslušná modifikace nastavení a
hardwarové konfigurace. S rostoucím počtem uživatelů lze očekávat zvyšující se nároky na
technické vybavení. S výhledem dalšího používání systému je jedním z důležitých kritérií
snadná rozšiřitelnost systému (škálovatelnost).
207/217
SyRoTek - V003.1
Kapitola 12
Závěr
Hlavním obsahem této zprávy je detailní popis konceptu systému SyRoTek. Zpráva rozšiřuje prvotní koncept uvedený ve zprávě [1] a blíže specifikuje jednotlivé vazby mezi dílčími
objekty systému. Detailní koncept vychází z některých klíčových rozhodnutí o způsobu
realizace vybraných objektů systému. Tato rozhodnutí jsou uvedena v úvodní kapitole a
mezi nejdůležitější rozhodnutí patří využití systému Player jako hlavního rozhraní přístupu
uživatelské aplikace k robotické platformě. Tento systém je však nutné rozšířit o vhodné
zapouzdření přístupu k robotické platformě s ohledem na požadované vlastnosti systému
pro podporu vzdáleného vzdělávání Toto rozšíření bude realizováno pro uživatele pokud
možno transparentním způsobem, neboť uživatelská aplikace může využívat standardních
knihoven běžné instalace systému Player.
Nezbytnou součástí většiny objektů systému SyRoTek je uživatelský přístup velmi úzce
související s koncepcí Internetového přístupu, která bude řešena v následujícím období
řešení projektu SyRoTek. V objektech, které jsou přístupné uživatelům, vznikají různé kategorie uživatelů a podle příslušného kontextu mají uživatelé v rámci konkrétního objektu
příslušnou uživatelskou roli. Tyto role se uplatňují při řízení přístupu k různým funkcím
systému SyRoTek. Jednou z náplní koncepce Internetového přístupu, je proto definice a případná unifikace hlavních uživatelských rolí a jejich přesné a jednoznačné vymezení v rámci
konkrétní funkcí, resp. základních objektů systému SyRoTek.
Celková detailní koncepce systému umožňuje stanovení plánu vlastních realizačních prací
na softwarových a hardwarových částech systému SyRoTek. Výstupem těchto prací je vytvoření systému, ve kterém uživatel řeší robotickou úlohu implementací uživatelské aplikace, jenž je spouštěna na řídicím nebo palubním počítači a ovládá reálný robot. S ohledem
na dílčí závěry kapitol 5 (Řídicí počítač), 6 (Roboty a senzory), 7 (Uživatelská stanice) je
vhodné realizaci jednotlivých aplikací založit na společných rysech, které lze shrnout do
základních systémových knihoven systému SyRoTek.
S výhodou lze také definovat vývojové prostředí pro realizaci systémových aplikací s ohledem na vývoj uživatelské aplikace, neboť tyto dva druhy aplikací se v podstatě liší pouze
používanými knihovnami a uživatelským prostorem (ve smyslu práv v operačním systému),
208/217
KAPITOLA 12. ZÁVĚR
SyRoTek - V003.1
v rámci kterého jsou spouštěny. Samotný vývojový proces je totožný, neboť uživatelská
aplikace může být vyvíjena jak pro řídicí počítač, tak pro palubní počítač, podobně jako
systémové aplikace.
Při vlastní implementaci software bude kladen důraz na postupné rozšiřování funkcionality jednotlivých aplikací a znovupoužitelnost již implementovaných funkcí, jak bylo
uvedeno v oddílu 7.5. Z pohledu implementace jednotlivých systémových aplikací je vhodné
zvážit použití některé technologie middleware, která může výrazným způsobem zjednodušit unifikaci vzájemné komunikace jednotlivých aplikací. Důležitými aspekty při případné
volbě konkrétní technologie jsou:
• náročnost používání,
• možnost využití nezávislého radiového komunikačního systému (je použit při komunikaci s roboty),
neboť praktické použití této technologie musí být možné nejen na řídicím počítači, případně
uživatelské stanici, ale také na palubním počítači.
Základní milníky implementace systému SyRoTek jsou následující.
1. Realizace základního softwarového vybavení:
(a) software palubního počítače,
(b) software řídicího počítače.
2. Dokončení základní hardwarových konstrukcí:
(a) konstrukce arény a robotu/ů,
(b) realizace lokalizačního systému.
3. První ověření funkčnosti systému:
(a) unifikace uživatelského prostoru,
(b) ověření funkčnosti systému realizací prvních úloh.
4. Realizace Internetového přístupu:
(a) webové rozhraní,
(b) vizualizace,
(c) uživatelská stanice.
5. Dokončení:
(a) manuály, tutoriály, kurzy,
209/217
SyRoTek - V003.1
(b) úlohy,
(c) roboty.
6. Provoz:
(a) uživatelská podpora,
(b) servis,
(c) vyhodnocení používání systému.
210/217
LITERATURA
SyRoTek - V003.1
Literatura
[1] Jan Faigl, Jan Chudoba, Miroslav Kulich, Roman Mázl, Jiří Pavlíček, Libor Přeučil,
and Petr Štěpán. SyRoTek v001.2 - Koncepce systému. Technical Report GLR
79/07, ProTyS a.s. and ČVUT v Praze, FEL, Gerstner Laboratory, 2007.
[2] Jan Faigl, Jan Chudoba, Miroslav Kulich, Roman Mázl, Karel Košnar, Libor Přeučil,
and Petr Štěpán. SyRoTek v002.1 - Architektura robotů. Technical Report GLR
81/08, ProTyS a.s. and ČVUT v Praze, FEL, Gerstner Laboratory, 2008.
[3] Jan Faigl, Jan Chudoba, Miroslav Kulich, Roman Mázl, Jiří Pavlíček, Libor Přeučil,
and Petr Štěpán. SyRoTek v001.1 - Stav problematiky. Technical Report GLR 78/07,
ProTyS a.s. and ČVUT v Praze, FEL, Gerstner Laboratory, 2007.
[4] http://www.moodle.org.
[5] http://www.apache.org.
[6] http://insurrection.tigris.org.
[7] http://www.adobe.com/products/flash.
[8] http://www.docbook.org.
[9] http://www.pragma-ade.com.
[10] K. Zeilenga. Lightweight Directory Access Protocol (LDAP): Technical Specification
Road Map. RFC 4510 (Proposed Standard), June 2006.
[11] E. Rescorla. HTTP Over TLS. RFC 2818 (Informational), May 2000.
[12] http://www.webdav.org.
[13] http://en.wikipedia.org/wiki/Tunneling_protocol.
[14] http://www.mysql.com.
[15] http://www.oracle.com/database/berkeley-db.html.
[16] http://www.sqlite.org.
211/217
LITERATURA
SyRoTek - V003.1
[17] Richard W. Stevens and Stephen A. Rago. Advanced Programming in the UNIX(R)
Environment (2nd Edition). Addison-Wesley Professional, 2005.
[18] http://playerstage.sourceforge.net/index.php?src=gazebo.
[19] http://www.opengl.org.
[20] http://playerstage.sourceforge.net/wiki/Clients_Visualization.
[21] http://ardev.sourceforge.net/wiki/index.php/Main_Page.
[22] http://miarn.sourceforge.net/html/index.html.
[23] Daniel J. Barrett, Robert G. Byrnes, and Richard E. Silverman. SSH, the Secure
Shell, 2nd Edition. O’Reilly, May 2005.
[24] http://www.eclipse.org.
[25] http://www.netbeans.org.
[26] http://robotics.ece.auckland.ac.nz/index.php?option=com_docman&task=
cat_view&gid=5&Itemid=32.
[27] http://sourceware.org/gdb.
[28] http://www.ruby-lang.org/en/.
[29] http://www.python.org.
[30] http://www.lua.org.
[31] Ruby, io, php, python, lua, java, perl, applescript, tcl, elisp, javascript,
ocaml, ghostscript, and c fractal benchmark. http://www.timestretch.com/
FractalBenchmark.html.
[32] The computer language benchmarks game. http://shootout.alioth.debian.org.
[33] http://www.freebsd.org.
[34] Jan Faigl, Jan Chudoba, Miroslav Kulich, Roman Mázl, Karel Košnar, Libor Přeučil,
and Petr Štěpán. SyRoTek c004.1 - Koncept hardwarové komunikace. Technical
Report GLR 85/08, ProTyS a.s. and ČVUT v Praze, FEL, Gerstner Laboratory,
May 2008. ver. 1.0.
[35] http://www.mesa3d.org.
[36] http://www.straightrunning.com/XmingNotes.
[37] http://www.microsoft.com/windows/products/winfamily/virtualpc/
default.mspx.
212/217
LITERATURA
SyRoTek - V003.1
[38] http://www.vmware.com.
[39] http://www.trolltech.com/products/qt/index.html.
[40] http://www.fltk.org.
[41] http://www.wxwidgets.org.
[42] http://www.libsdl.org/.
[43] http://www.gnu.org/software/make/make.html.
[44] http://ant.apache.org.
[45] http://www.scons.org.
[46] http://subversion.tigris.org.
[47] http://esvn.umputun.com.
[48] http://tortoisesvn.net.
[49] http://pysvn.tigris.org.
[50] http://www.twobarleycorns.net/tkcvs.html.
[51] http://www.rapidsvn.org/index.php/Main_Page.
[52] http://subclipse.tigris.org.
[53] http://subversion.netbeans.org.
[54] http://www.ratslife.org.
[55] http://en.wikipedia.org/wiki/Self-Monitoring,_Analysis,_and_
Reporting_Technology.
[56] Walter F. Tichy. RCS a system for version control. Softw. Pract. Exper., 15(7):637–
654, 1985.
[57] http://www.mrunix.net/webalizer.
[58] Marshall Kirk McKusick and Gregory R. Ganger. Soft updates: A technique for
eliminating most synchronous writes in the fast filesystem. In Proceedings of the
FREENIX Track: 1999 USENIX Annual Technical Conference, pages 1–17, 1999.
[59] J. Bonwick. Zfs: The last word in file systems., 2006. http://www.opensolaris.
org/os/community/zfs/docs/zfs_last.pdf.
213/217
LITERATURA
SyRoTek - V003.1
[60] Holger Linde. On Aspects of Indoor Localization. PhD thesis, University of Dortmund, Germany, 2006.
[61] Luis Navarro, Chris Paredis, and Pradeep Khosla. A beacon system for the localization of distributed robotic teams. In Proceedings of the International Conference
on Field and Service Robotics (FSR ’99), August 1999.
[62] D. Hähnel, W. Burgard, D. Fox, K. Fishkin, and M. Philipose. Mapping and localization with RFID technology. In Proc. of the IEEE International Conference on
Robotics and Automation (ICRA), 2004.
[63] Chuang wen You, Yi-Chao Chen, Ji-Rung Chiang, Polly Huang, Hao hua Chu, and
Seng-Yong Lau. Sensor-enhanced mobility prediction for energy-efficient localization.
In Proceedings of Third Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks, (IEEE SECON 2006), September 2006.
[64] The limits of localization using signal strength: a comparative study, 2004.
[65] Asis Nasipuri and Ribal Najjar. Experimental evaluation of an angle based indoor
localization system. In Proceedings of the Second Workshop on Wireless Network
Measurements ( WiNMee 2006 ), Boston, MA, USA, April 2006.
[66] NorthStar Evolution robotics. http://www.evolution.com/products/northstar/.
[67] NorthStar Evolution robotics. NorthStar projector kit - user guide.
[68] Jeremy Ma. Northstar calibration. Technical report, California Institute of Technology, May 2006.
[69] Jan Faigl, Tomáš Krajník, Martin Saska, Karel Košnar, and Jan Chudoba. Fira
MiroSot - G-Bots team description. Fira EuroCup Robot Soccer Workshop, 2005.
[70] Tomáš Krajn ík, Jan Faigl, and L. Přeučil. Decision support by simulation in a
robotic soccer domain. In F. Breitenecker I. Troch, editor, MATHMOD 2006, volume
1,2 of ARGESIM-Reports, ISBN 3-901608-25-7, page 10. Institute for Analysis and
Scientific Computation at Vienna University of Technology, 2006.
[71] http://www.baslerweb.com/index.html.
[72] http://www.turnkey-solutions.com.au/index.html.
[73] http://www.turnkey-solutions.com.au/cam_firewirecamera_index.
htm#Basler%20Cameras.
[74] http://www.matrix-vision.com/products/hardware/mvbluefox.php?lang=en.
214/217
LITERATURA
SyRoTek - V003.1
[75] Camera Link - Specifications of the Camera Link Interface Standard for Digital Cameras and Frame Grabbers, 2000. http://www.alacron.com/downloads/
vncl98076xz/CameraLinkSPEC.pdf.
[76] http://www.mikrotron.de/index.php?de_home.
[77] Kamery s rozhraním Camera Link. http://www.turnkey-solutions.com.au/cam_
camera_link_index.htm.
[78] http://www.euresys.com/Products/grablink/GrablinkSeries.asp.
[79] http://www.datx.com/datx/products_pricing/prod_dt3145_price_acc.jsp.
[80] http://www.matrix-vision.com/products/hardware/mvhyperion.php?lang=en.
[81] http://www.epixinc.com/index.htm.
[82] http://www.prosilica.com/index.html.
[83] http://vfm.dalsa.com.
[84] http://www.matrix-vision.com/products/hardware/tablegammatitan.php?
lang=en.
[85] http://www.alacron.com.
[86] http://www.arvoo.com/html/home.htm.
[87] http://www.matrox.com/imaging/products/odyssey_xcl/home.cfm.
[88] http://www.kanecomputing.co.uk.
[89] http://www.matrix-vision.com/products/hardware/mvbluelynx.php?lang=en.
[90] http://www.apollo-image.com.
[91] http://www.vision-components.com/en.
[92] http://www.neuricam.com.
[93] http://www.tattile.it.
[94] http://www.leutron.com.
[95] http://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0.
[96] http://www.unibrain.com.
[97] http://www.adobe.com.
215/217
LITERATURA
SyRoTek - V003.1
[98] http://www.lupa.cz/clanky/jdeme-do-online-videa-1.
[99] http://developer.apple.com/opensource/server/streaming/index.html.
[100] http://www.realnetworks.com.
[101] https://helixcommunity.org.
[102] http://www.theora.org.
[103] http://www.lupa.cz/clanky/jdeme-do-online-videa-2.
[104] http://www.videolan.org/vlc.
[105] http://www.videolan.org/developers/x264.html.
[106] http://sourceforge.net/projects/hdot264.
[107] http://www.videolan.org/vlc/streaming.html.
[108] http://www.videolan.org/.
[109] Michal Krsek. Streaming multimediálního obsahu s vyskoým rozlišením. Technical
Report 23/2005, CESNET, Prosinec 2005.
[110] http://www.xiph.org.
[111] http://www.techsmith.com.
[112] http://www.viewcast.com.
[113] http://www.ituner.com.
[114] http://www.gaotek.com/index.php?main_page=index&cPath=116_92_
46&zenid=d8c56aed08fe4a1f365fd1724b3ba895.
[115] http://www.digital-rapids.com/Products/IndividualProducts/DRC-Stream%
20500.aspx.
[116] http://www.firefox2.com.
[117] http://www.mplayerhq.hu.
[118] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocol
for Real-Time Applications. RFC 3550 (Standard), July 2003.
[119] H. Schulzrinne and S. Casner. RTP Profile for Audio and Video Conferences with
Minimal Control. RFC 3551 (Standard), July 2003.
216/217
LITERATURA
SyRoTek - V003.1
[120] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman. The Secure
Real-time Transport Protocol (SRTP). RFC 3711 (Proposed Standard), March 2004.
[121] H. Schulzrinne, A. Rao, and R. Lanphier. Real Time Streaming Protocol (RTSP).
RFC 2326 (Proposed Standard), April 1998.
[122] B. Quinn and K. Almeroth. IP Multicast Applications: Challenges and Solutions.
RFC 3170 (Informational), September 2001.
[123] http://labs.adobe.com/technologies/apollo.
[124] http://sam.zoy.org/projects/libcaca.
[125] http://www.axis.com.
[126] B. Haberman and R. Worzella. IP Version 6 Management Information Base for The
Multicast Listener Discovery Protocol. RFC 3019 (Proposed Standard), January
2001.
[127] R. Hinden and S. Deering. Internet Protocol Version 6 (IPv6) Addressing Architecture. RFC 3513 (Proposed Standard), April 2003. Obsoleted by RFC 4291.
217/217

Systém pro robotickou tele-výuku

Transkript

Podobné dokumenty

ročenka - aktuálně - Západočeská univerzita

Sborník konference - XXXVIII. dny lékařské biofyziky

Workshop biomedicínského inženýrství a informatiky 2013. 2013

Prezentace aplikace PowerPoint

Kalibrace lokalizačního vizuálního systému Calibration of

práci - Intelligent and Mobile Robotics Group

Algoritmy skupinové inteligence pro využití v multi

Navrh ridici architektury bezpilotniho vrtulniku LinkQuad

TEROSON MS 939 BK

Nástroje kvality. Softwarový proces Obsah 7 základn´ıch (“starých

Výroční zpráva 2012

Worldwide Industrial Camera Directory

lšiCB

Tomas Krajnik - Research outputs Journals and Magazines Books

CRYOTECH sro

Data Sheet (Czech)