SICK Robot Day 2018
první robotická loupež
Letos na podzim se koná další ročník soutěže „SICK Robot Day”. Hrací plocha je opět tělocvična (cca 13 x 7 metrů), kde proti sobě nastoupí dva soutěžní roboti + jeden organizátorský! Ten bude jezdit po kruhové dráze s nákladem železných koulí a úkolem soutěžních robotů je „uloupit co se dá” a dopravit lup do vlastního doupěte. Blog update: 18/10 — Eduro video
Pravidla v kostce
Hrací aréna má rozměry cca 7x13m. Startují od svých přepravek, které jsou
umístěny na opačných stranách hřiště. Robot musí během 10 minut lokalizovat
transportního robota a dopravit do své přepravky co nejvíce červených koulí.
|
Transportní robot jede relativně pomalu (20cm/s) a je vybaven senzory na
detekci překážek. Pokud je cesta blokovaná, tak zastaví. Je-li ale blokován
déle než 1 minutu, blokující robot končí a v daném kole nezískává žádný bod.
Obsah:
- 180921 / 21 dní do soutěže
- 180922 / Simulace a konkurenční shrabovák
- 180923 / APU2 SW reset??
- 180926 / Kouřové signály z Prahy
- 180927 / Viewer a TiM 571
- 180929 / Proč OSGAR?
- 181003 / Verze 0
- 181007 / Tlačítka a scan_split() (zbývá 5dní)
- 181008 / Brute force detect_box() (zbývají 4dny)
- 181009 / Nové baterky, kamera a počítač (zbývají 3dny)
- 181010 / Podlaha (zbývají 2dny)
- 181011 / Méně je někdy více (zbývá 1den)
- 181012 / bus.publish (zbývá 26hodin)
- 181013 / Hrad (GAME OVER)
- 181015 / Soutěž a video
- 181016 / Short Circuits Prague video
- 181018 / Eduro video
Blog
21. září 2018 — 21 dní do soutěže
Říkal jsem si, že je pomalu na čase začít blog na téma přípravy na „SICK Robot
Day 2018” pořádaný německou firmou SICK a s překvapením jsem zjistil, že už
jsem to začal sepisovat v březnu, jen jsem to zapomněl (?) zveřejnit. :-(
Soutěž samotná se koná za tři týdny, v sobotu 13.
října 2018 ve Waldkirchu v Německu.
Eduro Team začal experimentovat již v lednu, krátce po zveřejnění pravidel.
První experimenty byly s magnety a robotickou rukou UR5 (viz video níže).
Magnet
přitahuje bez napájení a teprve pokud předmět (kouli) chcete upustit, tak je
třeba napájet (24V, 300mA).
Začátky byly slibné, ale pak byl skoro půlrok relativní klid. Teď už je po
Robotour, tak se můžeme všichni znova
soustředit na soutěžní úlohu.
Moje osobní motivace je rozjet na Eduru
OSGARa, který momentálně běží na
John Deere a Spider3 a nově i na lodičce
Marina. A jak to vypadá? No zatím ještě kontrolovaně neujedeme ani jeden
metr. :-( … ale to se podá.
Co je horší, že asi za ty dva roky odešly i baterky — rádo se to resetuje a
podle dnešního logu
eduro-180921_141638.log to
skoro vypadá, jako když dojde ke zkratu (a ano, hlavní řídící počítač to
resetuje):
To je až podezřelé … takový propad napětí. Asi jsou baterky mrtvé.
Tak alespoň motivační video s rukou, co poslední dny připravoval MartinS se Standou:
22. září 2018 — Simulace a konkurenční shrabovák
Pavel ze Short Circuits Prague mi poslal nahrávku ze simulátoru
V-REP:
Trošku jsme to propočítávali a jestli je průměr zhruba 7 metrů, tj. obvod okolo
20 metrů, tak při rychlosti 0.2m/s bude trvat jedno kolečko transportéru 100s.
Deset minut = 600s, takže transportér udělá maximálně šest koleček a
2*6*9=108 … tj. teoreticky lze získat přes 100 bodů! (prakticky jestli
některý tým dokáže dát 10 bodů, tak to bude obří úspěch)
Tým MART se spojil s Martinem L. z robotického klubu v Rychnově nad Kněžnou a
hardwareově by jejich „shrabovák” měl šanci nasbírat bodů více než dost:
23. září 2018 — APU2 SW reset??
Došel jsem k závěru, že jsem vás předevčírem mystifikoval. :-( Trošku jsem
upravil kód
tools/plot.py
(rozuměj, ošklivě to hacknul v feature/eduro větvi), abych dokázal
pyplotem rovnou z logu udělat graf změny napětí v závislosti na čase, a
dostal jsem následující dva obrázky:
|
|
python tools\plot.py eduro-180921_141638.log
Šťouravý čtenář by se mohl zeptat, jak je možné, že APU2 (řídící počítač) dále
logoval při napětí okolo 6V nebo v druhém případě dokonce na 1.4V?! No on to
logoval, protože to nebyl ten problém! První graf ve skutečnosti ukazuje
zamáčknutí STOP tlačítka, které už více jak 10let od
Eurobota vypíná 24V napájení. APU2 je na 12V a
stále napájené. Že napětí výrazně klesne je tedy očekávané (možná bych čekal
přímo nulu).
Případ, kdy se to opravdu resetovalo a samotný log soubor je „nabořený” je
ten pravý graf, kdy jsem log musel po 34.291899s ručně uříznout. Pak se měla
obnovit 24V napájecí větev, ale místo toho se APU2 resetovalo a konec. Teď si
myslím, že to vůbec nebylo způsobeno HW, ale SW a že stále je zapojena nějaká
varianta konzole přes sériový port a vhodným kódem APU2 donutím k resetu.
Otázka, zda to nastává úplně pokaždé??
Ještě je varianta, že regulátory motorů očekávají, že po vypnutí STOP tlačítkem
mají být v pre-operation módu, což nejsou … prostě si 100% jistý nejsem
a začal bych podezřívat i SW.
26. září 2018 — Kouřové signály z Prahy (zbývá 16dní)
Včera byl „robotický úterek”, kterého jsem se ale nezúčastnil, a tak mám
zprávy pouze telegraficky. Podle všeho vypadalo HW již zkompletované, ale …
chybné zapojení fáze na relátka od magnetů ukončilo život jednoho Arduina a na
nápravě se momentálně pracuje.
Podařilo se nahrát první obrázky z IP kamery. Ukládání velkých datových zpráv
je ošetřeno (viz logger.py -
support large data blocks), i když bylo nakonec třeba jiné URL a pak ta data
nejsou zas tak velká … alespoň jedna dobrá zpráva. O trošku horší je to s
tím, jak obrázky vypadají.
Nejprve mělo Eduro „růžové brýle”:
ale kamera vrátila pouze jeden jediný obrázek. V dalším běhu bylo již vše OK,
ale obrázky byly „přepálené”. Dnešní testování dopadlo se stejným
výsledkem.
První normální obrázek, kdy se kamera „kousne” a v dalších testech vše OK, až
na to jak obrázky vypadají:
Pro zájemce případně viz
eduro-180926_170554.log ke
stažení.
27. září 2018 — Viewer a TiM 571 (zbývá 15dní)
Dnes jsem upravil starší (vlastně prastarý) tools/viewer.py, aby četl data
rovnou z OSGAR logů. Zatím scan data z laseru TiM 571 a obrázky z kamery. Co
jsem viděl mne úplně nepotěšilo … ostatně si to můžete zkusit sami z logem ze
včerejška:
python tools/viewer.py eduro-180926_170554.log
… no chtělo by to animovaný gif, co se děje mezi 85 a 95 cyklem :-(
Ono to bude ještě zábavnější, protože naším cílem bude se k transportéru dostat
poměrně natěsno a tam asi podobné artefakty uvidíme častěji.
Jinak jsem lehce znaven sledováním DARPA SubT
Challenge webcastu, tak si zítra asi dám „svátek”. V gitu je i staro-nová
verze osgar/followme.py, jen v datech jsou i 2mm měření a ta jednoduchý
algoritmus zmatou …
29. září 2018 — Proč OSGAR? (zbývá 13dní)
Už delší dobu si říkám, že bych měl nějak obhájit, proč přepisuji základní
funkcionalitu pro Eduro do OSGARa a nepoužiji již několik let starý funkční
kód. Navíc času je málo, tj. o důvod více „nic nového nerozjíždět”!
Asi bych měl začít tím, co že to přesně ten OSGAR je? Původně
to měl být Open Source GARden cosi, dokonce ani ne nutně roboti. Pak se GAR
změnil na Garden (Autonomous) Robot a byl to kód šitý na upravený zahradní
traktor John Deere X300R. Pak došlo na Spider3 Rider a pokus vytvoření
„základny” pro další „zahradní” roboty. Zbyněk se nabídl
dělat review kódu na GitHubu a přestala
to být one man show. S Naio soutěží jsem
si vyzkoušel loni vše nanovo v Python3 … a nějak se již nechci vracet.
Tak co ten OSGAR, co to je teď? Pomalu bych to přejmenoval z Garden na
Generic, ale cíl je ještě daleko. Když jsme se po loňské (nebo dokonce
předloňské?) Robotour bavili o zobecňování
robotického SW, Ondra i Zbyněk tvrdili, že něco zobecňovat má smysl až pro
třetího robota. U druhého je rychlejší Copy&Paste a teprve u třetího se to
možná vyplatí. První byl John Deere, druhý Spider3 a Eduro by
mohl být ten třetí robot. Po pravdě řečeno, třetí byla vlastně
lodička Marina, ale ta ještě není zapracovaná v
masteru.
Co je tedy ten společný základ? Logování, systémová sběrnice, I/O drivery,
konfigurace a možná pracovní postup včetně přehrávání logu s asserty.
Logování
Dříve (míněno posledních X let) jsem si každý komunikační kanál logoval zvlášť.
Základní cyklus bylo typicky řízení rychlosti motorů. Extra senzory jako laser
nebo kamera se na tento cyklus napojovaly pomocí extra logu, který obsahoval
počty základních cyklů kvůli přehrávání. Obrázky se navíc logovaly každý zvlášť
(JPEG formát z IP kamery), takže jedna nahrávka mohla mít i tisíce souborů. S
tím se špatně pracuje a špatně se to sdílí. Mezikrok byl vše ZIPovat (jako
post-processing) do jednoho souboru a přehrávat logy rovnou ZIPované. Ostatně
viz historii několika desítek sdílených logů na
https://osgar.robotika.cz/.
OSGAR logování je rovnou do jednoho jediného souboru. Jednotlivé zdroje jsou
indexované (kanály, streamy) a každým datový blok má navíc timestamp
(Python datetime.timedelta s rozlišením v mikrosekundách).
Systémová sběrnice
Druhý, podle mne zásadní, posun byl s přechodem na společnou systémovou
sběrnici. Jednotlivé moduly mezi sebou komunikují pouze přes publish a
listen funkce. Je tedy teoreticky možné přejít z více-vláknové aplikace
(každý modul má své vlákno) na jedno-vláknovou (přepínání kontextů je možné při
volání publish/listen funkcí). Základem je jednoznačná opakovatelnost
původního kódu + smysluplná (zalogovaná) data i pro jiné programy/nástroje.
I/O drivery
Robotik jich vlastně potřebuje až překvapivě málo: pyserial, komunikaci
přes sockety, možná USB?? U lodičky se hodil driver na I2C … chybí někomu
něco?
A když je logován externí svět, tak pak je programování různých parserů
celkem přímočaré. V první fází stačí nahrát vzorek dat a pak postupovat podle
specifikace. K dispozici je parsování SICK lidarů, NMEA z (d)GPS, nějaká IMU.
Na TODO-listu je úprava parsování UDP paketů z Velodyne lidaru a časem asi
přibudou další.
Konfigurace
Konfigurace je dost zásadní součást nahrávky reálného testu. Obsahuje jak
nízkoúrovňové popisy driverů (port, IP, rychlost komunikace a pod.) tak i např.
vstup pro aplikaci jako seznam GPS průjezdních bodů. Vše je momentálně
popsané v textovém JSONu a lze více konfiguračních souborů (částečně) při
pouštění z příkazové řádky kombinovat (např. v jednom je popis robota a v jiném
seznam úkolů, které má vykonat).
Přehrávání s asserty
Přehrávání je zatím pouze po jednotlivých modulech (viz skript replay.py)
případně aplikační kód lze přímo přehrát z aplikace (např. python followme.py
replay <log>). Lze tedy relativně bezpečně refaktorovat kód (ověřit, že
vrací stále stejné příkazy jako v původním běhu), případně s parametrem
--force porovnávání výstupů vypnout. Kód tedy běží „nasucho”, ale z
reálných (starších) dat.
…
Konec obhajoby, je na čase připravit „verzi 0”
3. říjen 2018 — Verze 0 (zbývá 9dní)
Včera Eduro poprvé autonomně bodovalo:
eduro-181002_213400.log
lze přehrát pomocí
python tools/viewer.py eduro-181002_213400.log
v feature/eduro git větvi.
Ale … transportér byl statický, jeden úspěšný pokus z devatenácti
(ano, prvních X jsme ladili komunikaci s rukou, rychlosti a pod, ale po
úspěšném pokusu následovaly tři neúspěšné, takže skóre minimálně 1/4). Co je
asi ještě horší je záznam z kamery na robotovi — po startu obraz zčerná, pak
se objevují pestré odstíny, ale chvílemi je ostrý, pěkný?! Provedli jsme reset
nastavení, což rozhodně pomohlo, ale evidentně nedostatečně. Je tam asi ještě
zapnutá nějaká automatická korekce na nevhodné části obrázku (předpokládám, že
se nastavuje podle pohledu na ruku?? TODO-1).
Ze včerejších zpráv byla asi největší zklamání zásilka náhradních baterii z GME
(olověné gelovky). Byly vybité a jedna vadná. Baterky jsme tedy zatím neměnili
a tak problém s resetem APU2 přetrvává (jednou potvrzeno, vícekrát jsme STOP
tlačítko raději nemačkali).
Ze zajímavostí možná integrace „Arduino ruky”, na které pracuje MartinS. V
kódu používá Serial.parseInt(),
což je pohodlný způsob jak ze seriáku číst čísla, ale … pokud si člověk nedá
pozor, tak bude možná zaskočen timeoutem na čtení: Initial characters that
are not digits or a minus sign, are skipped; Parsing stops when no characters
have been read for a configurable time-out value, or a non-digit is read; If no
valid digits were read when the time-out (see Serial.setTimeout()) occurs, 0 is
returned;
V komunikaci s rukou používáme čtveřice: poloha dvou serv a stav dvou magnetů.
Co se tedy stávalo, že se čtení posunulo timeoutem o jedna a pak magnety
dostávaly polohu serva a pod. Rychlá záplata byla zakázat nuly, které mohou
přijít pomocí timeout, ale když jsem odstranil i Serial.available()
podmínku (počet bajtů k dispozici), tak se to celé „zadřelo”, nějak to
reagovalo, ale už to nic (!?) neodpovídalo. Teď je tam zpátky
while(Serial.available() vyčti ty čtyři čísla, ale úplně dobrý pocit z toho
nemám.
Ještě něco? Asi v pěti pokusech Eduro vyrazilo mírně vpravo, jako by jeden
motor měl chvíli výpadek nebo se opozdil. TODO-2
Jinak SICK lidar TiM 571 Standa na naše přání umístil na Eduro vlevo (foto
nemám, ale MartinS pak nahrával neúspěšné pokusy), takže jsme si zúžili výhled
z 270 stupňů na 180, ale vidíme jak 17cm vysokou vykládací krabici, tak se
můžeme na těsno přiblížit k transportéru. Jak moc je to dobré ukáží další testy
…
p.s. ještě ten „sofistikovaný” kód pro verzi 0:
def ver0(self):
self.go_straight(1.0)
self.bus.publish('hand', b'40/50/0/0\n') # ready for pickup
self.go_straight(1.0)
self.bus.publish('hand', b'30/40/0/0\n') # hit balls
self.wait(timedelta(seconds=3))
self.bus.publish('hand', b'20/80/0/0\n') # move up
self.go_straight(-1.0)
self.bus.publish('hand', b'40/50/0/0\n') # traveling position
self.turn(math.radians(180))
self.go_straight(1.25)
self.drop_balls()
self.wait(timedelta(seconds=3))
p.s.2 a tady je konečně to mizerné (zpomaléné) video vyrobené pomocí
tools/log2video.py
7. říjen 2018 — Tlačítka a scan_split() (zbývá 5dní)
Ještě v pátek večer mi Jakub nahrál sadu testů (16 jízd) s různým úhlem
najíždění na krabici (storage box) a i ukázky jízdy s pohyblivým transportérem.
Do systému jsou nově zapojena tlačítka a samozřejmě jsem je prohodil :-(.
Eduro má jednak povinný startovací kabel z
Eurobota 2007 a přepínač
červená/modrá pro volbu strany. Oddělený start je užitečný a přepínač možná
budeme používat na volbu klidné (modrá) a agresivní (červená) strategie. Stav
tlačítek se posílá pouze na začátku a pak při změně všechny. Zpráv je tak málo,
že jsme nakonec zvolili čitelné dictionary:
python osgar\logger.py –times –stream eduro.buttons eduro-181005_172623.log
0:00:05.650637 7 {'blue_selected': False, 'cable_in': True}
0:00:21.344589 7 {'blue_selected': False, 'cable_in': False}
0:00:22.362757 7 {'blue_selected': False, 'cable_in': True}
Prohození je teď snad již fixed.
Základní navigace je postavena na skenech z lidaru TiM 571: 811 měření s krokem
1/3 stupně, kdy z 270 stupňů používáme pouze 180 stupňů. Zatím jsem si hrál s
navigací na storage box 40x30cm. Předpokládám (možná špatně), že chyba
otočení bude menší než 45 stupňů a tak robot na cestě zpět buď uvidí zadní
stěnu nebo cílovou krabici:
(koukám, že zase mám ten laser otočený, TODO fix vizualizaci)
Zatím naivně předpokládám, že sousední měření si jsou velmi blízká:
Pro první pokusy je použitý limit 2cm (20(mm) v grafu výše). Filtr je ještě na
minimální délku „řetězu”, zatím nastaven na 10 tedy cca 3 stupně. A vlastně
podle očekávání tato triviální metoda má své slabiny. Pokud robot najíždí
hodně šikmo, tak vedle mantinelu a přední stěny krabice ještě vidím jeden bok.
To by až tak nevadilo, jenom je třeba revidovat „řetěz”, který roh
„uřízne”. Pokusný kód je v
osgar/lib/scan_feature.py.
8. říjen 2018 — Brute force detect_box() (zbývají 4dny)
Ráno jsem změnil názor na detekci krabice a přešel na hrubou sílu. Pro každý
bod laserového scanu se ptám, zda může být středem krabice? Box má definovaný
rozměr 40cm x 30cm a z naměřené vzdálenosti mohu spočítat kolik měření by
mohla krabice maximálně protínat (math.asin(200/dist) pro dist v
původních milimetrech). Toto číslo vydělím dvěma a získám angle_step. Body
odpovídající měření -angle_step a +angle_step proložím přímku a ptám
se, zda můj vstupní střed je dostatečně blízko (zda leží na přímce). Pokud ano,
tak zkusím ještě -3*angle_step a +3*angle_step, že jsou 20cm až 40cm
za přímkou. Pokud ano, tak to může být bod přední strany krabice.
Toto fungovalo celkem dobře pro skoro kolmé nájezdy, ale pro 45 stupňový
nikoliv (krabice je vidět poměrně výrazně z boku a na druhé straně je mantinel
zastíněný … a pak končí lavička, což je náš testovací problém, nikoliv
očekávaná SICK aréna). Ošidil jsem to tak, že jsem přidal ještě další test jak
dopadne bod -4*angle_step a +4*angle_step — pokud celkově alespoň dva
body jsou na očekávaném zadním mantinelu, tak testovaný střed akceptuji.
Takovýchto bodů vyjde více (většinou), a tak z nich vyberu medián.
Navigaci na pohyblivý cíl jsem ošidil ještě více: definuji tři sektory vlevo,
střed a vpravo, kde zjišťuji nejbližší překážku. Pokud je vlevo zatáčím vlevo,
pokud na středu jedu rovně a je-li vpravo, tak zatáčím doprava. Rychlost
konstantní (zatím pomalá 0.2m/s, tj. jako jede transportér).
Doufal jsem, že se touto dobou (23:00) budu vědet, jak dopadla dnešní výměna
baterií a možná i kamery, ale vypadá to až na zítřek …
9. říjen 2018 — Nové baterky, kamera a počítač (zbývají 3dny)
Včera Tomáš s Jakubem vyměnili baterky. Staré měly dokonce nálepku
robotika.cz a byly z roku 2014 … ale kupodivu nebyly tak špatné!
Tj. stále nevěřím, že jsme problém vyřešili.
Kamera se ale s novým zdrojem napájení nijak nezlepšila a tak jsme ji vyměnili.
Obrázky jsou větší, ale už se na ně dá koukat a červené koule jsou opravdu
červené. (viz dnešní video ver1)
Po několika testech jsem dal Eduro na nabíječku a počítač APU2 se resetoval —
ono se resetovalo úplně všechno, včetně kamery, kde jsem probliknutí
zaregistroval. Co mne ale hrubě nepotěšilo byl následující obrázek:
 rozbitý filesystém |
Tak jsem to promazal, znova vyrobil lokální bare repozitory a po cca 20min
(?) jsme mohli pokračovat v testování. Závěr — před připojením na nabíječku
je třeba vše vždy vypnout :-(
Jinak první test byl hrozný:
- přepínač barvy byl zase prohozený (tentokrát červená a modrá) 0ec55e8 (mám pocit, že i ten kabel je obráceně …)
- u transportéru místo doprava zatáčel doleva 69900fc
- při návratu na „základnu” se několikrát resetovaly motory a Eduro sebou trošku škubalo
Ono už cesta metrem byla taková předehra — zkoušel jsem si přehrávat
jednotlivé logy a can nefungoval kvůli závěrečnému (nedeterministickému)
přepnutí do pre-operation, eduro jsem řešil to prohození kabelu a výběru
barev, laser strašně dlouho trval, protože je tam sleep a
pull request není (a do SICKa
nebude) dořešen …
Nic, konec naříkání … (asi mám dost, teď jsem pushnul všechny větve na
github, protože mi zůstal zatržený checkbox z toho obnovování repozitory na
APU2, sigh).
Ze "zajímavostí":
- již v prvních pokusech Eduro zastavovalo příliš brzo, protože rohy/hrany generují duchy a když je blíže jak 20cm STOP
- jízda na transportér jako nejbližší překážku není ideální, protože někdy je blíž zeď
- trénovat nájezdy pod 45 stupni mají smysl … robot tak několikrát zabloudil
- laser je vlevo a ruka vpravo a jsou od sebe dost vzdálení na to, aby navigace z laseru špatně navedla ruku (prostě posun je nutný vzít v úvahu)
- detekce krabice asi celkem fungovala, jenom zadřela APU2 počítač (divné je, že s APU3 to ani jednou motory neresetovalo, ale mohla to být jenom shoda okolností)
- Standa s MartinemS připravili super testovací plochu, jenom se bojím, že nás ostatní uživatelé haly proklejí a bude se to v pátek řešit na katedrové schůzi …
10. říjen 2018 — Podlaha (zbývají 2dny)
Dnes jsem začal vizualizací logů ze včerejška (konkrétně to s
videem ver1). Obrázek mne překvapil, ale jenom
částečně:
Eduro vidí podlahu na cca 3 metrech! Navíc je to celé trošku nakloněné vpravo,
tj. naklání ho nejspíše konstrukce ruky. Je to cena za nízko posazený laser
(12.5cm je střed), ale pokud by byl vysoko, tak neuvidí storage box a
testování by bylo možné pouze u 7 metrů dlouhé stěny. Jedním z důsledků je, že
transportér není vidět pořád, ale pouze v relativně malém okolí.
Druhé překvapení bylo, když jsem si přehrával
eduro-181009_204921.log
— ZeroDivisionError: float division by zero?! Pak jsem si vzpomněl, že v
jedné jízdě mi to celé nějak popadalo (spousta mrtvých vláken a tedy tuna
hlášek) a opravdu tam mezi tím byla i ta týkající se dělení nulou.
Důvodem bylo měření 17528mm, kdy opravdu půlka půlky krabice odpovídá 0.326888
stupňů a s rozlišením 1/3 stupně a oříznutím na int dostanu 0. Fixed.
11. říjen 2018 — Méně je někdy více (zbývá 1den)
Dnes to pěkně jezdilo snad jenom MARTům (snad
se David nebude zlobit za zveřejnění unlisted videa). Je zase půlnoc, tj.
dnes to asi nestihnu ani sepsat … a je to bída, co vám budu povídat. Člověk
stárne a měkne a když neudělá některá hrubší rozhodnutí, tak jsou z toho jen
všichni zklamaný :-( …
Začal bych včerejší telekonferencí, kdy Zbyňkovi i Jirkovi nebylo moc jasné, co
screenshot z minula znamená, ale že je tam bílý pruh a podivný titulek. Na
rovinu ten pruh jsem vůbec nezaznamenal a je to důsledek vykreslení obdélníku
na záporných souřadnicích — Pygame ho
prostě posunul na nulu.
Původ nesmyslného titulku jsem věděl až moc dobře … posledních 10let jsme
měli obrázky v jednotlivých souborech, ale s novým OSGAR logováním toto opadá a
hack byl, že místo jména jsem měl rovnou buffer se zabaleným JPEGem. Řešit
takové blbosti v předvečer bitvy?! … tak jsem to alespoň odstranil, ať to
„neruší”.
To bylo zahřívací kolo. Ve vlaku jsem pro změnu opravil detekci
startovacího kabelu (koukám na
129 commitů a řekl
bych, že už se to vymklo a dostat to do masteru bude těžké), předělal
posílání rychlosti na int (ha, už je půlnoc), protože mi neseděly
floaty z Edura při přehrávání logů (něco podobného jsem řešil na
lodičce) … jinak potvrzuji, že verze jsou jinak stejné:
root@voyage:~# python Python 3.6.0 |Continuum Analytics, Inc.| (default, Dec 23 2016, 12:22:00) [GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import msgpack >>> msgpack.version (0, 5, 6) M:\git\osgar>python Python 3.6.2 (v3.6.2:5fd33b5, Jul 8 2017, 04:57:36) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import msgpack >>> msgpack.version (0, 5, 6)
… ale verze Pythonu je trošku jiná — no jak jsem říkal včera, zkoumat toto
budu až na cestě zpět z Německa.
Pak jsem zkusil trošku optimalizovat detekci boxu, ale napsal jsem to do jiné
funkce a špatně … bez unittestu asi brzy „skončím na dlažbě”, hrůza.
Přišel jsem na to vlastně přes python -m cProfile -s cumtime, kdy se
počet volání nijak nezměnil?! No přechod z 270 stupňů na 180 zrychlil kód na
notebooku jen o 1/15 … resp. místo 15s referenční test trval 14s … nic
převratného.
Pak jsem konečně zapojil offset polohy laseru. Včera jsme se s Jirkou bavili,
že to vlastně úplně nepatří/nesedí na místo konfigurace TCP, ale tam, kde se
scany zpracovávají, což je momentálně pouze aplikace. Je to tam. Jak moc je
to dobře ještě nevím a např. do vieweru to zapojené není. Pěkný důsledek byl,
že Eduro již najíždělo na střed krabice a nikoliv aby laser byl na středu.
Pozici ruky jsem sice do konfigurace vyplnil, ale zatím vlastně nijak
nezohlednil.
Když jsem přijel na CZU, tak tam Eduro nebylo. Měl ho Standa v dílně a montoval
na něj brutální konstrukci na nabírání všech devíti míčků najednou. Ano, ptal
se mne v úterý 2x a já to nezakázal … jen jsem si myslel, že na to nebude
mít čas (do Německa nakonec totiž nejde). Přiznám se, že i mne mamon zlákal
a to byla chyba :-(, za kterou asi zítra (když už je pátek) zaplatíme. Dorazil
nakonec i Tomáš s relátkama na vypínání tohoto magneto-monstra … ale na
zapojení nedošlo. Navíc nás v 22h vyhodili ze školy (nějaká změna politiky),
takže jsme to ani nezkoušeli. Jako plus bych bral, že teď máme zálohu za
Arudino na vypínání magnetů přes CAN, kdyby se něco pokazilo … no nebudu
citovat Muphyho zákony
(jak jsem teď dohledával link, tak nad prvním zákonem jsem se musel usmát —
už si je asi nepamatuji: Jestliže jde vše podle plánu, stala se někde
chyba.)
Tak co dál? Asi je znám důvod resetu motorů na Eduru — je to watchdog z
„malého Edura”, které ještě mohlo jezdit až 4m/s a přišlo nám, že chyba v
programu by mohla být fatální a robot by mohl zdrhnout. Teď, když se řídící
program trošku moc zamyslí nad tím laserovým scanem u krabice, tak:
0:02:58.926802 ('0x201', ['0xcb', '0x3', '0x2d', '0x4'])
0:02:58.938039 ('0x201', ['0xd4', '0x3', '0x24', '0x4'])
0:02:59.028251 ('0x201', ['0xd4', '0x3', '0x24', '0x4'])
0:02:59.083863 ('0x201', ['0xd4', '0x3', '0x24', '0x4'])
0:02:59.089301 ('0x201', ['0xd4', '0x3', '0x24', '0x4'])
0:02:59.181230 ('0x201', ['0xd4', '0x3', '0x24', '0x4'])
0:02:59.183149 ('0x201', ['0xe7', '0x3', '0x11', '0x4'])
0:02:59.412628 ('0x201', ['0xe7', '0x3', '0x11', '0x4'])
0:02:59.414627 ('0x201', ['0xe2', '0x3', '0x16', '0x4'])
což jsou časy, které úplně neodpovídají 20Hz (50ms). Asi každý druhý scan budu
ignorovat, ať se stihne „nadechnout”. Uvidíme.
Asi timeout … chtěl jsem ještě skupinové foto a myšlenku „virtuálního laseru
vpravo”, ale to až zítra, jestli to bude alespoň trošku fungovat.
python osgar\logger.py –stream camera.raw eduro-181011_182810.log -i 220 > group-photo.jpg
p.s. on dnes asi nikdo nespí?! Ještě jedno video od Davida …
12. říjen 2018 — bus.publish (zbývá 26hodin)
Nevím, jak dnes budu na web reportovat, ale chtěl jsem se po ránu podělit o
dobré zprávy. Resp. je typ popostrčení, který vám otevře oči. Motory se
resetují, co s tím? Je to přetížené a je tedy nutné to zrychlit nebo omezit
frekvenci zpracovávaných skenů. Jak ale poznám, že nestíhám? Až do včerejška
nijak, ale triviálním
rozšířením
bus.publis() už ano. … prostě, když něco zveřejníte přes
bus.publish(), tak se v odpovědi dozvíte „kolik je hodin?”. Čas je
definovaný sběrnicí, resp. je to časová zámka uložení zprávy do logu. Pak máte
jak čas senzorů, tak čas vaší reakce a pokud je rozdíl příliš velký, tak to
můžete nějak vzít v úvahu:
0:00:09.475444 — START — 0:00:09.475444 — LOOP 0 — 0:00:09.475444 catch_transporter - ver1 0:00:12.522903 go_straight 1.0 [0.0, 0.0, 0.0005235987755982988] 0:00:44.523313 go_straight -1.0 [2.038, -0.684, 0.3078760800517997] 0:00:49.874231 turn 180.0 0:00:54.723206 stop at 0:00:00.402148 0:00:54.723206 approach_box Queue delay: 0:00:00.101231 Queue delay: 0:00:00.100362 Queue delay: 0:00:00.100122 Queue delay: 0:00:00.102373 Queue delay: 0:00:00.100764 Queue delay: 0:00:00.104890 Queue delay: 0:00:00.101579 Queue delay: 0:00:00.100030 0:01:02.951894 drop ball 1 + 2 0:01:05.971651 drop ball END
Toto asi nikdo jiný neocení, ale pro mne to je ten „šťouch” proč se s touto
soutěží tak zbytečně stresuji. Vás asi spíše zajímá toto:
… jo, všichni bychom potřebovali ještě nějaký extra čas … (jinak
Comenius University je kombinovaný tým Smelého Zajka a Istrobotics.
Pavol P. psal, že robot sa vola Kocúr Mikeš
https://github.com/Robotics-DAI-FMFI-UK/mikes-generic)
18:00 — No comment (zbývá 16hodin)
Řekl bych, že mne po posledních deseti hodinách energie zcela opustila. Viděl
jsem krátce po sobě 2x reset počítače po odblokování STOP tlačítka, trik s
počítáním zpoždění na vstupní frontě modulu/aplikaci s resety motorů
nepomohl, monstrózní konstrukci jsme v 15:36 od montovali a složili do krabic.
Arduino se občas resetuje a nehýbe se servy ani nevypíná magnety :-( … jestli
tam také není vazba na „power management” … no to je spíše hysterický
smích.
Z „vtipných” pozorování např. fakt, že používané magnety mají černý a červený
kabel a v té mega-variantě jsou přímo před kamerou — ne, že by na tom
záleželo …
13. říjen 2018 — Hrad - offline (GAME OVER)
 hrad po ránu |
Ráno to bylo fajn — na místo soutěže jsme dorazili okolo deváté hodiny, potkali
organizátory Deflefa a Andreu, a přestože oficiální otevření bylo až v 10:00, tak nás
pustili dál, ať si posloužíme kafem. Ideální začátek.
V 9:45 otevřeli soutěžní halu. Rovnou jsem popohnal Jakuba s MartinemS, aby
vše proměřili. Nakonec jsme vlastně potřebovali pouze dvě měření: vzdálenost od
storage boxu k navigační čáře a výšku horní strany koulí na transportéru. Všechny
týmy startovaly z obou pozic (levá a pravá) a jak měření ukázalo, vzdálenosti se lišily
o 4.5cm. Eduro Team byl hned v prvním zápase vlevo (při pohledu od tribuny),
takže po tomto zjištění jsme všechny testy dělali na této půlce.
Můj první dojem byl, že hrací prostor není příliš velký?! Transportér se
pohyboval necelý metr a půl před robotem, takže ver1 s šikmým výjezdem
následovaným followme() šla hned „přes palubu”. I strategie ver2 s
blokováním transportéru se jevila zbytečná — transportér projížděl i dost
natěsno od překážek/robotů a každé jeho zpomalení znamenalo méně cyklů a šancí
získat více koulí. Celou letošní soutěž jsme tedy nakonec odjeli s ver0:
- popojeď 1.32m (případně 1.32 - 0.045 pro pravou stranu)
- čekej
- couvej 1m
- otoč se o 180 stupňů
- popojeď 0.57m
- vypni magnety
S takto složitým kódem se dalo pracovat, ale do ničeho složitějšího bych se
neodvažoval na místě zasahovat.
První problém bylo čekání — jak dlouho má robot čekat? Nakonec jsme limit
nastavili na 5 minut (jedno soutěžní kolo trvalo 10 minut) s myšlenkou, že
pokud transportér nedorazil během tak strašně dlouhé doby, asi jsme něco udělali
špatně a pro případ, že náhodou máme nabrané koule, je raději odhodíme.
Zapojili jsme sledování transportéru a jakmile se objevil blíž než 0.5 metru
vpravo od robota (pohyboval se po směru hodinových ručiček), tak se spustil
druhý timeout nastavený na 15s. Následně si robot couvl, otočil se a vyhodil.
Co se dělo (a viděl jsem to už v Praze) bylo, že někdy pravý magnet vůbec
nesepnul a chycená koule v něm zůstala. To byla TOP PRIORITA, protože bez
spolehlivého vyhazování není šance bodovat. Jirka s MartinemS zkontrolovali
kabeláž, drátek v čokoládě znova utáhli, ale žádný zjevný problém nenašli. Já
jen mohl z logu potvrdit, že Arduino na ovládání ruku, reportovalo přijetí
příkazu k sepnutí obou magnetů.
Další problém bylo občasné (někdy nechtěně, někdy nutné) stisknutí STOP
tlačítka. Po zkušenostech z testování na domácí půdě jsme z robota vždy
zkopírovali všechny logy a raději ho vypnuli. Tato akce vždy trvala
minimálně 5min (pomalý halt i boot up), což bylo nepříjemné, ale stále
lepší než pokažený disk.
Co úplně nefungovalo, bylo nabírání pomocí magnetů — v plném transportéru
koule do sebe ťukaly a několikrát nám vypadly. Navíc při nepřesném najetí se
magnety nechytly vůbec. Mimochodem laser nedetekoval ani spodní část
transportéru ani horní krabici. Viděli jsme pouze 4 nožičky a spojovací
kabely.
Řešili jsme, zda ruku nefixovat do konkrétní polohy, protože pozice lišící se i
o 3mm byly pro nabírání fatální. Finální kód pro první jízdu byl s pohyblivou
rukou, kdy jsme si odpočítali 1.5s a pak s rukou pohnuli dolu a nahoru.
A konečně jsme řešili narůstající chybu odometrie, kdy na storage box jsme
najížděli až na dotek a následně byl transportér příliš daleko.
V prvním zápase jsme skórovali 2 míčky, ! mission completed !
Vzhledem k tomu, že náš druhý soupeř Gymnázim nedorazil (včera odpálili
elektroniku), tak Def tabulku zápasů upravil a startovali jsme až jako
poslední. Tj. vlastně maximální čas pro nějaké taktizování/úpravy.
Došlo ke změně mechaniky i SW. Dvě koule vedle sebe v této strategii si vlastně
překážely a tak MartinS levý magnet vystrčil o řadu dopředu. V kódu jsme
nakonec zapojili detekci vykládací krabice, ale aplikovali jsme to až na
třetí vyhození. Na Jirkovo doporučení jsme také trošku taktizovali s umístěním
Edura na startu — posun o 5cm vpravo vedl častěji k úspěšnému výhozu.
Vlastně jsme ještě uměle posunuli navigaci na krabici o 10cm vlevo, aby
magnety byly nad středem.
V druhé jízdě jsme bodovali celkově 3 míčky a čtvrtý, který nás dělil od
druhého místa, jsme odhodili až několik sekund po skončení.
(leze mi po monitoru nějaký hmyz a je 22:46, tak pokračování zítra v autě)
14. říjen 2018 — Hrad - offline (cont.)
 hradní věž |
No jednak tam místo jednoho hlavního vlákna jsou hned 4 (pro tuto podmnožinu) a
zatím není implementované „spřažení” s pevnou prioritou. Teď nad ránem mi ale
došel další „detail”, který v této kauze nejspíše hraje roli. Čtení ze
sériového portu je s timeoutem, protože potřebuji občas zjišťovat, jestli
celý program nemá už skončit. Důsledkem je opoždění zpracování minimálně o ten
timeout. Přestože se bavím s CAN bridge modulem na rychlosti
115200bps, mám
self.com.timeout = config.get('timeout', 0.01) # default expects updates < 100Hz
a v konfiguraci eduro-sick2018.json žádný speciální timeout nastavený
nemám. Z 50ms cyklu tedy vyplítvám 10ms jenom na prvním čtení. Je fakt, že tím
zpracování vlastně jenom posunu, takže pouze prodlužuji reakční dobu ale
nikoliv délku cyklu?? No moc mi to (po ránu) nemyslí. :-(
OK, jsme zpátky na cestě a je tedy nejvyšší čas si přečíst, co jsem to včera a
ráno sepisoval a doplnit fotky. Zde je navíc alespoň výsledková listina:
15. říjen 2018 — Soutěž a video
Letošní soutěž byla zajímavá — přijde mi zábavné, jaké „tipy” se vyplnili a jaké ne?
Robot, který dá alespoň jeden bod, bude „na bedně”
True — toto se vyplnilo. Jak mi psal Jirka, i kdyby nám nakonec ten pravý magnet
nefungoval a vyhodili bychom jenom jeden jediný míček pomocí levého magnetu,
tak to stále bylo na třetí místo.
Když se podíváte na výsledkovou listinu, tak je tam i mnoho záporných bodů.
When the transporter finds a vehicle (or any other obstacle) in its path, it
will decelerate in order to avoid a collision. The path has to be cleared,
however, as fast as possible. If the transporter comes to a halt for more than
30 seconds, the party responsible scores one penalty point for every further
half minute (or parts thereof), after 2 minutes the obstructive vehicle
will be disqualified (for this run) and removed from the arena.
Hmm, tak on transportér mohl zpomalovat … tak to jsme měli kliku. V každém
případě za každou půlminutu blokování transportéru byl trestný bod a po dvou
minutách diskvalifikace (-250 bodů). Tým „Gymnázium” nedorazil (-500 bodů). Ve
zkratce bodování je směrodatné pouze u prvních třech týmů s nenulovým skóre a
další místa jsou spíše zavádějící.
Soutěž bude nezajímavá, protože to nikomu nebude fungovat
False - soutěž byla zajímavá, protože to skoro nikomu nefungovalo. Ta
úloha byla na rovinu hodně těžká a v těch 3h (původně jsem myslel, že jsou
jenom 2h) testování s dalšími jedenácti týmy na hřišti je bez šance naladit jen
o trošku složitější strategii.
Díky pohyblivému transportéru se na hřišti stále něco dělo, a aby robot získal
bod, tak muselo dojít k interakci. Vítězný tým RT-Lions/Universität
Reulingen s chapadlem (mimochodem, ten robot měl 250kg!) říkal, že
doma během testování v průměru sbírali 40 koulí … tady jednou vše vysypali mimo
storage box (viz Jirkovo video níže) a kvůli penále se jím nepočítalo
plných 8 (možná 9) míčku v kole druhém. Jak se tam berou půlbody se budu muset
zeptat.
Pěkné byly i různé „tanečky”, kdy si roboti popletli soupeře s transportérem.
MART nebude bodovat
True a zase mne to mrzí :-(. Tentokrát byla ve hře divoká karta: Martin
Locker, který udělal shrabovák na sběr koulí a teoreticky bylo tedy možné v
jednom kole nabrat všech 9 míčků. Ale MartinL má vedle spolehlivé elektroniky
a mechaniky (viz např. druhé místo na mezinárodním
Eurobotu 2005) i tvrdou disciplínu, která matfyzákům chybí. Také je třeba
hledat nejjednodušší (což je zároveň často i nejspolehlivější) řešení. I
Eduro, kdyby mělo spolehlivou ver0 s nabráním dvou míčku pro každý průjezd
transportéru, by mělo šanci s deseti míčky na vítězství …
Podobná situace byla u kombinace „Smelého Zajka” s „Istrobotics” — snad
získám více detailu, co se tam přesně dělo.
Transportér nepřežije více jak jeden zápas
False — vydržel celou soutěž. Vlastně nevím, zda byla k dispozici i
náhrada, ale teď bych tipoval, že ano. Transportér nebyl „žádný srab” a
přibližoval se opravdu skoro na milimetry. Jezdil pěkně a detekce čáry pomocí
laseru fungovala spolehlivě. Ve druhém (?) kole do něj jeden z robotu opravdu
nepěkně najel, ale nějak to rozdýchal. A když to 250kilové monstrum transportér
zamáčklo do země, tak i potom se dal do pohybu. Tady organizátoři rozhodně
bodovali!
Drobné zajímavosti
Vedle drsného monstra vítězů stály za shlédnutí nejrůznější použité konstrukce
naběráků. Jsem rád, že se Jirkovi podařilo jich několik zachytit v akci. Mně
utkvělo pár momentů:
- Short Circuits Prague konečně nabere míček, ale moc dlouho si ho robot neužil, protože mu ho oponent vyrazil z ruky.
- Slovenský Comenius University číhá v druhé jízdě na transportér, ale soupeř Furtwangen University vždy zablokuje cestu na tak dlouho, že to slovenský robot vzdá, vrátí se na základnu a těsně se mine s transportérem. Toto se opakovalo snad 5x — krásně sladěná choreografie.
- Zed – Who is Zed? Zed is dead baby (ne promiň Honzo, to je asi špatná asociace s Pulp Fiction), ale když jsem viděl robota na kolech na ležato (a nebude prý létat jako drony), tak … nejel.
16. říjen 2018 — Short Circuits Prague video
Zápas s Duke, Uni + HS Osnabrück. Za zmínku stojí záběr v čase 1:17, kdy je
uprostřed snímku 95 letá paní
Gisela
Sick, manželka zakladatele firmy.
18. říjen 2018 — Eduro video
Přemýšlím, jak zveřejnit video záznam z Edura, který trvá přes 10 minut a
většinu času se tam nic neděje … ale bylo by pěkné vidět vše, jen „nudné”
úseky trošku zrychlit. Inspiroval jsem se článkem
Image
Difference with OpenCV and Python a použil funkci
skimage.measure.compare_ssim.
Takto vypadá graf na začátku videa:
No asi bude nejjednodušší to upravit ručně, ale pro začátek
viz nekoukatelné referenční 15 minutové (!) video.
Příklad počítání podobnosti a psaní do obrázku/videa je pak v tomto
commitu.
Večer/zítra snad udělám revizi.
p.s. jinak kompletní logy jsem uploadoval hned po návratu:
- eduro-181013_141037.log — první zápas (587MB)
- eduro-181013_164907.log — druhý zápas (554MB)
(zajímalo by mne, jestli vůbec někoho OSGAR logy zajímají ... když tak mi napište)
p.s.2 Eduro Team - 2nd Run (video po optimalizaci) … 5x zrychleno pro podobnost větší než 0.95
p.s.3 Eduro Team - 1st Run … aneb ten první
méně úspěšný (dva body, jeden vypadlý míček). Ale je to asi dobré pro porovnání
vidět, že i za těch pár hodin tam byl nějaký posun k lepšímu.