czech english

SICK Robot Day 2012

aneb Eurobot na velkém hřišti

Letošní soutěže, organizované německou firmou SICK, se zúčastnilo 15 týmů. Co však mne a mnoho dalších překvapilo, že z toho bylo 7 českých! Herní plocha byla podobná jako v roce 2010, tedy aréna zhruba o průměru 15m. Tentokrát ale byla naplněna míčky tří barev (bílá, žlutá a zelená) a roboti zápasili současně hned tři. Jejich úkolem bylo sbírat míčky své barvy a vozit je do domečků. A jak to dopadlo?

Tento článek je kompilace příspěvků jednotlivých týmů, které se zúčastnily soutěže „SICK Robot Day 2012”. Obsah se možná ještě s časem bude vyvíjet, jak budou přícházet české i zahraniční příspěvky, případně jak budou příspěvky průběžně překládány. Česká a anglická varianta tedy zatím neobsahuje identický text!

1. místo: Redbeard Button, Parma

Od tohoto týmu zatím nemáme žádný detailnější popis, ale vítězství si zasloužil. Minimálně sběr zelených míčků v prvním zápase fungoval pěkně, jak ostatně můžete vidět na tomto videu.

2. místo: Team Attempto, Tübingen

Ani příspěvek od týmu Attemto zatím nedorazil. I když to na hřišti nebylo až tak poznat, rozhodně to byli favorité. Na YouTube je vidět testování kopání míčků a úspěšné nabrání několika míčků při druhém zápase.
Pokud si na tento tým moc nevzpomínáte, tak se doporučuji připomenout moc pěknou vítěznou jízdu z roku 2010. A že v Tübingen pár robotů mají, včetně několika čtyřtulek, nahlédnete zde.

3. místo: Team Short Circuits, Prag

Pavel Jiroutek

Popis robota:

Na soutež jsme jeli s robotem, kterého používáme pro české outdoor souteže. Zde je základní popis našeho robota v konfiguraci, jaká byla na SICK Robot Day. Robot je na platformě podvozku modelu monster trucku velikosti 1:5. Hlavní výpočetní jednotku tvoří standardní notebook. Hardware je monitorován deskou Arduino Duemilanove. Senzorické vybavení robota tvoří magnetický kvadraturní enkodér, kompas, lidar a kamera. Software je psaný v jazyce Python. Program získává aktuální informace o stavu HW prostřednictvím USB. Informace o stavu HW sbírá jednočip ATMEGA328, který je v pravidelných intervalech posílá dále do hlavního programu. Hlavní program zajišťuje transformace stavu HW do jednotek a struktur nezávislých na HW platformě, PID kontrolér rychlosti, lokalizaci z odometrie a kompasu, detekce překážek a reakce na ně a konečně řízení strategie. Robot rozpoznává barevné míčky před sebou kamerou, cizí roboty, mantinely a branku rozpoznává lidarem. Informace z těchto senzorů reprezentuje v lokální mapě, ve které metodou Vector Field Histogram plánuje další cestu.
Robot se choval podle následující jednoduché strategie:
(1):
Dokud není nabraný míček:
  Zapni válec na nabírání
  Najdi směr, ve kterém je můj blob blíž než cizí blob
    Vyhoď z plánovací mapy bloby, které jsou blíž než 50cm od robota
    Když existuje blob:
      Jeď tímto směrem
    Když neexistuje:
      Jeď za nosem
Když je nabraný cizí míček:
  Vyhoď míček
  Couvni do oblouku
  Skoč na (1)
Když je nabraný můj míček:
  Jeď podle odometrie na waypoint 5 metrů před brankou
  Nastav pozici branky podle odometrie
  Dokud nejsi 2 metry před brankou:
    Detekuj branku lidarem
    Když branka detekována, zapamatuj si novou pozici branky
    Jeď na pozici branky
  Vypni vyhýbáni se překážkám kromě nárazníku
  Dokud nejsi 1 metr před brankou:
    Detekuj branku lidarem
    Když branka detekována, zapamatuj si novou pozici branky
    Jeď na pozici branky
  Dokud nejsi na pozici branky a nenaboural jsi a netrvá to moc dlouho:
    Jeď na poslední známou pozici branky
  Když jsi na pozici branky nebo jsi naboural:
    Vyhoď míček
    Vyresetuj chybu odometrie
  Couvni
  Zapni vyhýbání se překážkám
  Jeď podle odometrie na waypoint 5 metrů od branky
  Skoč na (1)
Paralelně k této hlavní složce strategie byly aktivní i další chování:
  • Vyhýbání se překážkám metodou Vector Field Histogram
  • Monitoring trvání jednotlivých akcí. V případě neočekávané doby trvání akce skončí na timeout a robot začne vykonávat jinou činnost aby se z deadlocku dostal.
  • Detekce překážek aktivním nárazníkem.

Detekce míčků:

1. Vezmi snímek z kamery a transformuj perspektivu do pohledu shora.
2. V několika pevně vybraných bodech obrazu spusť algoritmus opencv.FloodFill (zaplaví homogenní plochy). Tím se pravděpodobně oddělí podlaha od míčků.
3. Ve výsledném RGB obrazu najdi podle definovaných RGB rozsahů barevné bloby odpovídající jednotlivým barvám míčků.
4. Eliminuj bloby, které jsou moc malé nebo velké.
5. Co zbyde, zakresli do globální mapy jako kandidáty na pozice míčků.

Detekce branky:

1. Data z lidaru (průřez vodorovnou rovinou ve výšce 25cm, která koliduje jen s mantinely a cizímí roboty) nakresli do obrázku a propoj body, které jsou blízko sebe (predpokládám, že náleží stejné prekážce)
2. Pusť na ten obrázek opencv.GoodFeaturesToTrack. To najde "rohy v obrázku" (předpokládám, že branka je tak výrazná, že její hraniční body jsou mezi těmito rohy).
3. Projdi všechny dvojice rohů a hledej takové, které:
  • jsou od sebe 90-110cm
  • přímka, která jimi prochází, vede podobným směrem, jakým je orientace očekávané branky.
  • uprostřed mezi nimi není žádná překážka
4. Z nalezených kandidátů vyber ten, který je směrově nejblíž k robotovi.

Průběh soutěže:

Soutěž pro náš tým probíhala poměrně hladce. Po sestavení robot fungoval podle očekávání. Při několika testovacích jízdách se zjistily pouze dva problémy. Prvním byla barva podlahy v kombinaci s osvětlením, ve kterém byla podlaha velmi obtížně barevně odlišitelná od bílých i žlutých míčků. Řešením bylo překalibrování barevných rozsahů. Druhým problémem bylo znovuobjevení problému se špatným dopočítáváním absolutní pozice branky z lidaru, který jsme už z domácího testování považovali za vyřešený. Problém jsme naštěstí včas odhalili ve špatném výpočtu goniometrie a od té chvíle robot fungoval jak měl. Hodinu před startem jsme na něj už tedy nesahali.
V prvním kole jsme se do branky vrátili celkem třikrát což byl náš dosavadní rekord a třikrát převýšil naše očekávání. Bohužel se projevily dva problémy. Prvním z nich byl velký počet míčků na hřišti, který způsoboval, že robot narážel na nepřátelské míčky mnohem častěji, než jsme očekávali. Druhým problémem bylo již zmíněné problematické rozpoznávání barev. Kombinací těchto dvou problémů jsme se bohužel dvakrát vrátili do branky současně s naším i cizím míčkem. Nicméně se nám podařilo v prvním kole jako jednomu ze tří robotů pozitivně skórovat.
Ve druhém kole byl průběh podobný. Do branky jsme se vrátili s míčkem celkem čtyřikrát. Většinou ale i s cizím míčkem, takže z toho byl jen jeden pozitivní bod.

Závěr:

Soutěž hodnotíme za náš tým jako velmi úspěšnou. Naším cílem bylo bez ostudy se zúčastnit, ale nakonec jsme skončili na třetím místě z celkem čtrnácti týmů. Medailové umístění bylo vysoce nad našimi očekáváními i vzhledem k tomu, že mnoho hlavně německých robotů bylo speciálně určených pro tuto soutěž a na přípravu robota jsme měli tři týdny, které následovaly po Robotour. Robot dělal v obou zápasech přesně to, co měl. Překvapila nás přesnost, s jakou jsme s outdoorovým podvozkem schopni zajet do relativně úzké branky. Jediné, co jsme podcenili, byl velký počet míčků, který způsobil, že robot do široké radlice velmi často vzal současně se svým i cizí míč. Tím, že se nám podařilo pozitivně skórovat v obou soutěžních zápasech, jsme vlastně přivezli nejspolehlivějšího robota, protože se tohle nepovedlo ani vítězům.

Sonderpreis: Team Ballcollector 3000, Osnabrück

Martin Günther

Náš robot Ball Collector 3000 byl postaven a naprogramován v kooperaci University of Applied Sciences Osnabrück a University Osnabrück. Jako základ robota jsme použili platformu Kurt, která je diferenciálně řízená. Laserový snímač, SICK LMS 100, byl použit pro lokalizaci (pomocí domečků) a vyhýbání se překážkám. Byl namontován ve výšce těsně nad míčky, takže viděl pouze obvod hřiště s domečky, případně další roboty.
Pro rozpoznávání míčků jsme používali Asus Xtion Pro RGB-D kameru. Hloubková informace byla použita k odstranění všech bodů pod daným hloubkovým limitem. Také všechny body blízko laserovému scanu byly odstraněny (tj. ostatní roboti a body hranice hřiště). Výsledkem byl RGB obrázek, který obsahoval pouze míčky a pro jejíž detekci už stačil jednoduchý blob detektor. Pokud byl míček rozpoznán, přiblížili jsme se k němu pomocí reaktivního řízení a nabrali speciálně vyrobeným paralelním chapadlem.
Během soutěže náš systém fungoval celkem dobře, ačkoliv jsme měli problémy v obou zápasech. V prvním zápase jsme zapomněli aktivovat laser scan filtr, což znamená, že robot ignoroval mnoho míčků než nějaký konečně nabral. Do druhého kola jsme tuto chybu opravili a tak robot začal úspěšně míčky sbírat. Bohužel lokalizace, která v prvním kole fungovala spolehlivě, nyní selhala a robot slepě spoléhal pouze na odometrii. Poté, co úspěšně nabral několik míčků, ztratil přehled kde se nachází jeho domeček a vysypal všechny míčky vedle. I přes to jsme s vystoupením robota a 4. místem, které jsme získali, spokojeni!

KZS/Eduro Team

Martin Dlouhý

Občas se cítím jak rohaté zvíře na tři, nedodržující své vlastní zásady :-(. V případě této soutěže to byla neodladěná integrace detekce domečku. Jedna chyba v převodním vzorečku, která se projevila pouze tehdy, pokud robot najel na domeček pod větším úhlem, a celá příprava šla do háje. SICK Robot Day je opravdu soutěž, kde není žádný prostor na testování, jen nastavení pár základních parametrů. V domácím prostředí byla odometrie dostatečná i pro posbírání až čtyř míčků, nikoliv však na kluzké podlaze v německém Waldkirchu…
Druhá vážná chyba byla detekce barvy, která byla klasifikována pouze do tří kategorií: bílá, žlutá a zelená. Chyběla varianta „jiná”, která by znamenala, že se robot díval na podlahu a míček minul. Podlaha však měla blízko k naší žluté a bílé, takže detektor by to asi stejně moc spolehlivý nebyl.
Třetí vážná chyba byla singularita v navigaci na míček. Ta se projevila v druhém kole, kdy Eduro kroužilo okolo zeleného míčku několik minut, než ho „vysvobodil” italský robot přepnutím do režimu vyhýbání se překážce.
Čtvrtá slabina byl deformovatelný úchyt květináče. Za předpokladu fungující lokalizace by se robot tak blízko k mantinelům nedostal, ale takto měl cíle mimo arénu a ochranný prostor byl až příliš malý.
Kdybych měl všech 5 pohromadě, tak bych nikdy nemohl napsat (diff soutěžní a opravené verze):
-  x,y,angle = gatePose( (0,0,0), gatePosition )
-  angle -= absGatePose[2] # ???
-  return -(absGatePose[0]+x)*(cos(angle)+sin(angle)), -(absGatePose[1]+y)*(-sin(angle)+cos(angle)), -angle
+  gate = gatePose( (0,0,0), gatePosition )
+  return inversePose( combinedPose( gate, inversePose( absGatePose ) ) )
a robot by se choval asi 100x lépe, ale … jednou se s tím možná smířím . Je fakt, že minimálně v prvním kole se Eduro chovalo zajímavěji než jeho soupeři. Druhé kolo už byla jen rezignace, kdy korekce u branky byly vypnuté a veškeré důsledky tedy očekávané.
Konec lamentování.
Základní konstrukce Edura byla postavena na robotické ruce z Field Robot Event 2012 z Holandska/Floriade, kdy Eduro jako jediné splnilo Professional Task (autonomní nalezení květináče s růží, jeho nabrání a návrat na start). To fungovalo tak pěkně, že mi přišlo škoda mechanizmus ještě nerecyklovat. I u květináče zůstalo, jenom jsme ho otočili vzhůru nohama a vybrali o něco větší.
První pokusy proběhly už před dvěma měsíci (viz youtube video). Vypadalo to schůdně a de facto u toho i zůstalo. Při prvním větším testování s MART týmem se ale robotická ruka často zasekávala na balónku. To později řešilo pružné uchycení květináče nahoře místo dole a balónky tak do nakloněného květináče samy vklouzly.
pružná varianta uchycení květináče
pružná varianta uchycení květináče
Toto řešení, jak i diváci mohli vidět, fungovalo spolehlivě. A na pojistku „když se to zasekne, zkus to znovu” ani nedošlo. Co by bývalo stálo za změnu byl směr otáčení při nabrání míčku. Původně jsme se snažili, aby robot při otáčení s rukou čnící vpravo zabíral co nejméně místa a otočil se tak i v kuchyni, kde většina prvních pokusů probíhala. Při změně směru by tak byla větší šance nabrat nedokonale pokryté míčky.
Vývojový posun pro Eduro byla především integrace dvou laserů a kamery s tím, že se vše stále počítalo na linuxovém routeru s výkonem 500MHz a 256MB paměti. Senzor TiM310 je na USB a tedy náročný na výpočetní výkon. Bylo tedy nutné snížit vzorkovací frekvenci na cca 5Hz (program si říkal, když měl čas) a to samé i u LMS100 a IP kamery. Do analýzy obrazu jsme se nechtěli pouštět (a vidouce bíle a žluté míčky na žluto-bílé podlaze to bylo správný tah), takže plán byl, že až bude míček na dané pozici, tak z kamery ověříme barvu.
Pěkně se to řekne, ale hůře realizuje, především potřebujete synchronizovat USB laser a kameru. Pokud jen načtete obrázek, s běžícím dalším zpracováním, tak zpracujete jeden za sekundu! Ano, jak by určitě řekl Tomáš z týmu: když bych zpracovával pouze výřez, který kamera podporuje, tak můžu mít spousty obrázků … ale zase bych ztratil přehledovou informaci a možnost poskládat video, jaké vidíte zde. Snímky jsme tedy sbírali bez dalšího zpracování a pouze, když byl balónek na správném místě podle laseru, jsme udělali „fotografii”, kterou jsme následně pomalu analyzovali. Na videu je tato situace zvýrazněna probliknutím červeného čtverečku.
Typická chyba tohoto přístupu byla, že okénko, kde jsme testovali barvu (průměr všech RGB složek), obsahovalo míček jenom částečně. Pokud byste okénko příliš zmenšili, tak se budete divit, že bílé míčky jsou vlastně někdy modré … jak to? Viz modrý nápis, který je stejný na všech míčkách!
Algoritmus klasifikace barvy byl velmi triviální: pokud je v RGB dominantní zelená složka (1.2x větší než R a B), je míček zelený. Pokud je dominantní červená a zelená, tedy minoritní modrá (zase 1.2x menší než R a G), tak je míček žlutý. V ostatních případech je bílý. Prosté, ale moc spolehlivě to nefungovalo. Jednak zelená měla trošku odstín do modra a pokud ve výřezu byl modrý nápis, tak detekce zelené dokonce selhávala … podmínku jsme změnili do podoby, že stačí, pokud je G>1.2*R. Hodilo by se ještě nějak odfiltrovat barvu podlahy, ale ta byla náhodná, občas i se zelenými pruhy …
Pro vyhýbání se překážkám (ostatním robotům a mantinelu) byl použit VFH (Vector Field Historam) algoritmus. Fungoval pěkně, ale byl náročný na výkon. Zapínal se tedy pouze pokud byla překážka blíž jak 1m a to v případě mantinelu bylo už pozdě. Problém odlišení míčku od dalších robotů jsme nakonec řešili hardwarově — dvěma lasery v různých výškových rovinách. Když se robot navigoval na míček pomoci USB laseru, tak nejprve ověřil, že v IP laser scanu v daném směru nevidí blízkou překážku. Fungovalo to pěkně, pokud se Eduro příliš rychle neotáčelo - pak by nastoupil problém s desynchronizaci scanů, který jsme pozorovali ještě při testování v Praze, kdy robot nabíral fantom míčky hned u branky.
Uzavřel bych to Achilovou patou, tedy detekcí brány. Přestože v laserovém scanu to vypadá triviálně, získat robustní řešení až tak snadné není. Teoreticky brankou prochází výrazná Voronoiova hrana. To jsme ale neměli pořádně implementované. Co jsme použili byl takový náznak Voronoi — postupně rostoucí vlnu. Hledání začalo redukcí scanu na intervaly po pěti stupních, kdy každý prvek reprezentoval nejmenší měření. Vlna pak začala s poloměrem nejbližší překážky a rostla po 5cm. Tím se definovaly střídavé úseky překážek a volného místa. Pokud volný úsek splňoval podmínku velikosti a hloubky branky, tak hledání úspěšně skončilo, jinak se zkoušel větší poloměr. Detekce brány vlastně nakonec fungovala celkem dobře, ale zásadní závada byla v korekci pozice robota, zmíněna už výše.
Závěr — po zklidění emocí, shlédnutí video záznamů a přečtení si problémů u ostatních týmů, to až tak zlé zase nebylo. Nebudu opakovat frázi „stačil by jeden den testování navíc”, protože na to je jediná správná odpověď „tak jsi měl o den dříve začít testovat”. Organizátorsky byla soutěž připravena dokonale a bylo milé po čase vidět tolik nadšených robotiků .

Video


Tým RoBohemia

Ondřej Vožda

(Lukáš Otava, Tomáš Grepl, Martin Mališ, Martin Tříska, Milan Papež, Ondřej Vožda)
RoBohemia
RoBohemia
K této soutěži jsme se dostali naprosto náhodně. Během výběru tématu projektu do předmětu „Robotika“ nám padlo do oka zadání, které po nás požadovalo sestavení týmu, robota a následný výjezd do německého Waldkirchu. Výhodou navíc bylo, že pořádající firma SICK poskytne pro realizaci jeden ze svých laserových scannerů, jenž po soutěži připadne fakultě. Takovouto příležitost jsme si jakožto hrdí studenti VUT, toužící reprezentovat naši alma mater, samozřejmě nemohli nechat ujít.
Jali jsme se tedy realizovat tento odvážný plán. Po prvotních peripetiích ohledně cenově přijatelného řešení a vymýšlení všech možných i nemožných hardwarových koncepcí našeho robota jsme nakonec zvolili osvědčený čtyřkolový diferenciální podvozek, který nám zapůjčilo oddělení robotiky. Realizace by rovněž nebyla možná bez přispění sponzora, společnosti TIPA s.r.o.
Nejvyšší vrstvu řízení měl zajišťovat systém Toradex Robin s procesorem Intel Atom, kterému zdárně sekundovala deska STM32 F4, zabezpečující operace vyžadující zpracování v reálném čase. Aby robot nevykazoval příznaky otravy methanolem a mohl efektivně vnímat svět kolem sebe, vybavili jsme jej ještě webkamerou a dvěma laserovými sensory pořadatelské firmy SICK.
V průběhu realizace se však ukázalo, že naše megalomanské plány budou muset ustoupit tvrdé realitě v podobě blížícího se termínu soutěže. Globální mapa totiž i přes použití všemocného Kalmanova filtru nemapovala, jak jsme si představovali. Počítačové vidění odmítalo vidět, regulátory neregulovaly…jediné pozitivum v období horkého léta tak byly firmou SICK dodané vzorové míče, skvěle se hodící k rozličným vodním aktivitám.
Po mnoha bezesných nocích, kdy nás už i noční hlídač vyhazoval z laboratoře, jsme však robota dokončili a vyrazili směle směr Waldkirch. Cesta se neobešla bez různých veselých situací, nakonec jsme se ale úspěšně ubytovali na hotelu, přeměnili tamní společenskou místnost na testovací arénu a využili poslední noc pro finální úpravy.
Nastal den D a po vydatné snídani jsme dorazili do Stadthalle ve Waldkirchu a započali ranní warm-upy. Zde přišel ke slovu náš vzácný doprovod, Ing. Burian, který, ačkoli našeho robota viděl poprvé, nám jej pomohl uvést do provozuschopného stavu. Po vydatném obědě přišla na řadu první jízda.
Vyšlo najevo, že barevný prostor HSV je sice vynikající věc, nicméně kombinace žlutý míč, béžová podlaha a osvětlení zářivkami udělala své. Nepodařilo se nám úspěšně zachytit žádný míč. Perličkou bylo, že našemu notebooku (který nakonec suploval desku Toradex) se pravděpodobně nelíbil některý ze spuštěných programů a na startu se na nás usmála krásná modrá obrazovka smrti. Rychlý restart vše spravil a robot odvážně vplul do arény. V průběhu jízdy jej však překvapilo větší než předpokládané množství míčů, takže po chvíli rezignoval na jakoukoli snahu cokoli provádět.
Do další jízdy naštěstí zbývaly dvě hodiny, byl tedy ještě čas na úpravy. Ve druhé jízdě jsme se již nikde nezasekli, kamera detekovala míče úspěšně (tentokrát byly zelené), avšak ani tak nám nepřálo štěstí ani technika a žádný bod jsme nakonec domů nevezli.
Soutěž pro nás představovala velkou pozitivní zkušenost, ať již z pohledu odborného, robotnického, tak i toho takříkajíc manažerského. Sesynchronizovat v období prázdnin šest zaneprázdněných lidí, kteří se tomuto projektu navíc věnují čistě dobrovolně, se ukázalo být úkolem vskutku sisyfovským.

Máte-li jakékoli dotazy či připomínky — kontaktujte nás.