Field Robot 2014
fandorama blog
Za necelý měsíc se v Německu koná další ročník soutěže Field Robot Event. Pro případné zájemce o detailní informace z přípravy a samotné soutěže vznikl tento mini-fandorama projekt. Na FRE máme v úmyslu jet s robotem FireAnt a AR Drone 2.0 (Heidi a Isabelle) Blog update: 23/6 — FRE 2014 video
Toto je další z fandorama blogů o přípravě na soutěž
Field Robot 2014. Zbývá necelý měsíc a pokud by to někoho zajímalo, tak
bychom zde prezentovali průběžné výsledky a problémy.
Pokud máte zájem, aby na tomto místě vznikl blog, včetně reportáže z Německa,
tak zde je odpovídající fandorama link:
Odkazy:
- Stránky soutěže: https://fre2014.uni-hohenheim.de/
Blog
29. květen 2014 — numpy Green, Eduro a 3 dny
Zatím to vypadá, že „polní robotika” nikoho moc nezajímá :-(. Do konce
fandorama projektu
zbývají 3 dny (do soutěže pak necelých 20), tak jenom krátká zpráva co je
nového…
numpy Green
Minulý týden lítal Jakub s Isabelle nad různými políčky: jahody, brambory,
květák … s tím, že soutěžní kukuřice ještě není dostatečně vzrostlá. Na
výsledné snímky jsem chtěl použít můj oblíbený detektor zelené, kdy v RGB
obrázku je složka G > 1.2*R a G > 1.2*B. Cvičně jsem si to
napsal v Pythonu
jako ultra pomalou referenci s tím, že je to dobrá motivace k prozkoumání
numpy polí. Proč? OpenCV2 používá numpy jako datovou strukturu pro
obrázky, matice, kontury atd a nebylo by tedy nutné nic speciálního alokovat
nebo složitě převádět.
K mému velkému překvapení to nebylo až tak zlé . Hlavní inspirace pochází ze
stránky
kde je rovnou ke stažení
Cext_v2.tar.gz.
V headeru je třeba dopsat
static PyObject *rowx2_v2(PyObject *self, PyObject *args);
jak v komentářích píše Paul Ivanov. Pro kompilaci pod windows jsem ještě
recykloval
setup.py, kde
bylo nutné přidat cestu na Céčkové hlavičky numpy (jsou přímo součastí
instalace numpy). Visual Studio mám nainstalované, takže stačilo pouze
setup.py build
a pak
setup.py install
a bylo to . Výsledný obrázek vypadá např. takto:
Funkční příklad pak naleznete na
githubu.
Eduro RTK GNSS
Vypadá to na další „znovuzrození” Edura. Od organizátorů FRE2014 totiž přišlo
upřesnění k Task3, kde robot má detekovat žluté golfové míčky (=plevel) a
vytvořit mapu s pomocí zapůjčené GPS s korekcí. Bude se jednat o
Trimble
AgGPS RTK Base 450, což vypadá na pěknou hračku, ale z dokumentace bych
citoval: GPS receiver, radio, and battery are contained in a robust unit
weighing only 3.64 lbs (1.65 kg) making it a breeze to set up quickly anywhere
on your farm. Těchto 1.65kg mravence položí a drona nemá šanci vzlétnout …
do hry tedy zase vstupuje staré dobré Eduro (Maxi) .
Eduro dostalo nové baterky (od
natáčení
v listopadu se to samo kupodivu nezlepšilo). Po jejich výměně už můžete vidět
první chodbové snímky:
Vidíte na obrázku 3 míčky? No už se těším, jak je budeme detekovat mezi
nažloutlými listy kukuřice .
Pokud by někoho zajímaly zdrojové kódy pro robota Eduro, tak už má také vlastní
repository:
Do konce fandorama
projektu zbývají 3 dny, tak jsem opravdu zvědavý, jestli podobné informace
někoho zajímají … .
2. červen 2014 — cvideo
Psal mi Pavel S., ať to s tímto fandorama projektem ještě nevzdávám … a tak
jsem přidal ješte jeden extra den …
Po detekci zelené v Céčku, kombinované s numpy modulem, jsem se konečně
rozhoupal pro „vlastní” dekódování videa. Nyní mám plnou kontrolu nad tím
kolik snímků po I-frame dekóduji, žádná berlička s dočasným souborem
tmp.bin pro OpenCV2 … O víkendu jsem to zkusil/ladil na zahradě a mám dvě
zprávy. Ta dobrá je, že to funguje pěkně. A ta špatná, že výpadky videa v Písku
na RORO14 s tím neměly nic společného.
Stále se zpracování videa po několika metrech samo ukončí :-(.
Pokud by vás zajímaly zdrojáky, tak
zde jsou věci k cvideo
(ale ještě to budu muset uklidit — chci minimálně udělat automatizovaný
cvideo.init(), bez jehož zavolání se to teď položí) a
příklad
použití v rr_drone.py.
p.s. přidal jsem vám jeden snímek (takto si představuji cestičku na zahradě
), ale ten černý proužek dole se mi nelíbí :-( … TODO.
4. červen 2014 — Eduro Revival (12dní)
Nejprve díky Pavlovi S. za podporu tohoto blogu/článku — existuje tedy
alespoň jeden člověk, kterého by to zajímalo a s touto myšlenkou se mi to píše
daleko lépe .
Včera přišla odpověď od FRE organizátorů. Přestože byla samý mandatory,
only, not possible, not allowed, tak to lze pozitivně interpretovat,
že to výrazně zjednodušuje další rozhodování. Ve zkratce:
- použití AgGPS (co váží 1.5kg) je povinné
- pro úlohy 1, 2 a 3 je nutné používat stejného robota
- externí notebook a létající roboti nejsou povoleni (úloha 1, 2 a 3)
Závěr? Přestože se „smečka” robotů rozrostla (Eduro, 2x
FireAnt, Heidi, Isabelle,
Husky), tak nasadit lze pouze Eduro.
Musím přiznat, že i po letech (Eduru teď bude 7 let) toho robota mám rád a mrzí
mne, že oba jeho tvůrci (Honza a Tomáš) ho považují za „mrtvou platformu”.
Včera jsem s Edurem testoval cca 1h na políčku. HW fungoval dobře a SW měl
staré mouchy, na které jsem za ten rok už úspěšně zapomněl . To selektivní
zapomínání je fakt úžasná věc!
Test1 — základní projíždění řádků. Na konci má robot odbočit do další
řádky a směr tohoto posunu je dán přepínačem modrá/červená (z prapůvodního
Eurobota na výběr barvy). Měl jsem jen 3 řádky na
testování, ale to stačilo. Z 1 do 2 to šlo, ale z 2 do 1 snad pokaždé naboural.
K navigaci se používá laser, ze kterého si dělám „ASCII Art” a vybírám
vhodnou skulinu. Zde je funkční příklad:
===== ACTION -1 ===== battery: 24.34 ' X ..X...x..x xx.. C ....xxx x XX XX ' ' X ..X...x..x xx... C ....xxx x XX XX ' ' X ...X ..X. x xx... C ....xxxx xx X X ' ' XX . XX .Xx.xx xx.. C ...xxx.x x X X ' ' X ..X. .X..x xxx.. C ...xx.x x X X ' ' XX .X ..XX..x xxx.. C ..xxx.x xX XX XX ' ' X .X ..X...x x.x... C.....xx x.x X X X ' ' X XX.. X. .x. xxx.. C ..xx x x Xx XX X ' ' X X....X...x xxxx.. C ..xx x x XX X X ' ' X X. ..X.. X..x xx... C ..xxx x xx X X X' ' X X...X ...X..xxxxxx.. C ..xxx x. xx X XX ' ' x X ..X...XX..Xx xx x.. C ..xxxx x X X X ' ' X .X.. .X ..X. xx x... C .xxx x x XX X X ' ' xx X. .Xx. .Xx.x x x... C ..xxx x xx X XX X' ' x X...XX ..xX.xXxx xx.. C ..xx x x X X X ' ' x XX..Xx. .XX..X.x. xx... C .xxx.x xx X XX X' ' xx x .XX.. XX .Xx x xxx.. C ..xxx x x X X ' ' x x .X... X...X..x. xxxx. C ...xxx x x XX X ' ' x x XX.. XX ..X..X.. xx x.. C ..xx.x xx X X X' ' xx X...X.. XX..Xx...x xxx.. C ...xxx x X X X ' 'xx X..XX.. X..XX...X xxxx.. C ..xx x x x XX XX ' ' x X.. X. .X .. X..xxxx.. C ..xx x xx x X X ' ' Xx..X...X. ..XX.x xxx.. C ..xxx.x x xX X XX ' ' X..X. .X.. .xX..x x xx. C....xx x.x xx XX X X ' ' X XX..X... .X..XX x xx.. C ....xx.x.x. X XX XX Xx'
Jedná se o úhlový sken (laser je nakloněn mírně dolů), kde 'X' je překážka do
50cm, 'x' do 1m, '.' do 1.5m a mezera volno. 'C' je pak střed, kam se
robot snaží navigovat. Laser
LMS
100 má záběr 270 stupňů s rozlišením půl stupně. Vybírá se minimum (větší než
0 == žádný odraz) pro skupinku deseti měření, tj. jedno písmenko odpovídá pěti
stupňům.
Příklad neúspěšné otočky vpravo, kdy ho hrouda trošku „vykolejila” vypadá takto:
laser: END OF ROW ' ..... .C. x.. .xx ... ' ' ..... ..C xx.. .x ... ' '...... .. C x.. .xx .. ' '..... ... C . x.. ..x .. ' ' ... ... C x... ..xx ... ' '... .. C xx.. .xx ... ' '.. ... C xx. .xx ... ' ' .... ..C xx.. ..xxx .... ' 28 2 30 ' .... ...C xx.. ..xx ... ' 28 1 29 !!!DANGER!!! PATH BLOCKED!!! 28 HACK 1 2 ' .x. . C xx.. ..xxx .... ' ' xx. C .. xx.. ..xxx .... ' ' xx. C ... xx.. ..xx ... ' ' xx. C....xx... ...xx ... ' ' xx. C ....xx.. ...xx ... ' RESET ROW (4.26, -0.83, -165.2), offset= None RESET_DIFF -14.7 ===== ACTION -1 ===== battery: 23.87 HACK 1 2 ' xx. ...C.xx... ...xx ... ' ' xx. C ... xx.. ...xx ... '
… a sám se přiznám, že to tam moc nevidím :-(. Ale z přehledovéno obrázku je
to zřejmé:
Co jsou ty HACK 1 2? Moc si to nepamatuji, ale myslím, že když C není v
úzké uličce, tak se nikam neposouvá a pokud by padlo do překážky, tak se vybere
nejbližší volný vlevo/vpravo … a to je asi také ten důvod, proč to selhalo.
Měl ještě trošku přetočit a vybrat si „uličku vpravo”.
Test2 — detekce žlutých golfových míčků. Už jsem to nevydržel a upravil
kód, kdy
modrá
byla vlastně žlutá. Na výstupu je počet žlutých pixelů, kde žlutá je teď
definovaná jako
bool Color::isYellow()
{
return r()>100 && g()>100 && (b() < 0.7* r()) && (b() < 0.7 * g());
}
Počítání jsem ještě rozdělil na
levou
a pravou půlku a
zapojil
do hlavního kódu.
Limit pro detekci jsem si nastavil z logů na 100 pixelů. Fungovalo to celkem
pěkně, až na to, že (a to je další věc co jsem od loňska zapomněl) byly
prohozené indikátory levá a pravá a ukazovalo se to snad o půl metru
později?! V
kódu je
logika na posunuté reportování (časově) a to o 1s (20 tiků, sigh). Detekuji-li
míčky hned u kola a jedu rychlosti 0.7m/s … hm, to by skoro vycházelo, ale
ještě nějaký čas trvá uložit a zpracovat obrázek a to bude ta chyba. Proto tam
asi nemám vzdálenost, ale pouze „převlečený” čas. OK
Test3 — detekce kolize. Pustil jsem Eduro s konfigurací pro „Advanced
Task”, postavil se mu do řádky a prásk, trošku to bolelo. Pak jsem to
zopakoval a to samé. Až snad napotřetí jsem se podíval do kódu a
return self.ver2( [0,-1,0,-1,2], detectWeeds = False, detectBlockedRow = False ) # Task2
Hmm, detectBlockedRow = False … už si vzpomínám. To bylo „manažerské
rozhodnutí”, že tak daleko v zadaném vzoru (FRE2013) robot nedojede a tak
nejistou blokaci cesty raději vypnu (velké listy slunečnice občas zakryly výhled
laseru, ale nebyly to překážky). Změna na True dost pomohla
8. červen 2014 — Změna pravidel?! (8dní)
V rámci nedělní pohody jsem si znova přečetl poslední (?) verzi pravidel z
konce května. A tak mne to vytočilo, že se nějak musím ventilovat … a zde je
ideální místo (tedy nejprve jsem napsal mail organizátorům). Jedna se o
Advanced task, tedy pokročilou úlohu, kde se má ukázat jak jsou ti roboti
chytří. V předešlé verzi pravidel bylo
The robot has to be placed back to the starting point and re-start the task without stopping the time, if - i) the robot enters the wrong row after the headland turning and - ii) if there is a manual intervention during the headland turning.
což odpovídalo mé představě a našim upraveným pravidlům z loňska. V květnové
verzi je ale During headland turning – after exiting the rows - to help the
robot finding the right row will be punished with a penalty of 5 meters..
WTF! Pět let se s nima dohadujeme, že je to na hlavu a už je to tam zase!
RESET ROW (4.26, -0.83, -165.2), offset= None
Tak alespoň pár pozitivních poznámek. Asi už chápu, proč otáčení vlevo:
RESET ROW (3.54, 0.12, 184.2), offset= None
fungovalo zatímco vpravo (viz titulek) selhalo. Eduro totiž plně nedotočilo (chybělo
15 stupňů) a tím pádem koukalo rovnou do tyček (reálná kukuřice zatím ještě moc
nevyrostla). Tj. v této situaci by se měl rozhodovat podle chyby v úhlu.
Nabíječka
Další podraz byla „chytrá nabíječka” (3-Stufen Automatik-Blei-Lader Art.
Nr. 900001 — link teď nemám). Má tři LEDky (červenou, oranžovou a zelenou)
s tím, že u červené nabíjí max proudem, oranžová je přechodový stav s postupným
snižováním proudu a zelená už je pouze udržovací proud. Když jsem ale Eduro dal
posledně na nabíječku, tak červená jen problikla, pak nějakou dobu (hodiny)
svítila oranžová a vypínal jsem to na zelené. Co bylo ale dost podezřelé, že
napětí po nabíjení bylo menší než před nabíjením!? A další zradu ukázal
jednoduchý pokus, kdy nabíječka nebyla vůbec zapojena — chovala se stejně.
Důvod? (za vyřešení záhady děkuji Honzovi z práce/HW oddělení ) …
překroucený a přerušený kabel uvnitř nabíječky … asi nějaký pozůstatek, kdy
Eduro chtělo zdrhnout, ale bylo ještě na nabíječce. Nebo někdo zakopl o
nabíjecí kabel. No snad to teď bude fungovat (vyzkouším až večer doma).
10. červen 2014 — Přejezdy mezi více řádky (6dní)
Řeším teď úlohu přejezdu mezi více řádky. To byla vždy největší slabina a tak
jsme v „Advanced Task” nikdy moc nebodovali (i když nějaká „kukuřice”
(trofej) z toho byla v tom zlatém roce 2010). Co je problém? Kukuřice nemusí
být moc vyrostlá a povrch políčka nemusí být moc rovný. Toto je důvod, proč je
laser nakloněný dolů, aby při průjezdu řádkou viděl na zemi alespoň něco.
Při přejezdu kolmo na řádky je to ale nevýhoda a do strany typicky už skoro nic
nevidí (rostlina je pod řeznou rovinou).
V roce 2009 jsme se domluvili na ver0, která
vůbec nebude zatáčet . Malé vzpomínkové foto na Explorera, které se Kamilovi
opravdu vyvedlo:
V roce 2010 jezdilo políčkem už Eduro Maxi a,
pokud si dobře pamatuji, bylo to čistě na odometrii. Tehdy kukuřice moc
nevyrostla a ji organizátoři doplňovali obarvenými dřevěnými tyčkami. Pro
laser to bylo naprosto ideální .
2012 to byly květináče s růžemi, ale čekal
nás podraz, kdy v Advanced Task mohou být až 1m díry (simulace nevyrostlé
kukuřice nebo prodaných růží) na koncích řádek! Tam přejezd naslepo opravdu
nefungoval.
Loni to byla bída, recyklace všeho, tj. teď
nalézám jisté pokusy ve funkci crossRows() — v rámci úklidu jsem jí
smazal a tím se to „trošku rozbilo” . Snažil jsem se udělat shluky, které
laserová měření patří k sobě, a to jednak podle vzdálenosti, v kombinaci s
úhlem, a dále podle monotónosti posloupnosti jednotlivých měření. Vzorkováno to
bylo nahrubo po pěti stupních, ale nevěřil jsem tomu ani loni a raději jel na
odometrii.
Psal jsem, že jinde je laser scan již předzpracovaný a bere se minimum v úhlu
pěti stupňů? Tyčky nebo rostliny jsou „bodové” tj. nedostanete krásné odrazy
jako od zdi a často vidíte skrz i do dalších řádků.
Tak co s tím „dálkovým přejezdem mezi řádky”? Optimální řešení by byla nějaká
kombinace odometrie s verifikací z laseru, případně i s detekcí odklonu od
konce řádek, tj. aby robot nenarazil u prvního přetočení, případně aby
neztratil kontakt s tou troškou co detekuje.
Letos bych se opřel především o předzpracovaná data, tj. ty skupiny po pěti
stupních = minimum z deseti měření. To má řádově větší šanci na úspěch než
jenom každé desáté měření. Dostanu např toto:
[10.0, 1.145, 1.255, 2.186, 1.415, 1.514, 1.643, 1.906, 2.136, 0.505, 0.637,
0.981, 1.481, 3.104, 3.066, 2.528, 2.106, 1.717, 1.371, 1.138, 0.966, 1.567,
0.835, 1.745, 1.428, 1.611, 1.629, 1.644, 1.663, 1.682, 1.628, 1.726, 1.782,
1.898, 2.003, 2.06, 2.004, 2.611, 2.972, 2.604, 2.57, 2.033, 1.997, 2.771,
4.248, 10.0, 10.0, 10.0, 10.0, 10.0, 10.0, 10.0, 10.0, 10.0, 10.0]
což odpovídá ASCII artu:
' .. . xxx. ..x x . C '
… já to prostě v těch zjednodušených znacích vidím lépe než v těch skutečných
číslech. Po levé straně jsou tedy dva shluky a ty bych chtěl spolehlivě
detekovat a průběžně sledovat.
Matematicky se jedná o lokální minima … jak je ale vhodně vybrat? Nechal jsem
si vypsat prvních pět hodnot pro utříděné pole včetně indexu:
print sorted([(x,i) for (i,x) in enumerate(self.robot.preprocessedLaser)])[:5] [(0.727, 9), (0.867, 10), (0.967, 20), (1.112, 19), (1.191, 2)] ' ... xx. ..x C ' [(0.73, 9), (0.878, 10), (0.986, 20), (1.116, 19), (1.178, 2)] ' ... xx. ...x C ' [(0.715, 9), (0.878, 10), (0.968, 20), (1.099, 19), (1.188, 2)] ' ... x.. ...x C ' [(0.722, 9), (0.964, 20), (1.039, 10), (1.12, 19), (1.174, 18)] ' ... xx.. ...x C ' [(0.712, 9), (0.941, 20), (0.976, 8), (1.042, 10), (1.097, 19)] ' ... xx. ...x C ' [(0.726, 8), (0.862, 9), (0.921, 20), (1.061, 19), (1.204, 18)] ' .. . xx. ...x . C ' [(0.74, 8), (0.873, 9), (0.897, 20), (1.058, 19), (1.236, 18)] ' .... xx.. ...x . C ' [(0.737, 7), (0.871, 20), (0.905, 8), (1.031, 19), (1.061, 9)] ' ... xx.. ..xx . C ' [(0.762, 7), (0.856, 19), (0.887, 8), (0.994, 18), (1.079, 17)] ' .. xx.. ..xx .. C ' [(0.756, 19), (0.757, 6), (0.897, 7), (0.911, 18), (1.057, 17)] '.. xx... ..xx .. C ' [(0.732, 18), (0.772, 5), (0.894, 17), (0.915, 6), (1.007, 16)] ' . xx.. .xxx ... C ' [(0.761, 18), (0.799, 5), (0.803, 17), (0.929, 6), (0.973, 16)] ' xx... xxx .... C ' [(0.729, 17), (0.765, 16), (0.826, 4), (0.945, 5), (0.967, 15)] ' xx. . .xx .......C....... ' [(0.702, 16), (0.751, 15), (0.887, 3), (0.985, 4), (1.111, 24)] ' x.. .. xx .........C....... ' [(0.558, 14), (0.814, 13), (0.912, 2), (1.014, 3), (1.065, 23)] ' xx.. . x .........C....... ' [(0.557, 13), (0.934, 2), (0.943, 1), (1.023, 23), (1.047, 3)] ' x.. .. x. ...xx....C...... ' [(0.521, 12), (0.935, 22), (0.971, 1), (0.989, 23), (1.068, 2)] ' ... .. xx ...x . C ... ' [(0.525, 11), (0.811, 12), (0.927, 22), (1.006, 1), (1.047, 21)] ' .... xx. ....x.. C .. ' [(0.515, 10), (0.625, 11), (0.884, 22), (1.026, 21), (1.103, 2)] ' .... Xxx. ...xx.. C ' [(0.486, 9), (0.502, 10), (0.802, 11), (0.87, 22), (0.976, 21)] ' .... xxx. ..x.x.. C ' [(0.513, 9), (0.641, 10), (0.834, 22), (0.979, 11), (0.988, 20)] ' .. . xxx. ..x x . C ' [(0.505, 9), (0.637, 10), (0.835, 22), (0.966, 20), (0.981, 11)]
… hm, možná trošku moc čísel … chtěl jsem ukázat, že první 3 nestačí a
naopak prvních 5 vypadá dostatečně. Stejně tak asi stačí blokovat okolí třech
sousedních měření.
OK, takže mám dvě nejbližší měření, které by snad neměly být ze stejné řádky.
Co dál? Rozumný nápad měl včera (ano, mezi tímto a předešlým odstavcem uteklo
24h) Jakub: proložit body přímkou, posunout jí o půl metru vpravo a podle toho
jet (viz
diff).
Ladil jsem to s Honzou C. a první pojízdný test skončil bouráním do židlí (na
políčko to je přeci jenom kousek a pravděpodobnost úspěchu zanedbatelná, takže
jsme zůstali nejprve testovat v hale). Co bylo příčinnou? Dva nejbližší body
byly utříděné podle vzdálenosti a navigační linie je orientovaná — prostě se
robot po chvíli chtěl otočit a jet po druhé straně židlí. Opraveno.
Po opravě se ale program místo assertu na změnu chování zacyklil :-(. Ono ta
navigační linie je ve skutečnosti navigační úsečka a když dojedete na její
konec, tak už se nic nevykonává. Protáhli jsme to na 2m a pak už Eduro začalo
pěkně objíždět jak simulované řádky pomocí židlí, tak i nebezpečně vypadající
stroje .
Další krok byl odpočítávání jednotlivých řádek. Dal jsem Honzovi za pravdu, že
se bude hodit pole detekovaných konců řádků v absolutních souřadnicích a když
už jich bude srovnatelně s počtem požadovaných přejezdů, robot zastaví, otočí
se o 90 stupňů a spustí zase navigaci v řádku. Tomu odpovídá
další
diff. Eduro trošku přejíždí, tak tam možná dáme otočku na místě. Chce to
reálný test na políčku. Včera se venku ale mezitím zešeřilo a budovu školy
jsme raději opustili, než se spustí automaticky časované alarmy. Nebude-li dnes
večer bouřka (5%?) je dnešní úkol jasný.
p.s. dostali jsme další verzi pravidel: ... after some discussion also with
some of you we again slightly modified the rules. Point 2.2 - Task 2 - We set
the penalty to for manual intervention on headland to 10 meters! This shall
avoid that teams go for a quick (!) and dirty (!) solution. ... … kdo to
byl ten some of you . Velké penále, ale žádné vracení na start — zatím
nevím co budeme dělat, až Eduro udělá chybu v půlce vzorce …
p.s.2 koukám, že mi Honza posíla
pull request na Eduro …
nakonec tu spolupráci přes github rozhýbáme! … ale co tím autor myslel
moc nechápu.
12. červen 2014 — Ničitel (4dny)
Už zase propadám „lehké” depresi. Včera jsme na políčko vyběhli za doprovodu
hřmění a lehkého deště, ale už i ten stačil k tomu, aby se písčitá zem začala na
Eduro nabalovat. I drobný důlek vedl při otáčce na místě k zaseknutí.
Detekované míčky byly reportované pozdě, i když stále v 0.75m vzdálenosti. A
hlavně z Edura nám vyrostl Ničitel! Kukuřice již povyrostla, ale těch
zlomených klasů a tyček :(. Do toho se rozhodl pípací modul, že si bude pípat
(chvíli to vypadalo, že robot vysílá nějaký S.O.S. signál?!) … no neměl jsem
na to moc nervy.
S detekcí jízdy podél řádků nastávaly dvě výrazně odlišné chyby:
- robot viděl i rostliny za sebou na druhé straně z řádku, který právě opustil
- robot neviděl malou rostlinu po boku z řádku, který právě opustil
Tímto vznikne chyba +/- 2 … ha ha ha. Rozumný nápad měl Honza a to
zaznamenat si konce řádků ještě před vyjetím a po otočce s v nich najít
odpovídající referenční body. Zatím je to ve fázi TODO.
Přišly FAQ, kde asi nejdůležitější
jsou fotografie políčka:
 Rovné políčko |
 Zatočené políčko |
Snímky jsou malé a nedají se zvětšit, ale i tak je celkem vidět, že kukuřice
není moc vzrostlá a možná že místo laseru budu muset použít kameru … už se
těším :(.
Husky
Milan připravil víko na Husky s přistávací drahou — není to klasické 'H', ale
značka od Parrotu, tak to dostalo název „kvadriport”. Večer jsem si chtěl s
robotem pokecat, ale neposlouchá a jenom stále mluví. Minimálně jsem potvrdil
info od Clearpath Robotics podpory: pokud je robot v ESTOP (zamačknuté červené
„Emergency STOP tlačítko”), tak měření napětí, proudu a teplot jsou
zavádějící. Včera už to dávalo:
25.44 25.76 25.31 | 2.18 0.59 0.59 | 28.4 33.57 26.29 27.65
- The first three numbers: three voltages are measured at the MCU, the left motor drive, and the right motor driver. The driver voltages will report 25V as well, once the platform is brought out of e-stop.
- The next three numbers: the currents are similarly system current, left driver, right driver.
- The last four numbers: the temperatures are left driver, right driver, left motor, right motor. Note that the motor temperature is measured from the motor casing, and not the inside, so be aware that the temperature of the coils could be higher than these readings show.
Pokud máte zájem vědět o Husky více, tak viz
fandorama projekt
(zbývá 5 dní).
Avoid Green
Na dobrou noc jsem si ještě upravil „avoidGreen” detekci do Pythonu a po pár
drobných zásecích dostal rozumný výsledek:
Pro zájemce viz
diff
s C implementací s NumPy (jak je to copy & paste, tak je tam stále mix
tabulátorů, mezer, různých pojmenování … no „trošku” ostuda). Ve zkratce: v
daném pásu počítá zelené pixely dokud nedosáhne požadovaného limitu. Výslednou
X-ovou souřadnici vrátí a označí červeným kolečkem. Něco podobného možná
použijeme pro navigaci drony v řádce nebo i Edura, pokud kukuřice bude příliš
nízká. Spodní MSER experiment ignorujte — nemám teď rychle po ruce nějaký
pěkný ukázkový obrázek.
16. červen 2014 — Odjezd (0dnů)
O víkendu jsem měl jiné „povinnosti” a s roboty mnoho nepostoupil. Heidi
zkoušela
létat
nad krabicí, ale trošku foukalo a velmi pravděpodobně je tam ještě nějaká
chybka u znamének náklonu. Asi nejdrsnější byl start
meta_140615_175522.log, kdy to podle senzorů napálila až do výšky přes 5m
než přešla do stavu „odstartováno” :(. Video je useklé a moc toho na něm
spodní kamerou vidět není, tj. ani nebudu uploadovat.
S Edurem to bylo snad ještě horší. Zkoušel jsem jak uvidí kužel, co má
definovat překážku. Konkrétně, jestli ho jako překážku rozpozná, nebo se ho
bude snažit objet. V čtyř případech z pěti se snažilo o objezd …
Zaskočilo mne, jak všechno vidělo žlutě — pravda byl právě západ slunce a tak
non-stop pípalo a blikalo. Než jsem stihl dojít pro míčky, přeci jenom jsem
původně chtěl testovat něco jiného, slunce zapadlo a nastal druhý extrém, kdy
nepoznalo jediný míček.
Doma jsem v mailu našel poslední informace: ... the site with the maize looks
fine. But the plants are a bit smaller than planned. They are around 20 to 25
cm. Have a look at the attached photo. Hope you can use this information for
your last sensor and machine tuning. Přiložena byla tato fotografie
(zmenšil jsem ji z 4000x3000):
Držte nám palce. Je toho na „zalátání na místě” nějak moc …
19. červen 2014 — FRE 2014
Když jsme dorazili v pondělí k večeru do Němec, propadl jsem své oblíbené
náladě „co tady zase dělám?!”. Bylo zataženo, kosa (po výjezdu z Prahy, kde se
člověk schovával do stínu, aby přežil, mne nějak nenapadlo si vzít dostatečně
zimní oblečení), celá akce byla opravdu v polních podmínkách. Trošku jak na
frontě — jídlo dovezla sanitka, porost nízký, Němci hráli fotbal = kravál …
prostě se občas cítím spíše na „robotickou penzi” .
No nic, první noc jsme překlepali, někteří doslova, nevědouce, že mají mít
spacák, Eduro kosilo malé kukuřice … žádná radost.
Task1 a Task2
Nějak stále nechápu, proč organizátoři trvají na tom, že všichni roboti musí
být přednastartovaní v ohrádce a nikdo nesmí nic dělat „aby to bylo
spravedlivé”. Přišlo by mi spravedlivější, kdyby naopak mohli dělat co chtějí,
ale musí být včas na startu (kolikátí jsme startovali jsem nikdy netušil —
pořadí náhodné, ale nezveřejněné). Ono na poslední chvíli spíše něco pokazíte
než opravíte a pokud tomu nevěříte, tak si natlučte sami .
Eduro jsem tedy zapnul, zamáčknul STOP tlačítko a nechal robota cca půl hodiny
stát. Po odblokování odstartoval a systematicky projel 5.5 řádky (bodově
83metrů, jestli si dobře vzpomínám). Žádný spěch, ale také žádný ruční zásah a
žádné trestné body. S „Basic Task” jsem byl spokojený .
(video)
„Advanced Task” byl napínavější. Vlastně jsem neřekl nic o nepoužitelnosti
„inteligentního přejíždění”, které jsem zmiňoval dříve. Kukuřice byla nízká a
do strany nebyla vůbec vidět. Konce řádek nebyly úplně dokonalé, takže
hledání nejbližších shluků často selhávalo. A asi vrchol všeho byly šikmé
plochy na obou stranách způsobující blízké překážky. Jak jsme to vyřešili?
„Všechno vylejt!” a zpátky k verzi s pouhou odometrií. Ze tří testů tři
fungovaly („vychytralý algoritmus” stěží jednou).
Co jsem dál zrušil, v rámci „programování mazáním”, byly kusy kódu spojené s
kompasem. I v předešlých ročnících bylo důležité udržet směr u výjezdu a to hlavně
u druhé úlohy, kde části řádek byly záměrně odstraněny. Řešení, které se
osvědčilo, byla stará referenční pozice (2s, tj. cca 1.5m zpět) a
spojnice/linie skrz aktuální pozici robota. Pokud Eduro nevidělo bezpečný
tunel (tj. očekávanou volnou výseč mezi pravou a levou překážkou), tak
použilo poslední definovanou referenční linii. Fungovalo to vlastně krásně a
Eduro až kouzelně dokonale vyjíždělo z řádky.
Přejezdy ob řádek (kódy 2R a 2L) odometrie zvládala, ale u 3R a 3L se netrefovala
… další záplata: „pro větší čísla přidej 10cm”. A ostrá jízda? Nejprve kód:
S-2R-1L-0-2L-3R-2R-F. Organizátoři na konce řádků zatloukli cedulky s
odbočovacími instrukcemi a tím bylo jasné, kde bude blokující překážka
(dopravní kužel). Byl v předposledním řádku. Chvíli jsem zvažoval, zda
nevypnout detekci překážek, nebyla moc dokonalá a dva větší listy v nešťastné
kombinaci robota zastaví, ale neudělal jsem to a jsem tomu rád . Ono totiž
na Task2 bylo místo tří minut času více (pět minut) a tak i pomalé Eduro mělo
šanci celou dráhu ujet.
Dalším zádrhelem bylo řešení krizové situace, kdy robot začne likvidovat
kukuřici nebo odbočí do špatného řádku. Jak už jste mohli číst dříve,
prosazoval jsem „restart”, ale můj návrh byl zamítnut, že by to nebylo dost
divácky atraktivní. Měl jsem tedy vlastně kliku, když se Eduro „zbláznilo” už
v prvním řádku — špatná detekce překážky — a chtělo se tedy vrátit. Zde byl
ještě možný nový start s identickým kódem. Jak to bylo dál si už moc
nepamatuji, protože mé paměti dominuje jiný zážitek. Rozhodčí odpískal konec
času a Eduro jsem vypnul … jenom mi to přišlo nějak krátké a tak jsem se po
odklizení robota šel zeptat. A bylo to tak. I rozhodčí zapomněl, že na
druhou úlohu je pět minut a zařízl nás po třech. Nabídku opakovat pokus jsme
přijali. (video)
Ve druhé jízdě Eduro nezpanikařilo z převislých listů (je dost možné, že je
některý z dalších soutěžících robotů zlikvidoval), správně se otočilo o dva
řádky vpravo, ale pak něco zvoralo a pro jistotu poničilo i trošku kukuřice. Co
teď? Rozhodl jsem se demonstrovat „svoje pravidla” a odnesl robota na úplný
start a zkusil to znova. Celkově tedy třetí start, kde ale Eduro už nezklamalo.
Krásně projelo všechny kódy a včas se dostalo až k překážce. Detekovalo ji,
včas se otočilo, ale nemělo dost sil dotočit přes nějakou hrudku. Jemný dotek
(= trestný bod) a písk, konec pokusu. Nedalo mi to a nechali jsme ho ještě tu
1.5 řádku dojet. A aplaus vždy potěší .
(video)
Pak jsme chvíli odpočívali a časem nám přišlo, že je okolo poměrně málo dalších
týmů. Důvod? Propásli jsme vyhlašování výsledků! Davy se pomalu vracely a jednotlivci
nám třásli rukama, že jako dobrý a gratulujeme … hmmm. Hanz nám pak dal dvě
druhé ceny … dobrý né?
Task3 a Task4
Asi uvěříte, že se mi nálada do dalšího dne trošku zlepšila . V úterý jsme
ale museli dořešit ještě jednu záležitost — GPS s RTK korekcemi. Věřte
nevěřte (já tomu opravdu dloooouho nechtěl věřit), na 23 týmů byly k dispozici
pouze dvě zařízení! Zkoušeli jste někdy integrovat nový senzor s tím, že po
20min ho musíte vrátit a pak už vás čeká jen ostrá soutěžní jízda? Celkem dobrá
škola. USB-serial jsem si naštěstí vyzkoušel už doma (vedlejší tým tím
vyplejtval celý časový slot, protože nejnovější Windows neměly potřebný
driver) a tak jsem připojil Pythonovskou GPS (odkomentoval
self.robot.gps.start() a self.robot.gps.requestStop()) a podle
očekávání to spadlo (zapomněl jsem odkomentovat self.robot.attachGPS()).
Dále jsem změnil rychlost komunikace (z původních 4800 na 38400) a už jsem
viděl první data . Následoval test v řádce a reálné měření. Editace kódu, že
pozice ukládaná do self.robot.gpsData už není parsovaná GGA věta, ale
hacknutá PTNL věta. Ještě jeden test v poli a konec, už nám senzor berou …
Produkční kód jsem napsal druhý den ráno a odladil na posledním logu. Jo, na
něco jsem zapomněl: když jsem vytáhl USB-serial, tak se Eduru udělalo nějak
špatně a vyblinkalo na obrazovku:
Message from syslogd@Eduro at Tue Jun 17 18:10:42 2014 … Eduro kernel: [] ? finish_task_switch+0x2a/0x90 Message from syslogd@Eduro at Tue Jun 17 18:10:42 2014 … Eduro kernel: [ ] ? __ipipe_handle_exception+0xa7/0x1b0 Message from syslogd@Eduro at Tue Jun 17 18:10:42 2014 … Eduro kernel: [ ] ? do_group_exit+0x31/0xb0 Message from syslogd@Eduro at Tue Jun 17 18:10:42 2014 … Eduro kernel: [ ] ? sys_exit_group+0x13/0x20 Message from syslogd@Eduro at Tue Jun 17 18:10:42 2014 … Eduro kernel: [ ] ? syscall_call+0x7/0xb Message from syslogd@Eduro at Tue Jun 17 18:10:42 2014 … Eduro kernel: Code: 00 00 81 c2 d8 00 00 00 89 55 d8 8b 45 d8 8d 55 e0 c7 45 e8 10 44 11 c0 e8 1c b8 89 ef a1 00 90 38 c0 c7 00 01 00 00 00 8b 45 dc <8b> 08 85 c9 0f 84 f4 00 00 00 8b 31 89 f2 03 51 0c 2b 51 08 89 Message from syslogd@Eduro at Tue Jun 17 18:10:42 2014 … Eduro kernel: EIP: [ ] pl2303_close+0x82/0x350 [pl2303] SS:ESP 0068:cee6bdc4
… ano, opravdu dobře se mi usínalo .
Středa. Počasí přešlo do druhého extrému — vedro, ostré slunce. Myslíte, že
poznáte žlutou barvu? Ha ha ha. Z předešlého dne jsem měl několik logů, kdy
Eduro blikalo o sto šest a tak jsem v ranní směně řešil, jak zvětšit věrohodnost
tohoto algoritmu pro podmínky ostrého slunce. První zásah byl nahrazení žluté
bílou — aby byla barva pixelu klasifikovaná jako míček, tak musel být hodně
jasný (r()>240 && g()>240). Přesto i mnoho silně nasvícených
listů šlo na některých snímcích doběla. Omezil jsem tedy prohledávanou oblast
na minimum
Poslední, možná dost zásadní, omezení bylo přidat vedle minimálního počtu
„míčkových pixelů” i horní limit … a to bylo vše. Ostatní týmy
oblepovaly své roboty nejrůznějšími krabicemi a zastiňovaly své kamery jak to
šlo. Slyšel jsem flexu a cítil pach černé barvy ve spreji…
Task 4 (kooperace) měl hned následovat, takže jsem po ránu programoval ještě
„webový server” (ve skutečnosti jsem použil prastarý tip od Zbyňka python
-m SimpleHTTPServer, který na portu 8000 pustí http server s přístupem do
podadresářů). Tam jsem ukládal do souboru GPS pozice a druhý robot tedy mohl
sledovat Eduro, pokud by měl připojení na
http://10.0.0.11:8000/gpsdata.txt. Myšlenka snad dobrá, ale v těch 15min
mezi jednotlivými úlohami naprosto nerozchoditelná :-( … druhému týmu se
nepodařilo nastavit windows na svém robotu tak, aby Eduro viděl, přestože mně
to z mého notebooku šlo. Další kus kódu do koše (velký koš, malý kus kódu) .
A ještě jsem zapomněl na drobnost, že dopoledne jsem strávil na workshopu. Ale
nelituji toho.
Ve 14h jsme zase museli nahnat roboty do přihrádky, zapnout a zase doufat, že
hodinu (?) bude ještě vše běžet. Díky radě od Dimitrise jsem Eduro pustil se
zapojeným USB-serial převodníkem a pak naslepo zapojil Trimble GPS až na nás
přišla řada. Trošku to vypadalo jak v depu Formule 1, kdy zbytek týmu začal
1.5kg těžkou GPS s anténou přidělávat na zadek Edura.
Eduro odstartovalo a hned píplo, falešná detekce. Nějak mne nenapadlo, že v
políčku kukuřice je bíla startovní čára. Pak první správně reportovaný míček,
přejezd ob řádek, jeden ignorovaný míček, druhý reportovaný míček, ale nějaký
konflikt s kukuřicí a nutný restart. Podobných restartů bylo více a tak jsem se
obával, že vznikne několik krátkých souborů … ale mýlil jsem se. Zalátal
jsem to globální proměnnou a tak byl soubor již vytvořen a přidávaly se do něj
další špatná měření s omezením na pět (podle pravidel by soubory s více jak
pěti řádky nebyly akceptovány). Nějak jsme dojeli až na konec, zkopírovali
soubor FRE-Task3_EduroTeam_140618_122537.txt:
Team Name: Eduro Team Date and Time: 18.06.2014 12:25:37 +5746328.761,N,+686329.116,E +5746328.714,N,+686328.770,E +5746326.522,N,+686320.803,E +5746323.436,N,+686315.634,E +5746330.862,N,+686325.074,E
a čekali na výsledky „rulety”.
(video)
Task4 byl zklamání. Nakonec se ho účastnily pouze dvě dvojice, takže
„hodnocené místo garantováno” … škoda. Prostě to mělo být poslední den
až po skončení hlavní soutěže. Nakonec jsme vymysleli scénář s FireAntem,
ručním ovládáním a folowme.py: na poli je zloděj (FireAnt), co krade zlaté
míčky. Eskadra hlídacích robotů (BullsEye s Edurem) robota zablokují s tím, že
jeden se pověsí na vetřelce zezadu a druhý ho odřízne zpředu. Byla to sranda a
mnoha lidem se to líbilo, ale de facto to bylo to samé co ve Venlo před
dvěma roky. Navíc chytit mravence nebylo tak snadné (Eduro se jako klíště
drželo raději BullsEye) a ve finále se ozvala siréna (celkem tématická ), ale
znamenalo to, že BulsEye došly baterky. Druhé místo zní dobře, poslední trošku
hůř … ale celý večer a druhý den za námi chodili lidé z vítězného týmu a moc
se omlouvali, že jsme to měli vyhrát my, že to byla super zábava .
(video)
Nějak mlčím o Task3 … tentokrát jsme na vyhlášení šli . Třetí místo to
nebylo, druhé také ne … tak je to jasné, „bramborová pozice” … a vítěz
je Eduro Team!. Profesionálově potřetí v řadě!
Ale to znamenalo další „drama” … první a druhou úlohu vyhrál stejný tým a
ve třetí úloze byl na třetím místě. Bodově tedy 10+10+6 vs. 8+8+10. Sudí
evidentně měli odlišné názory (jsou dvě první místa více? nebo trestné body
jsou důležitější?) a tak letos vyhrály dva týmy … a tím pádem jsme poprvé
vyhráli FRE!
Task 5
Po vyhlášení výsledků byla párty a stejně jsem do západu slunce už neměl moc
sílu nic dalšího programovat. Heidi tedy skončila pod postelí, abych v 5h ráno
nemusel nikoho budit a do třetice hurá na programovací sprint. Ráno bylo
zataženo, ale pomalu se zvedal vítr. Nejprve jsem Heidi nechal proletět nízko
nad polem a snímal ho spodní kamerou. Zapojil jsem detekci zelené, udělal
projekci na zem (při známém stáří snímku a velikosti náklonů) a protože začalo
foukat čím dál více, tak se šel schovat do stanu týmů. Další test jsem udělal
na testovacím políčku a to byla síla … dost se na tom podepsal následující
snímek:
Po snídani byl fakt už vichr a to není na létání, navíc s indoor krytem, dobré.
Ale mám zase zajímavá data (přesněji myslím si, že by mohla být zajímavá), kdy
se kamera pere se sonarem a oboje ruší vítr a pohyblivé 3D listy kukuřice.
Zkusili jsme ještě umělou „kukuřici” pro FRE Junior uvnitř stanu:
ale bylo to snad ještě horší. Jednak řádky měly šířku pouze 40cm a ve stanu byl
stejně průvan, protože musel zůstat otevřený pro veřejnost. Nějaké tipy, co
dělat? Po třech dnech už mne napadla pouze „suicidal mission”, odstartovat ve
větru, udělat přelet, který mi jakž takž fungoval cca v 6h ráno, a uvidíme. No bylo
to maso: drona vystartovala vysoko a pak zase padala dolů, ale příliš rychle a
prásk. Sudí souhlasili s druhým pokusem a ten byl ještě drsnější. Přelétla
políčko, jak bych si představoval, a vypadala, že jde na přistání na zeleném
trávníku. Tam ale asi něco viděla, otočila se o 120 stupňů a vrhla se na
porotce. Crash2. No to už na žádnou cenu nebylo.
Workshop
Jak už jsem zmínil, tak ve středu dopoledne byl workshop. Časování zase dost
nešťastné v půlce soutěže, ale nelituji, že jsem tam byl. Teď si mne všichni
budou pamatovat jako „ten Python guy” a „ten co brojí proti simulátorům”.
Pěkná perlička byla, že se před mojí prezentací dlouze dohadovali, že by
možná bylo dobré nějak sdílet kód a má odpověď byla, že pokud někoho zajímá náš
kód, tak už je dávno na githubu .
Celkem jsem si pokecal s člověkem od Honda R&D v Německu, co řeší nějaké
inteligentní kamery a ve sklepě se mu „povalují” dva Asimo
roboti . Přišlo za mnou pak ještě pár nadšených Pythonistů, tak mi možná
pomůžou ty verze na githubu posunout na vyšší úroveň. Nedělám si až tak moc
iluze, že se ještě ozvou, ale nenulová šance tu je.
Závěr
Pokud vám v tomto článku přišlo alespoň něco trošku zajímavého, tak rád
přepošlu díky fandorama přispěvovateli Pavlovi S. Pokud ne, tak jste se asi až
sem na konec nepročetli .
|
Pár snímků …
23. červen 2014 — FRE 2014 Video
Basic Task
Advanced Task
- Phaenthon
- Eduro (poprvé)
- Idefix
- BANAT
- Agro-bot
- Robot TU Kaiserslautern
- Eduro (podruhé)
- příprava týmů na poslední úkol
Professional Task
Cooperation Task
Eduro view
A pro „Robo-Maso-Chisty” všechny videa v jednom playlistu: