Dana
21.místo a cena za nejlepší koncept, Eurobot 2003
Dana je výsledkem našeho snažení věnovaného soutěži Eurobot 2003. Poučeni z chyb a nedostatků z již absolvovaných soutěží, je tento robot ještě dokonalejší a chytřejší ale zároveň i jednodušší . Výsledkem je 21.místo a Best Concept Prize.
Základní informace
I Dana je úspěšným pokračováním podvozku vyrobeného pro
Barboru. Mezi základní charakteristiky tedy stále
patří dva BLDC motory (každý o výkonu 600W), základní deska s procesorem AMD K6
500MHz, 128MB RAM a 128MB CompactFlash karta, video vstup, 100Mb Ethernet a
operační systém Linux. Navigace je založena hlavně na odometrii a infra
senzorech CNY70 detekujících barvu podlahy. Kamera je využívána zejména pro
hledání puků. Posledním senzorem je nárazník, jehož účelem je zachytit to, co
zbytek „přehlédl”.
Aktualizace
Zdrojové kódy pod licencí GPL jsou nyní dostupné ke stažení (broken link).
Mechanika
Po mechanické stránce se robot skládá ze tří hlavních částí: podvozku, ruky
na otáčení puků a shazovadla na stojící puky.
Podvozek
Nejzajímavější částí je podvozek, původně vyrobený pro robota Barbora ve
vývojových dílnách firmy Vakuum Praha. Podvozek je provedený velmi kvalitně
z duralu. Za zmínku stojí prosazení myšlenky, že robot s pásy je skvělá věc.
Dobře drží na podlaze, nepřekotí se, má úžasné schopnosti akcelerace i
brždění.
Už tehdy jsme také znali první nevýhodu této koncepce — počítání
odometrie je oproti kolovému podvozku komplikovanější.
Nicméně jsme počítali s použitím optických myší pro posílení odometrie s
tím, že dokonce dokáží pokrýt i pohyb do strany (smyk) — tedy vlastně
jakýkoliv translační a rotační pohyb. V praxi ale myši nefungovaly, zejména
kvůli vysokému lesku našeho hřiště. Druhým kritickým bodem bylo nastavení a
udržení přesné výšky nad povrchem (povolená tolerance je díky malé hloubce
ostrosti použité optiky minimální). Letos zatím jezdíme bez
myší, ovšem plánujeme jejich reinkarnaci. Výsledkem absence myší máme značně
nepřesnou odometrii. Nepřesnosti vznikají z několika důvodů.
Jednak není znám přesný střed otáčení robota — u pásového podvozku
neexistuje něco jako střed přímky procházející dotykovými body koleček
s podlahou. Typicky se střed otáčení nachází někde v těžišti robota, ale jeho
poloha se může v závislosti na zrychlení měnit. Dalším zásadním (a pro nás
neznámým) parametrem je R, tedy vzdálenost dotykového bodu
virtuálního "kolečka" od středu otáčení. Jeho určrní komplikuje
fakt, že pásy mají nenulovou šířku (asi 2,5cm), a také to, že místo jejich
dotyku s podlahou je od středu otáčení jinak daleko v rohu než uprostřed pásu.
Tak se stalo, že i když robot by teoreticky měl mít R asi 14 centimetrů
(vzdálenost středů pásů je cca 28cm), R zjištěné dle odometrie vychází
asi 19,5cm, z čehož by vycházel robot o šířce 40cm. Rozměr 19,5cm je polovinou
délky úhlopříčky robota — robot tedy jezdí zejména po předních a zadních
kolečkách, malá kolečka přitlačující pás k zemi mezi nimi až tak důležitá (pro
výpočet odometrie) nejsou. Jediné, co víme přesně (dokonce naprosto přesně)
je ujetá vzdálenost, protože se jedná o synchronní ozubené řemeny, které se
země dotýkají nezakřiveným povrchem. Na jednu otočku motoru ujedeme přesně
14,4mm, pokud jedeme rovně a nejsme ve smyku.
Další nevýhoda se ukázala časem — pásy mají výraznou tendenci jezdit
rovně. Tento efekt je zesílen tím, že Dana neumí otáčet motory pomalu s
velkou silou — kvůli koncepci regulátorů můžeme regulovat pouze výkon
(činitel plnění PWM), nikoliv otáčky. Motory nelze ani mírně (proporcionálně)
přibržďovat, abychom dosáhli různých otáček levého a pravého pásu.
Například pokud necháme pravý motor jet vpřed na 20% a na levý na PWM 4%,
robot stále ještě jede přímo vpřed.
Poslední nevýhoda je spíš implementačního rázu —
u použitých řemenic pro synchronní (ozubené) řemeny byly bočnice odsoustruženy
tak, aby se jezdilo po řemenech a ne po řemenicích. Ve vývojových dílnách
bohužel osoustružení trochu přehnali — odsoustružili je až k zubům.
V důsledku toho se při zatáčení, kdy jeden pás stojí a druhý jede,
občas řemen z řemenic svleče a to je poměrně fatálni problém. Zatím ho řešíme
tak, že „svlékací” manévry jsou softwarově zakázány.
Vlastní pohonnou jednotku tvoří bezkartáčkové (brushless) DC motory.
Mezi motory a kolečky pásů je dvoustupňový řemenový převod s poměrem 9:100
(přesně), tedy zhruba 1:11. Enkodéry na motorech dávají 18 tiků za otočku
motoru, kola pohánějící pásy mají 32 zubů a jeden zub na pásech má 5mm.
Z toho plyne, že jeden tik enkodéru odpovídá změně polohy o 0,80 mm.
Motory dosahují 1480 otáček za minutu na volt, což při plném nabití
baterií na 14V (10 NiCd článků na každý motor) odpovídá maximální
rychlosti robota 5 metrů za sekundu – 18 km/h (tedy rychlosti běžícího
člověka).
V praxi to znamená, že typicky nejezdíme s větším plněním PWM než 20%.
Ruka
Ruka je vyrobena z hliníkových profilů a kuprextitu. Umí se zvedat/klesat,
otáčet a zavírat/otvírat. Puky uchopuje třísegmentovými prsty, které se
zavírají taháním za provázek navíjený na kladku spojenou se servem.
Ruka je poháněna dvěma servy (zvedání, otáčení) a jedním mikroservem (prsty).
Z manipulačních schopností stojí za zmínku možnost zvednout asi půl kila
do výšky 6,5cm. Přední část robota a ruka jsou tvarovány tak, aby puk ležící
až 12cm od osy robota vždy sklouznul do ruky. Ruku v akci můžete vidět
na videu.
Shazovadlo na puky
Shazování stojících puků se řeší plexisklem vpředu na robotovi
To končí zhruba ve výšce 11cm nad zemí. To znamená, že sloupeček ze tří
puků pod ním projde, ale puk stojící na výšku nikoliv — je shozen.
Při shazování múže puk odskočit, takže tvarování robota a ruky nemusí mít
žádoucí efekt — takže puk sice leží, ale nevklouzne do ruky.
Řízení pohonu a výstupy
Regulátory otáček motoru
Používáme modelářské regulátory TMM od MGM ComPro upravené pro řízení po
sériové lince. Jsou malé, lehké, vykonné a pro letecké
modeláře nejspíš uplně skvelé. Pro robotiky ne až tak úplně.
Regulátory jsou koncipovány jako bezsenzorové (sensorless) – to
znamená, že nijak nevyužívají enkodéry spojené s motory (nové motory už proto
ani enkodéry nemají). Místo toho určují polohu rotoru z napětí indukovaného
na cívkách statoru v okamžiku kdy motor není napájen a funguje jako generátor.
To bohožel znamená, že pokud se motor otáčí pomalu, indukované napětí je
příliš malé a poloha rotoru se nedá zjistit. Proto regulátory neumí řídít
motory vnízkých otáčkách. tento problém se v praxi objevuje především při
rozběhu. Protože není známa poloha rotoru, regulátor motorem
„zatřese” a tak polohu rotoru zjistí, pak motor „naslepo”
roztáčí a teprve když motor začne dávat rozumný signál, přejde regulátor do
normální regulační funkce. Po celou dobu roztáčení nelze plnění PWM měnit.
Regulátory měly průběžně posílat počet otáček (od posledního čtení).
Avšak tento výstup byl (nezávisle na směru otáčení) vždy kladný.
Horší „vlastností” byl nenulový výtup v případě, kdy motory stály.
To způsobilo, že takto získaný počet otáček byl v praxi zcela nepoužitelný.
Díky ochotě výrobce jsme vyměnili motory za starší model s vestavenými
senzory (enkodéry) a otáčky pro potřebu odometrie si měříme sami.
Nastavování polohy serv
Pro řízení serv používáme modul SOS-AT od Rotty. Zatím funguje spolehlivě,
drobná připomínka je, že by se nám více hodilo řízení po I2C místo sériového
portu — na ruku by vedlo méně kabelů.
Indikační LED
Veškeré vstupy a výstupy mikrokontroléru EzUSB mají připojené LED diody
indikující jejich logickou úroveň. Dá se tak rychle poznat, že něco nefunguje
tak jaka by mělo, navíc lze nezapojené výstupy použít na signalizaci různých
stavů EzUSB, pripadně při ladění.
Brzdová světla
Robot ma vzadu šest vysocesvítivých LED diod připojených přes
PCF8574 na I2C. Ty lze softwarově ovládat. Máme tak dispozici dalších šest
indikačních prvků. Případně prostředek pro efektní běžící světlo…
Na tomto modulu se nám při přidávání konektoru podařilo vyrobit studený
spoj, takže nefungovala komunikace. Problém byl odstraněn.
LED na čelním panelu
Na horní straně robota jsou umístěny další dvě LED diody připojené spolu s
tlačítky na další budič PCF8574.
Voltmetr
Dalším prvkem horního panelu robota je digitální voltmetr ukazující
sdruřené napětí napětí napájení elektroniky robota — nikoli přímo
napětí baterií, které může být na ruzných sadách akumulátorů (robot může
používat až čtyři sady akumulátorů současně) různé.
TFT panel
Robot je vybaven průmyslovým vysocekontrastním 12" TFT panelem s
18-tibitovou barevnou hloubkou a rozlišením 800x600 pixelů.
Čidla
Senzory otáčení motoru
Senzory otáčení motoru jsou 3 fotozávory integrované uvnitř motoru.
Určují absolutní polohu motoru v rámci jedné periody rotace magnetického
pole. Protože máme šestipólové motory, máme tři periody rotace pole
na otáčku. Během jedné periody dostaneme šest různých kombinací výstupů
těchto tří fotozávor. Dvě kombinace (000 a 111) nikdy nenastávají.
Fotozávory používáme jako inkrementální enkodéry v obyčejné počítačové
myši — jen čtyř stavů 00 → 01 → 11 → 10
jich máme šest. To znamená, že i když jeden „propásneme”,
dokážeme přesný počet kroků zrekonstruovat.
Senzory polohy ruky
Žádné senzory určené přímo pro detekci polohy ruky neexistují.
To znamená, že nepoznáme, že se nám ruka někde zasekla nebo že nefunguje.
Dokonce i komunikace s modulem SOS-AT je výrobcem implementována jako
jednosměrná, takže nepoznáme, že modul žije. Jediné čím dokáže robot zjistit,
že má ruku funkční je to, že když při otáčení se změní hodnoty čidel
přítomnosti a barvy puku. Pro přibližné určení polohy ruky by se daly využít i
nově nainstalované detektory vzdálenosti Sharp GP2.
Senzory přítomnosti a barvy puku
Součástí elektroniky ruky jsou dvě infračrvené reflexní závory CNY70
(orientované nahoru a dolů) pro detekci vnitřní barvy puku (černá/bílá).
Tak dokážeme rozeznat, jestli se má puk otočit, nebo jestli jde o puk
bonusový (jednobarevný, sestřelený z boku hřiště), který nemá smysl otáčet.
dalším čidlem na ruce jsou dva fototranzistory (IRS5) osvětlované zhora
vysocesvítivými infračervenými LED diodami Agilent. Fototranzistory jsou
zastíněny, když je v ruce puk. K zastínění dojde ještě dřív, než je puk
úplně v ruce, takže se prsty můžou začít dřív zavírat. Jak CNY70 tak
fototranzistory jsou připojené na sběrnici I2C přes A/D převodník PCF8591.
Senzory barvy podlahy
Pro detekci barvy podlahy je robot vybaven dalšímimi sedmi CNY70
připojenými přes další dva převodníky PCF8591.
Akcelerometry, gyra, kompas
Tyto pokročilé senzory zatím nebyly implementovány. V plánu je použít
12-tibitové A/D převodníky pro sběrnici I2C MAX127 a MAX128 pro připojení
MEMS akcelerometru, iMEMS/Piezo gyroskopu a permalloyového kompasu.
Z jimi naměžených údajů by se potom podobně jako v inerciální jednotce
bojového letadla počítala virtuální odometrie daná pouze dynamikou v prostoru
(v našem případě pouze v rovině). Tento přístup ale znamená dvě integrace místo
jedné a tudíž větší chybu. Naproti tomu je výhoda v tom, že akcelerometry a
gyra fungují zcela nezávisle na vnějších podmínkách (povrch stolu…).
Optické myši
Vloni byl robot vybaven sadou čtyř optických myší. jejich rozlišení je asi
0,07mm/tick, maximální snímaná rychlost přesahuje 1 metr za sekundu.
"Myšometrie", tedy odometrie spočítaná z myší se vyrovná i se smyky a
podobnými šílenostmi. Nikdo ale nemůže zaručit že optické myši budou fungovat
správně i na hřištích v La Ferte (mají problémy s lesklým povrchem). Myši
pořád máme, byly opraveny a dvě z nich z testovacích důvodů opět namontovány
na robota.
Interní kamera
Na robotovi je nainstalována levná barevná PAL CMOS kamera. Pomocí
nepříliš výkonného image grabberu na základní desce řídícího počítače dokážeme
získávat obrázky v rozlišení 352x288 pixelů a barevném prostoru YUV422
(16 bitů na pixel). Bohužel, pokud se snímá 25 snimků za sekundu, je procesor
vytížen ma 100% (grabber neumí DMA). Přístup do jeho paměti je navíc
nebufferovaný. Pracujeme na snížení této náročnosti, jednou z možných metod
je čtení jen některých pixelů.
Externí kamera
Přes 2,4GHz mikrovlnné pojítko je připojena externí kamera. Ta je uvnitř
jednoho z beaconů. Její obraz je oproti interní kameře víc zašuměný, kvalita
signál je horší a někdy obraz vypadne úplně. Výhofou této kamery je její fixní
pozice. Přijímač mikrovlnného přenosu je připojen ke stejnému
image grabberu jako interní kamera. Grabber je totiž vybaven čtyřmi
videovstupy, které bohužel nelze používat paralelně. Navíc přepnutí
videovstupu nějakou dobu trvá (asi 2 snímky, tedy 100 ms).
Nárazníky
V každém rohu robota je poměrně robustní mikrospínač připojený přímo k
mikrokontroléru EzUSB. O jeho stisknutí je okamžitě informován řídící počítač.
Nevýhodou našeho mechanického provedení je, že nárazníky sepnou pouze
v případě, že do něčeho nabouráme rohem a to ještě relativně čelně —
chyba oproti kolmému nárazu nesmí být vetší než 10 stupňů. Jinak dřív
narazíme pevným rohem robota. Původně jsme chtěli používat nárazníky
k dorovnávání podle okrajů hřiště. Ještě teď by to asi nebylo nesmyslné,
ale muselo by se narážet VELMI opatrně.
Tlačítka
Pro obládání robota z čelního panelu je k dispozici šest tlačítek
připojených ke sběrnici I2C prostřednictvím stejného čipu PCF8574 jako LED
diody umístěné tamtéž.
Procesory
PC
V ýpočetní sílu robota tvoří hned několik procesorů. Řídící počítač PC je
vybaven procesorem AMD K6-2/500, 128MB SDRAM, 128MB Flash diskem, čtyřmi
sériovými linkami, paralelním portem, dvěma USB porty, čtyřmi videovstupy,
stereo audiovýstupem a několika stereo audiovstupy. Průmyslová základní deska
dále obsahuje vychytávky typu LVDS, PCI a PC-104 slot.
EzUSB
Mikrokontrolér EzUSB je z hlediska architektury 8051 taktovaný na 24 MHz
s dostatečným množstvím paměti. K řídícímu počítači je připojen přes
USB sběrnici s přenosovou rychlostí až 12Mbit/sec.
Mezi jeho vlastnosti patří 24 GPIO (univerzálních vstupně-výstupních) pinů,
sběrnici I2C a dva sériové porty.
SOS-AT
Modul SOS-AT je destička s mikrokontrolérem AVR, který generuje signál
pro serva v ruce. Je připojen k EzUSB sériovou linkou s rychlostí 9600bps.
TMM
TMM jsou regulátory pro řízení BLDC motorů od firmy MGM ComPro. Jejich
srdcem je také AVR a jsou připojené sériovou linkou o rychlosti 19200 bps přímo
k PC.
Přehled elektrického zapojení
Kabeláž uvnitř robota měří v současné době něco kolem 15m a počty konektorů
(převážně krimpovaných) jdou do stovek. Schéma propojení jednotlivých modulů
je patrné z obrázku stejně tak jako použité sběrnice a pod. Červeně je
kresleno napájení, modře sériové spoje, zeleně sběrnice I2C a fialově ostatní
spoje.
Software
EzUSB
Na EzUSB běží velmi jednoduchý prográmek, který neustále posílá aktuální
stav všech vstupů (z I2C a GPIO) do PC. Také přijímá příkazy pro nastavení
polohy ruky prostřednictvím SOS-AT, umí zapnout/vypnout napájení ruky a
motorů a číst a nastavovat periférie (CNY, tlačítka, LED) připojené
prostřednictvím sběrnice I2C. Mimoto počítá otáčky motorů z enkodérů.
Ty se musí pollovat asi tak 3000x za sekundu a to by nebylo
rozumné posílat do PC přímo. Ticky enkodérů se proto počítají interně a do PC
se posiljí až nasčítané hodnoty. Program se do EzUSB nahrává přes USB z PC.
Jádro operačního systému
Řídícím operačním systémem robota je upravený OS Linux.
Abstrakce hardware je u dany řešena na úrovni jádra OS (narozdíl od Daisy,
kde je abstrakce na úrovni sériové linky). Oddělení až na úrovni jádra
bylo použito z důvodu, že regulátory motorů jsou připojeny přes sériovou linku
přímo k PC. Jádro posílá aplikaci, která řídí robota, strukturu
input_data', v níž je popsán stav robota a naopak od aplikace přijímá
přijímá strukturu struct output_data, která obsahuje příkazy pro
hardware robota — nastavení serv, PWM pro motory, rozsvěcení LED…
Userspace
V userspace na PC běží jeden single-threaded program, který cyklicky
čte data o stavu robota, rozhodne se pro další akci a vyšle příslušné příkazy.
Pouze zpracování obrazu se plánuje jako separátní proces proto, aby
mohlo využít veškerý "zbylý" výpočetní čas procesoru.
Software je rozdělen na znovupoužitelné (reusable) části, které jsou v
umístěny v podadresáři lib/ a na samotné řídící programy, které se nachází
v adresářích v0/, v1/, v2/ atd.
Máme k dispozici i různé testovací utility na oživení, jako např.
dana-io-test pro testování komunikace s perfériemi robota,
nebo cvtest na ověření funkčnosti kamery.
Knihovny:
- gmcl
- GMCL
- iodrive
- základní funkce pro komunikaci s jádrem — přijímání zpráv o stavu robota, posílání příkazů
- cvideo
- funkce pro příjem obrazu
- waypoint
- funkce „jeď na určité místo”, v závislosti na poloze navrhuje další akci — otáčení, jet rovně…
- fbgraph
- knihovna na kreslení na TFT displej
- regions
- hledání objektů
Programy:
- v0
- jede dopředu, pokud narazí na puk, otočí ho zelenou stranou navrch a vrátí se do výchozí pozice – video
- v1
- nedodělaný pokus o ježdění po hřišti bez GMCL jen na základě synchronizace podle čtverců a ježdění kolmo
- v2
- jezdí po obdélníku pomocí gmcl a waypoint
- joy
- (joydrive, joyride) ovládání robota joystickem
Algoritmy
GMCL
Na určování polohy používáme GMCL (genetická MonteCarlo lokalizace),
což je verze MCL, která používá jinou (méně výpočetně náročnou a možná i
silnější) strategii vyrovnávání vah vzorků. Do GMCL se zatím posílají data
z enkodérů na motorech a z CNY sledujících podlahu.
GMCL sice funguje poměrně dobře, ale díky velmi nepřesné odometrii robota
se nám robot stále ještě ztrácí. Jedna z možností jak se tomu vyhnout je udělat
lepší (dynamický) model pohybu robota než čistou odometrii. Druhá
možnost je jezdit víc „cik-cak”, aby GMCL mělo víc udajů (přechody
na podlaze) na zpracování.
Třetí možností (o kterou se právě snažíme) je jezdit opatrně tak, aby
odometrie víceméně seděla. Další možností (do budoucna) je použít inerciální
navigační systém s akcelerometry nebo optické myši a přidat jejich výstup
k normální odometrii.
Už je vymyšlen i způsob, jak do GMCL dodat víc než jednu pohybovou
funkci, takže je možné zároveň zpracovávat odometrii a např. akcelerometry.
Řízení (Waypoints)
O řízení se v současné době stará triviální stavový automat s hysterezí,
který rozhoduje, jestli se pojede
rovně, nebo se bude zatáčet. Hystereze zařizuje, aby automat neosciloval mezi
dvěma stavy. tato verze automatu neumí couvat. Bylo by asi rozumné umět využít
i couvání a (teoreticky) by to nemělo být ani příliš těžké.
Zpracování obrazu – hledání barevných objektů (Regions)
Jednoduché hledání objektů dle barvy se dá dělat tak, že se nejprve
obrázek klasifikuje podle barevných rozsahů na plochy různých barev,
které mohou představovat objekty. Pak se použije floodfill na to, aby
se našly hranice těchto ploch. U každé z nich se spočítá těžiště a váha.
Navrhli jsme rychlejší a poměrně zajimavý algoritmus, který tohle vše
udělá rychle (jen v jednom průchodu obrázkem). Je částečně napsaný, ale
ještě nějakou dobu bude trvat, než bude plně funkční.
Bohužel se nejvíc času tráví kopírováním obrázku z videopaměti grabberu
do operační paměti (viz výše).
Obraz se ovšem nemusí zpracovávat celý. Pokud víme, kde objekty byly
minule, můžeme zkusit floodfill z těchto pozic. Tím, pokud se objekty
nepohnuly, upřesníme jejich pozici bez zdlouhavého zpracováni celého obrazu.
Pokud nevíme, kde objekty jsou, můžeme je hledat buď náhodně (v každém novém
snímku projdeme nějaké řádky a pokud na nich najdeme objekt, uděláme
floodfill), nebo systematicky (půlením intervalu, nebo cyklicky tak,
abychom za n snímků nutně našli všechny objekty větší než daný práh).
Zpracování obrazu – hledání čtverců na hřišti a navigace podle nich
Jeden z čnenů týmu zpracovává diplomovou práci o hledání hran, jejich
vektorizaci a využití pro určení pozice. My bychom pomocí tohoto algoritmu
byli schopni určit polohu (až na posuvné a rotační symetrie kostkované plochy)
a použít ji jako vstup pro GMCL.
Strategie
Zatím nic nemáme. Budeme se snažit o „vezmi obraz, najdi špatně otočený
puk, dojeď tam, otoč ho správně”. Až tohle bude fungovat, můžeme jít
dál.
Máte-li jakékoli dotazy či připomínky –
kontaktujte nás. Rádi vám odpovíme.