czech english

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

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.