Re: Tak co s tym spravime?, Was: Roboticky den

[Ing. František Burian]

Zdravim konferujici,

  Nedalo mi to, musim reagovat. Jak jiz mozna nekteri vite, jsem clenem tymu, ktery v lonskem 
RoboTour zvitezil 1. misto, a to za pouziti "hloupeho" algoritmu. Necetl jsem vsechno, nicmene 
na nejake postrehy musim reagovat, protoze jsem vedoucim (nedobrovolne zvolenym, aby nekdo 
nenamital...) par robotickych projektu, vcetne robotu U.T.A.R. 

  Na VUT v Brne je ted velky zajem o mobilni roboty - za tento rok se nam narodily 4 nove kusy 
naprosto odlisnych robotu, kteri studenti z vlastni iniciativy v ruznych tymech sestavili a osadili
 senzory v ramci predmetu Robotika, ktery unas na fakulte ucime. Musim podotknout, ze reseni 
jsou docela ruzna, a nechali jsme volne ruce studentum, aby si pohrali. Po detailnejsim zkoumani 
se naslo par zakladnich problemu, ktere se opakovaly, a meli byste se jich vyvarovat:

1. VEDENI

Kazdy tym se musi semknout, a musi vedet co dela. To, co jsme predvedli na Robotour 2007 se 
priznam bylo hrozne. Sestava 4 jedincu, pozue minimalne kooperujicich, kdy kazdy zna pouze svuj 
dil, prace ani nevede o tom druhem, bez aktivniho zapojovani do reseni problemu. Pokud v tymu 
neni vudce, ktery ma vizi, a vi PRESNE, co chce, tak to tak vypada. Tym je demotivovany, a k 
"vyhecovani" dojde tyden pred soutezi. Tez chce mit profesionalizovany tym, tedy mit jednoho/dva 
programatory, jednoho/dva eletrikare. Nesmi byt kolizni v nazorech !!!

2. RIZENI

Mame tu mnoho robotu, nektere maji PC jako ridici ovladaci centrum (MicroATX, i ruzne podobne 
boardy), a nektere jsou ovladane z nejakeho jednocipu. Musim rict, ani jeden z tech rizenych 
pomoci PC nejede podle parametru. Navrhari byli vzdycky na pocatku uneseni jednoduchosti 
a RAD (Rapid application Development), at uz rizenych pomoci C,C++,C#, Delphi nebo jinych 
nastroju. Jenze zrada je, ze u takovych systemu muze ve velmi rychle dobe neco "uhnit" a opravdu 
velmi spatne se zavady hledaji, protoze konsekvence se kombinuji (napriklad Linuxove stroje mely 
problemy s cronem, windows stroje nekdy nenabootovaly apod.) Prosim neresme detaily, Jde o princip. 
Nehlede na to, ze seriove porty v PC nejsou az tak uplne SUPER, jak by se mohly zdat ... (vkladani mezer 
az 20 ms mezi znaky apod.) Na druhou stranu stroje, rizene nejakym z MCU (AVR :o), ale i Rabbity, Coldfire, 
a ja nevim co jeste se tu pouziva jsou jednoduse odladitelne, a da se tam primo zamerit na ladeni problemu - 
nemusi se resit vazby na multitasking OS. Vse je krasne casove operujici - lze si testovat osciloskopem sledovat 
nohu MCU, ktery ji taha podle toho kde prave je, a skoro vubec se nestava, ze tam neco "uhnije" (pokud se 
neprepoluji vstupni svorky, nestrci se drat kam nema apod.). JEDINY a opravdu jediny problem je vypocetni vykon. 
Ze sve doposavadni roboticke praxe vim, ze 90% reseni lze napsat opravdu jednoduse, a jakakoliv slozitost zavani 
poruchou. I u naseho vojenskeho supertajneho robota, ktery vyvijime, jiz vsechny PC opustily dvere nasi 
laboratore, a vime proc ... (pro rejpaly, ne vsechny ale snaha tu je :-)

3. ANALYZA CHYB

Tohle bylo u uplne vsech robotu na soutezi zanedbano, nebo reseno pouze okrajove. Dle meho nazoru to 
byl prave tento duvod, proc jsme zvitezili. Protoze jsme si dokazali vycislit, co technika nam dostupna 
v te dobe dokazala predvest. Je sice krasne, ze laserovy skener SICK zmeri okoli, podle ktereho se mohu 
orientovat, ale pohybujici osoby v zornem poli toto mereni naprosto znehodnoti (mozna Gerstnerovic lab vi 
o cem mluvim, ti to mozna dokazali nejak slozite eliminovat ale to je know-how za kterym jsou leta prace ...). 
Krasny je gyroskop, ktery s teplotou ujizdi, GPS se zakladni presnosti radiusu 7 metru pod stromy (viz ty hlasice, 
co mel kazdy robot na kapote - sef se koukal online na netu a byl zdeseny, co delame v tom travniku, kdyz jsme 
vlastne na ceste.). Nebo kompasy, zavisle na nakloneni, s gyroskopickou korekci falirujici pri zrychleni robota. 
Odometrie, ktere se s casem zvysuje chyba, kamera, ktera je sebelepsi proste proti slunci nema sanci (za soucasnych 
technologii) ... Vse se da vice - mene resit, temer vzdy kombinaci senzoru, ktere si my jsme si vybrali senzory, 
u kterych to zvladneme naprogramovat za tyden, a u kterych dokazeme "selskym rozumem" tyto chyby vycislit.

4. DOKUMENTACE

Vsechny snahy vedou na decentralizovane systemy, ktere, jak tu jiz nekdo z prumyslu rekl, jsou opravdu lepsi. 
Bohuzel u takovychto systemu je potreba davat opravdu poradneho majzla na dokumentaci, kdo, kdy, s kym bude 
komunikovat, a jaka data mu preda, navic, pokud to ma prevzit po nem nekdo jiny i mit konzistentni HW a SW dokumentaci, 
a cislovani verzi. Ti, co maji ISO mozna vedi o cem je rec, nekteri to berou jako nutne zlo, ale ze sveho postu musim 
uznat, ze ty tymy, ktere dokumentuji, jsou proste uspesnejsi.

5. FINANCE

Tohle pisu az na konec, protoze to mnohdy neni zadrhel, vetsinou je to banda nadsencu, ktera ty penize sezene, ale ne 
vzdy nakup materialu je oduvodneny, a chce to mit kritika, ktery voli mezi variantami, ktera je vyhodnejsi. Dost casto
se stava, ze se koupi senzor, ktery pak ve vysledku vubec nejde pouzit, protoze meri napriklad jednou za sekundu ale 
potreba je to 10x apod ... Souvisi to i s dokumentaci a sledovanim projektu.


Treba jeste na nejake vzpomenu

Abych vas neodradil, od zalozeni hw-news tymu, tak muzu rict, ze vam fandim, a docela rad i pomuzu, ze sveho postu 
doktoranda bych i mel pomahat "studentum", snazicim se nejakym zpusobem vyresit problem. Jak rekl nejaky moudry ucenec,

"Neni dulezity cil, je dulezita cesta"

Pokud vezmeme ad-absurdum tato slova, pak Martin Dlouhy a spol. zvladli udelat obrovsky kus prace, ikdyz byla fura 
nejasnosti ohledne pravidel. Ale vzdyt o to neslo. Slo hlavne o tu cestu - o to pohnout bastliri, pohnout s sikovnymi 
lidmi, aby neco vytvorili, a posunuli vedeni dal, a neco se pak naucili.


S pozdravem, 

  F. Burian