Robotour 2026: první celé doručení a chyba, která zavírala správné cesty

Letošní Robotour se jel v sobotu 19. září 2026 v pražské Stromovce ve spolupráci s Planetáriem Praha, přihlášeno bylo dvanáct týmů. Do Stromovky se ARBot vrátil po čtrnácti letech — v roce 2012 tu skončil pátý. Zadání je pořád stejná simulace doručování: robot vyjede z depa, u nakládky mu obsluha ukáže QR kód s cílem, robot náklad doveze a vrátí se. Letos se navíc pravidla změnila v tom, že po vykládce smí následovat rovnou další nakládka. Robot jede bez operátora; jediné lidské vstupy jsou QR kód a tlačítko nouzového zastavení.

Pro robota to byla první soutěž se softwarem přepsaným od základu, který vznikal od června. Všechny mise se do té doby jezdily v simulaci a na testovacích výjezdech, a jak se ukázalo, věci, které simulace nikdy nezkusila, přišly hned v prvních dvou kolech. Každý běh robota se nahrává, takže se záznamy daly rozebrat hned na místě: první opravy vznikly z logů už během soutěže, po předkole a po prvním kole. Co zbylo, se rozebralo do čísel druhý den.

Předkolo (9:00–10:00): robot nepřečetl QR kód

Testovací předkolo vypadalo ze začátku dobře. Než mise začne přijímat kód, potřebuje si nejdřív spolehlivě zaměřit polohu depa z GPS, a to se povedlo za pět sekund (šestnáct družic, HDOP 1,36 — HDOP je číslo, které říká, jak dobře jsou družice na obloze rozmístěné, čím menší, tím lepší). Robot pak čekal pod drženým stopem na kód. Ukazoval jsem mu ho z mobilu, z displeje notebooku, nakonec i vytištěný na papíře, kroutil s ním, přibližoval, oddaloval — a stránka náhledu v telefonu po celou dobu tvrdila „kód nevidím". Po čtyřech minutách bylo jasné, že se nerozjede.

Rozbor záznamu na notebooku dal odpověď za pár minut. Skener v záznamu neposlal ani jednu zprávu s přečteným kódem, ale offline dekodér nad týmiž snímky ho čte v 725 z 3 957 snímků obou kamer. Kód tedy v obraze byl, jen se k dekodéru nedostal. Příčina je až trapně prostá: skener čte z kamery jménem Right, jenže skutečná kamera D435 se v aplikaci jmenuje Right 740112071021 — driver skládá název a sériové číslo. Virtuální kamera v simulaci vrací holý název, takže simulace i všech devatenáct testů skeneru procházely a na skutečném robotu skener nikdy nedostal snímek.

A byla v tom ještě druhá past. Stránka náhledu kreslila první kameru, která poslala snímek, tedy levou. Podle telefonu jsem tak ukazoval kód levé kameře (ta ho trefila už v 9:30:04), zatímco se mělo číst z pravé (ta ho viděla až v 9:31:25). V terénu je stránka náhledu jediné místo, které ukazuje, co robot vidí — a když kreslí levou kameru, člověk kód přirozeně nastaví levé kameře.

První kolo (10:00–11:00): GPS brána a ostrov v mapě

Oprava skeneru byla nasazená před startem kola a čtení kódu na robotu hned potvrdil první běh: v 10:04 mise zaměřila depo za šest sekund, kód přečetla a přijala. Jenže pak jsem robota přesunul na start do servisní zóny a od té chvíle se v dalších třech bězích střídaly dvě jiné poruchy.

Mise se nedokázala zaměřit v depu. V 10:15 robot stál v servisní zóně 158 sekund a mise pořád čekala na spolehlivou polohu z GPS. Stránka ukazovala nejistotu polohy 60–70 m, což vypadá hrozivě, ale je to jen číslo, kterým se poloha z GPS váží při skládání odhadu polohy robota, a podmínkou pro zaměření depa to není. Ta zní: alespoň šest družic a HDOP nejvýš 2,0 nepřerušeně 5 sekund. Pod stromy u Planetária byl HDOP 1,74–2,95 (medián 2,30) při 12–16 družicích, takže podmínce vyhovovalo 4,7 % měření a nejdelší nepřerušená série byla 3 sekundy z pěti potřebných. S prahem 3,0 by vyhovovala všechna měření celého záznamu. Práh je od té doby nastavitelný a provozní nastavení má 3,0 — rozptyl polohy hlídá jiná podmínka, HDOP tu má chránit jen před vyloženě špatným rozmístěním družic. Ve třetím kole se to hned vyplatilo: robot si zaměřil depo s HDOP 2,71 a šesti družicemi, s původním prahem by nevyjel.

Kód se četl, mise ho zamítala. V bězích v 10:11 a 10:19 skener kód přečetl 535× a 195×, a mise ho pokaždé odmítla s hláškou „na cíl nevede po síti žádná trasa (je mimo mapu?)". Jenže cíl z kódu je přesně uzel mapy na živé cestě. Stránka navíc důvod zamítnutí vůbec neukazovala, dál psala „čeká se na QR kód", takže jsem to na místě neměl jak poznat. Rozbor proti mapě, kterou runtime skutečně měl, ukázal, že síť cest se rozpadá na dvě navzájem nespojené části: chodníky se 169 křižovatkami a 4,3 km cest, a vedle nich ostrov — dlážděné náměstí před Planetáriem (highway=pedestrian, area=yes), 40 uzlů na 139 metrech, které je se zbytkem sítě spojené jedině schody. Profil robota schody nepouští. GPS posadila robota na to náměstí (3–4 m od jeho uzlů), poloha robota se přichytila na jeho okraj, a z ostrova samozřejmě nevedla žádná trasa. V 10:04 týž kód prošel jen proto, že robot stál o padesát metrů dál na chodníku.

Druhé kolo (11:30–12:30): poprvé vyjel — a došla baterie

S oběma opravami se robot ve druhém kole konečně rozjel: v 11:37 mise zaměřila depo za pět sekund, kód přečetla a přijala, robot opustil servisní zónu a pěkně si zamířil k nakládce. Po 27 sekundách jízdy a zhruba padesáti metrech se zastavil. Ne kvůli softwaru — vybitá baterie. Robot byl zapnutý od rána a při opravách po prvním kole jsem se tak soustředil na kód, že jsem ho zapomněl zapojit na nabíječku.

V záznamu je to nepřehlédnutelné, jen to tam nikdo nečetl: medián napětí baterie z motorové jednotky byl dopoledne 12,1 V, ve druhém kole už 10,6 V a poslední hodnota před useknutím záznamu 10,0 V; po nabití před třetím kolem 12,5 V. Napětí ale nikde na stránce náhledu není a nic na něj nevaruje — jediné místo, kde se ukládá, je záznam.

Třetí kolo (14:00–15:00): celé doručení, pak otočka na pěkné cestě

Robot ve třetím kole jel, jak měl. Z depa vyjel v 14:10, k nakládce dojel za pět minut, tam přečetl kód s cílem vykládky a za dalších jedenáct minut náklad vyložil — poprvé celý průchod depo → nakládka → vykládka na skutečném robotu, ne v simulaci. Pokus o další nakládku podle nových pravidel jsem nezkoušel, software ji ještě neuměl, takže robot po uvolnění stopu vyrazil zpátky do depa. A tam se po prvním odbočení projevil zádrhel: na docela pěkné cestě se po chvíli otočil, a podle stránky náhledu bylo vidět, že se přeplánovala trasa. Po dalším odbočení uvízl v hrubém písku. Zbytek cesty do depa dojel v režimu bez mapové navigace (jízda v koridoru cesty).

Na místě jsem to bral jako smůlu, ale záznam ukazuje něco jiného: za 24 minut a 830 metrů jízdy navigace šestnáctkrát penalizovala úsek cesty, po kterém robot právě správně jel — třikrát cestou k nakládce, osmkrát cestou k vykládce a pětkrát cestou do depa. Že to dopadlo dobře až do vykládky, byla náhoda: penalizovaný úsek zůstal i tak nejlevnější cestou, takže trasa se nezměnila a robot jel dál. Cestou do depa se poprvé našla objížďka (trasa se protáhla z 299 na 536 m) a robot se na té pěkné cestě otočil. Ve chvíli poplachu přitom plánování cesty mezi překážkami v okolí robota hlásilo 82–101 % plánů v pořádku a robot jel rychlostí kolem 1 m/s. Detektor bloudění se totiž díval na odhad zbývajícího času do cíle, který má při postupu k cíli klesat — a ten rostl přesně o 1 sekundu na metr. Vysvětlení je v poslední části.

Čtvrté kolo (15:30–16:30): tam a zpátky, tam a zpátky

Rychle dát robota na nabíječku a nahrát software podporující opětovnou nakládku. Do čtvrtého kola jsem nastupoval s nadějí, že se výkon třetího kola zopakuje, nebo ještě vylepší. Robot vystartoval, nabral směr přímo k nakládce, ale po chvíli se otočil a začal se vracet. Na nejbližší křižovatce odbočil doleva, přibližně podobným směrem k nakládce, ale po chvíli se opět otočil. To už bylo opravdu divné. Tohle zopakoval na různých křižovatkách ještě několikrát a z aplikace bylo vidět, jak po chvíli vždy přeplánuje trasu — stejné chování jako v závěru třetího kola, to už nebyla náhoda. Po chvíli bloudění uvízl na úzké vyšlapané pěšince rovnoběžné s hlavní cestou. Konec čtvrtého kola, jeden bod. Po sečtení všech kol měl robot 13 bodů a šesté místo z dvanácti týmů (po kolech 0 + 1 + 11 + 1, výsledková listina) — skoro všechny body vyjel ve třetím kole.

V záznamu je to týž mechanismus jako ve třetím kole, jen zhuštěný do deseti minut. Mezi 15:37 a 15:46 navigace sedmkrát penalizovala úsek, po kterém robot správně jel, a dvanáctkrát změnila trasu. V 15:43:30 penalizovala i hlavní cestu, takže nová trasa vedla úzkou pěšinkou vedle ní a byla o 77 m delší. V pěšince se robot 94 sekund nedokázal dostat k nejbližšímu bodu trasy, protože mapa překážek kolem něj hlásila 41 % plochy jako neprůjezdné. Detektor „nehýbu se" pak uzavřel i pěšinku a od 15:49 robot hlásil kolize.

Co se našlo v záznamech druhý den

Obrácený úsek cesty. Navigace vede robota po síti cest z OpenStreetMap, rozdělené na úseky mezi křižovatkami, a postup k cíli měří odhadem zbývajícího času do cíle, který má při jízdě klesat i při objíždění. Kolik z úseku ještě zbývá, se počítá z toho, kde na něm robot je: když ujel t (0 na začátku, 1 na konci), zbývá 1 − t. Jenže u obousměrné cesty existuje každý úsek dvakrát, jednou pro každý směr, a navigace si vybere ten levnější — při jízdě proti směru, v jakém byl úsek do mapy zapsán, tedy ten obrácený. Pro něj ale zbývá t, ne 1 − t. Výsledek: odhad času do cíle při správné jízdě rostl o sekundu na metr, po každých 20 metrech detektor bloudění viděl „žádný postup" a správný úsek pětkrát penalizoval (zdražil), načež se trasa přeplánovala kolem něj. Přesně to „po chvíli zamítl pěknou cestu". Ve třetím kole to běželo celou jízdu, ale trasu změnilo až cestou zpět; ve čtvrtém hned od startu, protože trasa k nakládce vedla proti směru zápisu úseků. Opraveno, s testem, který jede po téže cestě oběma směry a chce odhad času stále klesající; na robotu to zatím neběželo. Penalizace a uzavírání úseků se navíc do té doby nikam nezapisovalo, takže se celé muselo zpětně poskládat z čítačů v záznamu.

Skoky polohy. Druhý nález ze stejných záznamů: na rovných úsecích poloha robota občas skočila o 0,6–4 m, v sériích jedním směrem, a všech 14 skoků ve třetím kole a 9 ve čtvrtém přišlo do desetiny sekundy po přijatém měření z detekce okraje cesty (koridoru), které opravuje polohu napříč cestou. Filtr, který skládá polohu z GPS, kompasu, odometrie a koridoru, nezahodil ani jedno z 1 404 měření koridoru, i když to největší se od odhadu lišilo o 443násobek své udávané nejistoty. Koridor je zároveň jediný zdroj, který polohu napříč cestou opravuje, a za jízdu takhle stáhl 20–28 m nasbírané chyby, takže se nevypíná. Nabízelo se dát mu menší váhu, ale přehrání záznamu ukázalo, že by to zpomalilo i těch 95 % oprav, které jsou drobné a správné, a poloha by trvale ujížděla o 0,8–1,3 m. Zkusil jsem rychlostní omezení polohy, podle které robot řídí: filtr by počítal dál přesně a poloha pro řízení by za ním jen dojížděla omezenou rychlostí. Po rozboru jsem to zase zahodil — robot by měl dvě polohy, jednu ve filtru a druhou v řízení, a rozešly by se s nimi snímky z kamer, vizualizace i další měření. Léčba skoků tak zůstává otevřená.

Rozbory dělají nástroje ARBot.Analyze mission (fáze mise, kvalita GPS, snímky živým dekodérem, zamítnuté cíle proti mapě) a ARBot.Analyze nav (skoky polohy, stavy plánování v okolí robota, uzavírání úseků, přeplánování, časová řada odhadu času do cíle). Oba vznikly kvůli téhle soutěži a zůstávají v repozitáři, aby šlo příští „to je divné" změřit stejně.

Co si z toho odnáším

• Tři ze čtyř poruch dne se v simulaci nemohly projevit: jméno kamery ze skutečného driveru, kvalita GPS pod stromy a mapa s ostrovem. Testovat se musí s tím, co dává železo.
• Stránka náhledu musí ukazovat to, podle čeho se robot rozhoduje: podmínku pro zaměření depa, důvod zamítnutí kódu, napětí baterie, a proč navigace zavřela úsek cesty. Všechno, co dnes chybělo, se hledalo hodiny.
• Chyba o jedno znaménko v odhadu času do cíle stála dvě kola, a přitom celou dobu vypadala jako rozumné chování navigace. Detektor, který umí měnit trasu, musí do záznamu psát, proč to udělal.