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:
- 160907 / ver0
- 160914 / Velodyne Black Hole
- 160925 / ver1
- 160928 / kabeláž
- 160929 / Svatováclavské testování
- 161002 / Příprava ver2
- 161003 / Posedlost absolutní pozicí?
- 161005 / Společné testování
- 161006 / Odometrie
- 161007 / Prohozená kola?
- 161008 / Show Time
- 161009 / Eduro a Cogito log videa
- 161011 / Oficiální výsledky
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.