Seznámení s Playerem

Od skončení soutěže Robotour 2008, kde na společném workshopu tým Short Circuits popisoval svého robota, na Player/Stage narážím na každém kroku. Co se stalo? Co je na tom softwarovém balíku tak úžasného?! Případně co si představit pod „device interface” jak se píše v původním popisu Playeru?

Pokud začínáte s roboty a postupujete od blikání s LEDkou, přes hýbání servem a nakonec si postavíte malého robůtka, který se zúčastní soutěže jízdy podél čáry, tak na Player/Stage možná nikdy nenarazíte. Není třeba, byla by to pro vás pouze překážka.

Pokud ale postoupíte do „vyšší kategorie” a začnete si hrát s roboty, kteří mají už větší výpočetní výkon a na robotu vám běží třeba nějaký linuxový router, dostanete se do fáze, kdy přemýšlíte jak napsat software, aby robot dělal „něco chytrého” nebo „něco užitečného”. K tomu už vám nebude stačit pouze s robotem jezdit, ale pravděpodobně přidáte nějaké senzory, začnete se vyhýbat překážkám, mapovat prostor, plánovat cestu, …

Budete-li se roboty zabývat ať už jako hobby nebo ve škole, určitě dospějete do situace, kdy by se vám hodilo software napsaný na jednoho robota použít na nějakého jiného. Problém je, že ten druhý robot ale má například jinak velká kolečka, místo řízení po sériové lince je napojen na I2C a třeba místo IR senzorů má sonary. Když se vám to stane poprvé, tak v lepším případě upravíte pár konstant a v horším program přepíšete. Věřte nebo ne, časem vás to přestane bavit a budete chtít nějaký společný základ. Bude to chtít nějaký standard, o který se můžete opřít. V té chvíli bych vás seznámil s Player/Stage.

Začněme od toho nejjednoduššího — naučíme se jezdit s „univerzálním robotem”. Nejprve se vrátíme k malému robotu, postavenému na jednočipu, kde rychlost otáčení kola je dána počtem tiků enkodérů za nějaký časový interval (třeba 20ms). Zde vám stačí experimentálně zjistit, že když na PWM motoru nastavíte hodnotu 37, tak se kolo pomalu otáčí. Algoritmus si pak můžete poskládat z jednoduchých funkcí jeď rovně, zatoč doprava, zatoč doleva a stůj. Samozřejmě to samé můžete udělat i na robotovi řízenému z nějakého PC, a bohužel hodně robotiků v této fázi nějaký čas zůstává. Věřte mi, že když někomu řeknete, že váš robot jede rychlosti 420 tiků za jedno přetečení časovače, tak to nikomu nic neřekne, ani jestli robot jede rychle či pomalu.

Tady je ještě pomoc snadná a málo kdo by o ní diskutoval. Prostě převeďte vaše tiky (nemyslím teď cukání oka, které se s touto činností dříve či později dostaví) na nějaké smysluplné jednotky. Čas měřte v sekundách, vzdálenosti v metrech a rychlost tedy v metrech za sekundu. Nevěřili byste kolik účastníků Eurobota raději počítá v centimetrech — hřiště je typicky velké 2.1m x 3m, tj. 210x300 a jde to rovnou nakreslit … nedělejte to. Jednou narazíte.

Pokud se shodneme na jednotkách (ani toto nemusí být samozřejmé, když pracujete v evropsko-americkém týmu), tak vás ještě čeká jedno zásadní rozhodnutí. Volba souřadné soustavy. Určitě budete chtít, aby robot jel na nějaké konkrétní místo, a tak bude třeba popsat jak to cílové místo, tak na kterém místě robot právě je. Nuže špatná zpráva je, že když uděláte anketu: „Pojede-li robot startující z pozice (0,0,0) rovně a mírně vlevo, tak kde skončí?”, odpověď zda y-ová souřadnice poroste nebo bude klesat nebude jednoznačná! Ještě v horším případě budete kombinovat oboje. Aby toho nebylo málo, tak po zobrazení na obrazovku y-souřadnice je dolů a občas je třeba prohodit pravé a levé kolo … no nic. Dokud si to nevyzkoušíte, tak neuvěříte. Předpokládejme tedy xy souřadnou soustavu, kde (0,0) je v levém dolním rohu, x roste vpravo, y nahoru a úhel roste proti směru hodinových ručiček

Ok, máme jednotky, souřadný systém, ale k řízení robota jsme se ještě nedostali. Nechť tedy máme nějakého diferenciálně řízeného robota, kde ovládáte rychlost pravého a levého motoru. Pokud jsem vás předešlým textem trošku přesvědčil, tak možná přejdete z tiků enkodérů na počet otáček za sekundu (pravda standard je počet otáček za minutu), ale z toho se ale ještě nedozvíte, zda robot jede rychle nebo pomalu. To záleží ještě na velikosti kol, případně rychlost změny natočení pak i na jejich vzdálenosti. Nebudu to protahovat, player má interface position2d, kde pro tento typ robota nastavujete dopřednou rychlost v metrech za sekundu a úhlovou rychlost v radiánech za sekundu (jen pozn. ze ještě můžete nastavovat rychlost v ose y, pro roboty co mohou jezdit do strany). Použitý kód/define je PLAYER_POSITION2D_CMD_VEL.

Co nám to přineslo? Máme-li takto jednoznačně definované rozhraní (interface), tak robot na příkaz speedPxPa( 1.0, 0.0 ) pojede rychlosti 1m/s rovně dopředu, speedPxPa( 0.0, PI/2 ) se bude otáčet o 90 stupňů za sekundu proti směru hodinových ručiček a je úplně jedno, jestli je robot malá Khepera nebo velký Pioneer.

I kdyby jste Player nepoužívali, tak nastavování robota pomocí rozhraní podobnému position2d doporučuji. Konečně, rozhodnete-li se pro implementaci driveru pro Player, bude mít práci usnadněnou.

Pro měření vzdálenosti platí stejná pravidla jako pro řízení robota. Opět jednočipem převedete např. výstup z IR senzoru Sharp pomocí A/D převodníku a hodnota 23 znamená vzdálená překážka. Převedete-li ji rovnou na metry, tak se vám s ní bude věru snáze pracovat.

Player podporuje několik rozhraní: laser, sonar a ranger. Všechny tři popisují naměřené vzdálenosti a liší se detaily spojenými s daným senzorem.

Máte-li laserový dálkoměr od německé firmy SICK, tak pomocí rozhraní laser ho můžete rovnou „zaobalit”. Předávaná informace jednak popisuje relativní polohu senzoru vůči robotu a dále scan, pole dat naměřených vzdáleností s pravidelným krokem.

Hlavní motivací pro rozhraní sonar byli pravděpodobně roboti Pioneer, kteří mají sadu sonaru umístěných po obvodu robota. Sonary, na rozdíl od laseru, detekují překážku v jistém prostorovém úhlu a tento fakt by měl být zohledněn i v rozhraní. Vedle pole naměřených dat a pole pozic jednotlivých senzorů bych zde čekal popis šířky záběru senzoru, ale teď to v dokumentaci k verzi 2.1.1 nevidím.

Ranger je podobný jako laser interface — posílají se kompletní scany a pozice je právě jedna.

Přiznám se, že z rozhraní pro měření vzdáleností jsem teď trošku rozpačitý. Zatímco sjednocení počítání pozice robota a jeho řízení mi přijde bezchybné (resp. netuším, jak by se to dalo udělat lépe), u vzdáleností bych čekal nějaký odhad přesnosti a u sonaru pak šíři záběru. Je i celkem pravděpodobné, že jsem to ne zcela pochopil a v diskuzních fórech bych se dozvěděl více.

Máme teď dvě důležitá rozhraní: můžeme robota řídit a dovíme se, jaké vzdálenosti naměřily jednotlivé senzory. První pozorování je, že takto popsaného robota by bylo možné snadno simulovat. V tom okamžiku přichází na scénu Stage, kde si můžete simulovat hned několik robotů současně. Stage je totiž simulátor 2D prostředí.

Dále můžete s robotem jezdit po zadané trase, plánovat ve vektorové mapě, nebo se v ní automaticky lokalizovat. Píšete-li univerzální program, tak se ale musíte vyvarovat řízení typu: „pokud 3. a 4. sonar naměří méně než 0.5m, tak zastav” protože tím se dostáváte zpět na úroveň tiků a váš program poběží už pouze na vašem robotovi. To by ale zase bylo na delší vyprávění, tak někdy příště…

Jakékoliv poznámky/připomínky jsou vítany — použijte k tomu prosím tohoto formuláře.