czech english

SICK Robot Day 2016

kostky jsou vrženy

Letos se koná další ročník soutěže „SICK Robot Day”. Tentokrát to bude desetiminutová etuda (nebo ostuda?) pouze pro dva roboty na poli hustě osázeném RFID čipy. Jejich úkolem bude nabrat žluté nebo růžové kostky a umísťovat je do 5x5 metrů velké „šachovnice”. Po položení se kostky stávají překážkami a kolize jsou penalizovány. Blog update: 11/10 — Oficiální výsledky

Pravidla v kostce

Hrací aréna má rozměry cca 7x13m. Dva autonomní roboti startují ze žluté a růžové 3x3m nakládací zóny. Jejich úkolem je dopravit kostky do střední 5x5m velké šachovnice. Kostky je nutné vozit jednotlivě a roboti získávají body za každý pokrytý 1x1m čtverec. Bod získává robot, který kostku na daný čtverec umístí první. Jakmile kostku položí stává se automaticky překážkou (pro oba roboty) a kontakt je penalizován ztrátou 0.5 bodu.
Zápas trvá 10 minut a každý tým odehraje jenom dva. Soupeř a barva jsou náhodně losovány. Pro usnadnění lokalizace je v každém křížení RFID čip. Kód jednak určuje (X, Y) pozici a dále typ „zóny”. Týmy mají od pořadatele zapůjčené senzory RFU 620, pomocí kterých lze pres Ethernet nebo CAN data číst.

Obsah:



Blog

7. září 2016 — ver0

Začínám s textem jako klasický Copy & Paste předloňského a tak vidím, že před dvěma lety byl první záznam s titulkem „Měsíc do soutěže” … tak to sedí . Soutěž se totiž koná v sobotu 8. října 2016 ve Waldkirchu/Německo … jako vždy.
Náš tým je v zásadě stále stejný, jenom se k nám nově přidal Ondra z prvních MARTů — původně se přišel podívat na autonomní traktůrek, ale na tento měsíc jsme přesměrovali veškeré kapacity na „SICK robota”. A už se i plně zapojil (viz Pull request - simple interface for RFU620 sensor).
Promazávám starý text … a github, kde naleznete kód (za včerejší commit se fakt stydím) stále platí:
Ten ošklivý commit odpovídá naší verzi 0, tj. nejjednodušší verze, kdy robot boduje. Naslepo zavře klepeta, popojede 2m, otevře a trošku si couvne, aby mu přihlížející mohli tleskat .
Po rozchození verze 0 jsme upgradeovali hardware, takže to už nefunguje a jsme zase na začátku . No nejsme — stačí prohodit Alix s APU2 a ver0 by zase měla fungovat. Co je za problém? APU2 není ještě pořádně nastavené a tak vypisuje systémový log do CAN komunikace … a to není pěkné. Možná jsou ve hře ještě další faktory, ale to zatím nevíme. Hlavní podezřelý je /boot/grub/menu.lst. (konzoli nechceme úplně zaslepit, protože v případě problémů je to jediná(?) cesta jak se s APU2 bavit)
p.s. podle posledních zpráv dmesg -D problém řeší

14. září 2016 — Velodyne Black Hole

Výsledky včerejšího testování byly zajímavé. Primárně šlo o integraci všech plánovaných senzorů a nasbírání dat. Standa si nechal (naštěstí) říci, že servo ručičky během prvních jízd urveme, a tak přidělal ochranný kryt (a hned jsme ho 2x využili). Přibyla také polohovatelná základna pro Velodyne VLP-16, protože vodorovně kostky skoro neviděl.
Ta změť drátů vzadu skoro odpovídá současnému stavu — navíc přibyl router/switch, protože na řídícím počítači APU2 nám již došly Ethernet zástrčky (kamera, Velodyne laser, RFU620 čtečka a terminál k notebooku). Což mi připomíná, že pokud se nějakému týmu podařilo rozchodit RFU620 po CAN sběrnici, tak nás to zajímá (ten router bych rád zase odstranil).
První dobrá zpráva byla, že nějaké RFID čipy jízdou po hřišti detekujeme:
(31, [scan(id=17592236638209, RSSI=-67.2, power=24.0)])
2
(32, [scan(id=17592236638209, RSSI=-69.2, power=24.0)])
3
(33, [scan(id=17592236638209, RSSI=-70.8, power=24.0)])
2
(34, [scan(id=17592236638209, RSSI=-73.1, power=24.0)])
2
(35, [scan(id=17592236638209, RSSI=-76.6, power=24.0), 
      scan(id=17592253415427, RSSI=-71.2, power=24.0)])
2
(36, [scan(id=17592253415427, RSSI=-64.5, power=24.0)])
3
(37, [scan(id=17592253415427, RSSI=-67.4, power=24.0)])
2
(38, [scan(id=17592253415427, RSSI=-73.8, power=24.0)])
2
(39, [scan(id=17592253415427, RSSI=-69.7, power=24.0), 
      scan(id=17592236638209, RSSI=-77.9, power=24.0)])
3
(40, [scan(id=17592253415427, RSSI=-67.5, power=24.0)])
Jak moc se z toho bude dát lokalizovat teprve uvidíme. Zatím to vypadá celkem dobře: vždy nějaké detekce a někdy i dvojité … ale neplatí to pro celý log.
Horší to bylo s Velodyne. Takto vypadá jízda s nakloněným senzorem:
Neviděl blízkou kostku a na konci pokusu „prošel zdí” a zmizel v „černé díře”. Ono to dává smysl, že senzor má nějakou slepou zónu, jen jsme nečekali, že to bude s poloměrem 50cm … to ty SICK LIDARy mají méně. A tak jsme dočasně Velodyne odstranili a nahradili ho „malým SICKem” vpředu vedle klepet.
Jednu slabinu to ale má? Když se nabere kostka, tak ztratíme polovinu výhledu. Jako brute force řešení je dát druhý malý SICK i zleva, ale třeba přijdeme na něco elegantnějšího.
A co vy? MARTi se snad pomalu „probouzí”, Alpaca zatím „mlčí” … kdo dál se chystáte na soutěž?

25. září 2016 — ver1 (zbývá 11dní)

Je neděle, krásné počasí (nesrovnatelné s minulým týdnem na Robotour), ale místo relaxace na zahrádce zase koukám do logů. A moc uklidňující to není.
Cílem verze 1 je dokázat umístit více kostek (tři na nejbližší pozice). To by možná fungovalo, kdyby robot „zavřel oči” a nesledoval potenciální kolizi s nepřítelem a neinspiroval se RFID tagy pro určení pozice. V úterý jsme částečně přešli na čtení dat z RFU620 přes CANOpen, tj. místo Ethernetu teď chodí packety po CAN sběrnici. Ale chová se to nějak divně. Robot jede 2 metry rovně a na konci přejezdu čtečka hlásí, že zase vidí RFID tag, co byl na začátku :-(.
Ani s detekcí nepřátelského robota to není moc růžové. KISS řešení, kdy se v daném úhlu vezme nejmenší vzdálenost a pokud je menší než řekněme 20cm, tak prohlásí cestu za neprůjezdnou, kupodivu nefunguje (viz raw data z laseru v milimetrech):
[   56    68    62    59    62    66    68    64    66    84   287   496
   535   549   559   570   583   597   606   619  2227  2240   644  2261
  2273  2285  2300  2314  2332   743   758   777   795   818 10000 10000
 10000 10000 10000 10000 10000  2632  2666  2703  2739  1172  1210  2802
  2744  2722  2758  2718  7839  1687  1651    21    18    41    65     2
  2369  2339  2311  2281  2261  2232  2122  2092  2079  2061  2038  2019
  2004  1987  1979  1969  1960  1938  1933  1926  1912  1898  1890  1891
  1880  1867  1863  1854  1846  1841  1843  1840  1836  1824  1830  1828
  1827  1827  1817  1822  1816  1822  1825  1830  1840  1843  1838  1850
  1854  1856  1866  1874  1886  1899  1902  1921  1924  1946  1953  1965
  1986  1989  2007  2033  2043  2060  2081 10000 10000 10000 10000  1956
  1972  2002  2024  2045  2030  1983  1948  1909  1864  1500  1576 10000
 10000   805 10000  1665  1641  1625  1608  1583  1563  1541  1527  1517
  1487  1474  1191  1353  1436  1414 10000   623   613   619   615  3003
  1330  1320  1307  1297  1290  1285  1279  1275  1268  1260  1257  1248
  1257]
Ať žijí duchové! Teď nemyslím ty malé hodnoty na začátku, to by šlo vyřešit menším úhlem, ale 21 18 41 65 2 už je marnost, opakovatelná. Navíc hodnoty odrazivosti jsou až na poslední dvojku rozumné, takže ani tak nelze měření profiltrovat …
Uvidíme na dalším testování v úterý. Snad alespoň navigace na kostku bude fungovat lépe (teď se místo nejbližší hodnoty vezme skupinka, snad odpovídající detekované kostce, a pro ní se vezme středový úhel).
p.s. Alpaca potvrdila účast na společném testování 4. října

28. září 2016 — kabeláž (zbývá 8dní)

Přemýšlel jsem, co se včera posunulo a jediné, co mne napadá, je kabeláž. Tomáš nahradil několikametrové „industriální” Ethernet kabely menšími, takže teď jsou už zase vidět LEDky na horním panelu. Ale to je asi vše. :-(
Rezignovali jsme na CANopen u RFID čtečky — pro zapnutí skenu je třeba posílat textovou SDO zprávu, rozdělenou do více packetů, a to se nelíbilo ani mně ani Tomášovi. RFU620 tedy bude pouze na Ethernetu. Tečka.
Co se týče detekci kostky z malého laseru, tak stále potvrzuji přítomnost „duchů”. Jakub to do mailu komentoval: Martine, když už je to Jakub's idea, nechceš tam přidat i tu část, která umí rozlišit mezi kostkou a stěnou? a měl pravdu. Teď se pro hlouček bodů ověří i velikost a tím se některé zavádějící detekce (např. [ 438 211 1767] … tj. ojedinělý bod v 0.211m) odstraní.
Problém s duchy, resp. rušícími odrazy od konstrukce, asi nastává i pro detekci blokované cesty. Zde bude nutné filtrovat na překážky veliké alespoň jako kostka.
Ještě jeden vtipný test s navigací na kostku (vlastně jeden z mála pseudo „úspěšných”). Bral se nejbližší bod, ale slepá zóna byla nastavena na 20cm. Zároveň se kostka musela nacházet v prostoru osy středu robota do 40cm. V této kombinaci robot najel na první kostku a „ztratila se mu z výhledu”. Uviděl však další a pak ještě jednu. Vypadalo to celkem zábavně:
… ale kdo ví, co přesně dělal. Teď je tam slepá zóna 1cm a doplněno filtrování na velikost kostky.
Navigace na kostku ale dobrá není. Použitý driver.goToG generátor hrozně osciluje. Je na čase to po sobě po několika letech zase přečíst … tak nastavit se dá jak daleko od cíle skončit. Teď naviguje na pozici kostky, aby byla ve středu robota a to není dobré (nutně jí netrefí napřímo a kostka mine klepeta). Pak lze omezit rychlost otáčení, default je 10 stupňů za sekundu … to je asi hrozně málo??
Samotný goToG algoritmus je jednoduchý:
  • pokud cíl vidíš pod příliš velkým úhlem otáčej se na místě (velký úhel defaultně znamená také 10 stupňů)
  • pokud jsi blíž než finishRadius zastav a konec jinak otáčej rychlosti
  • proporcionální úhlu na cíl (zhruba) OK, zvětším úhel i cílový poloměr a snad to bude lepší.
Jirkovi (Cogito) jsem přislíbil nějaké foto naběráku, tak tady je:
p.s. za větší počet kostek vděčíme Davidovi/MART týmu, díky. A mimochodem vznikla „Cogito MART” koalice, tak jsem zvědav.

29. září 2016 — Svatováclavské testování

Svátek v půlce týdne … jak stvořený pro testování.

Navigace na kostku

Není nad „hloupé” algoritmy a dnes se mi to znova potvrdilo. Původní implementace si spočítala polohu kostky a pomocí GoTo navigovala robota (ostatně viz výše). Ale vhodně naladit parametry nebylo úplně triviální a tak nastoupil KISS (Keep It Simple Stupid).
Co takhle: když je kostka vlevo, toč vlevo. A když je vpravo, tak toč vpravo. Zní to dostatečně triviálně? Asi čekáte šílené oscilace, ale co když definujete střed +/- 1cm, kde nic neděláte, a rychlost otáčení jen 10 stupňů/sekundu? Kupodivu se Eduro trošku vrtělo, ale jinak dobrý! Tak se vám otáčí za detekovanou kostkou a když se neotáčí, tak je něco špatně. Vzhledem ke složitosti algoritmu je špatně detekce kostky.
Předešlý algoritmus skončí na TIMEOUT a nikdy nic nenabere. Co drobné vylepšení, kdy ve střední poloze se robot pomalinku rozjede vpřed? A je to! Pravda ještě podmínku, že když je kostka už v klepetech, tak konec, popojeď rovně a spusť nabírání.
Robot buď popojíždí ke kostce nebo „se kousne” a v daném laserovém skenu nic nevidí … a to je vzorek dat hodný prozkoumání (celkem z 37 jízd a 20MB laserových dat).
Případně viz odpovídající commit (ano, zase ostuda, je tam namícháno i vypínání serv po ukončení jízdy … prostě mne ten zvuk při testování rozčiloval a git commit -p úplně ještě neovládám :-(

Verze 1

Cíl umístit 3 kostky: vlevo, rovně a vpravo. Opakovaně. Spolehlivě. Aneb „bylo nebylo” … no zatím to není. Využívá to již navigaci na kostku a ano, často se to „kousne” (zatím), ale to je řešitelný problém. Spíš už pomalu nastupuje úloha: a co když místo jedné kostky jich je 25?! Ono i 4 kostky jsou pro začátek dost:
  • pokud robot nabere jednu kostku, ale jinou hrne, tak ztrácí body (a v našem případě se sám sebe lekne, kostky odhodí a vrátí se do domečku/nakládací zóny).
  • když jsou kostky blízko sebe, tak nefunguje klasifikace podle velikosti.
  • když si už jednu kostku vybere, tak se nesmí nechat zmást jinou, bližší. Aby robot neskončil jako oslík mezi dvěma kupkami sena.

Kostka viděna laserem

Toto je příklad dat, kdy hrana kostky je detekována blíž než stěna kostky.

2. říjen 2016 — Příprava ver2

Je asi chyba začít pracovat na „verzi 2”, když „verze 1” ještě není ani odladěná ani spolehlivá. Čas už se krátí. Verze 2 by měla být schopna se absolutně lokalizovat a měla by zajistit funkčnost robota po celých 10 minut soutěže. Z dřívějších zkušeností víme, že na klouzavém povrchu ve sportovní hale ve Waldkirchu se samotnou odometrií dlouho nevydržíme. Letos tam mají položit koberec, ale jestli to bude posun k lepšímu těžko říci.
Pro absolutní lokalizaci se nabízí:
  • kompas
  • RFID tagy
  • detekce mantinelů hřiště
  • použití již položených kostek
  • ???

Kompas

Obecně mu moc nedůvěřuji, ale po posledním projektu s „robo-lodičkou” bych ho zase vzal v úvahu. Cvičně jsem si zobrazil hrubá data a trošku jsem se zalekl:
Ono toto už byla před-zpracovaná data! OK, druhý pokus, teď už snad opravdu raw:
Viděl jsem už hezčí kružnice, ale dal bych mu šanci (zase mám pocit, že i s kompasem byl u SICKů nějaký problém, ale … uvidíme).

RFU620

Data z jízd pomocí ver1 lze použít i pro vizualizaci detekce jednotlivých tagů (ono hezčí by byl nějaký animovaný gif, ale ten teď asi neposkládám):
Rozptyl u (3, 5) bude již pravděpodobně způsoben chybou v odometrii. Pro hrubé určení, kde se na hřišti nacházíme (s přesností na 1m) by to asi mohlo stačit. Pro přesnou navigaci mezi kostkami ale nikoliv.

3. říjen 2016 — Posedlost absolutní pozicí?

Dnes jsem něco přes hodinku testoval Eduro a aktuální verzi 1. Když jsem ho tam v té cca 3x4m veliké ohrádce pozoroval, říkal jsem si, jestli to neděláme úplně špatně a jestli to bazírování na absolutní pozici není nějaká posedlost?! Na „hromadě” tam leží laserem nepřehlédnutelných 25 kostek a cílový prostor lze spolehlivě poznat z RFID tagů a je také dost veliký na umístění mnoha kostek s rozumným odstupem …
Místo toho se Eduro zatím spíše leká samo sebe, kostky klidně položí dvě vedle sebe, tj. získá body jen za první kostku, a jezdí-li po „osvědčených koridorech”, tak stačí jedna chyba („nechtěně” položená kostka) a pak už je klíčové křižovatce položí všechny [dnes se mi to stalo snad 2x].
Asi je nejvyšší čas vymyslet kde startovat. Na start pomocí dálkového ovládání se nechystáme, takže by to mělo být někde u mantinelu a zároveň na kraji storage area, aby robot nehrnul kostky a měl šanci se vymotat vedlejším koridorem. Mimochodem do „mantinelu” jsem dnes narazil asi 3x. Je to tím, že ve storage area vypínam detekci překážek, aby mohl v klidu sbírat kostky, ale zdí neprojde … TODO.

5. říjen 2016 — Společné testování

Včerejší společné testování s týmem Alpaca dopadlo trošku jinak, než jsem si původně představoval, ale snad to mělo i pozitivní přínos pro oba týmy. Byl jsem rád, že dorazili. Jejich všesměrový robot se i po oddělání koleček horko-těžko vešel do obřího kufru a cestovat s tím MHD chce už hodně vysokou motivaci! Díky
Do skoro zaplněné haly by se nakonec hřiště 13x7 metrů nevešlo a tak byla klika, že sousední „kruhovka” měla prostor vyklizený (navíc se ukázalo, že jí ten večer hlídá spřízněná robo-duše). Jak už název budovy napovídá výsledné hřiště rozhodně nebylo obdélníkové (i když by se nakonec dalo ze dvaceti stolů „vyrobit”, ale tady motivace byla malá … možná až doplníme korekci na pozici???).
Rozchodili jsme WiFi na Eduru (ještě, že ty Windows ukazují heslo), předefinovali absolutní souřadnice — (0, 0) je od teď na obrázku vlevo dole a odpovídá tagu 0007 0000, resp. 0D00 0000 pro start z opačného rohu, provizorně zase vypnuli detekci nepřítele (především kvůli kostkám, které si Eduro nechtěně vyhrne ze storage area), a vytvořili seznam tras pokrývající 13 míst (zubatá hradba) … viz git.
Návrat přes potemnělou halu ale nebyl úplně šťastný. Ale vlastně to mohlo dopadnout i o řád hůř, např. zničeným laserem. Bilance: ulomený konektor k RFU620 (Tomáš udělal nové kabely, tj. nebylo to ani 2h staré), ohnuté pravé hliníkové Lko (nevěřil bych, že to lze ohnout) a nefunkční motor číslo 2. S tím motorem doufáme, že je to pouze vypadlý CAN modul, jako důsledek tahání za kabely při návratu k původním (jen je třeba rozdělat spodní krabici Edura).
Dost lamentování. Zbývá 56h do odjezdu a TODO-list se zatím moc nezkrátil …

6. říjen 2016 — Odometrie

Dofukovat kola den před odjezdem není sice nejrozumnější, ale bude to nutné udělat. Do teď jsme to neřešili (chyba) a teprve při jízdách na větší vzdálenosti je to hodně poznat. Test na 10m jízdy rovně ani neujel, protože po 9m robot „narazil” do překážky 2.5m vlevo. To má teď asi nejvyšší prioritu ať se to stihne ještě párkrát zkusit.
Druhá nepříjemnost je důsledkem úterní destrukce. Vypadá to, že pozice laseru není jako dříve a o pár stupňů je pootočený(?). Dříve nabíral kostky dost „na hraně” a včera to již několikrát selhalo. Vypadá to, že tam necháme hack na 5cm offset, se kterým to víceméně fungovalo.
Z předchozího textu je zřejmé, že už jsme zase jezdili. Ano, byl to vypadlý resp. vytažený konektor na motoru — fixed. Tomáš také udělal nový kabel k RFU620 a zatím bych to zaklepal ťuk, ťuk, ťuk snad vše funguje jako dříve a už to není změť klubek kabelů.
Z věcí, co se nemají dělat na poslední chvíli, jsem instaloval OpenCV na případné zpracování obrazu. Na traktůrku ještě kamera není a tak jsem na to pozapomněl. Přiznám se, že mne trošku znervóznil upgrade samotného Pythonu:
The following packages will be upgraded:
  libpython2.7-minimal libpython2.7-stdlib python2.7 python2.7-minimal
Ale snad také OK (do školního alarmu už jsme udělali jen jednu testovací jízdu s novou instalací).
Ze zajímavostí bych zmínil chybu v driver.py, což je jeden z nejstarších kusů kódu. Konkretně se projevovala tak, že když robot detekoval blížící se kolizi, tak pouze poslal příkaz na odhození kostky a couvnutí si 30cm. V realitě to ale bylo jinak: vůbec si necouvl a kostka mu zůstala v klepetech. Dokonce to sám věděl!
Kód:
print "COUVAM", self.robot.localisation.pose()
self.driver.goStraight(-0.3, timeout=30)
print "COUVAM done", self.robot.localisation.pose()
Výstup:
COUVAM (5.315444919738929, 1.4719470617866883, 0.0005103738339570794)
0x100005050003L (5L, 5L) -75.9 (1/1)
0x100005050003L (5L, 5L) -66.3 (1/1)
0x100005050003L (5L, 5L) -67.0 (1/1)
0x100005050003L (5L, 5L) -69.2 (1/1)
0x100005050003L (5L, 5L) -71.2 (1/1)
0x100005050003L (5L, 5L) -70.7 (1/1)
COUVAM done (5.524286769635407, 1.4720695179939571, 0.06971353374260535)
Tj. z pozice x=5.31m si „couvnul” na x=5.52?! Není to chyba znaménka, je to chyba skrytého předpokladu, že robot je před vykonáním příkazu v klidu. Ten ale jel svých 50cm/s, spočítal si brzdnou dráhu (absolutní hodnotu), ale pak jí přiřadil špatné znaménko pro vyhodnocení „jestli už to couvání ubrzdí”. Fixed přidáním zastavení před couváním (viz git — zase jsem byl líny ten commit rozdělit). Mimochodem asi není překvapení, že do překážky (opakovaně) narazil. V dalších pokusech jsem raději zeď nahradil taškou se spacákem a celkem ji decimoval. Ono detekce na 20cm, nějaká reakční doba a pak 5.31 + 0.2 vs. 5.52 …
Teď už jen pár obrázku z testování v hale, kde asi největší adrenalín bylo přeparkování Spidera. Jednou s tím začít musíš!

7. říjen 2016 — Prohozená kola? (7h do odjezdu)

Po včerejším reportu mi bylo trošku smutno. Když si vzpomenu, jak před lety Jirka/Cogito testoval Eduro před Robotour 2010 a následně (zaslouženě) vyhrál, tak to „smíření” s chybou 1.5m na 10m … nezkousnu to. Jirka tehdy kalibroval na cca 100m cestičce, 2m široké, s tím, že došel k závěru, že kola jsou různě veliká. Konkrétně o 0.00015m! Asi čitelnější to je jako 0.15mm … fakt malý rozdíl. Ale opakovatelnost byla neuvěřitelná a tak do kódu zavedl různě velká kola. Teď jsem jeho korekční člen přenesl do sickday2016.py (viz git diff), kdy nejprve jsem rozdíl nastavil na 0.0 a robot po přehrání logu byl necelý metr vlevo. Prohodil jsem znaménko na -0.00015 a až neuvěřitelně se to blíží realitě. Sherlock by asi řekl: někdo nám prohodil kola.

8. říjen 2016 — Show Time

„Hele, mně se to líbilo!” Je pravda, že jsme nevyhráli, ale mise vlastně byla splněna na 66.6% … a co že bylo cílem mise? Obsadit první tři místa českými týmy.
Z pohledu „generálů v kožených křeslech” byl tréning nedostatečný. Zakopaný pes nebyl až tak ve velkém množství kostek jako hrubý povrch koberce, na kterém kostky držely jak přilepené! Resp. kombinace mnoha kostek s kobercem byla smrtící.
Krátce po prvních testech bylo nutné povolat HW sekci kvůli přestavbě robota. Eduro bylo schopné kostky i přejet! Z různých kousků dřeva, zbytků hliníkových profilů a „NASA lepící pásky” vznikla ochrana obou kol a středu robota:

1. kolo

V kódu byl nedostatek timeoutů — prostě jestli se snažíte jet 1m rovně a to se vám za 60s nepodaří, tak je něco špatně a „měla by se” zkusit nějaká alternativa. U základních operací, jako je couvání, zatáčení nebo hledání kostky, tato kontrola byla, ale u navigace po lomené čáře už nikoliv. A za to jsme zaplatili už v prvním kole. Eduro pěkně položilo dvě kostky, ale pak v domečku najelo na jednu a to znamenalo konec. Byl to velmi smutný pohled na robota 9 minut v křečích.

2. kolo

Během soutěže bych na kód normálně nesahal, ale ten pohled z první jízdy byl fakt tristní. Přidal jsem timeout na minutu, ale co má dělat robot potom? Dostal za úkol couvnout, 90 stupňů vlevo a 90 stupňů vpravo. A pak? Hmm. Nejprve tam byla chyba a pak pokus o kód: nastav si znova timeout na 60s a zopakuj původní (neúspěšnou) akci dovezení kostky na cílové místo.
V realitě to nefungovalo dobře, ale i tak se robotu podařilo položit asi pět (?) kostek. Pak si najel moc do domečku (storage area) a to už bylo jak v bažinách. No alespoň s sebou jednou za minutu zuřivě cukal a dokonce se mu podařilo se vymotat. … no ale myslím, že si tím vykoledoval jen trestné body (náraz na mantinel). Za tu snahu ten půlbod stál (nevím, jestli jsme tím nepřišli o druhé místo??).

3. kolo (Show Time)

Třetí jízda ze dvou?! Za to vděčíme týmu „Smelý Zajko”, který nakonec nedorazil, a iterpelaci „Cogito MART” týmu, že zápas bez soupeře není fér vůči ostatním týmům a že klidně obětují svého robota i bez bodového zisku. Podle neověřených zpráv Smelý Zajko v sobotu ráno havaroval na cestě cca 50km do Waldkirchu :-(. Zranění snad nebyli, ale jak dopadlo jejich auto nevím.
Na poslední zápas tedy místo slovenského týmu nastoupilo Eduro. Nevím, jestli vidím do budoucna, ale stejně jako jsem tušil, že budeme „náhodně” vylosovaní do zápasu s Cogito MART, tak v poslední jízdě Eduro excelovalo, získalo by nejvíce bodů ze všech zápasů za celý den — byla radost na to koukat!

Ostatní zápasy a roboti

Letos dorazilo do Waldkirchu osm týmů. Většinu tvořily německé týmy + tři české týmy … i když je otázka, zda „švýcarské” Cogito, poskytující RaS (robot as a service), vlastně klasifikovat
Většina týmů se snažila posbírat pár bodů a jenom dva týmy měly součástí strategie agresivní výpad a blokaci nepřítele. Nechci být škodolibý, ale potěšilo mne, když nastoupily proti sobě . Podle očekávání to ublížilo spíše jim než soupeři. Kousek tohoto zápasu je i na přehledovém videu.

Video (Cogito MART - první zápas)

Odkazy


9. říjen 2016 — Eduro a Cogito log videa

1. kolo

2. kolo

Exhibice

… a stereo očima Clementine/Cogito


11. říjen 2016 — Oficiální výsledky

Na stránkách SICKu oficiální výsledky vyvěšené zatím stále ještě nejsou, ale Def mi poslal konečné PDFko obsahující toto info:
Team Lauf 1 Lauf 2 Bestes Platz
Karlsuni Prag 7.0 6.0 7.0 1
Uni FR -0.5 5.0 5.0 2
EDURO 2.0 4.5 4.5 3
Kamaro Engineering e.V. 4.0 4.0 4.0 4
Osnabrück 1.0 2.5 2.5 6
FRED X 1.0 1.0 6
Alpaca 0.0 0.0 0.0 7
WINGmen X X 0.0 7
Smelý Zajko - - - -
Pár zajímavostí:
  • nepočítal se součet bodů, ale nejlepší kolo (Def mne uklidnil, že i pro součet bychom dopadli stejně, protože na druhé místo by se dostalo Kamaro)
  • ten náraz v druhé jízdě nás opravdu stál druhé místo
  • kdyby exhibice byla normální jízda, tak by to …
Cogito MART vítězný zápas byl tedy ten první a zápas s Edurem byl tedy bodově nejlepší pouze pro Eduro. Zde je video od Davida/MART:
případně viz Davidův kompletní SICK Robot Day 2016 video list.

Video od Andrease/CS Freiburg (2. místo) s SicKubOS

Eduro Exhibice