czech english

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
Dnes už vjeli roboti X1 a X2 (tak se jmenují pozemní čtyřkolky) do tunelu.
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
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
3D trajektorie na lidarview.com
Pohled na artefakt
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.

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
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
Valve z blízka
Valve z blízka
Backpack
Backpack
Backpack detail
Backpack detail
Electrical Box
Electrical Box
Electrical Box detail
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_0tile_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??
Přeji vám všem hodně štěstí, zdraví a robotické zábavy do roku 2019!

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.