Kafe Maryša není zrovna můj šálek kávy a tak mi nezbývá než reagovat...
Zcela zásadní vliv na vývoj robotického projektu má pravdivá odpověď na otázku "Proč a co tím chci dokázat?". Od toho se odvíjí vše ostatní a předurčuje i budoucí úspěch či neúspěch. Hodnocení úspěšnosti je relativní a závisí právě na odpovědi na zmíněnou otázku.
Pokud jsem v obraze, tak náš cíl pozvednout úroveň hobby mobilní robotiky tak, abychom se za ni nemuseli stydět je velice vznešený a bude to hodně práce. Ostatně je načase s tím něco udělat, protože komerční firmy nám v posledních letech dávají těžce na prdel.
Pokusím se přispět se svou troškou do mlýna a budu se snažit to ilustrovat na příkladech vývoje svého robota Koulíčka.
Koulíček 2012
https://www.youtube.com/watch?t=1&v=zUr7Io4JS7I
Koulíček 2013
https://www.youtube.com/watch?v=OR_1TIAUl2Q
https://www.youtube.com/watch?v=-HB_POYJwXI
Odpověď na otázku zmíněnou v úvodu zní: "Ukázat životaschopnost všesměrového podvozku na koulích."
Za "absolutely must have" podmínku považuji mít robustní a spolehlivý podvozek s jasně definovaným rozhraním.
Konkrétně u Koulíčka má každá koule svůj vlastní procesor implementující zpětnovazební řízení rychlosti motorů a čtyři koprocesory pro vyčítání QE.
Každá koule přijímá příkazy ve formě rychlosti v m/s resp. cm/s a směru ve stupních a odpovídá deltou ujeté vzdálenosti od posledního příkazu. Komunikace je synchronní. Aby to nebylo až tak úplně jednoduché, tak každá koule posílá v odpovědi svůj status a zda nedošlo k resetu cpu (watchdog), protože potom nadřízený kinematický modul nebere v úvahu poslední (chybný) údaj, ale dopočítá si odhad delta z posledních validních dat. Frekvence vyčítání dat je v řádu desítek Hz.
Jako "must have" podmínku považuji mít celý sw robota modulární. To se mi až tak úplně nepodařilo splnit, ale do budoucna se s tím musím vypořádat, protože to považuji za zcela zásadní problém. Podle mne je pes zakopán právě zde a pokud se nám nepoří s tímto vypořádat, tak se nikam neposuneme.
Obslužný (hlavní) program robota Koulíčka je napsaný v jazyce C a běží na RPi. Skládá se ze dvou threadů, kdy v jednom běží komunikace s moduly (pohony, senzory), kinematický modul updatuje polohu a orientaci robota, 2D sonar updatuje mapu pravděpodobnosti výskytu medvěda a ostatní senzory updatují svůj status, případně mohou nastavit flag signalizující nutnost okamžité reakce v hlavním threadu. Zatímco druhý (hlavní) má za úkol "vysokoúrovňové" řízení robota.
Vlastní psaní programu pro řízení robota má svá úskalí a specifika, některá z nich se pokusím nastínit a doufám, že se připojí i ostatní. Bohužel toto téma zde zatím není příliš diskutované.
Výjimky nemá kdo číst.
Program se musí umět vymanit z nepředpokládaných či havarijních situací sám. Nemá mu kdo pomoci. Relativně jednoduše se toho dá dosáhnout u modulů nižší úrovně, které se snažím dělat bezstavově a využívám watchdog, pokud to jde. Každý z pěti procesorů pro obsluhu koule má zapnutý WDT, který se resetuje při komunikaci s nadřízeným modulem a posílá jen změnu od poslední komunikace. Má to i nezanedbatelný bezpečnostní efekt, protože když havaruje nadřízený program, koule se sama zastaví.
Log je tvůj best friend.
Veškerá komunikace je logovaná. Někdo to řeší přímo záznamem komunikace na sběrnici a nástroji pro její pozdější rekonstrukci, analýzu a třeba i opětovné přehrání. Já to řešil textovými výstupy do souborů z hlavního programu, který má zhruba následující formát: timestamp,adresa,příkaz,odpověď.
Modul mapy pravděpodobnosti výskytu medvěda má vlastní log, kam dumpuje mapu po každém updatu. Díky tomu jsem rychle zjistil, že uprostřed hřiště, kde se kříží hrany desek hracího pole, dostávám echa, která nepatří medvědovi a musel jsem tuto oblast váhově znevýhodnit.
Nevěřím žádnému jednotlivému měření ze senzoru a všechna jednotlivá rozhodnutí plánovače považuji za chybná.
Je až do očí bijící, jak někteří kolegové slepě věří zapůjčenému lidaru od faktulty, tupě dojedou dle odometrie na nějaké místo, jednou vyfotí a naslepo jedou dle odometrie na toto místo pro medvěda a diví se, že minou.
Případně na robotem rovně po pár metrech od startu ostře zatočí a skončí.
Daný problém se snažím řešit pomocí iterací a fúze dat z více senzorů a zde vidím velký prostor pro další zdokonalování. Aktuálně každé dílčí měření ovlivní plánovač jen do dalšího měření, kdy je opět přeplánováno dle aktuálních dat, frekvence iteračního cyklu je v řádu desítek Hz. Fúzi dat zatím nemám úspěšně zmáknutou a potácím se v if...then pekle. Principiálně se znažím váhově zvýhodnit senzory, které by v daný okamžik měly poskytnout validnější data a přihlédnout k předešlým měřením a apriorním informacím. Kolikpak let by dnes bylo panu Thomasu Bayesovi? A co by na to asi tak řekl Rudolf Emil Kálmán?
Jak naprogramovat robota a nezbláznit se u toho
titulek jsem si vypůjčil na
http://robotika.cz/robots/ester/sw/cs a doporučuji jej pečlivě pročíst!
Je velice smutné, že se zde odvolávám na 11 let starý článek a nemám k němu v podstatě co dodat, snad jen kromě odkazu na ROS
http://www.ros.org.
Právě v ROS vidím možné řešení a pokud se projekt hobbyrobot.cz outdoor robota ukáže jako životaschopný, tak se hlásím jako dobrovolník pro jeho implementaci.
Řídicí program robota Koulíčka je ukázkovým příkladem spaghetti code, jedná se o kombinaci použití fsm, sekvenčního kódu a ad-hoc ošetřovanými výjimkami (myšleno reakcí na nějakou událost, nikoli program exception). Celý kód je prošpikován cykly do ... while, kde podmínka je odkazem na funkci, která něco hlídá. Naivní pokus o modularizaci kódu, i když dobře myšlený. Například:
goUntil(rychlost, azimut, bumpersFront);
goUntil(rychlost, azimut, bumpersRight);
goUntil(rychlost, azimut, bumpersRear);
Závěrem bych ještě zmínil časovou náročnost vývoje robota, se kterou je třeba počítat.
Nápad na koulový podvozek jsem dostal někdy v roce 2010. Na Eurobotu 2011 jsem byl s proof of concept verzí Koulíčka (v té době měl jen dvě koule), kdy cílem bylo projít homogolací a získat zkušenosti pro další vývoj. V roce 2012 jsem na Robotickém dni startoval s plexi verzí, která projížděla hřiště stylem rojnice per partes a teprve v roce 2013 vykazovala finální hliníková verze snahu o nějaké vyšší řízení. Tím chci říci, že je vhodné postupovat po fázích a nejdříve pořádně dodělat a odladit jednu, a pak se teprve pouštět do další.