czech english

DARPA Subterranean Challenge

podzemní týmová robotika

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: 17/12 — Gambler and Abyss (zbývají 4 dny)

Pravidla v kostce

Oficiální pravidla myslím ještě nejsou úplně veřejně k dispozici. DARPA předevčírem (27. září 2018) pořádala Competitors Day, který bylo možné po registraci sledovat online. Asi zásadní bylo PDFko SubT Challenge Guidelines, které bylo přiloženo k registračnímu mailu a organizátoři ho snad brzy zveřejní na stránkách subtchallenge.com dedikovaných soutěži.
(The SubT Challenge Qualification Guide will be posted on the SubT Challenge website and SubT Community Forum by October 31, 2018 and will include qualification details and submission instructions.)
Celá soutěž je rozvržená na 3 roky (Final Event - August 2021) a skládá se ze tří různých prostředí: Tunnel Circuit, Urban Circuit a Cave Circuit. Cílem robotů je jednak mapovat předem neznámé prostředí a dále lokalizovat různé předměty (artefakty) a reportovat jejich pozici. Hodnocena bude jak přesnost lokalizace, tak dostatečná včasnost reportu.
Prostředí bude 3D, více pater a různé složitosti. Nejmenší průchody by měly být alespoň 1m x 1m veliké. Účastnící se můžou tešit na vodu, bláto, kouř, překážky a DARPA ví co ještě …

28. říjen 2018 — Resources

Dnes jsem koukal na stránky pořadatele, zda nejsou již k dispozici nová pravidla, a narazil na Resources. Přesměroval jsem tedy link SubT_Guidelines.pdf přímo na pořadatele (nikomu z čtenářů nechyběl, tak ho již ani na robotika.cz uploadovat nebudu), ale jsou tam odkazy na Virtual Testbed Wiki a prezentace z „Competitiors Day”.
https://bitbucket.org/osrf/subt/wiki/Home
https://bitbucket.org/osrf/subt/wiki/Home

31. říjen 2018 — SubT Challenge Qualification Guide

DARPA dnes vyvěsila šestistránkový SubT_Qualification_Guide.pdf aneb pravidla, jak se na SubT Challenge kvalifikovat. Trošku mi to připomnělo video homologaci na Robotour:
  • na unlisted YouTube videu demonstrovat funkci STOP tlačítka (navíc je třeba indikovat, že je robot vypnutý). Roboti nad 10kg musí mít vedle remote STOP i fyzické tlačítko na robotovi.
  • předvést 25m autonomní jízdy (bez GPS). Trasa musí obsahovat alespoň dvě ostré (90 stupňů) zatáčky a těsnou pasáž (nejvýše 1.2m širokou a alespoň 3m dlouhou). Trošku odlišené podmínky jsou pro létající roboty — koridor je omezen také výškou (1.5m x 1.5m). Pro velké létající roboty pak pasáž může být až 2x vyšší a širší než robot samotný.
  • alespoň jedna platforma musí být schopna detekovat artefakty v úplné tmě. Navíc to musí být minimálně 3 druhy popsané v pravidlech.
Pro Virtual Track je třeba dokončit kvalifikační scénář a poslat log z úspěšné jízdy.
DARPA může po odeslání přihlášky a dokumentů tým kontaktovat, vyžádat si telekonferenci a probrat případné detaily přihlášky.
Tak co, jde do toho někdo? Nezbývá příliš času …
Termíny jednotlivých kvalifikací
Termíny jednotlivých kvalifikací

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 …