Předehra
Robík, Eduro, ROS a OSGAR
Je čas dělat „podzemní robotiku”, minimálně DARPA (americká armáda) si to myslí. První cena v nové SubT Challange jsou 2 milióny USD a již se neomezuje pouze na američany. Vedle Systems kategorie, kde se očekává netriviální kombinace mnoha mapovacích robotů zvládající náročné podmínky v podzemí, je k dispozici i Virtual kategorie, online v simulátoru Gazebo 11. Update: 18/1/2019 — STIX Qualification
9. listopad 2018 — Brána do pekel je již otevřená
Po shánění reálných robotů, se kterými by se dalo natočit kvalifikační video,
jsem včera přepnul na Virtual Track. Manželce jsem přeinstaloval počítač na
Ubuntu 18 (už jsem jí ho rozbil loni, když jsem k Windows 8 „přiinstaloval”
Ubuntu 16, abych si mohl hrát s Naio Move Your
Robot soutěžním simulátorem) … takže to už tak nebolelo.
Druhý krok byla instalace ROSu a potřebných knihoven. DARPA nabízí dvě
varianty, kde první je
Catkin
workspace install a druhá
Docker
install. Šel jsem zatím první cestou, protože je mi jedno, že to vše rozbije
a zahluší množstvím potřebných (?) balíčků. Pochvala organizátorům — postup
Updated 2018-11-01 byl bez problémů (ano, ten počítač je pro mne skoro
nepoužitelný, ale po rozchození ssh, které má Ubuntu 18 jinak než předešlá
verze (viz
ver
18 vs.
ver
16) to z terminálu už vzdáleně šlo.
Simulátor jsem pouštěl přímo na linuxovým notebooku a zde jsou první screenshoty:
Stihneme ještě ve zbývajících 30 min
Example Setup?
V tom si můžete tunel projet robotem na joystick … pokud nemáte, stačí zajít
do Walmartu
přeci. No jo, je to americká soutěž. Nevylučuji, že tu doma někde leží z
Edura nebo Fireanta, ale … to bych asi teď po ránu už nestihl.
Podle instrukcí pouštím:
roslaunch subt_gazebo competition.launch scenario:=tunnel_practice_1
a zatím to vypadá stejně jako včera.
roslaunch subt_example team.launch
a objevují se dva pozemní roboti a dvě drony. Další krok je to pustit rovně …
jen ten počítač dost hučí … a už gazela umřela (no to asi není ideální
reklama, ale co nadělám).
--- timeout ---
p.s. pekelníci mi vybrali jako jazyk Ubuntu němčinu ... asi abych si to
opravdu užil
14. listopad 2018 — Světlo na začátku tunelu
Mittwoch, November 14
Jestli čekáte nějaký kód a video na YouTube, tak vás musím zklamat. První
krůčky jsem udělal podle
Understanding ROS
Topics s tím, že roboti mají timeout nastavený na 0.25s a
příkazy pohybu je třeba posílat opakovaně. Fungovalo např.
rostopic pub -r 20 /X1/cmd_vel geometry_msgs/Twist – '[0.5, 0.0, 0.0]' '[0.0, 0.0, 1.8]'
Ukázalo se, že na startu jsou roboti otočení proti sobě a velký robot snadno
malého odsune. Stejně tak malý robot nemá moc problém najet na zpevnění tunelu
a převrátit se na záda. Za úspěch ale považuji rozsvícení světel (funguje i
vypnutí s false parametrem ).
rostopic pub -1 /X1/light std_msgs/Bool true rostopic pub -1 /X2/light std_msgs/Bool true
Další pozorování je, že robotické platformy jsou v příkladu bez senzorů, tj.
další úloha je přidat a zapojit nějaký LIDAR a kameru …
28. listopad 2018 — OSGAR ROSProxy subt-ver0.json
Koukám, že uběhlo 14 dní a já sem nenapsal žádný „průběžný report”. Ono to
nikdy nebylo „to ono”, což ještě není ani dnes, ale možná platí to samé co u
zveřejňování kódu, že pokud se za něj nestydíte, tak už je vydaný pozdě … no
prostě taková omáčka k tomu, že ten současný stav je opravdu příšerný.
Začnu s tím, co je mým nejbližším cílem ve Virtual Track, tj. ver0 = co
nejjednodušší verze, co něco dělá. Moje původní představa byla jet jako
robot Karel
rovně dokud není zeď. Až bude zeď tak se otočit a znova jet dokud není zeď. Tak
to bylo moc složité — jak se otočit o 180 stupňů? Navíc jsou roboti ve
vzorovém příkladě rozmístěni tak, že velký X1 blokuje vjezd malému a sám
je otočen ke vstupu do tunelu zády. Ver0 jsem upravil tak, že tam budu couvat a
zpět pojedu dopředu, bez otáček. Nyní jsem tak v půlce: couvám dokud to
nenarazí.
Přijde vám to příliš hloupé? Kolik myslíte, že to ujelo metrů? Vlastně jsem
ještě neřekl, jak poznám, že je v cestě zeď?! No zatím nijak, prostě narazím.
Do další verze snad budu mít LIDAR a vyčtu to z něj. Pouštěl jsem to včera
krátce před půlnocí, pak se šel vysprchovat, pak ještě psal pár mailu …
prostě ten robot jel déle než 40 minut! Ta hlavní štola je totiž hrozně dlouho
rovně. Ano jel jsem jenom -0.5m/s a grafika na druhém notebooku není extra
silná, takže se to tvářilo, že odsimuloval pouze 5 minut, ale nahrávka má těch
40.
A teď konečně k OSGARovi (web,
github,
pip instalace,
doc). Na něm stále pracujeme a pomalu se
portfólio ze dvou zemědělských strojů rozšiřuje i na další. Už nechci zakládat
pro každého nového robota nové repository, ale jen přidat driver a základní
konfiguraci. Asi podobná myšlenka jako u ROSu, ale tam
je to na druhé straně spektra … my chceme, aby to bylo pokud možno co
nejjednodušší a postupně to rozšiřujeme.
OSGAR až dosud počítá s pevnou komunikační strukturou, tj. už na startu
programu se ví, kdo s kým bude mluvit a svým způsobem i co asi bude posílat. V
ROSu je to obráceně: i pokud chcete ujet 1m rovně, tak nejprve se musíte
dotázat ROS mastera, kde jsou jaké publikované topicy a jaké uzly
se o ně starají. Následně kontaktovat je a navázat typicky TCP spojení. Pokud
naopak chcete něco publikovat vy (např. požadovanou rychlost motorů), tak
musíte ROS masteru říci pod jakým jménem a jaký typ budete zprávy vysílat,
spustit XML RPC server, který pak bude odpovídat, kam se zájemci mohou připojit
a otevřít zase TCP spojení a čekat, až někdo přijde …
V originálním ROS se o toto asi postará, za mne poměrně složitá, mašinérie.
Součástí jsou i různé kompilace struktur a i pro Python musíte něco kompilovat.
To se mi již před lety nelíbilo, ale s Husky jsem neměl na vybranou a s ROSem jsem
musel žít. Je to stále online, jenom v anglické verzi, konkrétně mám na
mysli ROS without ROS? ze srpna
2014.
Cca před týdnem se mi podařilo s
hacknutým
Husky kódem popojet a v dalším pokusu rozsvítit světla:
def testNode(metalog):
# '/X1/imu/data'
node = NodeROS(subscribe=[], publish=['/X1/cmd_vel'])
for i in xrange(1000):
node.cmdList.append(('/X1/cmd_vel', (0.5, 0.0)))
node.update()
time.sleep(0.05)
Lokálně na „Ubuntu notebooku” mi fungoval i subscribe na
/X1/imu/data, ale vzdáleně tam mám asi nějaké „ohnivé zdi”, sigh. Toto
vše jsem potřeboval dostat do OSGARa (a není to jenom copy & paste), takže
jsem nakonec vše pouštěl jenom lokálně.
python3 -m osgar.go1m run subt-ver0.json –note "ubuntu, add subscribe, hack IP address,
fix tuple, fix run_input, LONG RUN!"
OT (Off Topic) tento týden nezávisle tři lidi narazili na to, že je pro OSGARa
potřeba python3 a na Ubuntu jsem na to narazil sám také. … prostě to
musíme lépe zdokumentovat a přidat omezení. Tu příkazovou řádku dávám jen pro
představu: snažím se jet 1m rovně, ale bez reportu odometrie to pojede pořád a
v poznámce mám co vše jsem fixnul/hacknul od posledního commitu (který byl
asi 5min před tím). Link na
subt-ver0.json
asi dát můžu, ale za vše ostatní se moc stydím (a kdo bude chtít, si to stejně
najde). Ve zkratce bylo třeba přiohnout konfigurovatelné TCP spojení, aby se
spustili aniž by věděly kam se mají připojit případně aby čekaly, jestli se k
nim někdo jiný nepřipojí. XML RPC server je zatím jeden globální a komunikace
se zatím neloguje. A konečně mam i malý ROS master v unittestu, abych to
alespoň trošku mohl pod Windows psát. Ještě výsledný log:
subt-go1m-181127_221851.log.
Timeout, budu muset do práce … takže analýza 8MB logu, který obsahuje pouze
posílání příkazu k couvání a IMU data bude muset počkat na večer. Tak alespoň
pár obrazovek ze včerejška (když v Gazebu přes pravé tlačítko na X1
vyberete Follow).
Omlouvám se za tak temné snímky … holt jsem včera nerozsvítil světla, ale ono
by to stejně oslňovalo.
30. listopad 2018 — IMU data
Dnes ráno jsem konečně koukal na data získaná úterní „noční jízdou” (couvej
dokud nenarazíš, resp. dokud simulaci nevypnu).
ROS IMU datová
struktura je celkem pěkně popsaná … a ano, už jsem za ty roky zase
zapomněl, že orientace jsou čtyři čísla … co to je?? …
Quaternions!
„Pro změnu” jsem vše opsal z
Husky kódu a
dostal následující obrázky:
Tak schválně, poznáte, kdy X1 narazil? Té simulaci jsem moc nevěnoval
pozornost, ale evidentně se tam střídají rovné a šikmé úseky tunelu pod úhlem
cca 16 stupňů. Je to celkově 18588 IMU paketů (odkazuji se stále na
subt-go1m-181127_221851.log
data) a ROS čas odpovídá 381s = cca 6 minut simulace.
Další krok je připojit kameru a nasbírat data pro detekci hasičáků a podobných
„artefaktů”.
p.s. z této „stupidní verze 0” bych skoro tipoval, ze jsem projel tři
křižovatky a že by se tato informace dala použít pro globální mapu …
p.s.2 asi jste pochopili, že znaménko u náklonu je převrácené … ale vlastně je
správně … couval jsem!
3. prosinec 2018 — X1_SENSOR_CONFIG_1=1
RTFM! aneb o víkendu jsem neměl
druhý počítač s ROSem a tak jsem si procházel SubT stránky a narazil na několik
užitečných:
- wiki subt/robots — základní popis všech dostupných robotů včetně čtyř konfigurací
- wiki subt/api — API pro komunikaci s roboty a především s příkladem X1_SENSOR_CONFIG_1=1 roslaunch subt_example team.launch, který pouští robota X1 s první konfigurací (2D short range LIDAR + QVGA camera + IMU)
- Ignition Robotics Portal — vstupní bod pro registraci na DARPA SubT (zatím se mi nepodařilo projít přes formulář Organization)
A pak ještě stará DARPA SubT
Resources stránka, kde jsou nově Questions and Answers a novější revize
SubT Challenge Guidelines.
Teď to nemůžu najít, ale někde se píše, že ve Virtual Track si soutěžící
mohou vybrat pouze ze čtyř konfigurací robota, tj. že bych si namodeloval
robota se dvěma 2D LIDARama, kde jeden kouká šikmo dolů tedy asi zatím
nepřipadá v úvahu … ale za
zeptání
člověk snad nic nedá … uvidíme.
No nic, zpět k X1_SENSOR_CONFIG_1=1 co jsem se dočetl v manuálu. Opravdu se
objevily nové topicy a to
/X1/front_scan
a
/X1/front/image_raw
(ve skutečnosti je jich více a minimálně k /X1/front/image_raw/compressed
se plánuji brzy vrátit).
Pak už to vše prodrátovat (ten kód zatím moc pěkně nevypadá) a za odměnu
dostanete obrázek 320x240:
 první pohled z robota X1 |
Srandovní bylo
,,uhádnutí''
kontrolních MD5. Už jsem si to moc nepamatoval, jak jsem to na
Husky dělal, ale teď už vím:
- přidáte nový typ zprávy a k tomu falešnou MD5 (ideálně rozlišitelnou a musí mít správný počet znaků)
- pustíte program a sledujete chybové výpisy na ROS master (v našem případě terminál s Gazebem)
[ERROR] [1543781745.433015564, 8.328000000]: Client [/osgar_node] wants topic /X1/front_scan to have datatype/md5sum [sensor_msgs/LaserScan/0002c6daae103f4ff57a132d6f95cec2], but our version has [sensor_msgs/LaserScan/90c7ef2dc6895d81024acba2ac42f369]. Dropping connection. [ERROR] [1543781745.439444791, 8.328000000]: Client [/osgar_node] wants topic /X1/front/image_raw to have datatype/md5sum [sensor_msgs/Image/0012c6daae103f4ff57a132d6f95cec2], but our version has [sensor_msgs/Image/060021388200f6f0f447d0fcd9c64743]. Dropping connection.
- opravíte MD5 a pak už bude master spokojen
Chtěl jsem pustit znova čtyřicetiminutové couvání až do nárazu v zatáčce, ale
tentokrát se zapnutou kamerou, laserem a rozsvícenými světly. No daleko jsem
nedojel (resp. moc nevím), protože Gazebo crashlo. Nasbíral jsem si 1.3GB
velký OSGAR log, u kterého se ukázalo jako problém ho i přenést z jednoho
počítače na druhý, takže ho ani nemám v plánu uploadovat. Večer bych rád zkusil
compressed verzi, kde doufám, že dostanu JPEG obrázky (možná bude nutné to
zase nějak konfigurovat). Pokud to projde, tak bych i zvětšil rozlišení a
poskládal video pro lepší představu.
A na závěr ještě jedna zajímavost — včera jsme s ND Teamem vzdáleně
rozcházeli OSGARa na robotovi Robík,
který je nyní první nominovaný do System Tracku. Testovací 1 metr:
python3 -m osgar.go1m config/cortexpilot.json
zatím ujel pouze ve vzduchu, ale data z LIDARu chodí a checksumy sedí.
Zajímavé je API, kdy vedle požadované rychlosti se zadává i požadovaný
absolutní směr (např. jeď na severo-západ) a o regulaci se už robot
stará sám. A co vy, nechcete se také přidat? Zbývá 18 dní.
4. prosinec 2018 — Robot X1 video ver0
Včera večer jsem rozchodil /X1/front/image_raw/compressed topic s typem
sensor_msgs/CompressedImage a stejným trikem jako posledně získal i jeho
md5sum = 8f7a12909da2c9d3332d540a0977563f. Defaultní kódovaní zabaleného
obrázku je naštěstí JPEG a opravdu z původních 230kB na jeden snímek jsem se
dostal na 10kB. To už bylo dostatečné natolik, že jsem zapnul náročnější
konfiguraci X1_SENSOR_CONFIG_2=1 a obrázky tedy mají místo 320x240 velikost
1280x960 (velikost jednoho JPEG cca 100kB).
Pustil jsem zase ver0 „couvání do tunelu”, kde světla jsem zapnul ručně v
extra terminálu. Tentokrát to jelo skoro hodinu (viděl jsem 59minutu a tak to
nechal úmyslně ještě chvíli v kolizi, protože jsem byl zvědav jak si OSGAR
poradí s nahrávkou delší než 1 hodina). No máme tam "assert" a je tedy třeba
zavést multi-file logy.
A výsledek? Podívejte se sami
Co dál? Je třeba nějak počítat ujetou vzdálenost (enkodéry jsem v seznamu X1
topicu neviděl, ale možná jsem to přehlédl) a asi bych začal nějaké rozumné
řízení, tj. aby python3 -m osgar.go1m opravdu jel 1m a zastavil. Laserová
data mi už chodí (jsou v té
subt-go1m-181203_195930.log
(1.3GB) nahrávce), tak asi nečekat na kolizi a orientovat se zhruba středem
tunelu.
11. prosinec 2018 — Huston, máme problém … laser data = -inf
Minulý pátek jsem dokončil parsování většiny potřebných ROS zpráv: IMU, JPEG
obrázku, laserového skenu a i pose, která je snad integrovaná z enkodérů
robota (a snad je povolená?). Natvrdo zadrátovaný příkaz couvej rychlostí
0.5m/s jsem nahradil daty, co přijdou po desired_speed kanálu z OSGAR
aplikace a už jsem schopen kontrolovaně ujet jeden metr:
python3 -m osgar.go1m run subt-ver0.json –note "ubuntu, X1_SENSOR_CONFIG_1=1"
což je i pro jiné roboty takový self-check. go1m.py vedle jízdy i
vypisuje data co dostal a tak jsem viděl toto:
A to je zlé! Podobný obrázek jsem totiž viděl i na
subt
fóru, kde po drobné diskusi došli k závěru, že PC uživatele nesplňuje
požadavky na GPU: You can try changing gpu_ray to ray on
this
line. This will cause the the ray sensor to be CPU based instead of GPU
based.
Tak to snad ještě nebude fatální, jen to bude ještě o trošku pomalejší (druhý
počítač ale teď u sebe nemám).
Můj plán byl „obyčejná jízda podél zdi”, kdy teoreticky by se měl robot
vrátit nebo spadne do propasti pro nedostatek pokrytí senzory (mimochodem na
můj
dotaz
ohledně dvou laserů, jsem dostal odpověď ať se rovnou zeptám na hlavním SubT
fóru … což jsem ještě neudělal, když mi momentálně nechodí ani základní
konfigurace).
Ještě jsem nezmínil, že máme konkurenční
český tým, který se na rozdíl od Robotika.cz již registroval. Nese jméno
CRAS (Center for Robotics and Autonomous Systems) a plánuje se zúčastnit
pouze System Tracku. Takže první cíl je jasný — porazit CRAS. … ne
vážně, beru to jako šanci na „paralelní slalom” podobně jako z
našich začátků na Eurobotu.
15. prosinec 2018 — Zpátky ve hře (zbývá 6 dní)
Ve čtvrtek jsem registroval Robotika.cz tým, kde jsem si ještě zahrával s
myšlenkou k tomu přidat RC1 (ano, jsem z těch pracovních předvánočních
release úplně pomatený), kde vedle release candidate 1 by to mohlo být
interpretováno i jako Robotic Consorcium 1. Jedná se totiž o kombinaci
momentálně třech týmů: ND Team, Short Circuits Prague a Eduro
Team. Uzávěrka je příští pátek (21-12-2018), sigh, tj. nejvyšší čas to
všechno rozchodit.
Včera večer jsem alespoň zprovoznil simulaci laseru bez GPU. Vedle přejmenovaní
gpu_ray na ray bylo třeba ještě přejmenovat (ve stejném souboru
subt/subt_sensors/urdf/planar_lidar.urdf.xacro)
libgazebo_ros_gpu_laser.so na libgazebo_ros_laser.so (viz
Gazebo Tutorials).
Došlo mi také, že vedle modifikace konfigurace je třeba to celé zbuildovat
pomocí catkin_make install a „konec dobrý, všechno dobré”. Při té
příležitosti jsem si updateoval Mercurial repository a i samotnou instalaci.
Měl jsem tam malý konflikt a to v pokusu o nastavení orientace robota X1
směrem do tunelu … teď je to default, takže bych vlastně ani nemusel couvat.
Ještě bych zmínil „starý vtip”, který jsem zapomněl popsat při integraci
pose — kolik si myslíte, že má zpráva obsahující polohu robota
(potřebujeme pouze x, y, heading, protože více z odometrie stejně
nevytáhnete) bajtů? No dost. 719 bajtů … pokud to dostáváte na 100Hz, tak
už jenom pozicí vám rychle poroste velikost logu. Důvodem jsou dvě (?)
kovarianční matice 6x6 v double (tj. 8 bajtů každý prvek), viz
msg/Odometry.
Toto je zatím první (naivní) pozorování.
16. prosinec 2018 — Jízda podél zdi v 3D? (zbývá 5 dní)
Za tuto citaci se bude jeden z Pavlů z Robotika.cz teamu zlobit, ale
„nemůžu si pomoci” : Jízda podle zdi mi nepřipadá jako něco, co by se
mělo posílat do DARPA, možná jenom proto, aby se pobavili. Tehdy (9/12, tj.
před týdnem) jsem argumentoval, že na těžkou úlohu, což SubT určitě je, je
třeba začít s něčím triviálním a nic lepšího než „jízda podél zdi”, která
přeci jenom nějakou exploraci dělá a zajede hlouběji do tunelu, jsem nepřišel.
A teď si myslím, že i ona jízda podél zdi v 3D triviální není!
Když jsem včera ráno reportoval, že problém se simulací laseru bez GPU je
vyřešen, tak jsem se pletl. Nebyl. Pravda, už mi nechodily -inf hodnoty,
ale na volném prostranství před tunelem jsem neviděl měření delší než 1m.
Vzpomněl jsem si, že někdo něco reportoval ohledně laseru na droně a
"X4
laser sensor limited range" opravdu problém řeší. Je to asi pouze problém
simulace na CPU, který „není podporovaný”. Řešením je nastavit minimální
vzdálenost na 1 metr. Autor problém demonstroval v rviz programu, tak jsem
si ho také pustil a jako vizualizace pěkné (a bez programování).
Jestli si myslíte, že tím už máme vyhráno, tak se pletete. Jenom není (snad)
třeba dále bojovat s ROSem a je možné se věnovat samotné úloze. V první
(nejořezanější) konfiguraci má robot X1 Hokuyo laser s dosahem pouze 5m a
kameru rozlišením 320x240 pixelů. Za mne je to preferovaná konfigurace, protože
má i minimální nároky na logování … a log je základ.
Na startu X1 robot nevidí nic — všechny překážky jsou dále než 5 metrů.
Překvapení pro mne ale bylo ústí do tunelu. Tváří se jako dokonalá zeď ve
čtyřech, třech i dvou metrech! Teprve na hranici jednoho metru se najednou
„dveře otevřou”:
… a teprve když robot překoná vstupní práh, začne profil vypadat rozumně:
Data jsou zatím nasbíraná jízdou rovně 10m (viz log
subt-10m-181216_060934.log,
4.5MB). Ještě jednou jsem to pustil na 100m (viz
subt-100m-181216_064651.log,
58MB) zatímco jsem sepisoval report … a ten přehledový náhled je asi k
nezaplacení:
Takže v logu by měla být vidět nějaká křižovatka.
p.s. ještě ten
viewer.py
je narychlo upravený pro SubT …
17. prosinec 2018 — Gambler and Abyss (zbývají 4 dny)
Musím nechat, že DAPRA vytvořila celkem pěknou gamesu … ještě tam přidat
nějaké „efektory” a mohl bych říci „střílečku”. Nějak mne to vrátilo skoro
30 let zpátky ke hře
Město
Robotů, kde hra byla „blokovaná” heslem, jenom ho tam autoři zapomněli v
plain textu :-(. Na internetu je ke stažení i
původní návod a co mi
utkvělo v hlavě je věta, kterou teď opíšu z toho PDFka: Ve hře se nepáchá
žádné násilí, nestřílí na lidi a nepropagují se žádné nehumánní myšlenky. …
ale střílelo se tam na roboty, jestli si dobře vzpomínám. Pro mne měla být hra
najít to vstupní heslo a to bylo velké zklamání … až do dnes.
No nic v SubT se nestřílí, ale roboty tam zničit můžete. Rozchodil jsem tu
jízdu podél zdi a na první křižovatce konečně odbočil vpravo. Timeout simulace
jsem si nastavil na 30min a robot zastavil těsně před propastí! Pak jsem vypnul
GUI podle
What
is a simple way to run Gazebo with no graphics? – gui:=false z
příkazové řádky nefungovalo, ale modifikace
subt_gazebo/launch/competition.launch
zabralo … jenom nevím, jak to dopadlo a zda se robot X1 opravdu zřítil do
propasti? Teď jsem to video viděl, crash test jedna báseň, ale robot přežil
a následně pokračoval v jízdě. To je rozhodně na upload/video. Tak nejprve log
subt-181216_172739.log
(167MB) a teď to video:
Jak to detekovat? Nedá se řídit náklon předního laseru? Skoro by mi přišlo, že
by to mělo jít …
18. prosinec 2018 — Vánoční besídka na ČZU (zbývají 3 dny)
Kolegové, kamarádi a zároveň členové Eduro Teamu z ČZU mne občas dostanou …
jako dnes. Před časem jsem se ptal, zda nemají nějaký tip na tunel, kde by se
dal vyzkoušet System Track případně natočit registrační video. A už tehdy
mne Milan překvapil, když zmínil, že přímo pod školou jsou kolektory propojující
jednotlivé budovy univerzity. Že to ale asi bude problém tam získat přístup,
ale že se pokusí …
V neděli 16/12 pak psal: Ahoj Martine, byls ve škole? Snad dopadnou ty
kolektory. Maš lano, tak 10 m na spuštění Edura do podzemí? Leze se tam po
žebříku. Tou dobou jsem to bral jako žert, ale Standa nedbal a hliníkovou
konstrukci ze SICK Robot Day převrtal
tak, aby se dal robot v jednom místě uchytit a pověsit (mimochodem Eduro s
olověnými baterkami není úplně nejlehčí, cca 15kg??).
Nedělal si srandu. Jediná cesta jak rozumně Eduro dostat do tunelu bylo po
laně. Možná to nebylo 10m, ale 5 a více určitě. No ještě teď mne mrazí — na
cestě dolu se roztočilo jak blázen a dostat ho zase po testu nahoru bylo o řád
náročnější. Ideální příležitost urazit dva SICKy a slušnou kameru … ale dobře
to dopadlo!
Jenom já zase nebyl připravený :-(. Použil jsem stejný kód jako na Virtual
Track, tj. jízdu podél zdi, která ale trošku zlobila. Jednak robot stále
viděl „duchy” a pak odvodňovací žlábek byl často konečnou. Po vypnutí
zastavování před překážkou se Eduro celkem pěkně vydalo na průzkum tunelu, viz
video:
Horší to bylo dostat se zpět — jízdu podél levé zdi jsem dopsanou neměl a
vedle různých chyb se to chovalo podezřele. Tak jsme se nakonec vrátili přes
osgar.followme.
p.s. teď mi přišel mail od DAPRA, že jsou k dispozici nová pravidla pro soutěž
v tunelu, která se bude konat v srpnu 2019:
SubT_Challenge_Competition_Rules_Tunnel_Circuit.pdf
19. prosinec 2018 — Do not panic! (zbývají 2 dny)
To se snadno řekne, aneb jak kdysi říkal můj šéf: „nepanikuj!” Dnes bych
rád uzavřel Virtual Track, ale … jak?! Přešel jsem na
tunnel_qual.world,
kde jsem po první zatáčce naboural do slepé uličky. Trošku mne zamrazilo, když
jsem ji viděl a teď už vím proč:
Ono totiž hodně podobně vypadalo to místo, kde jsem se s robotem X1 posledně
propadl. Jediný rozdíl tady byl v tom, že ta šachta byla nahoru! Při
rychlosti 1m/s se robot nestihl o 180 stupňů otočit, tj. teď je tam už
proměnlivá rychlost (zkoušel jsem to projet rychlostí 0.5m/s, ale to je
zase moc pomalé na průzkum rozsáhlého komplexu).
Pokud robot jede 1m/s, tak za minutu ujede cca 50 metrů a za časový limit 20
minut tedy 1km. Jak je kvalifikační scénář rozsáhlý? Ano, není úplně korektní
koukat se do „nápovědy”, ale zbývající čas už se počítá na hodiny :-(.
Další „zkratka” byla přes:
cat tunnel_qual.world | grep pose | awk '{print substr($1, 7)"\t"$2"\t"$3;}'
Simulace mi trvá cca 10x pomaleji než realita, tj. 20minut průzkumu odpovídá
cca 3 hodinám. Zbývá-li 48h + je třeba ještě rozchodit mapování, rozpoznávání
objektů a komunikaci přes nějakou C knihovnu … opravdu nemám panikařit??
Hacknul jsem (špatně) OSGAR logování, aby to ty 3h dokázalo nahrávat (ano, do
dalšího kola již opravím), ale podle mapky toho asi moc na videu vidět nebude.
A jestli tam bude zase propast, tak nevím.
Ještě „výškový profil” (x-ová a z-ová souřadnice v metrech):
… prostě podle defaultních parametrů generátoru světů: je scale_x=20,
scale_y=20 a scale_z=5 … vše metrů. Globálně se lokalizovat na mřížce
by tedy mělo být výrazně jednodušší.
TO BE CONTINUED …
20. prosinec 2018 — Battery Low (zbývá 24 hodin)
Nějak mi dochází energie. Včera Jirka navrhl, že propasti bych mohl detekovat
jako slepé cesty a nejezdit tam (buď je to opravdu slepá cesta, tj. nemá smysl
jet podél zdi, nebo je tam díra, ze které se nedostanu). To mi přišlo dobré,
ale ještě jsem neověřil, že ten laser s dosahem 5m to může poznat.
Popisoval jsem status a závěr byl zřejmý — rozchodit verzi 0, tj. verzi která
dokáže bodovat. Při jízdě podél zdi vlevo se dostanu až hasícímu přístroji …
jen je to asi po 2h simulace. Nasleduje zase novinka — úzká pasáž, kterou
možná robot X1 neprojede (zatím se mi tam vždy zablokoval). Pro verzi 0 to ale
není priorita.
Včera jsme také diskutovali počítání pozice pomocí quaternionů … a zbaběle
jsem se vrátil k yaw, pitch a roll a kupodivu to na první pohled
nevypadá tak zle:
 3D trajektorie na lidarview.com |
 Pohled na artefakt |
Osekal jsem i „detektor červené” a detekce není příliš daleko od reality:
<pose>158.000000 140.000000 -15.000000 0 0 0.000000</pose>
vs.
3:04:31.273877 2 [160465, 138987, 9424]
tj. 160m, 139m, a shi… ne klídek, to poslední číslo není z, ale úhel,
protože jsem koukal na pose2d a nikoliv xyz nalezeného artefaktu. Ten
jsem tady nenašel … mám tam timeout na 3h a „umřelo” to s pohledem na
hasičák. No nic, jede to teď znova bez GUI.
A teď už jenom jediný detail, přes který se nejspíše dnes nedostanu :-(.
Nedokážu tu zatracenou pozici nalezeného objektu předat do systému, abych
dostal bod. Vygeneroval jsem na toto téma dva dotazy (teď mi na pozadí problikl
mail, že na to amíci reagovali … mmt):
The CommsClient cannot be replaced by ROS. All robot-to-robot communication
must go through the CommsClient, which adds an RF modeling. During the
competition, ROS communication will be blocked.
hmm, tomu moc nerozumím. A to druhé je pouze editace zadání. Tak ještě ping
pong. Nic, nemám z toho dobrý pocit :-(.
TO BE (MAYBE) CONTINUED …
22. prosinec 2018 — Cesta tam a zase zpátky (3:21am)
To byl nějak dlouhý den. A ještě není dobojováno. Simulace momentálně běží na
dvou různých strojích a na svém vidím, že už jsem prohrál :-(.
DETECTED ['TYPE_EXTINGUISHER', 160443, 139374, -14611]
ale hlásí to [Distance bonus]: -1 a v mém debug výstupu je 11.5m
pravděpodobně kvůli špatné konverzi počátku světa.
6:00am
Přeci to nevzdáme!
Na východním pobřeží mají teď půlnoc … tak které časové pásmo platí?
martind@martind-Lenovo-G580:~/md/osgar/examples/subt$ gz log -f ~/.gazebo/log/2018-12-22T040945.151018/gzserver/state.log –filter *.pose/*.pose -z 60 -o ~/.gazebo/log/2018-12-22T040945.151018/gzserver/subt_tunnel_qual_sim_state.log
totiž stále přebaluje :-(
7:00am
Stále se to přebaluje, tedy již hodinu! (ano, je to netriviální doba, která
musí být vzata v úvahu)
Pustil jsem znova simulaci pouze s robotem X1 a je to zhruba 2.5x rychlejší,
tj. srovnatelné s GUI Docker verzi běžící všechny 4 roboty na NVidia GTX 1080.
Podle terminálu se blíží robot k cíli … poslední zatáčka a … něco je
špatně, asi mi nejede kamera nebo nefungovalo světlo :-( … přejel. A teď se
už převrací u úzkého vjezdu do jeskyně.
Obávám se, že další pokus udělám s GUI. (mimochodem to přebalení stále není
hotové)
No super, to světlo opravdu nefunguje. :-( … asi je to součást teleoperace,
kterou jsem také vyhodil?!
Nevím, uteklo 1.5h a stále to není přebalené!
8:00am
Opakuji se, ale stále to není přebalené. Za hodinu bude půlnoc i na západním
pobřeží a tak trošku propadám depresi :-(. Pustil jsem znova simulaci se
zapnutou teleoperací a světlo fungovalo! S GUI to bylo pomalé (250 pozic za
minutu, kde bez GUI mám 450 pozic) a tak jsem ho zase vypnul. Teď jsem raději
koukal i na začátek logu a světlo je zapnuté … tak se můžu vsadit, jestli to
bude do 9:00 přebalené nebo doběhne simulace s jedním robotem? Tipoval bych, že
ani jedno a bude vhodný okamžik si jít lehnout.
Vlastně je možná vhodný okamžik pro review … to co jsem si v noci říkal, že
sepíšu až ráno, až budu čerstvější. Jak naivní. Ale mám pocit, že už s tím
více nenadělám, takže takové „odevzdání osudu”.
Začnu asi s tím hobitím podtextem „cesta tam a zase zpátky”, resp.
Cimrmanovské „Dobytí severního pólu”, kdy „rezervy jsou nedotknutelné a krom
toho jsme je včera snědli”. A nezapomeňte to vynásobit dvěma! No velkou
oklikou mířím k tomu, že jedna věc je artefakt najít a přesně zmapovat, ale je
třeba výsledek ještě reportovat. Na komunikace s Base Station platí stejné
RF omezení jako u komunikace mezi roboty a prakticky to může znamenat, že se
robot musí vrátit na začátek tunelu a tam komunikace bude garantovaná.
Z pohledu simulace to znamená dvojnásobný čas, který i nyní je celkem dlouhý
(nemluvím o přebalení logu, to stále není hotové = 2 hodiny žádná doba!).
Byl jsem rád, že mi již fungovala jízda podél zdi pro obě varianty (levá a
pravá), ale drobný zádrhel se objevil u otáčení. Upravený algoritmus totiž byl:
jeď podél levé zdi dokud nenarazíš na artefakt, otoč se o 180 stupňů a jeď
zpátky podél pravé zdi daný počet původně ujetých metrů + 5 (chtěl jsem mít
jistotu, že z tunelu vyjede). Výsledkem bylo
celkem vtipné video, kde se X1 propadne
podlahou startovní oblasti (reportovaný
bug
#37).
Pak jsem opravil detekci, aby nevracela numpy int, který se neuměl
serializovat (problém OSGARa) a hacknul kód aby reportoval hasičák krátce po
vjezdu do tunelu, ale s přesnými souřadnicemi podle vstupního modelu.
Výsledek? Skóre 0 bodů?! Tak z toho vypadl
bug #38,
kdy jsem se ale dozvěděl, že existuje
dokumentace k API a je třeba
poslouchat na startu topic /subt/pose_from_artifact_origin a offset se
dozvím. Hloupě jsem ho opsal z jejich unit testu … a byl jiný. Je to parametr
každého světa. Nejmenovaná osoba dělala paralelní testy (okolo té třetí hodiny
ráno) a tím špatným offsetem to nakonec nic nenašlo, přestože souřadnice byla
cca 2m od reálné :-(.
Tou dobou jsem také poslal System Track přihlášku, ale jsem si jistý, že
nám ji hodí na hlavu … možná v dalším kole. (ten kašel je příšerný … prý je
to psychické?! … fakt nevím, s čím by to mohlo souviset …
Tak co dál? Když už konečně detekoval a reportoval objekt, tak se mu to
podařilo už hluboko v tunelu. Říkal jsem si proč takové <vulgarismus>,
když to pak stejně funguje napřímo a mám teorii, že tu moji pozici z Pythonu
pokoutně získali i další tři roboti na startu a ti opravdu byli poblíž Base
Station … tak proto zkouším teď ještě jízdu jedním robotem. (koukám, že
jsem znova ,,u otočky'', kde to přejel kvůli zhasnutým světlům ... tak co to
bude tentokrát?)
Vlastně jsem ještě nevysvětlil, že chyba může být i v triviálním otočení se o
180 stupňů. Na Eduru a dalších robotech totiž odometrii celkově integruji,
takže se mi nasčítají otáčky … ale tady přebírám odometrii z ROSu, který to
reportuje jako Quaternion a tam se cykly ztratí. Řešení? Ani se neptejte —
korekce na -PI, +PI a náhrada otočky 180 stupňů za dvakrát 90 stupňů …
„nebyl čas řešit kdo je kdo ... dvě dávky”.
(teď hasičák našel v 48 minutě simulace a vrací se na základnu, tj. do 9am to
nestihne. Ale Hra zatím nezměnila skóre)
9:00am
Ani se neptejte. Ještě to není přebalené … asi vytvořím další tiket. Zatím
poslední byl, že vlastně není jasné, co se má odeslat viz
bug
#39.
- #40 Filter the simulation state takes hours a tím bych to asi pro dnešek zabalil …
23. prosinec 2018 — 1:0 pro Cogito!
Jirka se sice tomuto bodovému hodnocení brání, ale je to rozdíl mezi tím
dosáhnout výsledku a nebo nic, tj. za mne rozhodně bod patří Cogito Teamu (nebo
sub-teamu ). Vedle vyladění regulátoru na jízdu podél zdi, aby robot
tak zuřivě nekmital, přibylo poslání souřadnic detekovaného artefaktu až po
dokončení jízdy po výjezdu tunelu. Ona totiž funkce SendToBaseStation()
vrací true (viz
bug
#41, nebo je to feature?) i když je vyslání úspěšné, ale příjemce to
nepřijal. A výsledek?
[Msg] Scoring has Started [Msg] [Distance bonus]: x1 [Msg] [Time bonus]: x1 [Msg] [Total]: 1 [Msg] Total score: 1
Jirka natočil i dvě videa: pohled z Gazeba a
pohled z robota (OSGAR).
|
|
|
|
Uploaduji 218MB nezkonvertovaného logu (což je proti pravidlům, ale
konverze jsme se nemohli dočkat) … a zatím nic … tak jo, je to tam .
Trvalo to možná 5-10minut. Status: Pending. Tak uvidíme až se dostane do
stavu Rejected.
27. prosinec 2018 — Im Westen nichts Neues
Na západní frontě je stále klid — na příspěvky přes vánoce nikdo nereagoval a
oba odeslané pokusy (raw zmiňovaný výše a filtered, kde konverze trvala
8 hodin!) jsou stále ve stavu „Pending”.
Začal jsem tedy alespoň s „údržbou”: na githubu jsem vytvořil tag
SUBT_QUAL_STIX_2018
na kód, kterým jsme získali první bod. Dále jsem uploadoval log z Jirkova
úspěšného pokusu
osgar-subt-181222_183949.log.
Konečně jsem si do notýsku napsal více jak dvě stránky bodů, co je třeba dále
udělat.
Asi první by bylo korektně rozchodit /subt/pose_from_artifact_origin, tj.
získání přesné pozice robota vůči soutěžní souřadné soustavě. Toto nově zavedli
i pro System Track, kde na vstupní bráně jsou speciální QR-kódy
(AprilTag):
 Označení počátku soustavy souřadné u vstupu do tunelu |
Ve Virtual Track je toto suplováno pomocí ROS Query, tj. předpokládám
Request/Respone, což v
ROSProxy zatím OSGAR
implementované nemá.
Další detail, co mne „trošku” štval, byla ta světla. Jsou minimálně tři,
oprava čtyři:
/X1/center_left_headlight/enable /X1/center_right_headlight/enable /X1/left_headlight/enable /X1/right_headlight/enable
Plus je tam ještě sada LED, které jsem ani nezkoušel:
/X1/left_lateral_front_led/enable /X1/left_lateral_rear_led/enable /X1/rear_center_led/enable /X1/rear_left_led/enable /X1/rear_right_led/enable /X1/right_lateral_front_led/enable /X1/right_lateral_rear_led/enable
Pro každou tuto „blbost” je třeba vytvořit TCP spojení a poslat True. Pro
ovládání z joysticku byly všechny světla svázány do /X1/light, což bylo o
něco snazší, a je to důvod, proč jsme ponechali Teleop node v konfiguraci
týmu.
Abych jenom nelamentoval, tak na co se těším je zjistit pozici robota před
vjezdem do tunelu a po návratu. Proč? No mělo by z toho být zřejmé, jak velké
chyby jsme se integrací dopustili a teoreticky jí snížit třeba na polovinu.
Stejně tak bych rád „oblíbený hasičák” přesně lokalizoval (teď počítám jen
pozici „když jedu kolem”) a našel bych snad odpověď na otázku, jak moc přesně
je možné čistě z virtuální odometrie objekty mapovat.
Další krok jsou RGB-D kamera (tj. včetně hloubky) a „vertical Lidar”
(předpokládám něco jako Velodyne Puck 16 s množstvím 3D bodů na výstupu). Jo a
vedle pozemních robotů je na čase asi zkusit i drony a začít sledovat i stav
baterie (opět v seznamu chybí,
nebo ho nevidím). To vše ale asi až po nějaké reakci od organizátorů …
p.s. na tom obrázku mají soustavu souřadnou pootočenou o 90 stupňů … to snad
také „doladí”.
28. prosinec 2018 — Robotika.cz System Track update
Věřte nebo nevěřte, ale DAPRA nás ještě do háje neposlala! Včera jsme
dostali mail, že je třeba do 11/1 doplnit video se STOP tlačítkem a video s
detekcí artefaktů. Takže to ještě není ztracené …
Na detekci lidí jsem chtěl použít loňské experimenty s
TensorFlow Object
Detection API, kdy to občas funguje pěkně:
a občas hrozně, tj. chce to dodatečnou filtraci. Z předučeného modelu by to
mělo samo, vedle lidí, detekovat i batohy a mobily, což jsou další dva typy
artefaktů, které v SubT Challenge budou. Ostatní by bylo nutné doučit jako v
pěkném článku
Building
a Toy Detector with Tensorflow Object Detection API, tak konečně bude trošku
tlak to „prošťouchnout”.
Pro detekci jsem použil starý model ssd_mobilenet_v1_coco_11_06_2017 z
Common Objects in Context datasetu.
30. prosinec 2018 — Virtual Track: artefakty
The SubT Virtual Portal will begin accepting Virtual qualification
submissions on December 1, 2018. … no to se snad stalo, ale uploadované
logy z 23/12 jsou stále ve stavu pending. Po pravdě předevčírem byl jeden
log ve stavu rejected a tak jsem se zeptal proč
(report
#43) a aniž by někdo odpověděl, tak se zase změnil zpět na pending.
DARPA expects to distribute approximately 10 artifacts throughout the
environment. To achieve the minimum score threshold, teams will need to
accurately locate at least half of the artifacts within 20 minutes of
simulation time. … OK, ale pokud artefaktů je místo deseti osmnáct? Je
minimum tedy 9?? Asi jo, tak je na čase rozpoznávat další. Následující vzorky
lze získat jízdou podél pravé zdi:
 Valve |
 Valve z blízka |
 Backpack |
 Backpack detail |
 Electrical Box |
 Electrical Box detail |
p.s. tak tu bednu, ale ani batoh pomocí laseru na robotovi X1 s první
konfigurací vidět není (pravděpodobně je laser 2D rovina výše než výška
bedny/batohu). Výjimka je roura s uzávěrem — ta je vidět pěkně:
(čas v záhlaví okna ignorujte — je to z logu
subt-181219_122102.log, kde
jsem měl špatně masku 0xFFFF na časové známky místo 0xFFFFFFFF)
1. leden 2019 — Happy New Year & SubT matfyzácky
U novoročního bloumání a sekání dříví jsem přemýšlel, jestli si z nás DARPA
nedělá srandu a co je vlastně vůbec teoreticky možné dosáhnout? Vzpomněl jsem
si na „teorii grafů” a Eulerovu kružnici. Pro zmapování celého podzemí je
třeba projít všechny chodby. Křižovatky jsou vrcholy/uzly grafu a chodby hrany.
No a průchod všech hran grafu je ta Eulerova kružnice nebo Eulerův tah,
jestli se nepletu. A aby šel vůbec najít, tak každý uzel musí mít sudý stupeň a
celý graf musí být souvislý … no snad ty pojmy po letech moc nemotám.
Co dělat v situaci, když graf nemá všechny uzly sudého stupně? Zdvojíme hrany a
robot danou chodbu projede dvakrát. OK?
Dosud ignoruji fakt, že informaci o nalezených artefaktech lze poslat z jiného
místa než ze startu a potenciálně přes jiné roboty. Prostě nechť je startovní a
cílový uzel ten samý.
Pokud máme tedy mapu tunelů, lze spočítat délku trasy nutné pro kompletní
zmapování jedním robotem. Dlaždice, spíše dílky, světa jsou velké 20 metrů —
nechť na jejich průjezd je třeba 20 metrů jízdy.
Chtěl jsem zase grepovat tunnel_qual.world, ale z názvu tile_0 až
tile_119 lze celkem dobře „odhadnout”, kolik těch dílků je … 120. Po
20m to je 2400m? Na kvalifikaci je 20 minut času = 1200 sekund … tj. i
kdyby celý systém tunelů byla jedna velká kružnice, aby nebylo třeba zdvojovat
žádné hrany a robot by každou chodbou projel právě jednou, tak to znamená jet v
průměru 2m/s. Ha ha ha (robot X1 má maximální rychlost 0.9m/s a X2 1.8m/s, ale
zatím jsme ho nezkoušeli).
subt/x1_control/config/control.yaml
# Velocity and acceleration limits
# Whenever a min_* is unspecified, default to -max_*
linear:
x:
has_velocity_limits : true
max_velocity : 0.9 # m/s
has_acceleration_limits: true
max_acceleration : 3.0 # m/s^2
angular:
z:
has_velocity_limits : true
max_velocity : 2.0 # rad/s
has_acceleration_limits: true
max_acceleration : 6.0 # rad/s^2
subt/x2_control/config/control.yaml
max_velocity : 1.8 # m/s
max_acceleration : 7.0 # m/s^2
max_velocity : 4.0 # rad/s
Jaké mají limity drony nevím :-(.
Ten graf kvalifikačního světa připomíná spíše
strom, kde je třeba zdvojit všechny hrany! To znamená 4800m objízdné trasy
(ano, uprostřed je kružnice, takže možná stačí 4km?). I kdyby šlo průzkum
„super-paralelizovat”, tak každý robot musí za těch 1200s ujet 1200m. Ale to
úplně nejde — asi nejsnáze si to představíte tak, že pokud by „systém
tunelů” byla jenom jedna rovná dlouhá chodba a všichni roboti byli na jejím
začátku, tak je jedno, zda to bude mapovat jeden nebo deset robotů … nemají
si jak pomoci. Stačí pouze ten nejrychlejší … a ano, ostatní mu můžou
připravit komunikační síť, ale to někdy příště …
Roboty můžeme nasadit čtyři, tj. přirozená strategie je dva pustit do pravého a
dva do levého křídla (možná s jedním opakováním). Jízda podél zdi tak hloupá
není, otázka jak poznat, že robot/drona má vyletět vzhůru??
3. leden 2019 — Robot X2, Cogito 4:0 a STIX v Edgar Mine v Colorado
Dnes jenom „rychlé zprávy” (timeout byl před dvaceti minutami). Včera v noci
jsme s Jirkou zkoušeli robota X2 s konfigurací 3 a 4, tj. s SICK lidarem s
dosahem 30m (ale co jsem koukal pak do konfigurace
subt/x2_description/urdf/accessories.urdf.xacro je tam limit na 20m —
zase mi to nefungovalo jako u X1 a musel jsem modifikovat
min_range="0.2"). Robot je menší a jede viditelně rychleji. Jirka si
upravil všechny parametry (je třeba i rychleji zatáčet, což já neudělal a tak
jsem míjel odbočky) a výsledek? Skóre 4 body! … shodou okolností (?)
pozice byla přesnější (2x násobení bodu) a robot to stihl zpět za poloviční čas
(8 minut, další násobení 2x). Upload na portál dnes Jirka udělá již přímo. A
mimochodem i tam je drobná změna:
Oba logy z 23/12 jsou approved! (ano, pouze jeden bod ) … tj. nyní
neplánujeme 200MB log více jak 8 hodin filrovat (na to se zatím neozvali).
Další zásadní info je na téma System Track. DAPRA zveřejnila
STIX_Operations_Guide.pdf,
kde jsou podrobné instrukce o dubnové STIX lokaci:
Edgar Experimental Mine in
Idaho Springs, Colorado … což je podle všeho školní důl, podobně jako ten
náše Štola Josef.
Z detailů, co mne zaujali, byl tento: As a reminder, Denver is at 5,280 ft.
mean sea level (MSL) and Idaho Springs is at 7,526 ft. MSL, so everyone is
encouraged to hydrate before and upon arriving in Colorado to prevent altitude
sickness. … prostě je to vysoko v horách!
TO BE CONTINUED
4. leden 2019 — Robot X3 — Take Off!
Kupodivu se to nezlepšuje — dnes byl timeout před 45 minutama :-(. Ale přitom
se toho děje poměrně hodně. Včera jsme dodali DARPA videa Robika (STOP
tlačítko) a první detekce objektů z Edura. Večer jsme se bavili s Jirkou, co by
se mělo udělat a co bychom kdo chtěli dělat … bohužel to jsou trošku odlišné
věci. Robot X2 dorazil až k zadní krabici s elektrickými rozvody a také do ní
narazil, tj. ani nižší robot nemá úroveň laseru níž než výška krabice. TODO je
alespoň detekce nárazu z IMU a v lepším případě analýza obrazu (to je oblast,
kde by si chtěl hrát Jirka).
Já si chvíli hrál s dronou X3 a kupodivu to vůbec nefungovalo. Jednak se
jednotlivé ROS topicy jmenují jinak (viz
bug #44) a
posílané standardní pakety jsou i jinak veliké! To ale byla chyba na naší
straně v parsovaní ROS zpráv — částečně fixed.
No a asi hlavní rozdíl od pozemních robotů X1 a X2 je, že je pro pohyb nutné
vzlétnout … takže malý hack na rychlost v ose Z = 0.4m/s (0.1 bylo málo a
1.0 i 0.5 přeletěl vchod do tunelu). Ale něco z toho už vypadlo, viz
video prvního vzletu s konfigurací #2 (kamera
s vyšším rozlišením). Další krok je RGBD kamera v konfiguraci #3, ale to až
„někdy příště”.
p.s. vtipné bylo, že občas detekoval hasičák … vidí své červené vrtule ..
5. leden 2019 — sensor_msgs/PointCloud2
Ještě včera jsem si nahrál data z drony X3 s konfigurací #3 (RGBD kamera
320x240). Sigh, hrůza. Odsimuloval jsem cca 5 sekund s faktorem 0.03, tj. 33x
pomalejší než realita, a za tu chvíli nasbíral 150MB dat :-(. A ano, zase jsou
úplně totálně k ničemu. Jeden „snímek” má 2.5MB (posílá to na 13Hz, což
nevím, zda je omyl nebo to vypadává … v
subt/x3_description/urdf/x3_with_sensors.xacro píšou
update_rate="20", takže nestíhá … ale pokud by stíhal, tak je to 50MB/s).
To jenom jeden robot pro jednu 20 minutovou (simulovaného času) simulaci by
sežral 20*60*50 = 60000 … 60GB! F*k
Kdyby z toho lezlo alespoň něco pořádného, ale data vypadají následovně:
M:\git\osgar>python -m unittest osgar\drivers\test_rosmsg.py b'X3/rgbd_camera_frame_optical' 7 610000000 240 320 False 32 10240 (3.4438311059246704e-39, nan, nan, nan) (0.0, nan, nan, nan) (0.0, nan, nan, nan) (0.0, nan, nan, nan) (0.0, nan, nan, nan) (0.0, nan, nan, nan) (0.0, nan, nan, nan) (0.0, nan, nan, nan) (0.0, nan, nan, nan) (0.0, nan, nan, nan) False
Hmm, to byla rozhodně odfláknutá analýza! Místo výpisu jsem přidal asserty:
for i in range(height*width):
pt = struct.unpack_from(' 0:
assert str(pt) == str((0.0, nan, nan, nan)), (i, pt)
a
AssertionError: (29440, (0.0, -2.961944580078125, -0.510680079460144, 5.146306037902832))
Takže tam jsou i nějaká rozumná čísla! Na začátku struktury je popis „blobu”
se jmény x, y, z a rgb. Celkově mi to nějak nesedělo o
4 bajty, takže teď pře …. chtěl jsem napsat předpokládám, ale už vím … jsou
tam uint8[] data, takže data předchází velikost proměnného bufferu. Tak
alespoň nějaká dobrá zpráva.
Tak jo, prima … teď už velikosti pěkně sedí a tedy i ten assert má správné
pořadí:
AssertionError: (29440, (-2.961944580078125, -0.510680079460144, 5.146306037902832, 0.0))
rgb (poslední číslo) je vždy nula … není nad to si ukládat 240*320*4 =
300kB nul, to je vlastně horší než RGB snímky bez komprese. No nic. Mimochodem,
pokud ten 150MB log zazipuji, tak se dostanu na 2MB, tj. je tam prostor pro
zlepšení pokud neexistuje nějaký kompaktnější topic.
Tak jo, další krok je jasný — zipování RGBD přijatých dat. A pak se můžu
vrátit k původnímu plánu, tj. spočítat si jak daleko jsem od země a podle toho
letět nahoru/dolů. Cíl je vletět do tunelu a rovně narazit až do slepé odbočky
cca po 220m.
p.s. možná bych měl zmínit ještě jednu motivaci, proč se trápím se
sensor_msgs/PointCloud2
ROS zprávou. Mám trošku výčitky svědomí co se týče vývoje ROS driveru pro
Pulu TOF senzor …
p.s.2 po
brutálním
hacku už alespoň stihl doletět až k tunelu a nalogovat
subt-190105_093306.log
(80MB, cca 5 minut reálného času).
11. leden 2019 — System Track: kostky jsou vrženy
Dnes byl dead-line na doplnění videí ke kvalifikaci na STIX v dubnu 2019 v
Colorado/USA. Jednalo se o video demonstrující STOP tlačítko na obou robotech
(Robík a Eduro) s tím, že Robík přesně splňuje požadavky (stav je indikován
pomocí LEDek, které ve STOP stavu blikají červeně) a Eduro funguje jako
posledních 12 let, tj. tam si možná budou stěžovat/zamítnou to.
Druhá část byla automatická detekce artefaktů. ND Team natočil „scary movie”
jak Robík jezdí po tmě po bytě a robot si svítí baterkou. Zkoušel jsem na to
pak použít přímo
TensorFlow
Object Detection API (git checkout mám z loňska) a detekci člověka sedícího
na podlaze to fungovalo velmi pěkně. Hasicí přístroj byl sice detekován jako
„bottle”, ale i to bylo relativně OK. Co ale vůbec nefungovalo byla detekce
batohu.
Postupoval jsem tedy podle
článku
s kačenkou, nainstaloval si
labelimg pro Windows (verzi
1.8.1), vygeneroval sadu obrázků pomocí
avi2jpg.py
a začal anotovat:
Kupodivu, když si uživatel zapne automatické ukládání (View/Auto Save
mode), přepne na anotování pouze jednoho objektu (View/Single Class Mode)
a používá w na spuštění Create RecBox, tak to jde celkem rychle. V
prvním kole jsem anotoval pouze 36 obrázků s batohem, abychom vyzkoušeli jak
celá ta mašinérie funguje. Výsledné video (kvůli DARPA bohužel unlisted)
obsahuje „batohy všude kam se podíváš” … prostě pokud něco mohl být nějaký
objekt, tak z toho klasifikátor udělal backpack.
V druhé fázi jsem anotoval všechny tři typy, takže obsah souboru
predefined_classes.txt byl:
backpack extinguisher person
a anotovaných obrázků bylo 113 (vše z jednoho zdrojového videa). Výsledkem
tohoto kroku je množství XML souborů, které se jmenují stejně jako původní
obrázky jenom mají změněnou koncovku. Obsah pro představu vypadá takto:
<annotation> <folder>data</folder> <filename>img_0342.jpg</filename> <path>D:\md\git\labelimg-windows_v1.8.1\data\img_0342.jpg</path> <source> <database>Unknown</database> </source> <size> <width>640</width> <height>480</height> <depth>3</depth> </size> <segmented>0</segmented> <object> <name>extinguisher</name> <pose>Unspecified</pose> <truncated>0</truncated> <difficult>0</difficult> <bndbox> <xmin>163</xmin> <ymin>95</ymin> <xmax>268</xmax> <ymax>452</ymax> </bndbox> </object> </annotation>
Na konci anotačního procesu je třeba získat TFRecord, kde asi
nejpřímočařejší řešení, co jsem narychlo našel na webu, byl
xml_to_csv.py
skript, co všechny anotace převede do jednoho souboru:
filename,width,height,class,xmin,ymin,xmax,ymax img_0137.jpg,640,480,backpack,82,106,204,228 img_0138.jpg,640,480,backpack,111,110,226,219 img_0139.jpg,640,480,backpack,130,105,239,212 img_0222.jpg,640,480,person,264,1,586,374 img_0326.jpg,640,480,extinguisher,214,80,276,305 …
a pak upravený
generate_tfrecord.py,
kde je třeba předat všechny vstupní parametry: csv_input, output_path a
image_dir, vytvoří jeden record pro TensorFlow. Jenom poznámka, že
potřebujete dvě sady — jednu pro trénování a druhou pro vyhodnocování
úspěšnosti.
Další krok bylo samotné učení, kdy jsem si nakopíroval konfigurační soubor faster_rcnn_resnet101_coco.config a stáhl a rozbalil tomu odpovídající model do zdrojového adresáře. Nutný byl ještě triviální label_map.pbtxt:
item {
id: 1
name: ‘backpack’
}
item {
id: 2
name: ‘person’
}
item {
id: 3
name: ‘extinguisher’
}
a učení mohlo začít. V adresáři models\research\object_detection bylo třeba pustit:
python object_detection\train.py –logtostderr –pipeline_config_path=data\md_faster_rcnn_resnet101_coco.config –train_dir=md_train
(jenom papouškuji, co jsem našel na webu a zatím slepě opisoval) a po hlášce:
UserWarning: Converting sparse IndexedSlices to a dense Tensor of unknown
shape. This may consume a large amount of memory. mi to opravdu sebralo
všechnu paměť. Nemohl jsem v první fázi prohazovat okna a ve druhé fázi už
ani hýbat myší … tak jsem šel spát, protože natvrdo vypínat počítač, kde se
disk točí jak blázen by byla nejspíše konečná!
Ráno naštěstí došlo místo na cílovém SSD disku a proces se zastavil. Výsledkem byl model „backpacks everywhere”, který bylo možné získat přes volání:
python export_inference_graph.py –input_type image_tensor –pipeline_config_path d:\md\git\models\research\data\md_faster_rcnn_resnet101_coco.config –trained_checkpoint_prefix d:\md\git\models\research\md_train\model.ckpt-64 –output_directory subt_2019_01_09
kde model.ckpt-64 byl „checkpoint” uložený při učení.
Pro velký úspěch jsem to zkusil, po uvolnění několika GB místa na disku, další
noc znova, tentokrát se třemi artefakty. Následná konverze videa trvala
nezdravě dlouho (3 hodiny na cca minutové video) a výsledek? Vůbec nic! To
vlastně bylo včera. Ukázalo se, že to místo došlo už po cca 30 minutách učení
a to je příliš krátká doba. Poslední dva dny to samé dělal paralelně i
Jakub/Eduro Team a štafetu přebral a dotáhl. Ještě jednou veřejné podekování!
Jakub to nazval „video s člověkobatohem”, protože na detekci člověka to síť
trošku míchala, ale za mne více než dobré! Tak uvidíme, co na to organizátoři
… nějaké oficiální vyhlášení je plánované na 18. ledna 2019.
18. leden 2019 — STIX Qualification
The DARPA announcement is expected no later than January 18. — tak
uvidíme, zatím ho nikde nevidím.
Jinak co se Virtual Track týče, tak tam se opravdu žádný STIX nekoná
(zatím):
STIX for
Virtual Track? (fórum vyžaduje registraci):
We are considering options for a similar STIX-like event for the Virtual
Competition and will be releasing more information in the coming weeks.
Konečně na poli zdrojového kódu pro Virtual Track jsou změny v názvech
„topiců” (sám jsem si je vyžádal, tak si nemůžu teď stěžovat … jenom stará
verze 0 již nebude s nejnovější repository fungovat). Viz
#44.