Robotika.cz

Robotem rovně 2017

2017-05-16T00:00:00Z

Soutěž Robotem rovně mám rád. Sice je rok od roku těžší doma vysvětlovat, proč někde musíme dokazovat, že náš robot neumí ani jezdit rovně, ale když k tomu vyjde počasí, jako letos, tak je to radost.

V první řadě se na jednom místě sejdou všichni, kdo si s mobilními outdoor roboty hrají. Letos mi přišlo, že ani nezáleží jak daleko je jejich robotická základna od Písku vzdálena: přijelo několik týmů z německého Deggendorfu, loňský vítěz Robotour z Bratislavy, ND Team… Troufl bych si říci, že většina soutěžících v Písku byla opakovaně (i když to nemám statisticky podložené). Proč? Je to jedinečná (nebo dokonce jediná?) šance se probudit ze „zimního spánku”, oprášit stroje a připomenout si, o čem ten reálný svět je. A samozřejmě spousty dalších důvodů.

John Deere X300R (CZU/TF + robotika.cz)

Zahradní traktůrek John Deere X300R už účastníci viděli loni. Mojí motivaci bylo ukázat, že jsme se od cihly na pedálu za ten rok trošku posunuli. Hydraulické řízeni má zpětnou vazbu z měření na levém předním kole, odometrie se počítá z enkoderů na obou předních kolech, jsou zapojena čtyři bezpečnostní STOP tlačítka (o kterých se i řídící program dozví, tj. nejenom zastaví motor, ale pošlou i signály po CANu), funguje dvojitý nárazník, integrován je laserový dálkoměr LMS100, kamera.

hračka pro děti

CAN modul si teď lépe filtruje měření polohy pedálu a v kombinaci s daty z enkodérů je již možnost regulace rychlosti (letos jsme jeli 0.5m/s). Tolerance zatáčení kol byla ale 2.5 stupně, což by ale v soutěži znamenalo, že robot sjede z cesty cca po 10m max. Dodělávali jsme tedy integrační složku, kdy pro akumulovanou chybu v natočení kol jsme jednorázově do nich „kopli” (otevření hydraulických ventilu na jeden cyklus = 1/20s = 50ms). Toto řádově pomohlo a hodí se to i do dalších, nesoutěžních, úkolů.

Jaká byla AIQ robota v sobotu 13. května 2017 ráno? Řekl bych nízká — robot uměl reagovat na tlačítka a zastavovat na překážky detekované laserem. Jak už to pokaždé bývá, tak robot nechtěl v prvním kole vůbec odstartovat. Myslím, resp. logy to pak potvrdily, že byl moc paranoidní a bál se vyrazit. Dav po obou stranách byl blíže než 1.3m (asi o 2cm) a tak nechtěl jet (přesněji, pokud je překážka blíže jak 1m, tak přejde do STOP stavu a rozjede se až při zmiňovaných 1.3m volného místa … a někdo před robotem při startu přeběhl). No nic, eXtrémní programování to sice nebylo, ale v tom dvou, možná tří, minutovém okně jsem tam po dvou neúspěšných startech na vhodné místo zasekl:

dist = 10.0

… vše je v pohodě, všemi směry je 10m volného místa. A pak bylo dobře, že na traktůrku seděl Zbyněk. Nic by ho nezastavilo (tedy až na STOP tlačítka a nárazníky). 44m

Do druhého kola jsme toto trošku poladili. 270 stupňů jsme rozdělili na tři sekce, kdy v levé a pravé byl limit snížen na 60cm a rozjezdová vzdálenost 70cm. Vpředu to zůstalo na původním 1m a rozjezd 1.3m. Sice jsme nedojeli tak daleko jako v prvním kole, ale jen o pár metrů. 38m

Pro třetí kolo jsme již měli nasbírána reálná data a vymýšleli chytrost. Konkrétně byl v Parku krásně zelený trávník, tak se od něj „odrážet” (i když to bylo proti vnitřnímu přesvědčení sekačky). Nejjednodušší to bylo zapojit do hlavní řídící smyčky, což ale zároveň je špatné místo … a i se to v třetím kole trošku projevilo. Traktůrek občas „pozastavil” protože systém vyhodnotil, že laserová data jsou opožděna o více jak 0.3s a je tedy nebezpečné pokračovat. Ale byli jsme svědkem dvoustupňové korekce a to nám stačilo. 74m

Do čtvrtého kola jsme kód trošku optimalizovali a pak robot stíhal zpracovávat obrázky v hlavní smyčce. Skončili jsme na hnědé zadupané zemi u stolu štamgastů, který přijíždějící traktůrek nijak nevyděsil — možná to bylo tím, že byl tiší než právě hrající kapela. 84m

Proč mám rád Python a jeho pomocné knihovny pochopíte z výsledného kódu:

#
                img = cv2.imread(filename)
                if img is not None:
                    img = img[2*768/3:,:,:]
                    r = img[:,:,0]
                    g = img[:,:,1]
                    b = img[:,:,2]
                    mask = np.logical_and(g > b, g > r)
                    left = mask[:, :512].sum()
                    right = mask[:, 512:].sum()
                    if left > GREEN_LIMIT or right > GREEN_LIMIT:
                        if left < right:
                            global_offset = math.radians(2.5)
                        else:
                            global_offset = math.radians(-2.5)
                    else:
                        global_offset = 0.0
                robot.set_desired_steering(0.0 + global_offset)

… tak s ním jsme to letos dotáhli na 11. místo.

Bebop2 (CZU/INFO)

Výsledky

výsledky

vítězové

Odkazy

fotky na rajce.idnes.cz

P.S. Omlouvám se za zveřejněný rozdělaný článek, ale nevím kdy dostanu odstavečky od vítězů ani zda je stihnu v rozumném čase zveřejnit, tj. plánuji ješte update

24. květen 2017 — vítězné týmy

Short Circuits Prague (Pavel Jiroutek)

Robotem Rovně byla naše první soutěž po tříleté pauze způsobené mým pobytem v zahraničí, kde průměrná strmost domovního schodiště téměř neumožňuje chůzi, natož přenášení těžkého robota (NL). Plán byl využít soutěž jako pevný milník pro znovuzprovoznění původně funkčního HW a SW. Jak to ale bývá, plán byl až příliš optimistický.

Největší ranou pro hladkou přípravu na soutěž bylo rozhodnutí (cca 2 měsíce před soutěží) zmigrovat ze starého Pythonu 2.7 na 3.5. Důvodem byl plán začít zkoumat DNN sítě ve frameworku, který novější python vyžaduje. Po hladké základní migraci kódu se robotický SW úspěšně otestoval na přehrávači historických dat a v simulátoru (používám V-REP). S optimismem a nákladem jiných pracovních i nepracovních povinností jsem odložil další přípravu na soutěž na čtvrtek před odjezdem do Písku. Bohužel se po prvním spuštění HW ukázalo, že nefunguje vůbec nic. Nový python pracuje jinak s daty a jejich kódováním, takže veškerou low-level komunikaci bylo nutné znovu odladit (po mnoha letech bez zásahu už jsem na to nebyl psychicky připraven).

Z pohledu HW došlo před soutěží k několika drobným změnám. Podařilo se mi rozbít USB konektor u kamery, pořídil jsem tedy novou, outdoorovou, 170 stupňů FOV. Také se mi nepodařilo najít IMU (našel jsem ji náhodně teprve včera pod stolem v troskách jiného robota), tak jsem na robota umístil starý kompas. Baterie naštěstí dlouhou odstávku přežily v pořádku (kromě baterie v řídícím notebooku, kterou bylo nutné vyměnit a projít si neočekávaným kolečkem kalibrace).

Jinak robot zůstal beze změn takto: Robot je na platformě podvozku modelu monster trucku velikosti 1:5. Hlavní výpočetní jednotku tvoří standardní notebook s Windows 10. Hardware je monitorován deskou Arduino Duemilanove. Senzorické vybavení robota tvoří magnetický kvadraturní enkodér, kompas, zadní sonary (pro tuto soutěž neaktivní), lidar (mířící šikmo na zem cca 3m před robota), GPS (pro tuto soutěž neaktivní) a kamera. Software je psaný v jazyce Python. Program získává aktuální informace o stavu HW prostřednictvím USB. Informace o stavu HW získává Arduino, které je v pravidelných intervalech posílá dále do hlavního programu. Hlavní program zajišťuje transformace stavu HW do jednotek a struktur nezávislých na HW platformě, PID kontrolér rychlosti, lokalizaci z odometrie a kompasu, detekci překážek a strmosti cesty (z lidaru) a také hlavní funkční logiku řídící chování robota - navigaci po zadané trase. Robot využívá strukturu Occupancy Grid Map pro fúzi vstupů z jednotlivých senzorů a metodu Vector Field Histogram pro navigaci v grid mapě.

Soutěž samotná proběhla až překvapivě hladce (na to, že jsem před soutěží nestihl robota ani jednou otestovat jako celek). První kolo bylo trochu kostrbaté, ale dojeli jsme až do konce a využili nasbíraných dat pro přesné nakalibrování směru robota pro další kola. Cestovní rychlost byla 0.3 m/s, takže jsme trať urazili za klidných cca 1200 sekund. Druhé kolo bylo o mnoho lepší, asi hlavně kvůli provedené kalibraci. Také jsme dojeli až do cíle a to v podobném čase.

Před třetím kolem nám kolega z jiného týmu prozradil, že se před několika lety změnila pravidla a že se roboti, kteří urazili celou trať alespoň jednou, celkově rozřadí podle nejrychlejšího kola. Nemělo tedy cenu pokračovat v hlemýždím tempu (viz první video), které jsme měli před třemi lety otestované. Abychom překonali nejrychlejšího robota, nastavil jsem rychlost na 1.5 m/s. Tuto hodnotu jsem použil spíše ve významu "maximální rychlost", protože jsem se domníval, že robot této rychlosti nedokáže dosáhnout. Ani jsem neočekával, že by dojel nějak daleko, protože veškerá konstanty (např. pro statistický update grid mapy) byly laděny pro velmi nízkou rychlost, aby se nemusel příliš optimalizovat kód. K mému velkému překvapení se této rychlosti robot skutečně celou cestu držel a navíc se mu podařilo celou trať opět projet. Tentokrát v čase 3:34 m (214 sekund). V cíli nám někdo řekl, že to na vítězství stejně není, protože to někdo před námi projel za 3:05. I tak jsem měl vítězný pocit, že jsme z daného HW a situace dostali maximum. Když jsme se vrátili na start, z výsledkové listiny jsem zjistil, že ARBot neměl 3:05 minut, ale 305 sekund, takže náš čas bohatě na první místo stačí (když to vidím teď zpětně, tak i těch 305 sekund mi přijde jako neskutečná rychlost).

Poslední kolo bylo už spíše exhibiční. Nechal jsem na robotovi nastavenou vysokou rychlost, protože jsem si chtěl tentokrát udělat pěkné video (odkaz níže) a potvrdit obecenstvu, že jsme si vítězství zasloužili. Tentokrát byl ale dojezd do cíle mnohem více vydřený. Přibylo hodně lidí a náš týmový rozrážeč davů (moje maminka běžící na videu před robotem) na to už sama nestačila. Robot proto musel řešit i několik skoro-kolizí (viz další video níže). Do cíle se ale dostal i tentokrát (za cca 288s). Tímto bych chtěl na cenu fair play nominovat Aleše z ARBotu, který skončil druhý. Zásadně nám pomohl v druhé půlce tratě udělat prostor pro dojezd opět až do cíle.

Závěrem bych chtěl zdůraznit, že Robotem Rovně je výborná vstupní soutěž do robotické sezóny, ale i do outdoorové robotiky celkově. Díky zdánlivě jendoduchému zadání se v ní lze dobře zúčastnit jak se začátečnickým tak i s pokročilým robotem. Příště určitě pojedeme znovu. Mezi tím si ale dáme ještě Roboorienteering a samozřejmě Robotour.

ARBot (Aleš Ruda)

Pro letošní sezónu jsem opustil technologii FPGA se stereoskopickou kamerou vlastní konstrukce, ale ve 3D vnímání světa vidím mnoho výhod a tak jsem se rozhodl použit komerční RGBD kameru Intel RealSense R200 a SBC UP2, který jsem podpořil na Kistarteru. SW jsem upravil z linuxu pro windows. Nakódoval jsem algoritmy pro detekci překážek z 3D kamery. Sonary jsem vyměnil za lidar Slamtec RPLIDAR A2. Algoritmus VFH jsem nahradil navigací na gridu. No pak jsem už jen čekal až mi dorazí UP2. Jenže SBC mi do závodu nedorazil a tak jsem ho narychlo nahrazoval notebookem Acer Aspire ES13. A ejhle, notes lidar neutáhne. Nu což, pojedu bez lidaru. A takhle jsem dorazil do Písku

ARBot

1. Kolo

Po startovním hvizdu robot vyrazí kupředu, ale něco je špatně. Jede mírně doleva a po cca 30 metrech vyjíždí do trávy. Krátká analýza problému, vypnutí všech neklíčových algoritmů, vlastně zbyl jediný – jízda podle kompasu a posunul jsem požadovaný směr jízdy o 5 stupňů doprava.

2. Kolo

Tentokrát byl výsledek mnohem lepší. 108 metrů bylo výrazné zlepšení, ale zase to táhlo doleva. Do třetího kola bylo spousta času a tak jsem se pustil do testování. Z logů vyplynulo, že do levého motoru je nutné posílat o cca 6% vyšší akční zásah, aby robot jel rovně. V několika iteracích jsem zvýšil zesílení regulátoru, upravil požadovaný směr jízdy a vše důkladně přetestoval na závodní dráze.

3. Kolo

Již první metry naznačily, co bude následovat. Robot jel krásně středem. Minul značku 100m, 150m, 200m, 250m a 314m v čase 305 sekund. Hurááááá. V tu chvíli to byl nejlepší výsledek závodu. Jenže dlouho nevydržel. Famózních 214 sekund týmu Short Circuits je nepřekonatelných. Zvýšil jsem tedy rychlost na maximum.

4. Kolo

Vyšší rychlost se projevila jemným kmitáním robotu a opět táhnul doleva. Závodní dráhu opustil u značky 120m.

Co se pokazilo?

Tak to bych taky rád věděl. Robot jel po cestičce, ale modrá čára v následujícím obrázku ukazuje kudy si robot „myslel“, že jede. Velmi dobře to souhlasí se zadaným směrem. Zelená čára reprezentuje údaje z GPS. Domníval jsem se, že problém by mohl být v motorové jednotce, ale její testování neukázalo žádný problém. Že by magnetická deklinace? Ta je v ČR cca 3.5 stupně východně, ale já mám odchylku 7.5 stupně západně. Záhada.

ND Team (Pavel Skoták)

Na letošní (2017) Robotem Rovně jsem se vyloženě těšil, a to hned z několika důvodů: Loni na podzim se mi podařilo integrovat na robota Speedyho homemade 360° skenující lidar, konečně jsem přišel na to, jak pořešit pthreads a tedy vícevláknové programování v linuxu na mém oblíbeném Odroidu U3 a nakonec se podařilo připravit i integraci kamery.

NDTeam

Účast v soutěži tedy měla být především ostrým testem nových senzorů a algoritmu vyhýbání překážkám včetně detekce cesty kamerou. Samozřejmě se podělalo co mohlo, počínaje odřeknutím účasti mého kolegy a konče generální stávkou napájení celého robota, která, jak se záhy ukázalo, byla pouze iluzí způsobenou drobným opomenutím zásadního významu (blbě nastavená proudová pojistka na laboratorním zdroji). V každém případě další cenný čas v háji v důsledku lokálního zatmění mysli. Nefunkční budík v sobotu ráno a tím způsobený hodinový lag byl už jenom ponurou třešničkou na dortu podrazů ze strany škodolibého osudu.

Nicméně, přijel jsem relativně včas, homologoval se, pokecal s kolegy a při první soutěžní jízdě ujel celých 50m! Tak špatný výsledek jsem na této soutěži ještě neměl. Takže plánované testy kamery šly stranou a začalo se upravovat nastavení regulátoru azimutu, který zůstal od podzimu rozvrtaný, na což jsem úspěšně zapomněl. Druhá soutěžní jízda ukázala, že je to téměř ono, pouze robot trochu táhl doprava.

Během přestávky na oběd byl čas obejít depo a ukázalo se, že valná většina kolegů přes zimu rozhodně nezahálela a poměrně zásadním způsobem upravila hardware i software svých strojů nezanedbatelným směrem vpřed, což potvrzuje výsledková listina, kde šest robotů dojelo do cíle. V každém případě bylo na co koukat a o čem diskutovat.

Třetí jízda se zdála být jízdou jistoty - Speedy se držel uprostřed cesty a dělal čest svému jménu. Na 290. metru mě kolemjdoucí jemně upozornil, že robotovi odpadlo kolo. Nepublikovatelné výrazy jsem naštěstí udržel za zuby, ale dojezd do cíle po nasazení kola mi paní rozhodčí stejně neuznala Letos poprvé jsem před soutěží zapomněl dotáhnout kola a hned se mi to vymstilo.

Čtvrtá jízda byla spíše jízdou v korytě kolemstojících a v cestě překážejících diváků. Algoritmus vyhýbání překážkám naštěstí fungoval spolehlivě, takže jízda skončila až u pomníku na konci cesty.

Nakonec se ukázalo, že poslední výkon stačil na třetí místo, což bylo sice nečekané ale milé překvapení.

Letošní soutěž se opravdu vydařila, panovala družná atmosféra, bylo k vidění několik zajímavých novinek a především nám nezvykle přálo počasí, takže roboti letos nemuseli být vodotěsní. Doufám, že příští, již desátý ročník, bude podobně hojně obsazen a bude to ještě větší zábava.

kontaktní formulář

Formula-E Roborace

2015-12-21T00:00:00Z

Autonomní auta mne zajímají už od DARPA Grand Challenge z roku 2004. Co ale nevím, jestli by to zajímalo i vás, čtenáře? Má smysl přepisovat útržky nalezených článků do češtiny? Případně zajímavé kusy kódu, pokud opravdu desátý tým bude vše zveřejňovat? Proto fandorama blog, který by měl pokrýt celou první soutěžní sezónu.

Zde je odpovídající fandorama link:

http://fandorama.cz/projekty/921778164/formula-e-roborace-2016/

22. prosinec 2015 — fandorama do 24h

To jsem opravdu nečekal, že do 24 hodin od zveřejnění se naplní fandorama rozpočet! velké díky prvnímu stoupenci:

cortexpilot.cz.

Oficiální informace k soutěži jsou přislíbené až začátkem příštího roku, tak alespoň přehled odkazů:

LinkedIn Kinetik — investor, zakladatel Denis Sverdlov (zástupce ministra v ruské vládě v letech 2012 a 2013)
kinetik.vc
roborace.com — budoucí stránky soutěže
charge.org — EV technologie pro náklaďáky a autobusy

Alejandro Agag - CEO Formula E, (motorsport.com)

Asi zatím nejvíce informací je na již zmiňovaném wired.co.uk. Teď se snaží získat firmy, které již autonomní vozy vyvíjí (Google, Uber, Continental a Bosh). Existuje i první verze API, aby týmy mohly začít se simulátory … dokumentaci jsem si vyžádal, tak uvidíme jestli odpoví.

A hle https://github.com/roborace/roborace jen tam zatím nic není.

15. leden 2016 — Wikipedia

Zatím je na všech „informačních frontách” klid. Jedinou novou informaci, co jsem dnes našel je na stránkách Wikipedia/Roborace. Je tam odkaz na Formula E sezónu 2016-2017 a první závod se pojede v září 2016 v Montrealu/Kanada.

Možná za zmínku i stojí poslední odstavec z The Verge článku:

Roborace fills a gap left by the School Series, an electric kit car competition for kids that was run before a number of races in Formula E's first season. The School Series was dropped from the season two schedule shortly before the first race in Beijing, leaving room for a new support series like Roborace. … tj. ruší závody pro děti a nahrazují je závody pro roboty … a co děti, mají si kde hrát?

16. únor 2016 — API na výsledky

Koukám, že už je to měsíc, co jsem zde naposledy napsal odstaveček. Ono se stále nic neděje. Alespoň jednou týdně projdu oficiální stránky a github … a nic. Jen různé polemiky typu deseti důvodů proč neignorovat robotrace, kde pozorování, že publikum bude trošku jiné a možná to přiláká i ostatní, kteří k F1 závodům nemají žádný vztah, mne moc nenadchly.

Zkouším také hledat "e-formula api" a na to jsem dnes skoro poskočil, když vyběhl odkaz na Ergast Developer API. The Ergast Developer API is an experimental web service which provides a historical record of motor racing data for non-commercial purposes. The API provides data for the Formula One and Formula E series, from the beginning of the world championships in 1950 and 2014 respectively. Tj. není to API na řízení formule :-(, ale přístup do databáze výsledků. Třeba se i toto bude časem hodit …

5. duben 2016 — Nový design

Informaci, že elektrická závodní auta budou mít nový design, jsem četl už zhruba před mesícem. Ale byla to agentura JPP (Jedna Paní Povídala), resp. Roborace hired the man behind Tron: Legacy's light cycles to design its driverless cars. Musím uznat, že některé návrhy Daniela Simona jsou opravdu „cool”, ale nějak mne spíše trápí technická stránka soutěže a toto patří spíše do kategorie „nice to have”. No nic, už je to oficiální a tak si můžete prohlédnout „vyrenderovaný obrázek”:

Originál, v plném rozlišení, naleznete zde.

p.s. mezi řádky The first Roborace 'shows' will take place during the 2016/2017 Formula E season., tj. už to nevypadá, že by závodilo pokaždé a začalo to letos … ???

27. duben 2016 — Nvidia

Když jsem se koukal posledně, tak jsem zaznamenal nějaké útržky, že Roborace podpoří Nvidia, ale teprve teď vidím relevantní článek. Každé auto bude tedy vybaveno počítačem NVIDIA DRIVE PX 2. Už podle obrázků to vypadá moc pěkně … no to by bylo zlé, kdyby Nvidia neměla pěkné obrázky .

DRIVE PX is a powerful auto-pilot car computer designed to run deep neural networks paving the way for the autonomous car.

Ještě přidám odkaz s informacemi o Nvidia na letošním CESu. 10x výkonější než starší generace (Dual NVIDIA Tegra® X1 processors = 2.3 Teraflops) … asi bych udělal malou odbočku. Cogito posílal před časem odkaz na nahrávané přednášky ze Stanfordu z ledna letošního roku — jestli o Deep Neural Networks nic netušíte (ale i když tušíte) tak vřele doporučuji (já se tím prokousávam jenom pomalinku, přeci jenom je to 15h videa, ale lepší zdroj asi nenajdete): CS231n Winter 2016 Tam člověk pochopí, jaká revoluce proběhla nárůstem výpočetní síly a množstvím vstupních dat.

ukázka klasifikace (zdroj Nvidia)

DRIVE PX 2 can process the inputs of 12 video cameras, plus lidar, radar and ultrasonic sensors. It fuses them to accurately detect objects, identify them, determine where the car is relative to the world around it, and then calculate its optimal path for safe travel.

Hm, tak to už tam pro programátora snad nezbývá ani co dělat??

5. květen 2016 — Vzdělání škodí lidem?!

Teď se mnou cloumá vztek, tak ho ventiluji alespoň do jednoho odstavečku tohoto blogu. Jestli jste se nestihli podívat na ty DNN videa ze Stanfordu, co jsem o nich psal minule, tak už máte smůlu. Jsou stažená: This video is private. :-(. Vysvětlení je na Karpathyho twitteru. Sigh. Prostě pokud něco uděláte pro vzdělané lidi, tak vás za to můžou i zažalovat, viz odkaz z toho twitteru: Harvard and M.I.T. Are Sued Over Lack of Closed Captions. Už vidím, jak se budou ilegálně kopírovat vysokoškolské přednášky … nebylo to tu už někdy? Proletáři všech zemí vy…

p.s. díky za komentář — ještě že existuje underground

2. srpen 2016 — Self Racing Cars

Na poli „Roborace” je trošku „okurková sezóna”. Proto mne celkem potěšil newsletter od NVIDIA (přihlásil jsem se do jejich NVIDIA Automotive News), kde byl článek o prvním testování závodních autonomních aut. A z něj se pak dostanete na stránku selfracingcars.com.

Vedle akce samotné mne na první pohled upoutal dataset ke stažení. Má 4.57GB, zabalený tar, takže si ho asi moc na svém notebooku neprohlédnu, ale už samotný fakt, že si náhodný kolemjdoucí může stáhnout data z Lidaru (na autech jsem viděl Velodyne 32) a kamer (?) mne těší . Asi budu potřebovat viewer od PolySync, ale věřím, že někde bude formát popsán. Až dojde na Roborace, tak to asi bude podobné …

Koukám, že ke stažení jsou i čistě data z Velodyne HDL-32 na data.selfracingcars.com (1.2GB).

YouTube video zas tak moc odvaz není. Je celkem dobře vidět vnitřek auta, ale závodní dráha v ostrém slunci je spíše bílá … a je to jenom demo, sběr dat, jen jedno auto na trati. Ale nějak se začít musí.

17. srpen 2016 — Roborace welcomes you

Asi jsem zase zaspal. To je mi podobný! Na druhou stranu jsem skoro přesvědčený, že tlačítko ENQUIRE bylo na oficiálních stránkách Roborace už od začátku a že jsem ho v únoru (?) použil, když jsem organizátorům psal. Jen vedlo na jiný formulář :-(.

Ono je i možné, že se to změnilo nedávno?? Každopádně, když teď na to tlačítko kliknete, tak se vám objeví Join us as a můžete zvolit Team or Roboracer a dále jestli registrujete tým nebo hledáte místo v týmu … pak vás čeká dotaz na znalosti a když správně odpovíte robotovi:

Hi, it’s Roborace AI speaking.
I believe you are one of us. Aren’t you?

4 + seven is:

tak dostanete mail s linkem na NDA (non-disclosure agreement). Je nutné podepsat, naskenovat a poslat … skoro mám obavy, jestli potom ještě budu moci v tomto blogu pokračovat. Uvidíme. Ještě jsem to neposlal — to tlačítko jsem dnes stiskl, protože jsem se chtěl zeptat jestli už nějaké týmy jsou … nepřidáte se ještě někdo?

24. srpen 2016 — DevBot

Z Roborace organizátorů se po mailu zatím nikdo neozval (automatické odpovědi nepočítám), ale teď jsem narazil na článek a youtube video, kde je první zmínka o stroji — DevBot. Příliš krátké = skoro nezajímavé, ale snad už brzy bude známo více.

DevBot - zdroj The Verge

p.s. ještě jeden článek, nesoucí stejnou informaci, kde je ale zmínka, že Roborace's DevBot will make its public debut on August 24th, at the Formula E open practice sessions at Donington Park. (to bylo včera) Na The Verge je také podrobnější článek o plánovaných senzorech, i když se obávám, že je to zatím spíše spekulace a je to definované možnostmi vstupů Nvidia Drive PX2.

Tady je zmínka, že demo již proběhlo, ale chtělo by to více …

29. srpen 2016 — První autonomní jízdy

Na webu jsou už k vidění první videa s autonomní jízdou. Přiznám se, že bych v DevBot-u moc sedět nechtěl. První video je s Lucas Di Grassi … trošku, jak když vás vystřelí na měsíc:

A toto je první veřejná jízda — škoda, že je video oříznuté:

18. zaří 2016 — TORCS?

Včera na Robotour večeři byla vyslovena hypotéza, že Roborace bude možná postavené na TORCS (The Open Racing Car Simulator), a zde je důkaz, že o tom organizátoři uvažovali … pro případ, že by link přestal fungovat, zde je originalní text:

> On 4/8/2016 3:52 PM, Vadim Butakov wrote:
>
>     Hi,
>
>     I'm a member of Roborace:
>     http://spectrum.ieee.org/cars-that-think/transportation/self-driving/
         nvidia-to-supply-roborcar-brains-for-roborace-formula-e-series
>
>     I'm evaluating an idea of modifying Speed Dreams to create a free
>     open-source platform that anyone can use to develop, test their ai
>     algorithms and compete with each other in virtual Roborace events.
>     It can be an alternative to a high-end (hence inaccessible to the
>     general public) sim that will be used by the actual teams.
>
>     The questions to you guys are:
>
>     - what do you think of this idea?
>
>     - are you willing to help us to build such a platform? The to-do
>     list will be to create a udp bot server addon (similar to one used
>     in TORCS championships), create a Robocar model, (if there is
>     enough time) crate tracks that will be used in the championship
>     and a Roborace event in the game.
>
>     Let me know what you think!
>
>     Cheers,
>
>     Vadim

Vadim Butakov — Autonomous Driving Software Lead at Roborace

26. zaří 2016 — Speed Dreams

Jako první krok Vadim doporučuje Speed Dreams, což je simulátor, který z TORCS vychází.

At some point we considered it as an option because it's an open source and there is a great community around it, but unfortunately it's quite outdated and there is plenty of work has to be done in order to get it to standards we aim. We might suggest Speed Dreams as a free simulator for very early algorithms testing, but no more than that.

OK, má pravdu, že už je to trošku outdated. Zdrojáky si můžete stáhnout na SourceForge, ale zabalené mají 2.98GB a rozbalené pak asi 4.5GB. Kód je psaný primárně v C/C++. Začít bude asi nejlepší v složce doc/tutorials/robot … ale ta je i online.

A robot is a program that drives a car (technically it's a function encapsulated into a shared object in Linux, into a DLL in Windows). It is executed from TORCS and gets as input information about the current status of its car and the situation on the track. Based on this it can compute how much it wants to steer, to brake or accelerate, which gear it needs and if it wants to pit. Your robot returns the data to TORCS and the next simulation step will be performed.

… a první lekce jak řídit robota středem závodní dráhy vypadá dobře … uvidíme …

6. říjen 2016 — DevBot v Hong Kongu

Ten čas hrozně utíká! Dnes jsem dostal info, že DevBot je v Hong Kongu a po chvíli hledání mi vyskočil starý článek, kde psali: The first Roboraces will take place during the upcoming Formula E season, which kicks off in Hong Kong October 9. … tj. závody začínají už tuto neděli!

DevBot v Hong Kongu

Přes FIA Formula E se dostanenete na televizní program:

HKT Hong Kong ePrix - Qualifying LIVE 	09/10/2016 	Sunday 	05:45 CEST 	07:10 CEST
HKT Hong Kong ePrix - Race LIVE 	09/10/2016 	Sunday 	09:30 CEST 	11:30 CEST

9. říjen 2016 — Závod Formule-E v Hong Kongu

Přestože podle časového rozvrhu měla být ukázka Roborace jak v sobotu tak v neděli, tak jsem jí zatím na YouTube nenašel. Během dne jsem alespoň narazil na stream z kvalifikace a závodů Formule-E. Stojí to za shlédnutí, co že všechno bude muset ten počítač zvládat

[video bylo změněno na "private" a není již k dispozici]

(start závodu je cca v 8:12:00)

12. říjen 2016 — DevBot měl v Hong Kongu problémy

Už vím, proč … DevBot nebyl na žádných záběrech, viz článek na CNN:

However, things didn’t quite go to plan for its first scheduled street track outing at the inaugural Formula E Hong Kong ePrix this weekend.

There were no high-speed figures of eight, only seven engineers struggling to push the 1.1-ton car through a three-point turn outside its temporary home in Hong Kong — problems recharging the battery the reason given for the no show.

We are calling this a Beta season — getting people on board and getting them up to speed.

The Roborace team will try again at next month’s Marrakech ePrix on November 12 with Tomlinson hopeful that they will be running races before the third season of Formula E ends next July.

Uvidíme tedy za měsíc v Maroku … (viz seznam závodů).

p.s. stream z víkendu je již nedostupný, tak alespoň sestřih:

p.s.2 vypadá to, že 14. října 2016 Roborace začne vysílat dokument Inside Roborace (viz Instagram, )

13. říjen 2016 — github Roborace-Dreams

Včera jsem víceméně omylem narazil na Vadimův repozitář Roborace-Dreams. Na první pohled to vypadalo jako prázdné repo, podobně jako roborace/roborace, ale klonování trvalo nějak hrozně dlouho. Důvod? On je skoro prázdný master, ale větev dev obsahuje modifikovanou verzi Speed Dreams!

Konkrétně by vás mohl zajímat adresář Info_Roborace. Je to 3 měsíce staré a asi opuštěné, ale zároveň v tom Info.docx je popis UDP stavový paketů a paketů pro řízení formule:

The protocol for the simulator out stream is defined below.

Signal	Start Byte	Type	Units	Description
LapTime	0	float	seconds	current lap time
DistStart	4	float	meters	distance from start line
LastLapTime	8	float	seconds	last lap time
RacePos	12	int32	-	race position
RPM	16	float	rev/min	RPM
EnergyLevel	20	Float	TBD	battery level
GearPos	24	int32	-	gear position
WheelVelFR	28	float	rad/sec	wheel speed front right
WheelVelFL	32	float	rad/sec	wheel speed front left
WheelVelRR	36	float	rad/sec	wheel speed rear right
WheelVelRL	40	float	rad/sec	wheel speed rear left
AbsPosX	44	float	meters	position of vehicle CG in abs CS
AbsPosY	48	float	meters
AbsPosZ	52	float	meters
AngX	56	float	rad	roll (X), pitch (Y) and yaw (Z) angles of the vehicle
AngY	60	float	rad
AngZ	64	float	rad
AngRateX	68	float	rad/s	angle rates
AngRateY	72	float	rad/s
AngRateZ	76	float	rad/s
AbsVelX	80	float	m/s	absolute speeds along the axis of the global CS
AbsVelY	84	float	m/s
AbsVelZ	88	float	m/s
AccelX	92	float	m/s²	vehicle acceleration in the local CS
AccelY	96	float	m/s²
AccelZ	100	float	m/s²
SteerAngle	104	float	deg	current road wheel angle
WheelReactionFL	108	float	N	front left wheel reaction
WheelReactionFR	112	float	N	front right wheel reaction
WheelReactionRR	116	float	N	rear right wheel reaction
WheelReactionRL	120	float	N	rear left wheel reaction
Collision	124	int32	-	collision state (0-no collision)
V2xN	128	uint8	-	number of V2x objects
V2xType	129	uint8 [39]	-	type of the objects: 0 – unknown, 1 – ai racing car 2 – human driver, 3 - slow car, 10 - static object
V2xXPos	168	float [39]	meters	position of the objects in the absolute CS
V2xYPos	324	float [39]	meters	position of the objects in the absolute CS
V2xSpeed	480	float [39]	m/s	speed of the object
V2xYaw	636	float [39]	rad	yaw angle of the object
SimStatus	792	uint8	-	3 – active, 5 - stopped
SimCounter	793	uint8	-	increments every send cycle
Total size: 794 bytes

The protocol for the simulator in stream is defined below.

Signal	Start Byte	Type	Units	Description
SteerAng	0	float	deg	“+” – left, “-“ - right
AccelRequest	4	float	N∙m or % gas	Overall torque request or gas pedal percentage (depending on CtrlMode)
BrakeRequest	8	float	% brake	brake pedal request (0 to 1)
GearPos	12	int32	-	gear position: -1 – reverse, 0 – neutral, 1 - drive
CtrlMode	16	uint8	-	control mode: 3 – torque request, N∙m 11 –gas pedal request, %
Ctr	20	uint8	-	the simulator checks if controller is alive using this counter

Je to kompromis mezi Speed Dreams a Roborace. Vedle absolutní pozice na trati máte k dispozici i rychlosti, zrychlení, úhly, derivace úhlů, rychlosti jednotlivých kol, úhel zatáčení, reakci kol (to moc netuším co je) a informace o stavu baterie, kolize a absolutní pozici soupeřů (X, Y, směr a rychlost).

Pro řízení pak posíláte příkaz na otočení volantu, sešlápnutí „plynu”, brzdy a řazení.

14. říjen 2016 — pyroborace ver0

Neodolal jsem. Vytvořil jsem si VirtualBox s Ubuntu, abych mohl snadno postupovat podle instrukcí. Až na to, že je to PDFko, celkem OK (obyčejný text by šel lépe kopírovat, případně ideálně rovnou pustit nebo patchovat). Drobnost s mkdir bild (má být mkdir build) a pak mi neprošla kompilace kvůli Windows socketům. Ono hned vedle je linux_fix/fix.zip, který po rozbalení skrývá README.md:

# Roborace Ubuntu Fix

#Install:

- Clone the original repo (https://github.com/vadbut/Roborace-Dreams)
- Copy the 'drivers' folder into 'Roborace-Dreams/src/' and choose to
     overwrite all conflicting files

… no asi bych to dělal jinak, ale vzhledem k tomu, že to fungovalo a jinak je to asi mrtvá větev OK. Prostě natvrdo překopírovat zdrojáky z toho ZIPu přes ty trackované v repozitory a pak zkompilovat a nainstalovat.

Chvilku jsem hledal, co mám vlastně pustit … odpověď je speed-dreams-2. V samotném programu pak vyberete závod (Quick Race pro test stačí), účastníky si vyberete ze skupinky UDP (v mém případě první byl UDP Nico Watt) a po odstartování, kdy vaše auto stojí a všichni vás předjedou, je vidět na konzoli, že nepřicházela žádná UDP data a spojení bylo ukončeno.

K Hello World! už je jenom krůček: opakovaně posílat 21 bajtů na port 3001, viz pyroborace/ver0.py:

# simplest version = just go straight with 50% gas

import socket
import struct

soc = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
ctr = 0
while True:
    data = struct.pack('fffiBB', 0, 0.5, 0, 1, 11, ctr & 0xFF)
    soc.sendto(data, ('127.0.0.1', 3001))
    ctr += 1

Když si představím, že toto by šlo pustit na závodní formuli, tak mne až zamrazí . Co to v simulátoru udělá? Částečně šlápne na plyn, jede to rovně a v první zatáčce to nabourá.

Co dál? Asi bych si rozchodil přesměrování portů, abych řízení mohl pouštět mimo VirtualBox (pro pohodlí), a pak ver1, která zároveň bude číst stavy a popojede s formulí 1 metr.

15. říjen 2016 — pyroborace ver1

Přidání čtení stavu simulované formule je v Pythonu poměrně triviální:

soc.bind( ('', 4001) )
soc.settimeout(1.0)

s tím, že ten timeout je pouze pro pohodlnost (nechci teď ještě řešit nějaká vlákna).

pyroborace/ver1.py opravdu dostával požadovanou strukturu velikosti 794 bajtů, včetně absolutní pozice na trati, a tak veškerá „logika” byla zapamatovat si pozici startu (není to (0, 0)) a když je vzdálenost (math.hypot()) větší než 10 metrů, jeden metr mi přeci jenom přišlo málo, sundej nohu z plynu.

Celkem to fungovalo, jenom mne překvapilo, když po chvíli formule začala couvat?! Že by tam byl kopec?? Přidal jsem si vypisování ještě Z-ové souřadnice a byl …

Po těch 10 metrech jsem tedy ještě začal zuřivě dupat na brzdu (soupeři za mnou se to moc nelíbilo a obratem do mne naboural) a celkově jsem zastavil až na 116 metru.

Další krok bude nastudovat trasu (netuším, jak ten 3D model popisují) a zkusit objet celé kolo. Pomalu.

16. říjen 2016 — Inside Roborace - Episode 1

… úplně jsem na to zapomněl …

Z toho záznamu z Hong Kongu je vidět, že Vadim Butakov hraje poměrně aktivní roli a další důležitou osobou je Gregory Forostovsky.

9. listopad 2016 — pyroborace track

Tento víkend se pojede závod v Maroku a tentokrát to snad DevBot alespoň jednou objede. Předpokládám, že následně sestříhají Epizodu 2.

Na poli Pythonovské Roborace je drobný update: přibyl jednoduchý parser popisu trasy track.py. Řeší zatím jenom 2D trasu a ignoruje náklony a stoupání. Mezi problematické segmenty patří zatáčky s proměnnou křivostí (popisují se pomocí poloměru na začátku a na konci), které u některých tras nesedí. Defaultní Espie Grand Prix Circuits ale funguje a tak je na čase se pohnout z místa „alespoň trošku inteligentně”.

Jinak potvrzuji, co mi psal Vadim, že souřadnice ostatních závodních aut jsou k dispozici pouze pro UDP roboty. Vedle Nico Watta jsem si přidal ještě UDP robota Petera Fleminga a začala chodit lepší data . Není to dokonalé, ale krůček to je.

10. listopad 2016 — DevBot #2 a Epizoda 2

Díky Jirkovi za korekci, že Epizoda 2 už je skoro týden online …

17. listopad 2016 — Roborace-Dreams ve Windows

Minulý týden se do Roborace aktivně zapojil i Zbyněk a prošlapal minimalistickou verzi simulátoru Roborace ve Windows. A klasicky „když dva dělají totéž není to totéž” — výsledek stojí za to (myslím, že i střípky z jeho trnité cesty), tak bych to zde zmínil …

Začal bych ale ještě pár poznámkami k „mé” Ubuntu verzi ve VirtuálBoxu (ta vlastně zavdala popud k větší revizi a vytvoření forku Roborace-Dreams). Lze si totiž zapnout Port Forwarding (Network >> Advanced >> Port Forwarding >> '+' >> UDP 127.0.0.1 3001 10.0.2.15 3001 a UDP 127.0.0.1 3002 10.0.2.15 3002), povolit ve firewall oba porty jak na straně Windows, tak ve VirtualBoxu (sudo ufw 3001 a sudo ufw 3002), restartovat VirtualBox a pak ověřit, že spojení funguje (netcat -lu 3001 — testovat to přímo ve speed-dreams-2 není moc dobrý nápad).

Cvičně jsem si pustil proti sobě ver0.py vs. ver2.py (u ver0.py jsem si změnil číslo portu na 3002), jedno auto dal na začátek a druhé na konec startovního pole a … začala mi chodit nesmyslná data jak pro mé auto, tak pro pozici soupeře:

(1,) 813.676025391 764.784240723 0.0
(873.676025390625, 764.78466796875)
0.0
(1,) 873.676025391 764.784667969 0.0
60.0000000015
(1,) 813.676025391 764.784240723 0.0
0.0
(1,) 873.676025391 764.784667969 0.0
60.0000000015
(1,) 813.676025391 764.784240723 0.0
0.0
(1,) 873.676025391 764.784667969 0.0
60.0000000015

… prostě to vypadá, že všechny informace se chybně posílají na port 4001 a pokud by druhé auto poslouchalo na 4002, tak nic nedostane … což byla motivace, proč zasahovat do Vadimových zdrojáků.

Následující sekci Zbyněk možná brzy zcenzuruje … ale v mezičase … začalo to mailem se subj. speed dreams (nebo spíš nightmares?) … jen pár výseků ze série mailů:

Tak jsem se do toho pustil…

[ale nakonec jsem nic užitečného nesepsal, takže to klidně ignorujte]

Klonuji

gitgithub.com:robotika/Roborace-Dreams.git

ale už to nějakou dobu běží, mám staženo 1.3G a píše to 60% - hmm, docela nářez. Snažím se postupovat dle

https://github.com/robotika/Roborace-Dreams/blob/dev/INSTALL.txt#L655

neb mám rozchozené MSVC express 2008 včetně qmake a cmake. Jinak ale vůbec netuším, co vlastně dělám. Potřebuji to vlastně kompilovat? No nic, časem snad asi jo, tak to nebude zbytečná práce. Ze souborů

https://github.com/robotika/pyroborace/blob/dev/ver0.py

https://github.com/robotika/pyroborace/blob/dev/ver1.py

soudím, že to asi potřebuji.

…

Mimochodem, už mám 2.2G a říká to, že je to 80%. Prostě je to na dýl.

…

Jinak pokračuji v rozchozování pod win 7 a vc express 2008. První problém je, že to nemá inttypes (a to tvrdí, že msvc 2008 je podporované). Proboha chápete někdo, proč má CMake gui tak strašně malé to okno s logem? No, pak nemohl najít 3rdparty - tak vězte, že mají být "vedle" checkoutu (../3rdParty). Pak prošel jak Configure, tak Generate, takže mám otevřené msvc a v něm sln se spoustou projektů. Dávám build all a "odcházím na párek" . Builduje se to v 21 paralelních jobech a stejně to v součtu nevytíží mé 4 procesory na víc jak na 30%. Tak uvidíme. A, už to frčí na 100% (je 12:36).

Můj nynější plán je, podívat se v debugeru, jak se vlastně parsují ty xml tracky.

Uhh, ho. Je 12:42 a je dobuildováno a žádný error! Teď už jen zjistit, jestli je tam ten udp driver. Projekt udp tam je, ale z roku 2006.

@Martine, co tam ten Vadim vlastně přidával či měnil?

SpeedDreams2 jde pustit. První věc - chci vypnout hudbu. Bohužel dostávám access violation :-(. A to v nějakém loggeru :-(. Protože _pStream není inicializovaný. Nicméně po ručním restartu už to alespoň nehraje, … a budu mít ještě chvilku čas se v tom vrtat .

Vybírám Race => QuickRace, ale nemůžu najít, jak tam vybrat nějakého UDP závodníka :-(. Tj. asi končím. Respektive nepustím si ver0.py, ale furt můžu zkusit kouknout na ty xml tracks.

…

Bingo (další polední spánek)! Jinak já teda nevím, ale asi máme o UI úplně jiné představy (tím myslím já vs. vývojáři Speed Dreams). Takže, když vyberete Quick Race, tak si nevybírejte jezdce kliknutím na tlačítko "Players", ne ne. Tím se jezdci nevybírají. Jak píše Martin, vybírají se tlačítkem Configure. A ta "herní" myš mě taky pěkně štve - vždycky, když to nad něčím přemýšlí, tak myš zmizí a člověk vůbec netuší, co se děje. A že to před startem přemýšlí fakt dlouho. Ale možná je to tou debug verzí.

Jestli to celé dobře chápu, tak na to, aby člověk programoval UDP bota, tak na to vůbec nemusí kompilovat vlastní Speed Dreams, ale stačí stáhnout binární instalaci. Ještě jsem to neověřoval, ale nemám dojem, že tam Vadim něco přidal či změnil. A to repozitory je teda mega nepříjemné na práci - 2.2G na stahování a po checkoutu a buildu to má 7.5G.

Čili první milník dosažen! Již druhý člověk po prvním průkopníkovi byl schopen spustit ver0.py!

… přijde mi, že kdybych sem dal pouze dvouřádkový návod, jak si to celé rozchodit, tak by si málokdo uvědomil, že to nebylo úplně „zadarmo” …

nainstalujte si minimalistickou verzí Speed Dreams 2 speed-dreams-base-2.2.1-r6404-win32-setup.exe (148MB)
přidejte Zbyňkův build UDP robota s Vadimovu konfiguraci a modelem Robocar speed-dreams-2.2.1-roborace.zip (10MB)

A je to. A je to celkem sranda.

Zbyňkova pozorování (resp. „detaily”, kterých jsem si já dříve nevšiml):

simulace je včetně zvuku (já ho mám na notebooku skoro permanentně vypnutý)
UDP roboti ve Speed Dreams byli ještě před Roborace
Roborace autíčka udp_1 až udp_20 jsou, včetně Robocar modelu, k dispozici pod složkou Roborace
ver0.py na Windows funguje a je to dost agresivní strategie (ve starších pokusech mi zůstávala v první zatáčce, ale s Robocar se odráží od mantinelů a i někam dojede)

Pohled z vrtulníku (F10)

Robocar ve zpětném zrcátku

19. listopad 2016 — Episode 3 (Maroko/12 autonomních okruhů)

Tentokrát díky za mailové echo od Martina … už je k vidění Inside Roborace — Episode 3:

Konečně pořádné záběry! Podle CNN Twitteru z minulého víkendu bylo sice vidět, že DevBot #1 jel v Maroku autonomně bez řidiče, ale info žádné.

Články ze včerejška:

(oba asi vychází ze stejné tiskové zprávy)

Ve zkratce:

DevBot #1 úspěšně dokončil 12 autonomních objezdů (bez řidiče) s tím, že v každém kole zrychloval
na příště plánují již „závod” dvou aut (pravděpodobně DevBot #1 a DevBot #2)

28. listopad 2016 — pyroborace - end_radius a predikce

Na poli Roborace byl minulý týden klid (jestli jsem zase něco nepřehlédnul) a tak bych alespoň zmínil, co nového s pyroborace — řízení Roborace-Dreams simulované formule programované v Pythonu.

Asi první zásadní změna je, že s demo.py už je možné jezdit po libovolném okruhu a ne nutně pouze Espie. Zbyněk vyřešil problém s offsetem tak, že teď je startovní čára vždy na pozici (0, 0, 0). Je k tomu potřeba jiná udp_Roborace.dll (viz Remove offset, fix #3, kde je detailněji řešení popsáno).

Druhý problém, který je snad již vyřešen (hrubou silou), ale zatím není v masteru, byly zatáčky s proměnlivou křivostí. Poznají se tak, že vedle radius mají v XML popisu také end radius. Jak se s tím pracuje je vidět v Roborace-Dreams zdroji, ale přiznám se, že mi to trvalo poměrně dlouho to pochopit (viz druhý pokus).

Algoritmus:

odhadni délku segmentu: arc * (radius + end_radius)/2
definuj počet dělících kroků jako podíl délky segmentu a hodnoty parametru profil steps length
přepočítej jednotlivé kousky tak, aby první měl poloměr radius, poslední end_radius a délka trajektorie byla v každém kousku stejná (tj. odpovídající úhel arc se pro proměnný poloměr také mění, stejně tak střed kružnice)

Výsledkem je výřez ze spirálovité křivky, kde ale každý jednotlivý úsek je stále „micro zatáčka” s pevným poloměrem.

K dalším drobnostem patří lepší počítání nejbližšího segmentu (chyba se projevila na okruhu Aalborg, kde jsou celkem divoké zatáčky) a řízení s 0.5s predikci, kdy Robocar už pěkně řeže zatáčky. S lepší regulací plynu se Robocar čas okruhu Espie snížil z 3 minut na 2:28 … ale stejně je stále na posledním místě.

bouračka u Aalborg

Ještě doplním krátký návod od Ondry aneb „pyroborace snadno a rychle”:

git clone git@github.com:robotika/pyroborace.git
cd pyroborace
git checkout XXX

(poslední krok je nutný pouze v případě, že chcete testovat nějakou „feature větev”)

spustit: c:\Program Files (x86)\speed-dreams-2.2.1\bin\speed-dreams-2.exe
naklikat Race->Quick Race->Configure->next
Z competitors odebrat player
Pod candidates přepnout na Roborace a do competitors přidat udp1
Next Next Start
Blokne se to na čekaní na UDP
spustit: ver0.py
nebo: demo.py "c:\Program Files (x86)\speed-dreams-2.2.1\data\tracks\circuit\espie\espie.xml"

A je to!

29. listopad 2016 — sada senzorů

Dnes jenom „štěk” z Twitteru: 17 ultrasonics, 6 cameras, 5 lidars, 2 radars and 2 optical speed sensors

Sada senzorů na Robocar

4. prosince 2016 — pyroborace - kreslení trasy

Na poli pyroborace je drobný posun. Předevnším už si můžete vykreslit trasu a do ní pozice auta nalogované během závodu. Kreslení je pomocí matplotlib, což je trošku „monstrum”, ale na kreslení grafů z Pythonu vřele doporučuji.

Merge kreslícího nástroje zatím probíhá zde, tj. v tuto chvíli v masteru ještě není. Já se ale zatím naučil spousty užitečných triků:

jak kreslit cestu (Path)
jak kreslit kružnici pomocí Bezierových křivek (o něco přesnější a podrobnější popis je pak zde)
jak pracovat s bounding boxem
jak si vynutit stejný rozměr v x-ové i y-ové ose

Další plán byl rozchodit logování přes WinCap, ale jelikož je komunikace pouze lokální, tak je ještě třeba Loopback a to už mi přišlo na „minimalistickou verzi” nějak nezdravě složité :-(. Dočasné řešení je tedy pouze:

log.write('{} {}\n'.format(absPosX, absPosY))

a drobné rozšíření plot.py.

A nějaké výsledky?! Co mne asi nejvíce překvapilo, jak je trajektorie po třech (resp. 2.5) kolech opakovatelná:

tady se to povedlo

a tady moc ne

Celý Espie okruh

p.s. tak ještě video (zdroj má 4.7GB, 4806 PNG souborů, konverze pomocí upraveného img2video.py). Je to bez zvuku, i když Speed Dreams zvuk generuje … někdy příště.

13. prosince 2016 — pyroborace - AmBot Espie 1:45

Včera mne potěšil AmBot, který v mailu píše:

Posílám jen informaci o tom, že také zkouším Roborace-Dreams a pyroborace.

Díky tvému blogu na robotika.cz se mi před pár dny podařilo systém zprovoznit (na Windows 10) a funguje jak ver0.py, tak i demo.py.

Už jsem si s tím i trochu hrál a hrubou silou se mi podařilo dosáhnout času pod 5:30 (v Quick race na trati Espie). Ta hrubá síla spočívala v tom, že jsem do skriptu pro každou zatáčku zadal maximální rychlost průjezdu a k tomu udělal jednoduchý regulátor rychlosti. Funguje to docela hezky. Zjistil jsem přitom, že když nechám jet to auto moc "tvrdě" (prudké přidávání plynu, prudké brzdění a rychlé průjezdy zatáčkami), tak se "rozbije" ještě před dojetím do cíle (selže na "damage", zastaví a je odtažen mimo trať). Také jsi to už zjistil?

Každopádně chci v pokusech pokračovat. Mám v plánu dopočítávat vhodnou rychlost v zatáčkách z parametrů trati (a ne to tam mít zadané natvrdo) a také se chci pokusit vyhýbat soupeřům (zatím na ně neberu ohled a počítám s tím, že uhnou oni).

a přiložil i link na video, jako důkaz:

Na titulním snímku je i vidět Best: 01:45.129, takže můj vánoční milestone už Aleš dosáhnul!

p.s. u Alešova videa si i můžete pustit zvuk

17. prosince 2016 — Episode 4 (Michelin HQ)

Testování na okruhu Michelinu

13. leden 2017 — Nvidia Autopilot

Tomáš S. mi poslal na první pohled nevinný link http://kevinhughes.ca/blog/tensor-kart s komentářem: „Pěkný článek, umělá inteligence pro Mario Kart pomocí Tensor Flow.” Nemusíte se bát na něj kliknout, jen varování, že přes pár odkazů se dostanete ke zdrojákům a datasetu Nvidia Autopilota! Ten původní článek se snaží ovládat počítačovou hru Mario Kart s využitím neuronových sítí a Tensor Flow frameworku.

Autor ve svém blogu zmiňuje, že Later, I switched to use Nvidia’s Autopilot developed specifically for self-driving vehicles. Cože?! Má tam odkaz na github Autopilot-TensorFlow, který implementuje nápady z Nvidia článku (pdf). Aby toho nebylo úplně málo, tak dává k dispozici i 2.2GB dataset, kde naleznete 45405 JPEG obrázků a soubor data.txt obsahující referenční úhel pro zatáčení. Nevím, zda úplně přesně implementoval, co bylo v článku. Tam je to 1/r, kde r je poloměr otáčení se znaménkem a rovné jízdě odpovídá hodnota 0.

obrázek 10070.jpg z datasetu

Nvidia pro učení použila stejný trik jako dříve švýcarská skupinka s učením drony (viz starší video od Cogito) — 3 kamery. Dopředná se učí kam má auto/drona jet/letět a levá a pravá jsou reference, pro které je třeba nějaká korekce. Nvidia ještě navíc generovala umělé pohledy s posunem z kombinace více snímků, ale základní myšlenka je stejná. Po naučení stačí už jen jedna (prostřední) kamera pro navigaci. Požadovaná reakce je sbírána ze senzoru na volantu auta.

Jestli vás to alespoň trošku vyvedlo z míry jako mne , tak toto cvičení máte skoro zadarmo. Je třeba si nainstalovat TensorFlow, k tomu ještě numpy, scipy, pillow" a opencv"" (de facto jsem vše instaloval z http://www.lfd.uci.edu/~gohlke/pythonlibs/ pro Windows a Python 3.5) a můžete nechat váš počítač zatopit. Pokud nemáte pořádnou grafickou kartu, tak to holt bude déle trvat, ale … uvidíme.

A proč to zmiňuji v tomto blogu? Nvidia je partner Roborace a řídicí algoritmy poběží na jejich DRIVE PX-2…

Ještě poznámka k velikosti zdrojového kódu: model.py má 88 řádek, train.py 55 řádek a run.py, který z video kamery určuje úhel pro zatočení, má 32 řádek. Nevím jak vás, ale mne to trošku děsí. Toto je předzvěst konce programátorů.

p.s. Udacity stejný kód použila pro svoji druhou lekci

21. leden 2017 — Episode 5

1. únor 2017 — Nvidia DRIVE PX2

Minulý týden jsem se snažil zjistit více informací k plánovanému řídicímu počítači Nvidia DRIVE PX2. Nevím, zda je to záměrné, ale je kolem toho docela guláš. Teď myslím sporné zprávy, že DRIVE PX2 má spotřebu 250W a musí být chlazený vodou vs. informace na že The new single-processor configuration of DRIVE PX 2 for AutoCruise functions —which include highway automated driving and HD mapping—consumes just 10 watts of power.

Zajímavá byla i informace, že DRIVE PX2 bude vedle Roborace používat i Tesla Motors ve všech svých autech (Model S, Model X a brzy i Model 3). To hned zvedlo diskusi na Tesla Motors Club, jak je možné dodávat počítač v ceně 15000 USD do aut, která mají stát 35000 USD?

Ono důvodem bude nejspíše více variant platformy, kde ta minimální by měla být brzy výrazně levnější, se spotřebou 10W, a na druhém konci spektra je výkoná se zdvojenou GPU i CPU jednotkou. Že se jedná spíše o platformu naznačuje i článek ZF debuts ProAI, a production self-driving system based on Nvidia’s Drive PX 2.

Představení DRIVE PX2 na loňském CESu

Product Specifications: NVIDIA DRIVE PX 2 is powered by the company's newest system-on-a-chip, featuring a GPU based on the NVIDIA Pascal™ architecture. A single NVIDIA Parker system-on-chip (SoC) configuration can process inputs from multiple cameras, plus lidar, radar and ultrasonic sensors. It supports automotive inputs/outputs, including ethernet, CAN and Flexray.

P.S. ještě bych přidal link na video, kde s tím Nvidia teprve začínala a auto, podle očekávání, dělalo pěkné skopičiny … je to jenom cca 20s předehra, pak už je prezentace, jak je to dokonalé po trénovaní 3000 mil z března 2016 …

17. únor 2017 — Zítra DevBotí duel v Buenos Aires!

Zítra se v Buenos Aires jede další kolo závodů FIA Formule E. V Čechách by to měla vysílat Sport Aréna TV (resp. na Slovensku), kdy kvalifikace je v sobotu v 15:45:

Buenos Aires  Qualifying LIVE  18/02/2017  Saturday  15:45 CET  17:10 CET
Buenos Aires  Race LIVE        18/02/2017  Saturday  19:45 CET  21:30 CET

Stánek Roborace

Roborace je ale pouze doplňkový program, který ale televize vysílat neplánuje:

Schedule - Saturday 18 February 2017
8:00 am - 8:45 am: PRACTICE 1
8:55 - 9:15 am: Roborace Practice
10:00 am - 10:20 am: Qualifying Group Lottery
10:30 - 11:00 am: PRACTICE 2
12:00 pm - 12:36 pm: QUALIFYING
12:45 pm - 13.00 pm: SUPER POLE
2:00 pm - 3:00 pm: ROBORACE
1:45 pm - 2:00 pm: eRace
2:00 pm - 2:30 pm: Drivers autograph session
3.00 pm - 3:18 pm: Drivers parade
3:30 pm: GRID POSITIONING
4:00 pm FORMULA E BUENOS AIRES ePRIX RACE 1
5.00 pm: Podium ceremony
6:00 pm: Gates close

Závodní okruh

Jestli dobře počítám, tak 20-16 je časový posun jen 4h … hmm, tak to by Roborace byl snad někde ke shlédnutí mezi 18-19h. No uvidíme. Při nejhorším to bude určitě další Roborace Epizoda.

19. únor 2017 — ibeo Wide Angle Scanning (ScaLa) Sensor

Včerejší závod stál za houby, resp. já z něj nic neviděl :-(. YouTube video stream byl povolen jenom v británii (The uploader has not made this video available in your country.) a proxy přes UK mi nefungovala. Veškeré info je tedy pouze z Roborace Twitteru, konkrétně Devbot 2 while pushing the boundaries of AI had a racing incident on track, leaving Devbot 1 to win. No drivers were harmed though

Co mne ale včera potěšilo je spekulace o použitých laserových senzorech. Tipoval bych (95%), že to jsou IBEO ScaLa senzory. Uznávám, že vycházím pouze z „podobnosti krabiček”, umístění úchytů a konektoru a z obrázku z listopadu, kde pět laserů má rozsah cca slibovaných 145 stupňů.

Foto z autonomoustuff.com

Tento senzor jsem viděl poprvé loni na Dni chytrých aut. Moc pěkný — skenuje ve čtyřech rovinách, rozlišení 0.25 stupně a záběr zmíněných 145 stupňů. Navíc se jedná o „chytrý” senzor, což znamená že snímaná data rovnou zpracovává (viz ibeo-Object-Tracking-3.pdf).

Pro představu přikládám toto veřejné video … možná to místo poznáte … mám pocit, že jsem tam za rohem roky chodil do školy

25. únor 2017 — Episode 6 - kolize při závodu v Buenos Aires

V šesté epizodě je alespoň malý střípek toho co se minulý víkend v Buenos Aires stalo: DevBot2 narazil na pravý mantinel, zlomil přední osu a demo závod byl ukončen.

3. březen 2017 — LEGO?!

Koukal jsem se teď na video s detailními záběry Robocar z Barcelony (viz Engadget.com) a zaskočilo mne logo LEGA?! Chvíli jsem hledal a jedno podezření bylo, že původní název Roborace používalo před mnoha lety LEGO (IEEE článek z 2004).

Logo LEGO na Robocar

Další nápověda je přímo na Roborace twitteru z loňského léta s pěkným komentářem Please tell me the Roborace cars aren't using Mindstorms. They are really great for kids... not so much racing cars

No a podle všeho LEGO zvažuje výrobu hraček Formula E (tři dny starý update): https://ideas.lego.com/projects/169283

Licensing: Potentially a big issue as this will need the approval of all the featured teams, their sponsors, drivers and Formula E themselves. However, Formula E's support series, Roborace, has already partnered up with Lego Speed Champions and placed the logo on the Roborace car; this means that a Roborace set is quite likely to be announced in the future. If the support series with close ties to FE decides to go for the Lego option, how long until the main series follows suit? In terms of attracting a younger audience, which is what both Formula E and Roborace set out to do, it makes perfect sense.

No čím nás ještě Roborace nepřekvapí …

31. březen 2017 — Episode 7 - představení Robocar v Barceloně

p.s. jenom připomínám, že zítra je závod v Mexico City

p.s.2 tak nakonec se Roborace v Mexico City neprezentovala :( … jako důkaz viz http://roborace.com/

Mexico 2017 bez Roborace

12. duben 2017 — Vstupenky na závody v Paříži již v prodeji

Pokud uvažujete o výletu do Paříže 20. května 2017, tak vstupenky na závody Formule E jsou již v prodeji (55 EUR).

Jinak nic extra nového/zajímavého. Možná za zmínku stoji informace z tohoto videa (zdroj CNN Money), kde na otázku kolik to auto stojí Denis Sverdlov odpovídá:

How much did it cost you? To me? Yeah. Around 1 million pounds, to make this car. So a little more than a million dollars.

No mně 31 milionů korun nepřijde „o trošku více” než 25 milionů, ale nechť … prostě rozflákat by to byla škoda.

19. květen 2017 — Roborace Paris (pátek)

22. květen 2017 — Roborace Paris 2017

… tak toto je vše, co bylo z Roborace v Paříži k vidění. Možná trošku zklamání, ale když si přečtu Jirkův „věštecký mail”: Mluvis o vstupu do zakulisi, nebo o sezeni na tribune, kdy kolem dvakrat projede devbot (v lepsim pripade)?, tak se musím jenom smát. Jak to věděl?! Ale od začátku. Závody FormulaE se konaly na Invalides, což je opravdu v centru Paříže. Po nedávných událostech jsou všude ozbrojenci a policie. Platí podobné zákazy jako na letišti, lahve s pitím do 500ml, pouze malé batůžky a pod.

Na místo jsme se Zbyňkem dorazili v pátek okolo 11h, ujasnili si, že v poledne nás pustí dovnitř (trať a veškerá infrastruktura již byla hotova) a obešli celý okruh z vnějšku. S nejrůznějšími zátarasy to vyšlo na tu zbývající hodinu. Invalides je palác s parkem, závody se jely okolo paláce. V parku byly na jedné straně pity jednotlivých týmů a na druhé pak reklamní stany převážně výrobců elektrických aut. Centrální trávník byl ohraničen dvěma obrovskými obrazovkami (eVillage).

Obešli jsme cca 90% a o Roborace ani zmínka. Info stánky vůbec netušily o čem mluvíme (a to nebylo jen z důvodu anglo-francouzského komunikačního problému) a tak jsem začal propadat depresi. Čekal jsem ledacos, ale že by Roborace do Paříže vůbec nedorazila (jak do Mexika), tak na to jsem psychicky připravený nebyl. Pak jsem ale zahlédl zadek auta na stánku pojišťovny Allianz a … to musí být Robocar! Byl, jenom nějak divně pomalovaný. Klučina, co měl dávat návštěvníkům informace, věděl jenom že to jezdí samo a víc nic. Ale šéfová stánku mluvila dobře anglicky a nasměrovala nás zpět na začátek s tím, že Roborace pit je hned první stánek a že jsme ho nemohli minout …

A stánek tam byl, jenom byl zavřený a za plotem a nikde nikdo. První osoby, kterou jsme viděli, jsme se ptali na Vadima, což byl jediný člověk z Roborace, co s námi občas komunikoval. A byl tam … ale moc nadšený nebyl a ukázalo se, že po Paříži s Roborace končí. Super, tím se počet kontaktů snížil na nula.

A tak jsme čekali dál za plotem a civěli na stánek Roborace. Po nějakém čase odtáhli pravou polovinu a hle DevBot1 a vedle DevBot3! Vida, tak alespoň něco nového. DevBot2 tu kolizi v Buenos Aires asi nerozdýchal. :-( O něco později jsme viděli DevBot1 na okruhu. Při druhé jízdě narazil. Podle všeho ale nebyl v autonomním módu a byla to chyba testovacího pilota.

Milé překvapení nastalo okolo 18:30 — otevřeli vstup všem do pitů. Zamířili jsme rovnou k Roborace, kde tentokrát pootevřeli i levou polovinu stanu. A tam byla „žlutá kára”, která mi byla daleko více povědomá než ta červená u Allianz. Bavili jsme se i s vývojáři a dozvěděli se, že jedna z věcí, co je trápí, je nízký framerate laserů (pouze 25Hz) a že ochranné sklo moc nevydrží. Dozvěděli jsme se i časy sobotního dema: ráno test v 8:55 a odpoledne v 14:00

A co sobota? Na okruh vyrazila žlutá robokára, ale na přechodech zastavovala a dávala asi přednost virtuálním chodcům. Chápu, že jí tvůrci nechtěli rozbít už při první příležitosti, ale … alespoň se to hýbe a není to jenom pěkná maketa.

Uvidíme, jak to bude dál, ale do Berlína 10. června 2017 nejspíše nepojedeme …

P.S. Roborace vydalo tiskovou zprávu, ale názor si musíte udělat sami …

P.P.S.S. 24/5 Roborace vydalo svoji verzi (zatím to není ani Epizoda)

kontaktní formulář

Grand Challenge 2005

2005-10-15T00:00:00Z

Logo soutěže

Mapa trasy s vyznačenými kontrolními body byla týmům předána dvě hodiny před startem. Do finále postoupilo celkem dvacet tři družstev. Po loňském debaklu, kdy nejdelší ujetá vzdálenost činila necelých osm mil, letos překvapivě soutěž dokončilo pět robotů, z toho čtyři se vešli do desetihodinového limitu. Poslední, největší a nejtěžší, nákladní automobil TerraMax, zdolal trať za necelých třináct hodin čistého času.

Prémii dva miliony dolarů si ovšem mohl odnést pouze jeden, a to ten, který trasu projede nejrychleji.

Stanley

Výsledky

Pořadí	Robot	Družstvo	Čas
1.	Stanley	Stanford Racing Team	6:53
2.	Sandstorm	Red Team Too	7:14
3.	H1ghlander	Red Team	7:14
4.	GrayBot	Gray Team	7:30
5.	TerraMax	Team TerraMax	12:51

Stanley

Letošní vítěz, Stanley, je od normálního VW Touareg takřka k nerozeznání. Pomineme-li množství čidel na střeše. Také jako jeden z mála přihlášených robotů se smí účastnit běžného silničního provozu. Mozkem robota je šest (dle některých pramenů sedm) základních desek osazených procesorem Pentium-M a uložených v robustním rámu. Vedoucí týmu Sebastian Thrun tvrdí, že i při výpadku dvou jednotek by byl robot schopný pokračovat v závodu.

Vývoj na tomto robotovi začal v červenci 2004 a jako testovací trasu používali vývojáři původní trasu Grand Challenge z roku 2004.

Komu nedělá potíže mluvená angličtina, nebo kdo si užije i jen záběry, tomu doporučujeme shlédnout některé filmy z oficiálních stránek Stanford racing teamu.

Stanleyho senzory

Vizualizace sledování cesty

Pro snímání okolí:

LIDAR — pět laserových dálkoměrů, slouží obdobně jako radar.
Kamera — některé zdroje uvádějí stereo kameru.
Radar — pro měření na delší vzdálenosti.

Pro určení pozice:

GPS s dvaceticentimetrovým rozlišením.

Pro určení orientace vozidla:

Měření posunu a náklonu podel všech tří os.
GPS kompas, založený na dvou GPS anténách.
Měření ujeté vzdálenosti.

Red Team Too (Také červený tým) — SANDSTORM

Red Team Too - Sandstorm

Loňský veterán Červeného týmu z univerzity Carnegie Mellon ve Spojených státech. Toto vozidlo armádního typu HMMWV (Hummer), vyrobené v roce 1986, se zúčastnilo již loňské soutěže Grand Challenge. Loni se stalo neoficiálním vítězem, neboť jako jediné ujelo téměř osm mil.

V letošním roce bylo jeho úkolem dojet na bezpečném třetím místě. Řídící systém byl na závod nastaven na "bezpečnou jízdu", která měla zajistit jistý dojezd.

O to větší bylo překvapení tvůrců, když SANDSTORM převálcoval H1GHLANDER, druhé vozidlo z univerzity Carnegie Mellon.

Red Team (Červený tým) - H1GLANDER

Red Team - H1ghlander

Tento 1999 H1 Hummer měl, podle autorů, "vyhrát závod s půlhodinovým náskokem před zbytkem závodního pole." Nestalo se. Technici Červeného týmu stále ještě analyzují počítačové záznamy jízdy, aby zjistili, co se stalo s motorem. Zdá se, že došlo k technické závadě a motor nemohl jet na požadovaný výkon. Řídící systém proto stále prudce zrychloval a opět zpomaloval, aby udržel požadovanou průměrnou rychlost. Za této situace je překvapivé, že H1GHLANDER vůbec dojel do cíle.

Senzorické vjemy

Senzory a řídící systém obou robotů

Nejviditelnějším prvkem je odpružený otočný laserový scanner umístěný na střechách obou vozidel. Ten se společně s dalšími lasery a radary stará o snímání okolí. Sedm počítačů s procesory Pentium-M pak řídí vozidlo na základě naměřených údajů, pozice naměřné pomocí GPS a ujeté vzdálenosti.

Více informací o obou vozidlech univerzity Carnegie Mellon se můžete dočíst na anglických stránkách týmu.

Gray Team - překvapení závodu

Gray Team (Šedý tým)- GrayBot

O tomto družstvu není mnoho dostupných informací. Ačkoli to podle názvu tak vypadá, nejedná se o další družstvo Carnegie Mellon. Za touto skupinou nestojí žádný významný sponzor typu Volkswagen, ani renomovaná univerzita. Hlavním tahounem a organizátorem se stali ředitelé a majitelé pojišťovny The Gray Insurance Company. To, a skutečnost, že tento tým z Luisiany přišel kvůli hurikánu Katrina o své vývojové laboratoře, vyvolalo v mnohých novinářích pocit, že se jedná o outsidery.

Po shlédnutí krátkých informačních filmů nezbývá než zamyslet se nad tím, o koho se jedná, když si může koupit pozemek o rozloze 52 000 akrů a na něm postavit 200 mil (zhruba 300 km) trénovacích cest a překážek.

Senzory GrayBota

Zdá se, že hlavní výhodou týmu se stala schopnost jeho vedoucích přenést vývoj a testování nových technologií na dodavatele senzorů a jiných potřebných částí.

Technické parametry

2005 Ford Escape Hybrid, nejužší, a tedy nejmanévrovatelnější, SUV na americkém trhu, byl zvolen nejen kvůli svým jízdním vlastnostem, ale i pro svou mimořádně nízkou energetickou náročnost. Díky optimálnímu využití výkonu a solárním panelům na střeše vozidla není potřeba žádný speciální zdroj energie pro palubní počítače.

Vjemy obstarává známá sestava lasery/radary/kamery/GPS. Rozhodování a řízení má na starosti, trochu netradičně, pouze dvojice počítačů. A to navíc jeden z nich pouze zaznamenává údaje o jízdě a do řídícího procesu nijak nezasahuje.

Další informace jsou dostupné na stránkách týmu (v angličtině).

TerraMax

I na této robotické soutěži jsou k vidění velmi rozdílná řešení

Největší vozidlo na startu, šestnáctitunový kolos TerraMax, dojel sice jako poslední, ale dojel až do cíle a to se počítá. Jako konstrukční základ posloužilo americké armádní nákladní vozidlo střední třídy.

Jako senzory používá:

LIDAR - čtyři dopředu (dva na dálku a dva na bližší vzdálenost) a jeden vzad zaměřený laserový systém
Kamery - tři vpředu, dvě vzadu pro couvání

Pro určení pozice a orientace:

GPS a blíže nespecifikované inerční zařízení

Software pro kamery, které jsou namířeny dopředu, byl vyvinut na univerzitě v Parmě v Itálii. Byly použity jednoduché VGA kamery.

Na oficiálních stránkách týmu (v angličtině) jsou k dispozici různá povídání, videa a fotografie.

Zajímavosti

Pro vyšší diváckou atraktivitu letos soutěž začínala i končila na stejném místě.
Trasa vedla několika tunely, aby roboti ztratili signál ze satelitního navigačního systému GPS a museli se bez něj chvíli obejít.
Roboti museli překonat několik mostů a velmi úzkých průsmyků. Robot TerraMax při zdolávání jednoho takového úzkého úseku skutečně zacouval jedním zadním kolem nad propast.
Když soutěž skončila, bylo jasné, že někdo vyhrál, nikdo však nevěděl kdo. První čtyři vozidla dorazila s několikaminutovými rozestupy a přitom byla v průběhu závodu občas zastavována. Tento čas stání tedy bylo potřeba zjistit a odečíst od naměřené doby jízdy.
Šedý tým dokončil závod za tmy v sobotu v noci, neboť jako jediný nebyl závislý na denním světle. Oproti tomu robot TerraMax byl na noc zastaven a dojížděl až v neděli ráno.
Americký slogan VW hlásí "Drivers wanted" - "hledáme řidiče", Staley má na kapotě: "Drivers not required" - "řidičů netřeba."
"Kdyby se neporouchal motor, byl by H1ghlander první" (člen Červeného týmu).
"Letošní soutěž byla příliš lehká. TerraMax byl připraven na mnohem těžší podmínky. V těch by zvítězil" (člen týmu TerraMax).
"" (členové týmu Stanford Racing Team).

Odkazy a zdroje (vše v angličtině)

The Great Robot Race (video)

Update 2017 (Martin Dlouhý)

Přišla mi reklama z Udacity na jejich revidovaný kurz Self-Driving Car Engineer Nanodegree Preview. Neodolal jsem a podíval se, co se změnilo od doby, kdy jsem původní kurz (tehdy zdarma) absolvoval. Asi zásadní rozdíl je, že nyní si můžete váš kód nakonec pustit v reálném autě … ale to odbočuji. Co mne dojalo až k slzám bylo následující video. Je to film pro pamětníky. Když budete pozorní, tak mezi soutěžícími najdete snad všechny velké hráče v oblasti vývoje autonomních aut

Máte-li jakékoli dotazy či připomínky — kontaktujte nás. Rádi vám odpovíme.

Robotour 2017

2017-03-08T00:00:00Z

Pravidla

Letos dochází k významnější změně pravidel: již nebude nutné startovat v chumlu s ostatními roboty ve vymezeném úzkém časovém rozmezí. Roboti se prostě v čase 0:00 dozví, jakou mají realizovat donášku (pozice nakládky a vykládky) s tím, že to je třeba realizovat do jedné hodiny od vyhlášení. Extra body zůstávají za automatickou nakládku a vykládku, i když ji vzhledem ke složitosti úkonu nedoporučujeme implementovat. Nakládka a vykládka bude v tzv. „autonomní oblasti” a je na týmu, kterou příjezdovou cestu zvolí. Ruší se i bodování ujetých metrů — body tým získá pouze za úspěšně realizovaný úkon (nakládka, vykládka a opuštění autonomní oblasti).

Detailní pravidla jsou k dispozici na GitHubu s tagem ROBOTOUR2017: česky a anglicky.

Ukázky cestiček v Žilině (park Ľudovíta Štúra)

Lokalita

Soutěž bude probíhat primárně v parku Ľudovíta Štúra.

přehledová mapa

Pokud chcete soutěž nějakým způsobem podpořit nebo máte nějaké doplnění/dotaz, tak se nám prosím ozvěte pomocí kontaktního formuláře.

SICK Robot Day 2016

2016-09-07T00:00:00Z

Pravidla v kostce

Hrací aréna má rozměry cca 7x13m. Dva autonomní roboti startují ze žluté a růžové 3x3m nakládací zóny. Jejich úkolem je dopravit kostky do střední 5x5m velké šachovnice. Kostky je nutné vozit jednotlivě a roboti získávají body za každý pokrytý 1x1m čtverec. Bod získává robot, který kostku na daný čtverec umístí první. Jakmile kostku položí stává se automaticky překážkou (pro oba roboty) a kontakt je penalizován ztrátou 0.5 bodu.

Zápas trvá 10 minut a každý tým odehraje jenom dva. Soupeř a barva jsou náhodně losovány. Pro usnadnění lokalizace je v každém křížení RFID čip. Kód jednak určuje (X, Y) pozici a dále typ „zóny”. Týmy mají od pořadatele zapůjčené senzory RFU 620, pomocí kterých lze pres Ethernet nebo CAN data číst.

Obsah:

Blog

7. září 2016 — ver0

Začínám s textem jako klasický Copy & Paste předloňského a tak vidím, že před dvěma lety byl první záznam s titulkem „Měsíc do soutěže” … tak to sedí . Soutěž se totiž koná v sobotu 8. října 2016 ve Waldkirchu/Německo … jako vždy.

Náš tým je v zásadě stále stejný, jenom se k nám nově přidal Ondra z prvních MARTů — původně se přišel podívat na autonomní traktůrek, ale na tento měsíc jsme přesměrovali veškeré kapacity na „SICK robota”. A už se i plně zapojil (viz Pull request - simple interface for RFU620 sensor).

Promazávám starý text … a github, kde naleznete kód (za včerejší commit se fakt stydím) stále platí:

https://github.com/robotika/eduro

Ten ošklivý commit odpovídá naší verzi 0, tj. nejjednodušší verze, kdy robot boduje. Naslepo zavře klepeta, popojede 2m, otevře a trošku si couvne, aby mu přihlížející mohli tleskat .

pohled na kostky z Edura

Po rozchození verze 0 jsme upgradeovali hardware, takže to už nefunguje a jsme zase na začátku . No nejsme — stačí prohodit Alix s APU2 a ver0 by zase měla fungovat. Co je za problém? APU2 není ještě pořádně nastavené a tak vypisuje systémový log do CAN komunikace … a to není pěkné. Možná jsou ve hře ještě další faktory, ale to zatím nevíme. Hlavní podezřelý je /boot/grub/menu.lst. (konzoli nechceme úplně zaslepit, protože v případě problémů je to jediná(?) cesta jak se s APU2 bavit)

p.s. podle posledních zpráv dmesg -D problém řeší

14. září 2016 — Velodyne Black Hole

Výsledky včerejšího testování byly zajímavé. Primárně šlo o integraci všech plánovaných senzorů a nasbírání dat. Standa si nechal (naštěstí) říci, že servo ručičky během prvních jízd urveme, a tak přidělal ochranný kryt (a hned jsme ho 2x využili). Přibyla také polohovatelná základna pro Velodyne VLP-16, protože vodorovně kostky skoro neviděl.

Eduro s nakloněným Velodyne

Ta změť drátů vzadu skoro odpovídá současnému stavu — navíc přibyl router/switch, protože na řídícím počítači APU2 nám již došly Ethernet zástrčky (kamera, Velodyne laser, RFU620 čtečka a terminál k notebooku). Což mi připomíná, že pokud se nějakému týmu podařilo rozchodit RFU620 po CAN sběrnici, tak nás to zajímá (ten router bych rád zase odstranil).

První dobrá zpráva byla, že nějaké RFID čipy jízdou po hřišti detekujeme:

(31, [scan(id=17592236638209, RSSI=-67.2, power=24.0)])
2
(32, [scan(id=17592236638209, RSSI=-69.2, power=24.0)])
3
(33, [scan(id=17592236638209, RSSI=-70.8, power=24.0)])
2
(34, [scan(id=17592236638209, RSSI=-73.1, power=24.0)])
2
(35, [scan(id=17592236638209, RSSI=-76.6, power=24.0), 
      scan(id=17592253415427, RSSI=-71.2, power=24.0)])
2
(36, [scan(id=17592253415427, RSSI=-64.5, power=24.0)])
3
(37, [scan(id=17592253415427, RSSI=-67.4, power=24.0)])
2
(38, [scan(id=17592253415427, RSSI=-73.8, power=24.0)])
2
(39, [scan(id=17592253415427, RSSI=-69.7, power=24.0), 
      scan(id=17592236638209, RSSI=-77.9, power=24.0)])
3
(40, [scan(id=17592253415427, RSSI=-67.5, power=24.0)])

Jak moc se z toho bude dát lokalizovat teprve uvidíme. Zatím to vypadá celkem dobře: vždy nějaké detekce a někdy i dvojité … ale neplatí to pro celý log.

Horší to bylo s Velodyne. Takto vypadá jízda s nakloněným senzorem:

Neviděl blízkou kostku a na konci pokusu „prošel zdí” a zmizel v „černé díře”. Ono to dává smysl, že senzor má nějakou slepou zónu, jen jsme nečekali, že to bude s poloměrem 50cm … to ty SICK LIDARy mají méně. A tak jsme dočasně Velodyne odstranili a nahradili ho „malým SICKem” vpředu vedle klepet.

Detekované kostky laserem

Jednu slabinu to ale má? Když se nabere kostka, tak ztratíme polovinu výhledu. Jako brute force řešení je dát druhý malý SICK i zleva, ale třeba přijdeme na něco elegantnějšího.

A co vy? MARTi se snad pomalu „probouzí”, Alpaca zatím „mlčí” … kdo dál se chystáte na soutěž?

25. září 2016 — ver1 (zbývá 11dní)

Je neděle, krásné počasí (nesrovnatelné s minulým týdnem na Robotour), ale místo relaxace na zahrádce zase koukám do logů. A moc uklidňující to není.

Cílem verze 1 je dokázat umístit více kostek (tři na nejbližší pozice). To by možná fungovalo, kdyby robot „zavřel oči” a nesledoval potenciální kolizi s nepřítelem a neinspiroval se RFID tagy pro určení pozice. V úterý jsme částečně přešli na čtení dat z RFU620 přes CANOpen, tj. místo Ethernetu teď chodí packety po CAN sběrnici. Ale chová se to nějak divně. Robot jede 2 metry rovně a na konci přejezdu čtečka hlásí, že zase vidí RFID tag, co byl na začátku :-(.

Ani s detekcí nepřátelského robota to není moc růžové. KISS řešení, kdy se v daném úhlu vezme nejmenší vzdálenost a pokud je menší než řekněme 20cm, tak prohlásí cestu za neprůjezdnou, kupodivu nefunguje (viz raw data z laseru v milimetrech):

[   56    68    62    59    62    66    68    64    66    84   287   496
   535   549   559   570   583   597   606   619  2227  2240   644  2261
  2273  2285  2300  2314  2332   743   758   777   795   818 10000 10000
 10000 10000 10000 10000 10000  2632  2666  2703  2739  1172  1210  2802
  2744  2722  2758  2718  7839  1687  1651    21    18    41    65     2
  2369  2339  2311  2281  2261  2232  2122  2092  2079  2061  2038  2019
  2004  1987  1979  1969  1960  1938  1933  1926  1912  1898  1890  1891
  1880  1867  1863  1854  1846  1841  1843  1840  1836  1824  1830  1828
  1827  1827  1817  1822  1816  1822  1825  1830  1840  1843  1838  1850
  1854  1856  1866  1874  1886  1899  1902  1921  1924  1946  1953  1965
  1986  1989  2007  2033  2043  2060  2081 10000 10000 10000 10000  1956
  1972  2002  2024  2045  2030  1983  1948  1909  1864  1500  1576 10000
 10000   805 10000  1665  1641  1625  1608  1583  1563  1541  1527  1517
  1487  1474  1191  1353  1436  1414 10000   623   613   619   615  3003
  1330  1320  1307  1297  1290  1285  1279  1275  1268  1260  1257  1248
  1257]

Ať žijí duchové! Teď nemyslím ty malé hodnoty na začátku, to by šlo vyřešit menším úhlem, ale 21 18 41 65 2 už je marnost, opakovatelná. Navíc hodnoty odrazivosti jsou až na poslední dvojku rozumné, takže ani tak nelze měření profiltrovat …

Uvidíme na dalším testování v úterý. Snad alespoň navigace na kostku bude fungovat lépe (teď se místo nejbližší hodnoty vezme skupinka, snad odpovídající detekované kostce, a pro ní se vezme středový úhel).

p.s. Alpaca potvrdila účast na společném testování 4. října

28. září 2016 — kabeláž (zbývá 8dní)

Přemýšlel jsem, co se včera posunulo a jediné, co mne napadá, je kabeláž. Tomáš nahradil několikametrové „industriální” Ethernet kabely menšími, takže teď jsou už zase vidět LEDky na horním panelu. Ale to je asi vše. :-(

Rezignovali jsme na CANopen u RFID čtečky — pro zapnutí skenu je třeba posílat textovou SDO zprávu, rozdělenou do více packetů, a to se nelíbilo ani mně ani Tomášovi. RFU620 tedy bude pouze na Ethernetu. Tečka.

Co se týče detekci kostky z malého laseru, tak stále potvrzuji přítomnost „duchů”. Jakub to do mailu komentoval: Martine, když už je to Jakub's idea, nechceš tam přidat i tu část, která umí rozlišit mezi kostkou a stěnou? a měl pravdu. Teď se pro hlouček bodů ověří i velikost a tím se některé zavádějící detekce (např. [ 438 211 1767] … tj. ojedinělý bod v 0.211m) odstraní.

Problém s duchy, resp. rušícími odrazy od konstrukce, asi nastává i pro detekci blokované cesty. Zde bude nutné filtrovat na překážky veliké alespoň jako kostka.

Ještě jeden vtipný test s navigací na kostku (vlastně jeden z mála pseudo „úspěšných”). Bral se nejbližší bod, ale slepá zóna byla nastavena na 20cm. Zároveň se kostka musela nacházet v prostoru osy středu robota do 40cm. V této kombinaci robot najel na první kostku a „ztratila se mu z výhledu”. Uviděl však další a pak ještě jednu. Vypadalo to celkem zábavně:

… ale kdo ví, co přesně dělal. Teď je tam slepá zóna 1cm a doplněno filtrování na velikost kostky.

Navigace na kostku ale dobrá není. Použitý driver.goToG generátor hrozně osciluje. Je na čase to po sobě po několika letech zase přečíst … tak nastavit se dá jak daleko od cíle skončit. Teď naviguje na pozici kostky, aby byla ve středu robota a to není dobré (nutně jí netrefí napřímo a kostka mine klepeta). Pak lze omezit rychlost otáčení, default je 10 stupňů za sekundu … to je asi hrozně málo??

Samotný goToG algoritmus je jednoduchý:

pokud cíl vidíš pod příliš velkým úhlem otáčej se na místě (velký úhel defaultně znamená také 10 stupňů)
pokud jsi blíž než finishRadius zastav a konec jinak otáčej rychlosti
proporcionální úhlu na cíl (zhruba) OK, zvětším úhel i cílový poloměr a snad to bude lepší.

Jirkovi (Cogito) jsem přislíbil nějaké foto naběráku, tak tady je:

Eduro před revizí kabeláže

naběrák

pohled zpředu

p.s. za větší počet kostek vděčíme Davidovi/MART týmu, díky. A mimochodem vznikla „Cogito MART” koalice, tak jsem zvědav.

29. září 2016 — Svatováclavské testování

Svátek v půlce týdne … jak stvořený pro testování.

Navigace na kostku

Není nad „hloupé” algoritmy a dnes se mi to znova potvrdilo. Původní implementace si spočítala polohu kostky a pomocí GoTo navigovala robota (ostatně viz výše). Ale vhodně naladit parametry nebylo úplně triviální a tak nastoupil KISS (Keep It Simple Stupid).

Co takhle: když je kostka vlevo, toč vlevo. A když je vpravo, tak toč vpravo. Zní to dostatečně triviálně? Asi čekáte šílené oscilace, ale co když definujete střed +/- 1cm, kde nic neděláte, a rychlost otáčení jen 10 stupňů/sekundu? Kupodivu se Eduro trošku vrtělo, ale jinak dobrý! Tak se vám otáčí za detekovanou kostkou a když se neotáčí, tak je něco špatně. Vzhledem ke složitosti algoritmu je špatně detekce kostky.

Předešlý algoritmus skončí na TIMEOUT a nikdy nic nenabere. Co drobné vylepšení, kdy ve střední poloze se robot pomalinku rozjede vpřed? A je to! Pravda ještě podmínku, že když je kostka už v klepetech, tak konec, popojeď rovně a spusť nabírání.

Robot buď popojíždí ke kostce nebo „se kousne” a v daném laserovém skenu nic nevidí … a to je vzorek dat hodný prozkoumání (celkem z 37 jízd a 20MB laserových dat).

Případně viz odpovídající commit (ano, zase ostuda, je tam namícháno i vypínání serv po ukončení jízdy … prostě mne ten zvuk při testování rozčiloval a git commit -p úplně ještě neovládám :-(

Verze 1

Cíl umístit 3 kostky: vlevo, rovně a vpravo. Opakovaně. Spolehlivě. Aneb „bylo nebylo” … no zatím to není. Využívá to již navigaci na kostku a ano, často se to „kousne” (zatím), ale to je řešitelný problém. Spíš už pomalu nastupuje úloha: a co když místo jedné kostky jich je 25?! Ono i 4 kostky jsou pro začátek dost:

pokud robot nabere jednu kostku, ale jinou hrne, tak ztrácí body (a v našem případě se sám sebe lekne, kostky odhodí a vrátí se do domečku/nakládací zóny).
když jsou kostky blízko sebe, tak nefunguje klasifikace podle velikosti.
když si už jednu kostku vybere, tak se nesmí nechat zmást jinou, bližší. Aby robot neskončil jako oslík mezi dvěma kupkami sena.

Kostka viděna laserem

Problémová detekce hrany kostky (vyřez)

Toto je příklad dat, kdy hrana kostky je detekována blíž než stěna kostky.

2. říjen 2016 — Příprava ver2

Je asi chyba začít pracovat na „verzi 2”, když „verze 1” ještě není ani odladěná ani spolehlivá. Čas už se krátí. Verze 2 by měla být schopna se absolutně lokalizovat a měla by zajistit funkčnost robota po celých 10 minut soutěže. Z dřívějších zkušeností víme, že na klouzavém povrchu ve sportovní hale ve Waldkirchu se samotnou odometrií dlouho nevydržíme. Letos tam mají položit koberec, ale jestli to bude posun k lepšímu těžko říci.

Pro absolutní lokalizaci se nabízí:

kompas
RFID tagy
detekce mantinelů hřiště
použití již položených kostek
???

Kompas

Obecně mu moc nedůvěřuji, ale po posledním projektu s „robo-lodičkou” bych ho zase vzal v úvahu. Cvičně jsem si zobrazil hrubá data a trošku jsem se zalekl:

kompas XY

kompas XZ

kompas YZ

Ono toto už byla před-zpracovaná data! OK, druhý pokus, teď už snad opravdu raw:

raw kompas XY

raw kompas XZ

raw kompas YZ

Viděl jsem už hezčí kružnice, ale dal bych mu šanci (zase mám pocit, že i s kompasem byl u SICKů nějaký problém, ale … uvidíme).

RFU620

Data z jízd pomocí ver1 lze použít i pro vizualizaci detekce jednotlivých tagů (ono hezčí by byl nějaký animovaný gif, ale ten teď asi neposkládám):

x=3, y=4

x=4, y=4

x=3, y=5

x=4, y=5

x=3, y=6

x=4, y=6

Rozptyl u (3, 5) bude již pravděpodobně způsoben chybou v odometrii. Pro hrubé určení, kde se na hřišti nacházíme (s přesností na 1m) by to asi mohlo stačit. Pro přesnou navigaci mezi kostkami ale nikoliv.

3. říjen 2016 — Posedlost absolutní pozicí?

Eduro na mini-hřišti

Dnes jsem něco přes hodinku testoval Eduro a aktuální verzi 1. Když jsem ho tam v té cca 3x4m veliké ohrádce pozoroval, říkal jsem si, jestli to neděláme úplně špatně a jestli to bazírování na absolutní pozici není nějaká posedlost?! Na „hromadě” tam leží laserem nepřehlédnutelných 25 kostek a cílový prostor lze spolehlivě poznat z RFID tagů a je také dost veliký na umístění mnoha kostek s rozumným odstupem …

Místo toho se Eduro zatím spíše leká samo sebe, kostky klidně položí dvě vedle sebe, tj. získá body jen za první kostku, a jezdí-li po „osvědčených koridorech”, tak stačí jedna chyba („nechtěně” položená kostka) a pak už je klíčové křižovatce položí všechny [dnes se mi to stalo snad 2x].

Schema startu a problémové křižovatky

Asi je nejvyšší čas vymyslet kde startovat. Na start pomocí dálkového ovládání se nechystáme, takže by to mělo být někde u mantinelu a zároveň na kraji storage area, aby robot nehrnul kostky a měl šanci se vymotat vedlejším koridorem. Mimochodem do „mantinelu” jsem dnes narazil asi 3x. Je to tím, že ve storage area vypínam detekci překážek, aby mohl v klidu sbírat kostky, ale zdí neprojde … TODO.

5. říjen 2016 — Společné testování

Včerejší společné testování s týmem Alpaca dopadlo trošku jinak, než jsem si původně představoval, ale snad to mělo i pozitivní přínos pro oba týmy. Byl jsem rád, že dorazili. Jejich všesměrový robot se i po oddělání koleček horko-těžko vešel do obřího kufru a cestovat s tím MHD chce už hodně vysokou motivaci! Díky

Do skoro zaplněné haly by se nakonec hřiště 13x7 metrů nevešlo a tak byla klika, že sousední „kruhovka” měla prostor vyklizený (navíc se ukázalo, že jí ten večer hlídá spřízněná robo-duše). Jak už název budovy napovídá výsledné hřiště rozhodně nebylo obdélníkové (i když by se nakonec dalo ze dvaceti stolů „vyrobit”, ale tady motivace byla malá … možná až doplníme korekci na pozici???).

Rozchodili jsme WiFi na Eduru (ještě, že ty Windows ukazují heslo), předefinovali absolutní souřadnice — (0, 0) je od teď na obrázku vlevo dole a odpovídá tagu 0007 0000, resp. 0D00 0000 pro start z opačného rohu, provizorně zase vypnuli detekci nepřítele (především kvůli kostkám, které si Eduro nechtěně vyhrne ze storage area), a vytvořili seznam tras pokrývající 13 míst (zubatá hradba) … viz git.

Návrat přes potemnělou halu ale nebyl úplně šťastný. Ale vlastně to mohlo dopadnout i o řád hůř, např. zničeným laserem. Bilance: ulomený konektor k RFU620 (Tomáš udělal nové kabely, tj. nebylo to ani 2h staré), ohnuté pravé hliníkové Lko (nevěřil bych, že to lze ohnout) a nefunkční motor číslo 2. S tím motorem doufáme, že je to pouze vypadlý CAN modul, jako důsledek tahání za kabely při návratu k původním (jen je třeba rozdělat spodní krabici Edura).

Alpaca

ohnuté pravé rameno

ulomený konektor

Dost lamentování. Zbývá 56h do odjezdu a TODO-list se zatím moc nezkrátil …

6. říjen 2016 — Odometrie

Dofukovat kola den před odjezdem není sice nejrozumnější, ale bude to nutné udělat. Do teď jsme to neřešili (chyba) a teprve při jízdách na větší vzdálenosti je to hodně poznat. Test na 10m jízdy rovně ani neujel, protože po 9m robot „narazil” do překážky 2.5m vlevo. To má teď asi nejvyšší prioritu ať se to stihne ještě párkrát zkusit.

Druhá nepříjemnost je důsledkem úterní destrukce. Vypadá to, že pozice laseru není jako dříve a o pár stupňů je pootočený(?). Dříve nabíral kostky dost „na hraně” a včera to již několikrát selhalo. Vypadá to, že tam necháme hack na 5cm offset, se kterým to víceméně fungovalo.

Z předchozího textu je zřejmé, že už jsme zase jezdili. Ano, byl to vypadlý resp. vytažený konektor na motoru — fixed. Tomáš také udělal nový kabel k RFU620 a zatím bych to zaklepal ťuk, ťuk, ťuk snad vše funguje jako dříve a už to není změť klubek kabelů.

Z věcí, co se nemají dělat na poslední chvíli, jsem instaloval OpenCV na případné zpracování obrazu. Na traktůrku ještě kamera není a tak jsem na to pozapomněl. Přiznám se, že mne trošku znervóznil upgrade samotného Pythonu:

The following packages will be upgraded:
  libpython2.7-minimal libpython2.7-stdlib python2.7 python2.7-minimal

Ale snad také OK (do školního alarmu už jsme udělali jen jednu testovací jízdu s novou instalací).

Ze zajímavostí bych zmínil chybu v driver.py, což je jeden z nejstarších kusů kódu. Konkretně se projevovala tak, že když robot detekoval blížící se kolizi, tak pouze poslal příkaz na odhození kostky a couvnutí si 30cm. V realitě to ale bylo jinak: vůbec si necouvl a kostka mu zůstala v klepetech. Dokonce to sám věděl!

Kód:

print "COUVAM", self.robot.localisation.pose()
self.driver.goStraight(-0.3, timeout=30)
print "COUVAM done", self.robot.localisation.pose()

Výstup:

COUVAM (5.315444919738929, 1.4719470617866883, 0.0005103738339570794)
0x100005050003L (5L, 5L) -75.9 (1/1)
0x100005050003L (5L, 5L) -66.3 (1/1)
0x100005050003L (5L, 5L) -67.0 (1/1)
0x100005050003L (5L, 5L) -69.2 (1/1)
0x100005050003L (5L, 5L) -71.2 (1/1)
0x100005050003L (5L, 5L) -70.7 (1/1)
COUVAM done (5.524286769635407, 1.4720695179939571, 0.06971353374260535)

Tj. z pozice x=5.31m si „couvnul” na x=5.52?! Není to chyba znaménka, je to chyba skrytého předpokladu, že robot je před vykonáním příkazu v klidu. Ten ale jel svých 50cm/s, spočítal si brzdnou dráhu (absolutní hodnotu), ale pak jí přiřadil špatné znaménko pro vyhodnocení „jestli už to couvání ubrzdí”. Fixed přidáním zastavení před couváním (viz git — zase jsem byl líny ten commit rozdělit). Mimochodem asi není překvapení, že do překážky (opakovaně) narazil. V dalších pokusech jsem raději zeď nahradil taškou se spacákem a celkem ji decimoval. Ono detekce na 20cm, nějaká reakční doba a pak 5.31 + 0.2 vs. 5.52 …

Teď už jen pár obrázku z testování v hale, kde asi největší adrenalín bylo přeparkování Spidera. Jednou s tím začít musíš!

David a Goliáš

testování v hale

7. říjen 2016 — Prohozená kola? (7h do odjezdu)

Po včerejším reportu mi bylo trošku smutno. Když si vzpomenu, jak před lety Jirka/Cogito testoval Eduro před Robotour 2010 a následně (zaslouženě) vyhrál, tak to „smíření” s chybou 1.5m na 10m … nezkousnu to. Jirka tehdy kalibroval na cca 100m cestičce, 2m široké, s tím, že došel k závěru, že kola jsou různě veliká. Konkrétně o 0.00015m! Asi čitelnější to je jako 0.15mm … fakt malý rozdíl. Ale opakovatelnost byla neuvěřitelná a tak do kódu zavedl různě velká kola. Teď jsem jeho korekční člen přenesl do sickday2016.py (viz git diff), kdy nejprve jsem rozdíl nastavil na 0.0 a robot po přehrání logu byl necelý metr vlevo. Prohodil jsem znaménko na -0.00015 a až neuvěřitelně se to blíží realitě. Sherlock by asi řekl: někdo nám prohodil kola.

8. říjen 2016 — Show Time

„Hele, mně se to líbilo!” Je pravda, že jsme nevyhráli, ale mise vlastně byla splněna na 66.6% … a co že bylo cílem mise? Obsadit první tři místa českými týmy.

Z pohledu „generálů v kožených křeslech” byl tréning nedostatečný. Zakopaný pes nebyl až tak ve velkém množství kostek jako hrubý povrch koberce, na kterém kostky držely jak přilepené! Resp. kombinace mnoha kostek s kobercem byla smrtící.

Krátce po prvních testech bylo nutné povolat HW sekci kvůli přestavbě robota. Eduro bylo schopné kostky i přejet! Z různých kousků dřeva, zbytků hliníkových profilů a „NASA lepící pásky” vznikla ochrana obou kol a středu robota:

pravý hák

revize středu

ochrana zleva

Eduro - konec prvního kola

1. kolo

V kódu byl nedostatek timeoutů — prostě jestli se snažíte jet 1m rovně a to se vám za 60s nepodaří, tak je něco špatně a „měla by se” zkusit nějaká alternativa. U základních operací, jako je couvání, zatáčení nebo hledání kostky, tato kontrola byla, ale u navigace po lomené čáře už nikoliv. A za to jsme zaplatili už v prvním kole. Eduro pěkně položilo dvě kostky, ale pak v domečku najelo na jednu a to znamenalo konec. Byl to velmi smutný pohled na robota 9 minut v křečích.

2. kolo

Během soutěže bych na kód normálně nesahal, ale ten pohled z první jízdy byl fakt tristní. Přidal jsem timeout na minutu, ale co má dělat robot potom? Dostal za úkol couvnout, 90 stupňů vlevo a 90 stupňů vpravo. A pak? Hmm. Nejprve tam byla chyba a pak pokus o kód: nastav si znova timeout na 60s a zopakuj původní (neúspěšnou) akci dovezení kostky na cílové místo.

V realitě to nefungovalo dobře, ale i tak se robotu podařilo položit asi pět (?) kostek. Pak si najel moc do domečku (storage area) a to už bylo jak v bažinách. No alespoň s sebou jednou za minutu zuřivě cukal a dokonce se mu podařilo se vymotat. … no ale myslím, že si tím vykoledoval jen trestné body (náraz na mantinel). Za tu snahu ten půlbod stál (nevím, jestli jsme tím nepřišli o druhé místo??).

Hra gentlemanů

Cogito MART zápas vyhrává

Eduro - konec druhého kola

3. kolo (Show Time)

Třetí jízda ze dvou?! Za to vděčíme týmu „Smelý Zajko”, který nakonec nedorazil, a iterpelaci „Cogito MART” týmu, že zápas bez soupeře není fér vůči ostatním týmům a že klidně obětují svého robota i bez bodového zisku. Podle neověřených zpráv Smelý Zajko v sobotu ráno havaroval na cestě cca 50km do Waldkirchu :-(. Zranění snad nebyli, ale jak dopadlo jejich auto nevím.

Na poslední zápas tedy místo slovenského týmu nastoupilo Eduro. Nevím, jestli vidím do budoucna, ale stejně jako jsem tušil, že budeme „náhodně” vylosovaní do zápasu s Cogito MART, tak v poslední jízdě Eduro excelovalo, získalo by nejvíce bodů ze všech zápasů za celý den — byla radost na to koukat!

Slovenská vlajka

Eduro - exhibice

Eduro Team SICK 2016

Ostatní zápasy a roboti

Letos dorazilo do Waldkirchu osm týmů. Většinu tvořily německé týmy + tři české týmy … i když je otázka, zda „švýcarské” Cogito, poskytující RaS (robot as a service), vlastně klasifikovat …

Alpaca vs. Cogito MART

CS Freiburg vs. SicKubOS Osnabrück

Kamaro Engineering vs. WINGmen Furtwangen

Většina týmů se snažila posbírat pár bodů a jenom dva týmy měly součástí strategie agresivní výpad a blokaci nepřítele. Nechci být škodolibý, ale potěšilo mne, když nastoupily proti sobě . Podle očekávání to ublížilo spíše jim než soupeři. Kousek tohoto zápasu je i na přehledovém videu.

Kamaro Engineering

Oko za oko, ...

SicKubOS Osnabrück

Alpaca

FREDT

WINGmen Furtwangen

Mise splněna na 66.6%

Hrací plocha

Kvíz - co je to?

... a zase oscilace

Video (Cogito MART - první zápas)

Odkazy

regiotrends.de

9. říjen 2016 — Eduro a Cogito log videa

1. kolo

2. kolo

Exhibice

… a stereo očima Clementine/Cogito

11. říjen 2016 — Oficiální výsledky

Na stránkách SICKu oficiální výsledky vyvěšené zatím stále ještě nejsou, ale Def mi poslal konečné PDFko obsahující toto info:

Team	Lauf 1	Lauf 2	Bestes	Platz
Karlsuni Prag	7.0	6.0	7.0	1
Uni FR	-0.5	5.0	5.0	2
EDURO	2.0	4.5	4.5	3
Kamaro Engineering e.V.	4.0	4.0	4.0	4
Osnabrück	1.0	2.5	2.5	6
FRED	X	1.0	1.0	6
Alpaca	0.0	0.0	0.0	7
WINGmen	X	X	0.0	7
Smelý Zajko	-	-	-	-

Pár zajímavostí:

nepočítal se součet bodů, ale nejlepší kolo (Def mne uklidnil, že i pro součet bychom dopadli stejně, protože na druhé místo by se dostalo Kamaro)
ten náraz v druhé jízdě nás opravdu stál druhé místo
kdyby exhibice byla normální jízda, tak by to …

Cogito MART vítězný zápas byl tedy ten první a zápas s Edurem byl tedy bodově nejlepší pouze pro Eduro. Zde je video od Davida/MART:

případně viz Davidův kompletní SICK Robot Day 2016 video list.

Video od Andrease/CS Freiburg (2. místo) s SicKubOS

Eduro Exhibice

kontaktní formulář

Robotour v praxi?!

2016-09-27T00:00:00Z

Začal bych tím, že se mi to nezdálo a opravdu na Staroměstském náměstí proběhlo demo robotů (+ video). Je zřejmé, že to byla spíše mediální kampaň, ale … roboti jsou od firmy Starship Technologies, která má sídlo v Británii a Estonsku. Podle jejich webových stránek: Starship Technologies was launched in 2014 by Ahti Heinla and Janus Friis. Our business headquarter is in London and our engineering in Estonia. A na rovinu to nejsou žádní začátečníci a podíleli se např. na vývoji Skype … hmmm.

Z toho mála, co jsem zatím zjistil na českých webových stránkách, asi nejvíce info bylo na connect.cz. Konkrétně

Starship Technologies poskytují roboty jako službu, tj. starají se o jejich provoz a umožňuje jim to další vývoj a průběžný upgrade
roboti mají dojezd 3 až 5 kilometrů, max rychlost 6km/h
primárním senzorem jsou kamery
na Staroměstském náměstí firma ukazovala dva modely (starší a novější)
hmotnost robota je 15 kg a nosnost pak 10 kg (na videu říká 18kg … prostě zhruba)
roboti jsou neustále připojení do internetu pomocí mobilní sítě
první cesta k zákazníkovi vyžaduje výrazný manuální zásah a ovládání operátorem, další už je ale plně automatická

Přímo od zdroje se mi moc informací získat nepodařilo. Jediné, co je zřejmé je, že to myslí naprosto vážně. Jejich roboti už navštívili několik evropských a amerických (Washington, San Francisco) měst. Procházel jsem výsledky na Google (starship technologies robot) a trošku mi to přišlo jak z filmu Amélie, kdy její otec dostává fotky s trpaslíkem z celého světa.

Pár detailnějších záběrů naleznete zde (původ snímků je na 95% přímo od Starship technologies):

pohyblivá zadní osa

senzory vpředu

detail kola a boční kamera

Tak alespoň rozměry kol jsou vidět — 8 x 1 1/4, což je velikost, která používá pro invalidní vozíky.

Tento obrázek pochází z Robotics Bussiness Review, ale článek je zamčený a registrovat se mi nechce (navíc je z loňského prosince = starý).

pokrytí senzory

Za zmínku stojí i scénář vyvíjený ve spolupráci s Mercedes-Benz. Ve spodním patře je 8 robotů a v dalších je pak zboží pro zákazníky:

Z pravidelných reportů je i vidět, jak firma roste:

London, United Kingdom, 2 November 2015(?)

The company employs 30 people and has offices in London, United Kingdom, and Tallinn, Estonia. Former Skype co-founder Ahti Heinla serves as the company’s CEO and CTO, serial tech entrepreneur Allan Martinson is Chief Operating Officer and tech and mobile industry veteran Keith Cornell is Chief Commercial Officer.

První předváděčka v Londýně

First launched in November 2015, the robot is designed for local delivery of goods and groceries for consumers for under £1 per shipment.

London, United Kingdom, 6 July

The company employs 55 people.

Automatická donáška zboží v USA

Starship said in July that its robots had traveled close to 5,000 miles and encountered over 400,000 people without a single accident. It claimed that during testing, about two-thirds of people ignored the bots entirely, while the rest reacted to them mostly favorably, often by snapping photos. The robots are programmed to avoid collisions with inanimate objects as well as people and pets. Of course, people and pets aren't programmed to avoid collisions with the bots.

,,tucet špinavců''

Další odkazy

The Verge - foto a video

Máte-li jakékoli dotazy, připomínky, či postřehy – kontaktujte nás.

Výsledky

2016-09-22T00:00:00Z

Soutěž

Účast

Letos se přihlásilo 14 týmů a z toho jich 12 aktivně soutěžilo. Český MART to vzdal v pátek a německý WallE také z důvodu neopravitelné závady (robot byl obratem rozebrán a jeho součástky použity pro tým „No! This is Patrick”).

Lokace

Technische Hochschule Deggendorf má moc pěkný areál university. Je na břehu řeky Dunaj a obklopuje ho hned několik parků. Stadthallenpark je klasický parčík s fontánou, růžemi a pískovými cestičkami. V okolí ale najdete i několik dlouhých rovných cest podél potoku Bogenbach a řeky Dunaj. Konečně jsou zde i anomálie jako kovový koridor na střeše parkoviště Parkdeck Deichgarten nebo pro ztížení soutěže lze použít mosty, podjezdy, rampy, železnici, schody atd.

Přehledová mapa

Počasí

… bylo prostě příšerné. Další úroveň obtížnosti by byl asi už jen sníh a kroupy! Pršelo celý den a soutěžní prostor byl pokryt mnoha loužemi (i několik centimetrů hlubokými), plus studený vichr … ale co tě nezabije, to tě posílí, takže možná letošní zkušenost bude hnací silou k vylepšení robotů i soutěže samotné.

Homologace

Páteční homologace byla jak procházka rájem, ve srovnání s počasím, co nás čekalo v sobotu. Ukázalo se, že automatickou nakládku piva řešily pouze dva týmy: Cogito využilo možnosti s 500ml plechovkou a Radioklub Písek vytvořil pneumatický jeřáb schopný nakládat plný pětilitrový soudek. Ostatní týmy byly rozumnější a tento extra bonus ignorovaly (do dalších let se je budeme snažit od toho odradit, dokud nebudou mít plně funkční realizaci základní úlohy).

Istrobotics

JECC - Fesl

Raptors

Zažili jsme i vzrušující moment hodný bulvární novinařiny: Quadrons tým nechal po úspěšné homologaci zaparkovaného robota vedle cesty (snad se stisknutým STOP tlačítkem?), když tu z ničehož nic se sám robot rozjel naplno ostře vlevo a z kopce do potoka. Nebýt stromků a keřů v těsné blízkosti vody, tak je tam. Náraz vytrhal olověné baterky, ale jinak se prý nic snad nestalo.

Robot na útěku

Quadrons

Lois

Kupodivu něco podobného se stalo i Raptorům cca o hodinu později (ale nebylo to tak dramatické).

Soutěžní kola

Na nulté trénovací kolo v 9 hodin skoro nikdo nepřišel. Jenom Aleš z týmu AmBot odstartoval a udělal si testovací jízdu. Všichni ostatní doufali v pozdější lepší počasí a asi je do deště nic nemotivovalo (nulté kolo není bodované).

Soutěž oficiálně začala v 10h u hlavního stanu a tak se první kolo posunulo na 10:30. Start byl v Stadthallenpark poblíž mostu a cíl na druhé straně parku (křižovatka na náspu). Istrobotics byli schopní získat několik set bodů a také AmBot, Smelý Zajko, JECC, Raptors a Quadrons trošku bodovali.

Druhé kolo bylo v 11:30, takže se jelo skoro bez přestávky. Tentokrát se vše odehrávalo na střeše krytého parkoviště. Hodně tam foukalo a všude spousty vody. Zde se již použilo pravidlo, že nejlepší týmy startují na konci řady a tak AmBot (předposlední) zkusil úhybný manévr do sousedního koridoru, aby se vyhnul dopravní zácpě, ale neúspěšně. Jeho robot osciloval, jestli ta orezlá stěna je nebo není sjízdná a v tomto kole nezabodoval. Vlastně bodoval jediný Istrobotics, který se prokličkoval mezi ostatními roboty a dostal se až na vzdálený konec parku. Kousek od cíle se ale rozhodl pro odbočku vlevo, kde ho čekaly tři podlouhlé schody. K mému překvapení ho Pavol nechal jet dál a pád z prvního schodu autíčko s barelem na zádech rozdejchalo, ale pak jsme Pavla přesvědčili, že to není dobrý nápad, a na dalším schodu robota zastavil.

2. kolo u řeky

Cogito

Třetí kolo bylo pro mne rozhodně nejemotivnější. Všech 12 robotů stálo v řadě na cestě rovnoběžné se železniční tratí. Tým Kamaro Beteigeuze, loňský vítěz, získal své první body. V plánu měli přejet most a pak vpravo do podjezdu, ale jejich robot si to rozmyslel, odbočil ještě před mostem a druhé vynucené odbočení vpravo ho „svedlo z cesty”.

3. kolo

3. kolo pokračování řady

Kamaro Beteigeuze

Také Istrobotics měli problém s mostem a robot odmítal na něj vstoupit. V tomto kole bylo hned několik kolizí na startu (Radioklub Písek to např. nacouval do soupeře vzadu). Několik týmů potvrdilo problémy s kompasem, takže buď to byl vliv kolejí nebo skrytého kabelu vysokého napětí podobně jako v Písku na Robotem rovně.

4. kolo

Čtvrté (poslední) kolo začínalo na druhé straně problematického mostu a roboti se měli vrátit zpět do školy. Bylo zde zase všech 12 robotů. Tým Cogito změnil strategii na jízdu 25 metrů po cestě, vyložení piva a návrat na start. Tímto by získal extra body za automatickou nakládku a vykládku. Ale úplně se to nepovedlo: ARBot vystartoval ve stejnou dobu a nacházel se ve slepé zóně senzorů. Vypadalo to jak opravdový závod, kdy se ale v jeden okamžik oba roboti rozhodli zahnout směrem k druhému a „vytlačit ho z cesty”. ARBot natáčel video, tak se na to můžete podívat i vy:

Bylo zajímavé, že Smelý Zajko a JECC skončili na identickém místě (toto se stalo již v prvním kole). Oba roboti narazili na betonový kvádr u nájezdu na most. Byla to náhoda, nebo neuronové sítě obou robotů vyhodnotily situaci stejně špatně?

Celkové bodování

Místo	Tým	1. kolo	2. kolo	3. kolo	4. kolo	celkem
1.	Istrobotics	156	272	90	94	612
2.	Kamaro Beteigeuze	0	0	76	94	170
3.-5.	Smelý Zajko	28	0	0	40	68
3.-5.	JECC - Fesl	28	0	0	40	68
3.-5.	AmBot	66	0	0	0	66
6.	Raptors	20	0	3	0	23
7.	Cogito	0	0	0	1+5	6
8.-9.	Quadrons	1	0	0	0	1
8.-9.	ARBot	1	0	0	0	1
10.-12.	Lois	0	0	0	0	0
10.-12.	No! This is Patrick!	0	0	0	0	0
10.-12.	Radioklub Písek TCVVI	0	0	0	0	0

Závěr

Soutěž byla letos dost vyčerpávající, ale bylo vidět neuvěřitelné odhodlání týmů posunout se dál. Tisíceré díky profesoru Kurprisovi a jeho kolegům za organizaci — byla dokonalá! Také díky sponzorům a městu Deggendorf za pokrytí nákladů na ubytování a společnou večeři.

A co dál? Diskutovali jsme to na nedělním workshopu (jako součást PAIR'16 konference) a nechal bych to teď do samostatného článku. Naše další plány se shodovaly i s týmy, které už nikdy nechtějí zadávat souřadnice přes mokré nefunkční klávesnice z promočených papírků. Je čas posunout se k větší autonomii

Polské týmy Quadrons a Raptors

Radioklub Písek - jeřáb

Cogito

ARBot foto (2. kolo)

ARBot

2. kolo - střecha parkoviště

AmBot a Istrobotics

Kamaro Beteigeuze

Smelý Zajko

Kamaro Betelgeuse Video

Pokud chcete nějak podpořit tuto soutěž nebo máte nějaký komentář/dotaz, tak prosím použijte kontaktní formulář.

Den chytrých aut

2016-09-14T00:00:00Z

Že firma Valeo pořádá dny otevřených dveří v Milovicích jsem se dozvěděl krátce po zveřejnění skoro bulvárního článku na iDnes (Záhadný prototyp: v Česku se testuje auto, které nepotřebuje řidiče). Ve skutečnosti to bylo právě Valeo, které na dálnici testovalo nikoli autonomní jízdu, ale kalibrovalo senzory pomocí referenčního Velodyne LIDARu.

Letiště Milovice

Letos akci byla věnována už dedikovaná webová stránka denchytrychaut.cz a viděl jsem i nejednu reklamu po Praze či v Google Ads. Do Milovic bylo možné dokonce jet „Valeo busem” a tak mne zaskočilo, ze byl skoro prázdný (čtvrtek holt není úplně ideální pro běžné pracující).

Na akci jsem se těšil jak malej kluk a tak první překvapení bylo, že se na ní nesmí fotografovat :-(. Navíc bylo třeba podepsat cosi na způsob NDA … tak jsem zvědav, jestli to nebude v rozporu s tímto článkem a nebude nutné ho odstranit.

Akce byla koncipována jako půldenní s tím, že návštěvníci se rozdělili do sedmi barevných skupinek a měli vždy 20 minut pro danou „atrakci”. Z tohoto pohledu jsem vlastně rád, že lidí bylo málo — odhad 42, což je ale pěkné číslo a šest lidí ve skupince lze dělit na dvojice a trojice (a více se do aut s řidičem případně ještě nahrávacím rackem počítačů stejně nevejde).

Jako „zelenáči” (zelené vesty) jsme začali u kamer. Valeo integruje čipy od Mobileye a po CAN sběrnici posílá buď info nebo přímo příkazy na brzdění/zatáčení. Neuronové sítě prý zatím Valeo neučí, ale s izraelskou firmou jsou v oboustranně výhodné kooperaci. Modul s kamerou dodávají hned několika automobilkám. Na autě ho najdete typicky za předním sklem v místě středového zpětného zrcátka. Pokud by někoho zajímalo, co přesně Mobileye vyvíjí, tak vřele doporučuji cca hodinové video Amnon Shashua CVPR 2016 keynote: Autonomous Driving, Computer Vision and Machine Learning.

Demo detekce v mrtvém bodě

Druhá zastávka byla o SSL, zde ve významu Solid State LIDAR (16 paprsků pokrývajících 60 stupňů), a senzoru ScaLa (laser skener s rotačním mechanismem, 4 roviny, 0.25 stupňů rozlišení). Senzor SSL je typicky umístěn v bočních zrcátkách pro detekci aut v mrtvém bodě. Toto demo již bylo spojeno s jízdou, kdy do nás druhé auto lehce najíždělo. Součástí prezentace byla i navigace v úzkém koridoru (zde je potřeba ScaLa senzor), např. při opravách dálnice, kdy je dočasný pruh určen betonovými bloky (tady pouze kužely). Nebyl čas, tak na to řidič šlápnul a toto už byla čistá autonomie … skoro jak na horské dráze to samo prokličkovalo připravené esíčko (v rychlosti okolo 80km/h). Do třetice jsme na této zastávce ještě viděli automatickou navigaci za předjezdcem — auto sledovalo kudy přesně jel a v daném odstupu trajektorii opakovalo.

Navigace pomocí ScaLa

Třetí zastávka byla ukázka radarů. Dnes pracují na 24GHz, ale už při 10% nasazení začnou vznikat problémy se vzájemným rušením. Z tohoto důvodu se přechází na vyšší frekvence (79GHz), kde jednak kratší vlnová délka umožňuje vyšší přesnost a dále se využívá širšího povoleného pásma. Od radaru se očekává jak odhad vzdálenosti, tak směr a z Dopplerovského efektu i rozdíl rychlostí obou vozidel.

Z různých zajímavostí mne zaujal scénář, kdy stojící auto zjistí, že do něj někdo zezadu za chvíli nabourá. Jako reakci na tuto situaci sešlápne brzdu, aby došlo k deformaci karoserie a energie se nepředala jako u kulečníkových koulí — prý tento ráz je jednou z nejčastějších nehod s poraněním krční páteře.

Čtvrtá zastávka „Safety Braking” byla asi největší adrenalin. Pro testování se používají nafukovací auta, do kterého to „napálíte” rychlostí 50km/h. A ke kolizi by nemělo dojít, protože automat to ve stavu nejvyšší nouze „zadupne”. Seděl jsem vepředu na místě spolujezdce a celkem křečovitě jsem držel madlo dveří. I bezpečnostní pás jsem si připnul bez komentáře . Druhá jízda byla za pomalu jedoucím autem, kdy ale řidič (člověk) na poslední chvíli strhne volant mimo kolizi. V tom případě automat musí brzdy okamžitě odblokovat.

Safety Braking

Pátá a šestá zastávka byla pak už jen na zklidnění. Sonary a parkovací automaty, jak pro paralelní tak pro podélné parkování. Pokud vás nebaví sedět v autě, tak se připojíte telefonem přes Bluetooth (nejnespolehlivější část celého systému) a kroucením palcem, jako důkaz, ze manévr kontrolujete, potvrdíte automatické parkování. Demo bylo na nejnovějším Mercedesu, který už je „běžně” na trhu.

Automatické parkování

Parkování z mobilu

Sedmá zastávka byla o kamerách a zpětných zrcátkách. Byl tam překryv s parkovacími automaty, kdy pomocí 4 kamer (vpředu, vzadu a pod bočními zrcátky) poskládáte 360 stupňový pohled. Pěkné. Kamerky jsou s rybím okem, FOV prý 190 stupňů … a na autě skoro nejsou vidět — takové špendlíky z Návštěvníků .

A pak už konec a autobusem do Prahy.

Vynechal jsem detaily, jako úvodní přednášku, kde mimo jiné bylo zmíněno, že se v Čechách opravdu realizují autonomní testovací jízdy (první proběhla 25. září 2015 na dálnici Praha-Liberec), „svačinku” (možná spíše oběd) v podobě švédských stolů, a celkově lákadlo pro potenciální nové zaměstnance do nově budovaného vývojového centra v Hostivaři …

Autonomní jízda

Bude-li se akce příští rok opakovat, tak vřele doporučuji.

p.s. některá dema je lépe vidět v pohybu — viz video z květnové akce

kontaktní formulář

RoboOrienteering 2016

2016-06-07T00:00:00Z

Po soutěži Robotem rovně 2016, kde se upravený zahradní traktůrek John Deere X300R poprvé automaticky rozjel, jsem přemýšlel, jak projekt posunout dál. Soutěž RORO16 nás nastartovala, ale robot dosud neuměl zatáčet, což v Písku nevadilo. Jako jediná cesta se jevila další soutěž a ve výhledu (nezdravě blízko) byl právě RoboOrienteering. Tomáš Roubíček, který na robotu dělá veškerou elektroniku, to komentoval se slovy: Martine, tobě jedna "Mission impossible" nestačila? RR byla šílenost, ale RO je mega šílenost, ne-li utopie. Pokud ale myslíš, že ten SW za 2 týdny dáš, tak ten HW nějak dohromady taky dáme. … a klobouk dolu, opravdu dali . Tak postupně.

[Mezi RR a RO byly sice 3 týdny, ale to víceméně znamenalo 2-(3) večery. S RO se nepočítalo, takže se to začalo řešit až 14 dní do soutěže.]

JD nikdy automaticky nezatáčel. Navíc se ukázalo, že to ani nejde — byla potřeba jedna z dalších netriviálních revizí, kdy Standa opravil směr otáčení (pro jednou prohození otáčení byla sranda, ale stačilo to). První měření naznačovala, že ventily jsou sice 12V, ale vyžadují 5A elektroniku. Nic podobného neměl Tomáš „po kapsách” a objednávky přece jenom nějaký den trvají. Rychlé řešení Tomáš nakonec vymyslel, ale v úterý, 3 dny do soutěže, součástky pro toto řešení ještě nedorazily.

Kdy John poprvé „zahnul”? V pátek večer, cca v době, kdy jsem slíbil Martinovi Lockerovi, že už budeme v Rychnově (a ano, byli jsme ještě tou dobou v hale na ČZU).

Ono se to vlastně všechno dalo do pohybu teprve týden před soutěže. První cíl bylo rozchození verze s Velodyne VLP-16 senzorem, aby, když traktor vidí překážku, zastavil. Toto mělo být připravené už v Písku, ale úplně se to nestihlo. První ostrý test proběhl v úterý (viz video), kdy jsme traktoru dali do cesty sloup z AirRace a zastavil cca 10cm do nárazu. Při druhém pokusu natvrdo narazil a situaci řešila STOP tlačítka.

Další test jsme chtěli udělat venku s dobrým GPS příjmem — přece jenom RoboOrienteering je outdoor soutěž. To přece vyjedeme automaticky ne? Robot lehce poskočil a jen tak tak líznul vstupní bránu! :-(

Velodyne Puck

Pořádná komedie nastala teprve venku. Před halou technické fakulty měl Standa zaparkované auto, ale tomu se kupodivu nic nestalo. „Zkusíme překážku?”, ptá se Standa. Souhlas a poměrně nečekaná reakce traktůrku — nejen, že zastavil, ale doslova skočil zpět a začal rychle couvat. STOP tlačítko.

To nám pro poprvé jako zdroj adrenalinu stačilo, ale dat jsme zatím moc nenasbírali. Standa přepnul na manuální řízeni, sedl na traktor a že ho odveze zpět. Já pustil prográmek, který dál hýbal s pedálem, jenom teď byl spojovací čep vytažený. Vše v pohodě, jen na cestě zpět se na mne Standa divně podíval a traktor vyrazil rychle vpřed. Říkal jsem si, že chtěl asi zkusit rychlejší jízdu, ale ten pohled byl co to tam děláš?! Jede to samo a pedál je u podlahy! Posun pro automatické řízení totiž vypadl a zasekl se mimo a navíc se snažil přidat kvůli dostatku volného místa před traktorem. To byla opravdu poslední kapka/třešnička na dortu a stačilo. Nehledě na to, že bylo skoro 22h a každou chvíli se měl zapnout školní alarm.

Na středu jsme si dali volno, resp. pokračovali každý sám. Když se podíváte na video znovu, tak si všimnete, že tam problikávají takové zuby/výřezy. Procházel jsem logy z Velodyne a opravdu tam chyběly některé pakety (mají 1206 bajtů a odpovídá to cca pěti stupňům dat). Systém je tedy nestíhal dostatečně rychle odbavovat a byla to i indikace zběsilého chování, kdy robot vnímal realitu ze starých dat.

Důvod byl nakonec celkem prostý (vyřešeno v pátek ráno): po nastartování programu se vytvoří Velodyne objekt, ale tím už začne dostávat data. Vlákno na zpracování jsem ale zapínal až po stisknutí startovacího tlačítka a tak nejprve musel vyčíst vše co tam za to mezidobí zůstalo. Fixed.

Páteční plán byl vyrazit cca v 17h z Prahy, v Rychnově povečeřet a případně udělat ještě nějaké testy v parku. Ono ale na JD bylo ještě hodně práce (Tomáš si na to vzal celý den dovolenou) a v kombinaci s opožděnou dodávkou součástek to bylo fakt kruté. Nicméně v 20:18 proběhl první test s otáčením bez motoru (tj. že správně cvakají ventily) a 20:39 traktor poprvé elektronicky zatočil, řízen z APU2 počítače.

Řízení v té době bylo zcela bez zpětné vazby, tj. pouze délkou pulzu se určovala doba otevřeného ventilu, nesymetricky. Hodnoty 0.8s a 1.2s pro zatáčení vlevo a vpravo vypadaly rozumně. Robot by se poprvé homologoval ve 21:13 (v pravidlech je, že se musí vyhnout překážce, ale pak jsme se dozvěděli, že by stačilo zastavit).

Příjezd

Do Rychnova jsme, k nemalé radosti Martina Lockera (ironie), dorazili až po půlnoci, vlastně skoro v jednu hodinu. Chvíle spánku a od 5:00 pokračování. Tomáš se mne ptal, jestli chci raději funkční enkodéry umožnující zpětnou vazbu alespoň při jízdě nebo zařízení na vyhazování míčku. Volil jsem vyhazovač — náš cíl je dát alespoň jeden bod a bez vyhazovače to fakt nedáme . Racionálně bychom měli spíše řešit ty enkodéry, které se budou hodit i později, ale jsme na soutěži a chceme bodovat!

Outdoor testy na parkovišti proběhly celkem fajn. Na Jakubovo doporučení jsme pravo-levé zóny z Velodyne zjemnili po pěti stupních, aby při zatáčení vpravo robot ignoroval překážky vlevo, ale ve finále jsme tento kus kódu nevyužili. Někomu by mohlo přijít smutné, že z 8Mbit/s prostorových dat ze šestnácti laserů vezmeme jen minimum v dané sekci a to je vše, ale nějak se začít musí . Po revizi tedy 6 čísel odpovídajících limitům -25, -20, -15, 0, 15, 20 a 25 na 10Hz.

Řídicí logika byla jednoduchá: když je překážka na 4m zatoč vpravo, když je moc blízko (2.5m) zastav, a když široko daleko nic není (více jak 4.5m) a zatáčíš, tak srovnej kola. Tímto způsobem jsme alespoň tušili, kterým směrem traktor vyrazí a ano, nebylo to dvakrát inteligentní chování. Pokud byla překážka vpravo, tak do ní ještě více zatočil.

Pro homologaci už volil lepší směr, ale chyba lávky. Startovalo se uprostřed parku, mírně do kopečka a tak se traktor s malým plynem nerozjel. Změnil jsem požadovanou polohu pedálu z 18000 na 20000, vystartoval, u překážky zatočil vpravo a následně se snažil srovnat a prásk! Rána a evidentně se uvnitř něco pokazilo. Po odstranění krytu se ukázalo, že vylítlo těsnění z desky rozvaděče (hned vedle orbitrolu). Hydraulika není sranda a toto de-facto byla konečná. Neměli jsme ani nástroje ani náhradní součástky. Problém byl na 90% špatně nastavený tlakový ventil.

První pokus o opravu naslepo nevyšel a Milan zodpovědně kapituloval. Standa odmítal (přece jenom s tímto strojem zápasí už nějaký čas) a vyrazil s Jakubem na procházku po místních obchodech s autodíly. Já jsem šel psát kód na vyhazování míčku na GPS souřadnicích (částečně Copy & Paste z roku 2012?) a Tomáš vymýšlel mechaniku na vyhození míčku.

Vyhazovač míčků

Jak to dopadlo? Provizorní těsnění částečně fungovalo, ale zatáčení jsme se rozhodli omezit na minimum. A software status? Výsledný algoritmus byl postaven čistě na GPS souřadnicích a míček se odhazoval, pokud se vzdálenost od cíle zvětšila. Toto vše o okruhu 10m od kuželu. Otázka byla jak volit cíl? Stačilo by nám vybrat jeden, ale na startu je trošku stres, soutěžící dostane pouze USB disk se zadáním a není rozumné cokoliv editovat. Řešení bylo nakonec triviální — naviguj na všechny cíle najednou, tj. použij minimum ze všech vzdáleností.

V mezičase Tomáš připravil servo s CAN modulem na vyhazování míčků. Alternativní plán byl jet rovně (pokud z důvodů problémů s hydraulikou nelze zatáčet) a u prvního cíle odhodit míček. První vyhazovací test proběhl v 11:33. Nefungoval, protože modul nedostal domluvené ID=5, změna na ID=0x7F. Další pokus v 11:35 s novým ID. Stále nefunguje. Tomáš zkouší znovu ze svého notebooku a nachází špatný kontakt u prastarého CAN modulu. Fixed. 11:46 první úspěšné vyhození.

Kolo 2

John Deere 2.kolo

Soutěžíme! Start je na cestě u dětského hřiště, podezřele blízko cíle (GPS hlásí 14m) — úplně to vidím, že se chytne cíle místo prvního kuželu a krátce před startem edituji kód. Ono v tom Pythonu je to jen změna na waypoints[1:-1], ale znáte to . Přehrání logu funguje, tak snad odstartujeme. Traktor jede mírně vpravo a tak kužel míjíme sice do vzdálenosti 10m, ale mimo bodovaný kruh (5m). Vyhazuje nebodovaný míček, ale necháváme ho jet dál. Zastaví se pod nižší větví, nadzvedáme větev a traktor pokračuje na další kužel. Druhý výhoz není implementovaný a přestože Tomáš nabízel ještě druhý podavač, tak jsem odmítl. Nicméně traktor u kužele pozastavil, což rozhodčí klasifikoval jako motivační výhoz … ale tyto body nejsou „košér” a nezasloužíme si je.

Kolo 3

Do posledního kola reviduji waypointy (po dosažení odmaž ze seznamu), a před vyhozením se zastavuje a podavač vrací do nulové polohy. Hydraulika prý jeden pokus vydrží, tak odkomentovávám posílání pulzů na ventily. Máme jen jednu šanci, tak si jí užijeme. Kužel, který jsme si vybrali, se ukázalo, že je cíl a za něj žádné body nedostaneme. Traktor pouštíme na „náhodnou procházku” s vyhazováním, kdyby jel okolo nějakého kužele. Věřte nevěřte vyhnul se pár stromům a bodoval u

K4: 50.166352 16.278328 55

Dostáváme zasloužené body a dokonce porážíme TeaPack Systems, viz výsledky. Jsem rád, že by tomu tak bylo i v případě nepočítání druhého kola. Prima.

VeloView z Rychnova

Závěr

Pokud se chcete podívat na soutěžní kód, viz

https://github.com/robotika/osgar/releases/tag/ROBOORIENTEERING2016

(očekávám masivní revizi, tak jsem to raději otagoval).

CZU/TF + robotika.cz

Za sebe jsem spokojen, vlastně velmi spokojen! Mise splněna (bodovali jsme), tým fungoval skvěle, jen jsem ještě teď po třech dnech stále unavený . Pomalu přemýšlím o třetím kvantovém skoku, ale show pro ministra to pozítří v Nabočanech asi nebude. Potřebujeme „dobít baterky” (lidské).

Čtenářům se omlouvám, že tento report je čistě egoisticky o našem týmu. Mariánky byly jednoznačný vítěz, Aleš s autíčkem se jim snažil dělat soupeře, ale přesto dostatečně nebodoval. TeaPack bych pochválil za snahu (celý den tam Honza něco kutil a nakonec robot alespoň jednou skóroval). Co měli za problém matfyzáci netuším a Pavla (ND Team) bych pokáral, že nefunkční robot ve dvě hodiny ráno není omluva . Ale Pavel je sám a ono je to hodně o týmu. Což mi připomíná návrh na změnu pravidel, kterou Martin Locker komentoval, že to bude těžké, když jenom dva týmy jezdí, ale … stejně ji ventiluji. Třeba se někdo chytne .

Foto

Aleš s autíčkem

Android navigace

Organizátoři

Ambot

Kolizní kurs

TeaPack

David

Explorer

JD v akci

Rychlá chůze

John Deere tým

John Deere

Mariánské Lázně

MART Team

MART

MART u překážky

Bitevní pole

Překážky

Bodování

TeaPack Robot

3. místo

Video (autor David Obdržálek)

foto od Davida:

MART

děti

John Deere team

Odkazy

Návrh na rozšíření pravidel

Motivace

Robotické soutěže jsou primárně o soupeření a spolupráce týmu je spíše vedlejší efekt (něco jako nemá někdo měřák, náhradní sonar, klíč 22 a pod). Z toho to pohledu se mi líbil Field Robot Event 2012, kde byl i Cooperation Task. Dva náhodně spárované týmy měli během dopoledne připravit demo nějaké spolupráce robotů. Byla to sranda, pořádný „brain storming” a oba týmy se lépe poznaly, včetně detailů obou robotů.

Druhou inspirací je Eurobot, který měl vždy pravidla stavěná tak, aby jedna úloha byla triviální a její rozšíření těžké. Každý tým si tedy našel to své a, pokud byl rozumný, tak začal nejprve s jednoduchou úlohou, aby zjistil, že až tak jednoduchá není.

Kvalifikace

Dopolední kola by byla úplně stejná jako letos, tj. start/waypointy/cíl, vyhazování míčků pro poloměry 2.5m a 5m. Obě kola by se ale počítala, aby součet bodů lépe definoval výsledné pořadí.

Capture the Kužel

v odpoledním programu by se týmy rozdělily na dvě skupiny. První a druhý tým podle kvalifikačního pořadí by byly vedoucí a buď by si vybíraly nebo losovaly nebo nějak systematicky přibíraly další týmy. Každý tým by měl svoji barvu golfových míčků (jsou bílé a zlaté např.), která by se losovala a ve druhém kole prohodila. Obě skupiny by se společně snažily obsadit co nejvíce kuželů. Obsazení znamená položit více bodovaných míčků než soupeř (na začátku by každý dostal zase 5 míčků). Startovali by všichni současně od různých kuželů (asi by se tím rušil start a cíl?) a na „souboj” by bylo zase 30 minut (nebo možná hodina?).

A teď ta těžká úloha — míčky by bylo možné během soutěžního času i automaticky sbírat a ubírat tak nepříteli body. Asi má Martin pravdu, toto je asi v našich současných podmínkách zatím nepředstavitelné …

kontaktní formulář

Robotem rovně 2016

2016-05-18T00:00:00Z

Pokud chcete prezentovat své zážitky (úspěchy i nepřekonatelné probémy) z letošního RORO2016, tak ať se mi prosím ozvěte a pomozte tak rozšířit tento článek …

John Deere X300R (CZU/TF + robotika.cz)

John Deere X300R je malý zahradní traktor (viz specifikace výrobce), který patří Technické fakultě České zemědělské univerzity v Praze. Co ale není na první pohled zřejmé, je že pod kapotou se skrývá zásadní přestavba (na hydraulicko-elektronické řízení), která otevírá cestu k realizaci autonomního mobilního robota.

pod kapotou

Po pravdě projekt trošku stagnoval ačkoliv výjimku pro účast na soutěži jsme si vyprosili už loni (spalovací motory nejsou povoleny). Letos to bylo nadějnější, protože John Deere X300R měl být začátkem dubna prezentován na stánku výstavy Techagro 2016 v Brně. Ale ani to nevyšlo a vypadalo to na rezignaci. Zásluha patří Standovi Petráskovi, který dělal hlavní přestavbu traktůrku, že nás ještě s Tomášem Roubíčkem (kompletní řídicí elektronika) vyhecoval, že když ne teď, tak už asi nikdy. Verze 0 vypadala realizovatelně: cihla na pedál a propojení sedačky jako STOP tlačítko. Standa přislíbil zapůjčení přívěsu a tak se i mně otevřela cesta, jak tuto šílenost realizovat .

Spíše pro pobavení bych sem dal kopii mailu kolegům ze školy z 12/4/2016, tj. cca jeden měsíc do soutěže:

Zdravim,
registroval jsem X300R na Robotem Rovne 2016. 
Standa mne presvedcil, ze to vlastne muzu dat vlastnima silama i se svoji Fabii
- prives mi pujci, pokud by skolni byl potreba a verze 0 muze vypadat takto:
1) emergency tlacitka propojena na kontakt na sedacce
2) volant chyceny gumicukem
3) cihla na plynu
a jedem . Namitky?

Mesic je takovy idealni cas na "robo-maraton" (viz FRE2012), takze - pokud se
vam ver0 nelibi, tak muze byt i lepsi.  

ver 0.1:
- elektronicke rizeni plynu
- maly sick na overovani volneho mista
- maly ridici pocitac ~ Alix2016

ver 0.2:
- zapojeni Velodyne 16, pokud by do konce dubna bylo
- elektronicke zataceni

Robotum zdar
  m.

To s tou cihlou to byl spíše vtip, ale jak diváci homologace a prvního kola mohli vidět, tak jen částečně.

Do soutěže nám tedy zbývaly čtyři robotické úterky. Že jsem byl hodně naivní jsem pochopil už první úterek, kdy ani zmiňovaná verze 0 nešla otestovat/realizovat. Znamenalo by to poskládání traktoru, zapojení hadic, napuštění hydrauliky olejem, udělat pokus s cihlou a pak zase vše rozdělat, aby se dalo dál pracovat kabeláži. Teď zpětně, ostatně jako většina generálů, to vidím tak, že jsme to stejně měli udělat, viz odjezd.

Na konci dubna posílá Milan Kroulík mail A nyní hlavní zpráva, Velodyne je tu! V té době je již k dispozici i řídící počítač pro nízko-úrovňové řízení APU2, který našel a doporučil Tomáš — je to další generace počítače použitého třeba na Eduru. Tj. začátkem května si mám i já s čím hrát. Ostatně chcete-li sledovat průběh projektu, tak viz graf na gitu.

Odjezd

Původní plán byl s traktůrkem v pátek odjet na chatu, udělat ještě pár testů na louce a pak v sobotu brzy ráno vyrazit do Písku. Během dne volá Standa, ať do školy raději moc brzy se ženou nejezdím, ať se tam nenudí. Nakonec tam vyrážím sám (naštěstí) a traktůrek nacházím ještě rozdělaný, Tomáš tahá kabeláž a nevypadá to na závěrečné dokončování. Je 20:00, tj. 12h do soutěže a v rozvodech ještě není olej a celý systém se ještě nikdy nepohnul. Žádná verze nula.

Standa

Tomáš

Rozvodová deska a APU2

Podle očekávání ani po doplnění oleje (bez něj by se po nastartování zadřelo čerpadlo a bylo by po srandě) stroj nerozjede. Trvalo asi hodinu (?) než se našly příčiny — jednak někdo prozkratoval nikoliv kabel na sedačku, ale kabel na koš, tj. STOP tlačítka jsou propojena špatně a motor okamžitě chcípá. Když bylo toto vyřešeno, tak se traktůrek stále nehýbal. Chyběl drátek na přepnutí mezi volnoběhem a normální jízdou. V mezičase Tomáš zapojuje lineární motor pro řízení plynu (všechny kabely je nutné nastavit) a já spíše dělám pomocníka Standovi … přece jenom mi přijde zbytečné teď řešit IP sítě pro Velodyne na APU2, pokud nemáme ver0.

Zkrátím to: největší problém byl dostat olej tam, kde má být (a z míst, kde nemá být) — v systému jsou i teď ještě vzduchové bubliny. Detaily, jako že hadice jsou prohozené a traktor zatáčí opačným směrem, neřešíme. Není to priorita. Když v 2:00 najíždím na rampu vozíku, tak se ozve šílená rána — spadne nepřidělaný řídící box s počítačem a baterkou, který naštěstí chytá Standa. Jsme úplně vyřízení, v 3:00 přijíždíme na chatu, 5:30 vstáváme a pokračujeme do Písku …

Homologace a 1. kolo (cihla)

Homologovali jsme se s verzí 0, tj. cihla na plyn (nebyla to žádná obyčejná cihla, před odjezdem jsem ji vytáhl ze základů boudy na traktůrek) a STOP tlačítka na zastavení. Kupodivu ani toto nebylo bez problémů: cihla byla lehká, resp. byla potřeba větší síla na stlačení pedálu. Nakonec fungovalo ji vystředěně položit na pedál a doufat, že hned nespadne.

cihla na plynu

první kolo

základna

1. kolo bylo záhy po homologaci a tak jsme se chystali scénář zopakovat. Jakžtakž to šlo, „John” ujel asi 10 metrů a vyjel vpravo. A pak nastala druhá chyba — nemohl jsem s traktůrkem odjet, i když jsem měl „plyn na podlaze”. V rámci trojité páteční přestavby totiž pedál nebyl úplně dotažený (má nastavitelnou střední polohu) a povolily se šrouby.

2. kolo (USB-serial + notebook)

Do druhého kola jsme měli cca hodinu času, tak začaly první pokusy o integraci lineárního pohonu řídícího jízdu vpřed a vzad po CAN sběrnici. Ovládání z APU2 se nám nedařilo rozchodit, tak jsme jako nouzové řešení resp. mezikrok použili k ovládání notebook a USB-serial převodník. To mi připomíná ještě jeden detail, který jsme zjistili při vybalování v Písku — Tomáš, v ranní rozespalosti, zapomněl svůj notebook s programy pro programování a ladění CAN modulů na chatě. Ve zkratce, na CAN se nedalo šahat, vše bylo třeba ošetřit přímo na řídícím počítači a ladění bylo také … netriviální.

Traktor se řídí pedálem, který ve střední poloze nic nedělá, v jednom směru uvede stroj do pohybu vpřed a ve druhém do pohybu vzad (X300R má vyvedená táhla na každý směr zvlášť). Lineární pohon zase zapnete a posouvá se jedním směrem, přepólujete a jede druhým. Pro zpětnou vazbu je tam integrovaný potenciometr, ale díky relativně dlouhému přívodu nebyl údaj zrovna stabilní. Triviální úloha se začala komplikovat. Na začátku nebylo ani jasné, který směr je dopředu a jak moc je třeba posouvat s pedály, aby se traktor rozjel. Tomáš počítal pár desítek milisekund a tak jsme první pokusné časovaní řešili jenom time.sleep(0.1) na počítači. Hodnoty z A/D převodníku celkem plavaly, ale bylo vidět, že se v průměru buď zvětšují nebo snižují. Mimochodem, bylo skvělé, že šlo s pedálem hýbat aniž by byl motor traktoru zapnutý!

Když už jsme pulzy uřídili, tak přišel ostrý test se zapnutým motorem. 100ms nic. 200ms nic … to už bylo divné, ale … zvedáme na 400ms a dokonce na 0.5s. Pokud někdo slyšel kolem 10 hodiny dopoledne velkou ránu, tak to jsme byli my. Došlo mi, že je zamáčnutý parking (na mém traktůrku na to mám kontrolku, JD ji nemá) a odblokoval jsem ho. Traktor vyskočil vpřed, ale rozvaděč s elektronikou a baterkou díky dobře namazanému posuvnému mechanismu zůstal na místě! Naštěstí kabeláž byla důkladná a udržela to. Stejně tak baterka i počítač byly v bedně přidělané, ale … Stando, proč to bylo proboha namazané?! Já vím, že říkal, že to musíme připevnit, ale kdo si to má všechno pamatovat :-(. Tak už víme, který směr je dopředu a že 500ms je opravdu hodně.

Aby traktor sám zastavil je nutné dostat pedál do střední polohy. Do druhého kola jsme to tam dostávali ručně — krátké pulzy dokud to „zhruba nesedělo” (stejně dlouhý pulz opačným směrem časem „oddriftuje”). Vyžádali jsme si možnost sedět na robotu, kdyby se náhodou traktůrek splašil, a skříň s elektronikou jsme pro všechny případy fixovali gumicukem. Soutěžní start byl zase hektický, takže se nepodařilo robota dostatečně srovnat (přeci jen 300kg snadno neposunete), a proto robot vyjel už po cca 2 metrech.

3. kolo (APU2)

Problém s ovládáním z APU2 nebyl v kabelech, jak se zprvu zdálo, ale v nastavení sériové linky. Defaultní nastavení v Linuxu (APU2) a ve Windows (notebook) se jaksi liší. Narychlo se nám to daří rozchodit, a zdá se, že to bude už ok. Ke spuštění programu je potřeba ještě notebook, ale jinak už vše běží na APU2. Pro start robota se doplnil provizorní spínač a terminál běží ve screenu, takže by nemělo vadit, že není notebook připojený. John ale neodstartoval. Připojuji narychlo notebook a zkouším znova — tady je minutové startovací okno „trošku” stres. Druhý pokus a robot vyráží. Dokonce ujel asi cca 15 metrů?? Lepšíme se.

4. kolo

Zatímco robotická špička se předhání v jakých časech dosáhnou cílených 314 metrů, my řešíme, proč nestartujeme. Upravil jsem kód, aby se pulz potvrdil, tj. pokud je poloha nedostatečná, tak dalším pulzem to posune dál … ale stále stejný problém. S otevřeným notebookem to jede, jinak ne. Zatím nerozluštěná záhada.

Do posledního kola tedy nastupujeme s otevřeným notebookem (občas do něj trošku kápne — naštěstí vody a ne oleje). Traktůrek jede krásně, prostředkem cesty, radost pohledět a na cca 25(?) metrech se zastavuje. Došel benzín.

druhé kolo

třetí kolo

čtvrté kolo bez benzínu

Závěr

autor článku

Máme příběh, jak to JD málem mohl „vyhrát” . No nic, i tak to považujeme za úspěch. Jezdilo to, nikomu to neublížilo, senzor za $8000 jsme nerozbili (ani ho nikdo neukradl) a je jasné, co je třeba dělat dál. Robotem rovně byl skvělý dead-line, který nás donutil k max výkonu a teď to nejspíše zase poleví. Skoro zvažujeme ve spolupráci se „Zemědělkou” uspořádat nějakou soutěž v sekání trávy … reálné prostředí, všichni roboti současně, asi někdy v době prázdnin. Uvidíme. Bez dead-line nic nebude … zájemci piště .

Komentáře

Odkazy

oficiální výsledky

kontaktní formulář

Robotour 2016

2016-05-04T00:00:00Z

Pravidla

Letos dochází k drobné změně pravidel: robot může automaticky naložit a případně i v cíli vyložit náklad. Jsou za to bonusové body. Jako alternativa k sudu jsou teď i možné 500ml plechovky, pokud jsou automaticky nakládány. Loňské pravidlo, kdy bodově nejlepší tým startuje na konci konvoje, zůstává v platnosti.

Detailní pravidla jsou k dispozici na GitHubu s tagem ROBOTOUR2016: česky a anglicky.

Ukázky cestiček v Deggendorfu

Lokalita

Soutěž bude probíhat v několika sousedních lokalitách, viz přehledovou mapu.

přehledová mapa

Základna bude na Technishe Hochschule Deggendorf, část soutěže bude v Donaupark, dále v Stadthallenpark a konečně v univerzitním campusu.

Pokud chcete soutěž nějakým způsobem podpořit nebo máte nějaké doplnění/dotaz, tak se nám prosím ozvěte pomocí kontaktního formuláře.

Lamia

2015-11-16T00:00:00Z

Odkazy:

Stránky českého prodejce: http://www.icornerhightech.cz/
https://github.com/robotika/lamia

Obsah:

Blog

16. listopad 2015 — Předehra

Robota ještě nemám. Pokud vše dobře dopadne, tak si ho domu odnesu ve středu odpoledne … a slavnostní otevření festivalu bude ve čtvrtek, týden na to. Nebude to nuda . Chci se na to trošku připravit a hned první překvapení: link https://github.com/ARDroneSDK3 vede na stránku, kde se píše This organization has no public repositories. Hmm, to jsem zvědav, co se stalo.

Mám ještě staré klony repository, když jsem pracoval na Jessice a Katarině. OK, konec paniky. SDK je stále veřejná, jenom se změnilo jméno:

https://github.com/Parrot-Developers/

Tak co dál? Možná inspirativní video, co by Lamia měla umět. Skáče po schodech, do koše, na postel. Podle XML příkazů ale moc parametrů k dispozici nebude:

<cmd name="Jump">
    Request a jump
    <arg name="type" type="enum">
        Type of jump
        <enum name="long">
            Long jump.
        </enum>
        <enum name="high">
            High jump
        </enum>
    </arg>
</cmd>

Zaujalo mne, že Lamia by měla i vydávat zvuky (třída příkazů AudioSettings/Theme s hodnotami robot, insect a monster). Nabízí i jednoduché skriptování (asi příliš silné slovo) pomocí RoadPlan (viz tutoriál).

Dnešní záznam bych uzavřel odkazem na projekt Sumo Charge, který má v plánu autonomní dobíjení se vzdáleným přístupem přes internet. Odkazuje dále na JumpingSumo-Python, což by možná mohl být první start (i když jsem plánoval copy & paste Katariny).

p.s. jdu se koukat na televizi … nějaký seriál Já a robot (ano, obsahuje v názvu klíčové slovo a to mi teď stačí )

17. listopad 2015 — Pružiny

Robota ještě nemám, venku prší, tak zatím brouzdám po webu. Přes varovné hlášky typu I have a problem with jumping "wheel" in the center of the jumping sumo --- broke after a few uses. nebo drsnější I tried to show it off to my friends, and not only did it not jump again, after one minute after power one it started to burn with white flame and smoke . bych se začal trošku bát. Přeci jenom pro vylezení schodů bude třeba 21x skočit. Na druhou stranu uživatelů budou tisíce a toto je snad jenom „špička ledovce”.

Přes rozbité skákání jsem se dostal k videu How to replace Jump Mechanism on Parrot Jumping Sumo s detaily natahovacího kolečka:

pružinový mechanismus

A toto by mohlo být i mechanické řešení mého problému — Lamia by měla skákat cca 80cm, ale je nutné se dotknout všech schodů, takže bych potřeboval cca 1/4 výšku … a to by mohla řešit výměna pružiny za slabší. Mechanismus totiž vypadá jako nabít a pal, tj. žádné mezistavy.

Na téma pružin jsem pak zjistil, ze pérovna je hned „za rohem” (pruziny.cz), případně že Alcomex má na webu rovnou katalog s tabulkami. Počkal bych ale až jak bude Lamia vypadat ve skutečnosti. A ještě jeden odkaz na výpočet pružin.

23. listopad 2015 — Codility

Robota ještě nemám, abych parafrázoval své předešlé příspěvky. Není na skladě a minulé úterý nedorazil. Alternativa by byla si koupit novější model na Alze a pak ho vrátit, ale to se mi nějak příčí. A 4999Kč se mi za to také nechce dát (starší model byl za 2999Kč … i když teď tam vidím rozbalený za 4135Kč, tak to asi vánoce dělají paseku).

Co v mezičase dělat? Byl jsem „programátorsky nabuzený”, takže, když jsem narazil na Codility Challenge, jsem to po fyzicky náročném víkendu prubnul . Ještě to není nejhorší, něco naprogramovat asi umím. Povolený čas 3h na 3 úlohy asi byl OK (programovací jazyk si můžete zvolit, u mne to byl jednoznačně Python). Naštěstí nejsem amík, takže mne nemusí trápit, že jsem nevyhrál $2500 = 63000Kč = 21000Kč/h … to by šlo . Ono i druhá cena 3x drona Lily by nebyla špatná … minimálně by bylo zase o čem na robotice psát . No nic, na to by člověk, resp. programátor, musel mít hodnocení (100, 100, 100). Okurková sezóna snad zítra skončí …

25. listopad 2015 — První pohyb

Dnešní titulek už zní nadějně, není-liž pravda? Ale růžové to není, ostatně jak by mohlo … robot bude zítra ráno a zítra večer (18h, NTK Galegie) je slavnostní zahájení festivalu. Mezi tím normální pracovní den. Nevydržel jsem to a „zainvestoval” hotovost do ROZBALENO RC model Parrot Jumping Sumo White s tím, že je to předražené a že jim to zítra (?) vrátím. Na krabici bylo navíc napsáno „04 Zápůjčky”, což je můj případ, nebo ne? No balení nebylo kompletní — chyběl nabíjecí kabel! Tak jsem to chtěl vrátit hned a oni, že na to mám 14dní … OK.

Nabíjení trvá 2 hodiny. Ano, opravdu. Tj. ve 20h jsem přišel z práce a ve 22h udělal první test. Popojel jsem kousek vpřed, kousek vzad a zkusil skočit. Jezdilo to, ale neskáče. Ono by to bylo divné, kdyby to hned vše fungovalo … nic, zítra pokračování.

Ještě jeden vtipný (?) detail: po vložení baterie robůtek ožije, rozsvítí se mu oči a po chvíli začne tancovat! Měl jsem ho na stole, že ho připojím na nabíječku, tak jsem se trošku lekl.

27. listopad 2015 — FreeFlight 3

Včera večer jsem zkoušel Android aplikaci FreeFlight 3. Na pracovním testovacím telefonu byla ještě nainstalovaná z loňska (tehdy to byla minidrona Jessica) a bez problému se připojila, zobrazila pohled z kamery a mohl jsem hned popojíždět vpřed a vzad. Otáčet mi ale šlo jen o 90 a 180 stupňů. To mi chvilku trvalo, že musím mačkat display a naklánět telefon („mrtvá zóna” byla nastavena poměrně široce). A skákalo to! Tj. problém s pružinovým mechanismem není a je to čistě v „mém” software.

Co bylo trošku zklamání je výdrž baterie. Zkoušel jsem na dálkové ovládání zdolat soutěžní schody a mám vážnou obavu, že to baterie nevydrží ani když to budu brát po třech. Samotné skákání mne ale mile překvapilo. Lamia se po dopadu snaží okamžitě stabilizovat, podobně jako dvojkolka Segway, a tak v lepším případě jenom dosedne. V horším, hrana schodu, to po pružných kolečkách dopadne až daleko od schodiště. Mimochodem i pro Lamiu je dobré, že schodiště mají po obou stranách poměrně vysoké mantinely. A konečně se snaží udržet směr, takže jako program by mi stačil for-cyklus, ve kterém by byl jediný příkaz: skoč.

Druhé zklamání bylo, že video se dá nahrávat pouze do externí USB flashky (navíc s micro USB konektorem), která ale není součástí balení. Chtěl jsem vám ukázat jak to šlo, ale … sigh, je třeba rozchodit logování a z videopaketů bych to pak poskládal.

Jinak robůtky mám teď dva: „Lamia A” a „Lamia I” … toto označení jsem zvolil, aby si žádná nestěžovala „proč zrovna já jsem Béčko” (Cimrman). Libila se mi i AI kombinace a vlastně i písmeno ukazuje na zdroj (Alza, iCorner). Barevně by druhá vypadala spíše na Emmu Dax z Genetixu , ale nechť.

bílá varianta

tandem

balení

p.s. upravil jsem trošku README u haraisao/JumpingSumo-Python

28. listopad 2015 — Verze 0

Je doslova „za pět minut dvanáct” a konečně mám Verzi 0. Nevím, co jsem dělal špatně v tom japonském kódu, ale teď to upraveným kódem z Katariny skočilo.

Z detailů, na které jsem narazil a které později už nebudou zajímavé:

bílá Lamia se dala z notebooku připojit, ale hnědá nikoliv — problém byl v defaultní WiFi, která je na 5GHz a já potřeboval 2.4GHz. Lze vyřešit tak, že se podrží 3s zapínací tlačítko (u bílé jsem to možná včera udělal nechtěně, když jsem se jí snažil vypnout). Ano, dnes jsem klesl tak hluboko, že jsem si přečetl i manuál
Jumping Sumo používá jinou IP (192.168.2.1, Katarina měla 192.168.42.1)
základní příkazy pro pohyb jsou jiné (PCMD má teď jenom rychlost jízdy a zatáčení)
Sindy (náš pes) se, na rozdíl od dron, skákací potvory bojí (asi jak vydává zvuky)
Lamia skoro nic neposílá, jenom ping-pong časové známky (tj. změnil jsem vnitřní update() funkci)
video asi chodí po celých snímcích, protože původní 40960 bajtový buffer nestačil (teď jsem tam dal 240960)
zase jsem narazil na podraz s enum, který není bajt, ale čtyři bajty

Je čas jít spát. Zítra, resp. už dneska v 13h na viděnou v NTK Galerii …

5:30-7:30

Ještě pár poznatků, než vyrazím do NTK:

japonský kód stále neskáče … rezignoval jsem na něj a pokud se autor neozve, tak ho asi odstraním (i když jeho knihovna se mi líbí, že je celkem kompaktní)
zaujal mne identifikátor ARCOMMANDS_ID_JUMPINGSUMO_PILOTING_CMD_ADDCAPOFFSET a tak jsem ho společně s ovládáním hlasitosti (děsně to řvalo a v noci a brzy po ránu to není úplně chtěné) vyzkoušel (diff). Co to dělá? Otáčí robota o přesně definovaný úhel v radiánech a to by se na točitém schodišti mohlo hodit.
video není H264, ale sada klasických JPEG obrázků. Upravil jsem tedy video.py aby místo frame_XY.bin ukládal s koncovkou .jpg (diff). Včera jsem po skoku měl příliš krátkou pauzu, a tak let a dopad nebyl už logován. Dnešní „duch na židli” = snímek 0131 vypadá takto:

Mezipřistání na židli

(omlouvám se za mizerné osvětlení)

29. listopad 2015 — Soutěž resp. přednášky

Včerejší soutěž dopadla nakonec celkem dobře, přestože jsem vynechal dopolední testování. Vedle totiž probíhala sekce robotických přednášek, které byly naprosto luxusní (!), a akustika v Galerii byla tak mizerná, že stačilo, aby se na druhé straně místnosti někdo bavil a už bylo špatně slyšet. Přednášky byly o evoluční robotice, robotech, kteří žijí v symbióze s rostlinami a směřují jejich růst, rekonfigurovatelní swarm roboti, roboti, kteří se vyrovnají s defekty svých částí, modulární stavebnice, kdy děti od osmi let jsou schopné postavit chodící nebo jezdící „tvory”, „genetický” drátový robot, který podle robotické DNA drát kombinovaný s motory zohýbá a výsledný „1D robot” se pohybuje v prostoru … fakt luxus a špičkoví přednášející! Bylo nás tam cca 15 a z toho 6 přednášejících — z tohoto pohledu bych plakal.

No nic, to jsem odbočil, ale co mne trošku znáte, tak pochopíte, že jsem si vedle prostě hrát nemohl. Zmíním k tomu alespoň pár odkazů, co jsem si napsal:

Joel Lehman, autor knížky Why Greatness Cannot Be Planned … ukončoval to pěknou hláškou, skoro bych řekl „životní motto”: To achieve your highest goals, you must be willing to abandon them. (článek).
Picbreeder.org — evolutionary art
REAL - Robotics, Evolution and Art Lab
florarobotica.eu
mars-one.com
Elephants Don’t Play Chess
Playware
OpenSource under water robot nebo přímo OpenROV … ale hledal jsem REMORA …
Human Brain Project
shaperobotics.com — robotická stavebnice

… nějak mi teď přijde nepatřičné psát dál o problémech s řízením podle stavu baterek. Asi až … časem.

1. prosinec 2015 — Soutěžní kód

Raději doplním alespoň krátkou zprávu o použitém kódu než to vše zapomenu …

Asi bych začal odkazem na github, kde je stav skriptu, pro který Lamia získala maximum bodů (10 na točitém schodišti v posledním kole). Robot skákal, otáčel se o 10 stupňů po každém skoku a couval, aby se dotknul přeskočených schodů (jinak by nezískal bod). A právě s couváním byl největší problém. Řízení robota je asi obyčejné PWM, tj. když jsou baterky nabité, tak na „padesátku” ujede řádově více než když baterky dochází.

Včera (?) jsem pustil git pull na libARCommands a zaujal mne commit Add command to let the JS report its speed. Je tedy možné, že pokud flashnu firmware, tak Lamia začne reportovat svoji skutečnou rychlost?! Myslím, že to rozhodně stojí za pokus a pak by to soutěžení bylo o něčem jiném … možná až moc nuda .

Jinak jestli jste neviděli Lamii v akci, tak viz ČT art (no je tam vidět vlastně jenom jeden skok, tak nic).

3. prosinec 2015 — telnet

Lamia, stejně jako Heidi nebo Katarina podporuje telnet:

Jumping Sumo telnet

Prapůvodně jsem chtěl nahrát pouze nový firmware, ale ono i nejnovější dostupná verze verze je 1.99.0 a ta je ze začátku roku, tj. velmi pravděpodobně stejně informace o ujeté vzdálenosti, resp. aktuální rychlosti v cm/s posílat nebude.

Co jsem našel? Řekl bych, že už standardně se hlavní řídící program jmenuje dragon, přesněji dragon-prog, kterého pouští DragonStarter.sh. Zajímavý je adresář /usr/bin, kde jsou pomocné nástroje jako:

[JS] $ ls | grep js_
js_PCA96n
js_adc
js_motors
js_vbat

Předpokládám, že je třeba nejprve „zabít draka” a pak je možné je používat. Příklady výpisů:

[JS] $ js_motors
*****
"js_motors": Version 1.1
 Build for Proto A3

*****
     js_motors Usage:
 js_motors –help
 js_motors –stopall
   ---
    Description:
  This program is made to command Jumping Sumo Motors
   ---
    Options:
  -h,   –help
                              Dislay this help
  -S,   –stopall
                              Stop all motors!
  -r,   –right  
                              Right motor command (-255->255)
  -l,   –left  
                              Left motor command (-255->255)
  -j,   –jump  
                              Jump motor command (-255->255) XXX TODO Add time out!
   ---
    Example:
 TODO
*****

[JS] $ js_vbat
JS_VBAT : Vbat = 3.614986 V

[JS] $ js_adc
 ### save_or_print_results_mode = 4
mmap phy0x400ea000 cpu 0x402e0000

** INIT DONE **

wait 1 sec…
START CAPTURE: => Ok
 __________________________________________________
| N loop | I jump | R wheel | offset |   N cycle   |
|     39 |    518 |     521 |  49152 |  2623983794 |
OUT OF LOOP (40 loops)
#### The End ! err=0 ; nbLoopBeforeErr=-1
#### munmap…
#### close driver…
#### close files…

a konečně

[JS] $ js_PCA96n
"js_PCA96n": Version 1.0

*****
     js_PCA96n Usage:
 Read  reg : js_PCA96n 
 Write reg : js_PCA96n  
*****

Nuže draka jsem nezabil a možná ho dotazem na stav baterky zmátl, tak se zuřivě rozblikaly červené LEDky a robot se vypnul. Je i možné, že už baterie byla opravdu vybitá — příště testovat na nabíječce!

p.s. myslíte, že I jump = 518 je čítač dosud provedených skoků? Jestli ano, tak potěš …

4. prosinec 2015 — dragon.conf

Dnes jsem se moc daleko neposunul. Prohlížel jsem si konfigurace a moc mne nenadchly:

dragon.conf

{
      "JumpingSumo" :
      {
              "audio_theme" : 0,
              "net_outdoor" : 0,
              "volume" : 10.0,
              "wifi_autoselect_mode" : "2.4GHz",
              "wifi_band" : 0,
              "wifi_channel" : 13
      },
      "network" :
      {
              "auto_country" : 1,
              "country_code" : "NL",
              "default_c2dport" : 54321,
              "default_d2cport" : 43210,
              "product_name" : "JumpingSumo-PI040318AB4H029718",
              "service_type" : "_arsdk-0902._udp"
      }
}

system.conf

{
    "CKCM":{
        "Enable":true,
        "DisplayTargetTime":true,
        "DisplayThreadId":true,
        "DisplayThreadName":true,
        "DisplayThreadPrio":true,
        "DisplayPC":false,
        "PortType":3,
        "DeviceName":"/data/ftp/ckcm.bin",
        "UartBaudRate":115200,
        "SocketPort":23000,
        "MaxFileSize":1000000,
        "Delay":500,
        "TcpPort":23059,
        "Libraries":
        [
            {
                "Name":"TANGO",
                "Verbosity":0
            },
            {
                "Name":"TALA",
                "Verbosity":0
            }
        ]
    }
}

Stále jsem doufal v nějaký debug, který nastavím na True a Lamia začne posílat debug hlášky, ale nevypadá to nadějně … zatím.

Ještě pár ukázek z pouštění „draka”:

[JS] $ /usr/bin/dragon-prog –help
posix init start build on : Aug  4 2014 17:34:44
Use ctrl+\ (SIGQUIT) to end the application
plog drop: RR time quantum 0s 0ns
tid=(nil), [I] POS: sup log : stack size 16144 is too small, setting to 16384
tid=(nil), [I] dragonprog:
Usage: /usr/bin/dragon-prog [options]
Options:
-h | –help                     Print this message
     –version                  Print version informations
-i | –ip                   host IP
-v | –verbose

[JS] $ /usr/bin/dragon-prog –version
posix init start build on : Aug  4 2014 17:34:44
Use ctrl+\ (SIGQUIT) to end the application
plog drop: RR time quantum 0s 0ns
tid=(nil), [I] POS: sup log : stack size 16144 is too small, setting to 16384
tid=(nil), [I] dragonprog:
tid=(nil), [I] dragonprog: ----------–
tid=(nil), [I] dragonprog:          Version Informations :
tid=(nil), [I] dragonprog: BUILD_DATE           = 2014-08-04
tid=(nil), [I] dragonprog: BUILD_TIME           = 17h27m27s
tid=(nil), [I] dragonprog: BUILD_COMPILER       = pimo
tid=(nil), [I] dragonprog: BUILD_COMPUTER       = pimoEliteDesk
tid=(nil), [I] dragonprog: BUILD_DRAGON_VERSION = 1.0.80
tid=(nil), [I] dragonprog: ----------–
tid=(nil), [I] dragonprog:

a konečně pokus o verbose

[JS] $ /usr/bin/dragon-prog -v 2
posix init start build on : Aug  4 2014 17:34:44
Use ctrl+\ (SIGQUIT) to end the application
plog drop: RR time quantum 0s 0ns
tid=(nil), [I] POS: sup log : stack size 16144 is too small, setting to 16384
Initialize PAL log
date=000000065711, tid=(nil), tname=init, [E] POS: The callback is NULL
CKCM config loaded and started.
Enable 0 for TANGO
Enable 0 for TALA

----------
     MPU FACTORY CALIB:
----------
sizeof (HAL_mpu6050_factory_file_calibration_t) = 54
 SIZE     =       52
 VERSION  =        1 = 0x    1
 CHECKSUM =    29574 = 0x 7386
 gyro_offset : +0.01827 ; -0.00863 ; -0.05359
 gyro_gain   : +0.99116 ; +1.00688 ; +0.99578
 acc_offset  : -0.10199 ; +0.57647 ; -0.23113
 acc_gain    : +0.99682 ; +0.98458 ; +0.99619
----------

pwm_requested_frequency_Hz: 50000, mode : "8 BITS MODE"
pwm_num 2 : pwm_actual_frequency_Hz = 54166
pwm_requested_frequency_Hz: 50000, mode : "8 BITS MODE"
pwm_num 3 : pwm_actual_frequency_Hz = 54166
pwm_requested_frequency_Hz: 50000, mode : "8 BITS MODE"
pwm_num 0 : pwm_actual_frequency_Hz = 54166
pwm_requested_frequency_Hz: 50000, mode : "8 BITS MODE"
pwm_num 1 : pwm_actual_frequency_Hz = 54166
libHAL's HAL_P6i_adc_jpsumo_init: mmap kernel_ptr0x(nil) user_ptr0x0x40a4d000
[libFSM ERROR] Duplicate stateID
[ESTIMATOR] Start estimator state machine
 state entry : init
[DRIVING CONTROLLER] Start control state machine
 jump state entry : init
[JUMP CONTROLLER] Start control state machine
 No high jump : phi is too low
File /tmp/run/init/etron_started already exists.
Unknown host
init OK !!!!
[ANIMATIONS] Start animations state machine :  state entry : start
 jump state entry : unknow
 jump state entry : stop detection init
 jump state entry : to_cam_stop
 cam stop detected
 jump state entry : learning
 jump state entry : to_cam_stop
[libFSM] stop
 state entry : driving normal
 cam stop detected
 jump state entry : unloaded
 state entry : stopping normal
 state entry : waiting

tak asi nic. Můj další cíl je prozkoumat Road Plan, což by měl být skipt popisující nějakou animaci, např. jeď 1m rovně, otoč se o 45 stupňů, skoč, udělej fotku atd. Bohužel popis formátu jsem nenašel, takže to bude delší cesta přes hackování s Free Flight 3. Mimochodem FF3 je i na Windows Store, ale na Windows 10 zatím upgradeovat nechci.

5. prosinec 2015 — Road Plan

Nedal jsem včera robota na nabíječku a to se mi teď samozřejmě vymstilo. Stihl jsem akorát zadat první příkaz „jeď 1 metr rovně”, přihlásit se telnem a podívat se, jak to vypadá:

[JS] $ pwd
/data/ftp/internal_000/Jumping_Sumo/scripts
[JS] $ ls
2e27a947-16cd-4e50-a181-4a3e0ee39d2d.json
[JS] $ cat 2e27a947-16cd-4e50-a181-4a3e0ee39d2d.json
{ "product": "902", "version": 1, "uuid":
"2e27a947-16cd-4e50-a181-4a3e0ee39d2d", "lastModified": 1449291081, "name":
"05\/12\/2015 05:51", "description": " ", "instructions": [ { "name":
"straight", "comment": " ", "distance": 1.000000, "maxSpeed": 1.000000 } ] }

To vypadá celkem srozumitelně, není-liž pravda? Žádné složité binární protokoly, jenom textový JSON. Asi bych si teď troufl změnit požadovanou ujetou vzdálenost a maximální rychlost. Ještě by mne zajímalo, zda funguje záporná vzdálenost (v té dělám snad vždycky chybu), protože na klávesnici Free Flight 3 jsem mínus neviděl. Pozn. do "description" a "comment" jsem teď vložil extra mezeru, aby to robotika-parser neinterpretoval jako kurzívu.

Robot se na nabíječce nechce nechat zapnout, tak to dnes bude holt asi jenom tento „štěk”.

p.s.

{ "product": "902", "version": 1, "uuid": "2e27a947-16cd-4e50-a181-4a3e0ee39d2d", 
"lastModified": 1449296904, "name": "05\/12\/2015 05:51", "description": " ", 
"instructions": [ 
  { "name": "straight", "comment": " ", "distance": 0.500000, "maxSpeed": 1.000000 },
  { "name": "arc", "comment": " ", "maxSpeed": 1.000000, "angle": 180.000000, 
       "radius": 0.000000 },
  { "name": "animation", "comment": " ", "animation": "metronome" }, 
  { "name": "takePicture", "comment": " " },
  { "name": "straight", "comment": " ", "distance": 0.500000, "maxSpeed": 0.500000 },
  { "name": "ledRed", "comment": " ", "side": "right", "lit": true }, 
  { "name": "ledRed", "comment": " ", "side": "left", "lit": false }, 
  { "name": "ledGreen", "comment": " ", "side": "both", "value": 255 }, 
  { "name": "wait", "comment": " ", "duration": 1.000000 }, 
  { "name": "takePicture", "comment": " " }, 
  { "name": "posture", "comment": " ", "type": "jumper" }
 ] }

6. prosinec 2015 — Parrot Developer Fórum

Djavan mi odpověděl na dotaz ohledně odometrie a přesměroval mne na Parrot Developer Fórum (asi je nutné přihlášení). Nic přímo použitelného jsem tam zatím nenašel, snad jen poznámka ohledně firmware, kde 2.0 je určené pro nové Jumping Sumo Race. Jestli se tím dá ale flashnout staré Jumping Sumo netuším.

Narazil jsem ještě na Hacking the Parrot Jumping Sumo, kde mne zaujala nápověda Debug options at /etc/debug.conf, tak se na to jdu podívat … nic tam není :(. Je tedy možné, že v pozdějším firmware byl odstraněn???

8. prosinec 2015 — Panoramatické snímky?

Přemýšlel jsem co s robotem dál a trošku se nabízí „panoramatické snímky”. Lamia má mizernou, nebo bych spíše měl psát nedostupnou, odometrii, ale dokáže se velmi pěkně a přesně natáčet. Pravda, že jak moc přesně to je nezjistím, dokud to pořádně nezměřím, ale i to co jsem viděl bylo OK.

Dal jsem tedy do gitu jednoduché demo (diff), kdy se robot otočí o DEG_STEP, zastaví, uloží snímek a tak celých 360 stupňů.

def demo( robot ):
    "panoramatic picture"
    DEG_STEP = 30
    robot.setVideoCallback( keepLastImage )
    for absAngle in xrange(0, 360, DEG_STEP):
        robot.update( cmd=addCapOffsetCmd(math.radians(DEG_STEP)) )
        robot.wait(1.0)
        assert g_lastImage is not None
        open( "scan%03d.jpg" % absAngle, "wb" ).write( g_lastImage )

Pak jsem dal do Google "cv2 image stitching" a mimo jiné vypadl odkaz na Multiple Images/ Panorama Stitching with Python OpenCV i se zdrojovým kódem. Trošku jsem to upravil, aby to šlo vůbec pustit (pull request), ale možná jsem to špatně pochopil, nevím. V každém případě pro testovací sadu snímků to nefungovalo, ale pro první dva jsem nějaký výsledek dostal:

scan000.jpg

mix

scan030.jpg

Ta distorze je neúnosná a je třeba jí nejprve kompenzovat. Ostatně jsem na tento problém narazil i na stránkách stitcheru.

Pokud by si někdo chtěl hrát nezávisle, tak tady je sada obrázků po 30 stupních:

Koukám, že posun křížení dlaždic je cca po 200 pixelech, obrázky jsou 640x480 a krok byl 30 stupňů, tj. hrubým odhadem má Lamia 90 stupňů FOV — to není špatné. Ono je to vlastně vidět i na té sekvenci, když se člověk podívá na sloupec místo na řádek.

Neodolal jsem, a od oka to bez kalibrace nařezal (diff, případně stitcher.py. Vyříznul jsem zhruba tu 1/3 (s těma pár pixelama by si asi chtělo pohrát) i na výšku z každé stranu ubral 100 pixelů a na těch 15min práce výsledek není až tak špatný:

výsledek jednoduchého spojení obrázků

5. leden 2016 — SICK Pink Cube

Je to už nějak hrozně dlouho, co jsem k Lamia nic nepřipsal — i jsem za tu dobu stačil zapomenout, jak se ten skokan jmenuje :-( … resp. pardón, skokanka. Alespoň bych tedy zmínil, co se za ty tři neděle dělo (vánoce a Nový rok trošku ignoruji).

Jednak mi kolega z práce přivezl z Německa kostičky pro SICK Robot Day 2016 (aktuální anglický externí odkaz je zde). V rámci „robotického semináře” měli studenti navrhnout nabírací mechanizmus a nejlepší by bylo ho rovnou vyzkoušet v akci, tj. detekovat kostku, přijet k ní a nabrat jí. A ta detekce by vlastně mohla být i pěkné cvičení na zpracování obrazu co posílá Lamia:

růžová kostka na SICK Robot Day 2016

Druhý střípek byla oponentůra práce Martina Döflera spojená s článkem Vision-Based Pose Recognition, Application for Monocular Robot Navigation

bezdrátová nabíječka

(na webu zatím vidím jen placenou verzi). Je to nápad, jak rozšířit navigační algoritmus SURFnav o detekci konce segmentů z obrázku, bez použití odometrie. Jsem na toto téma trošku skeptický a nejlepší by bylo to vyzkoušet. A pokud občas budu potřebovat „panoramatický snímek”, tak Lamia ho v hrubých rysech poskladá (ano, otázka, jak moc by byl použitelný pro navigaci).

A třetí střípek je, že dorazil „čínský vánoční dárek”: bezdrátová nabíječka, nebo jak se tomu říká. Myšleno je to pro mobily, které pak stačí pouze položit na nabíjecí plošku. Chci to zkusit s Lamií a tak trošku experimentovat s Sumo Charge myšlenkou. Časem …

8. leden 2016 — Experiment s ORBou

Mám jen 15min, tak to bude jen takový „štek”. Jak jsem psal minule, rád bych si pohrál s detektory a matchováním obrázku. A ono je to v Pythonu krásně jednoduché , viz např. tutoriál py_surf_intro. Zaujalo mne varování SURF is good at handling images with blurring and rotation, but not good at handling viewpoint change and illumination change. Ale změna místa pohledu a osvětlení je jistá … čert to vem, nějak začít musím.

Pak jsem párkrát stiskl Next, Next, Next … a dostal se na ORB desriptory (mimochodem, už chápu proč vědecké články obsahují všechny možné typy deskriptorů — ono je to skoro zadarmo, stačí slovo SURF nahradit ORB, BRIEF, FAST a je to … no trošku zjednodušuji). A poznámka, co asi všichni víte: ORB: An efficient alternative to SIFT or SURF in 2011. SIFT and SURF are patented and you are supposed to pay them for its use. But ORB is not! Tak jsem místo SURFnavu začal rovnou experimentovat s ORBou.

Mám starší verzi OpenCV, tak mi nefungovalo zobrazování výsledného matchingu. Evidentně v tom nejsem sám a nejrychlejší funkční řešení bylo vzít si kousek kódu ze stackoverflow. Ještě zobrazení nefungovalo na barevné obrázky, tak jsem je narychlo transformoval na šedotónové.

Zde jsou dva úspěšné příklady:

a zdrojový kód je pak zde.

Ještě mi zbyly 4min, to bych nečekal … než to pushnu … timeout.

10. únor 2016 — END

Včera jsem Lamii vrátil. Předběžná domluva je, že si jí zase půjčím cca měsíc do soutěže Tour the Stairs (bude-li dost zájemců), protože tam přeci jenom pasovala lépe než minidrona Jessica.

Nechávám tomu tedy „otevřený konec”. Pokud by v experimentování někdo rád pokračoval, může si robota koupit na icorner dnes za 2408Kč (alza má jenom ty novější za 4000kč) a napsat mi zkušenosti, případně poslat odkaz, který bych zde doplnil.

kontaktní formulář

Tour the Stairs 2015

2015-09-25T00:00:00Z

Pravidla pro rok 2015

Základní pravidla zůstávají stejná jako loni. Rozšíření pravidel se vás bude týkat až pokud se vám podaří splnit loňský úkol, tj. vyšplhat po schodech nahoru. Robot totiž může následně bodovat i za slezení schodů dolů.

Za každý zdolaný schod (počítá se nejnižší část robota) získá tým jeden bod. Aby robot bodoval i za sestup musí dosáhnout nejvyššího schodu, v opačném případě vlastně o body přichází. Bodově 1 schod = 1 bod.

Christian si vymyslel ještě „umělecké bodování”, které se mi nepodařilo mu rozmluvit. Pokud bude více jak 50% robota vyrobeno ze dřeva a zdolá alespoň v jednom ze čtyř kol alepoň jeden schod, tak získává bonus 25 bodů. Celkově lze letos získat maximálně 4*2*21+25=193 bodů.

Mimochodem vznikla přímo dedikovaná stránka soutěže:

http://tour-the-stairs.com/

p.s. registrační formulář zůstane stejný pro všechny ročníky a naleznete ho tedy na hlavní stránce soutěže.

UPDATES

1. listopadu 2015 — Registrační video KRA Písek

Mám pro vás dvě zprávy: jednu dobrou a jednu špatnou. Dobrá zpráva je, že „Klub robotiky a automatizace” z Písku dosáhl svého slibu a již natočil zdolání jednoho schodu pavoučí platformou:

Špatná zpráva je, že včera skončila registrace a toto je v danou chvíli jediný registrovaný soutěžící! Pokud jste pouze přehledli termín, tak nezoufejte, vyplňte registrační formulář a raději mi i napiště mail.

S Christianem jsme se předběžně domluvili, že v této situaci nasadím oponenta já …

9. listopadu 2015 — Husky schody nedá

Minulý den jsme cvičně zkusili robota Husky, jak se vypořádá se schody … a nedá to:

Mluvil jsem s Christianem a dostal mne jeden komentář, že pro některé robotiky je úloha TTS jenom mechanická záležitost a není potřeba žádná inteligence. Asi bych už teď odkryl karty na rok 2016, kdy je v plánu dělat „okruh”: robot po jedněch schodech vyleze a po druhých se vrátí zpět a znova na start. Možná ta navigace už nějakou inteligenci bude potřebovat. Proč to zmiňuji teď? No není nad to vyzkoušet si mechaniku rok předem .

Ještě poznámka, že v sobotu se soutěž bude prolínat s přednáškami a konkrétně např. Jean-Baptiste Mouret, který bude mluvit o zotavení robotů po nehodě, by mohl být zajímavý .

26. listopadu 2015 — Pozvánka na zahájení festivalu

Dnes v 18h se koná slavnostní zahájení festivalu v Galerii NTK v Praze Dejvicích. Detailní program naleznete zde.

First Person View drona, co je v plánu jí tisknout na 3D tiskárně

Přednáška o robotickém divadle

Posthuman Research Performance

MakersLab

Interaktivní robot z LEGO

www.MakersLab.cz

28. listopadu 2015 — Výsledky a Lamia video

Dva soutěžící týmy není moc, ale přesto si myslím, že pro návštevníky NTK Galerie to bylo mile zpestření . Pro mne pak bylo překvapení, když oba roboti po posledním kole skončili stejně:

Pořadí	Tým	1.rovné	1.točité	2.rovné	2.točité	3.rovné	3.točité	4.rovné	Celkem
1.-2.	KRA Písek	4	2	5	2	5	2	6	26
1.-2.	Lamia	2	2	3	3	3	10	3	26

Lamia - Tour the Stairs 2015 (straight)

Lamia - Tour the Stairs 2015 (twisted)

1. prosinec 2015 — Přehlídka robotiky na ČT art

ceskatelevize.cz/ivysilani/1097206490-udalosti-v-kulture

KRA Písek na ČT art

7. leden 2016 — minivideo

Zde jsou krátká videa od Christiana, co mi včera poslal:

KRA Písek

Lamia

kontaktní formulář

Výsledky

2015-09-09T00:00:00Z

Soutěž

Účast

Přihlášeno bylo devět týmu a dorazilo devět týmů . Ve skutečnosti ale místo AmBota, který měl den před soutěží vážné problémy s robotem a účast odvolal, nastoupil další německý tým JECC2. Jediným opravdovým nováčkem na Robotour byl tým Kamaro Engineering, který jsme potkali na soutěži Field Robot Event 2015, a po pravdě jsem úplně nevěřil, že dorazí. Ale oni nejen dorazili, on jim dokonce robot jezdil a dobře a s trochou štěstí i vyhráli!

Místo soutěže

To by nebyli Písečaci, aby si nevymysleli něco speciálního. Pod záminkou, že desátý ročník si něco takového zaslouží, byly na roboty nastraženy opravdové chuťovky. Jelo se částečně v parcích, resp. po parkových cestičkách, ale stejně tak po silnici, dlažkách a površích s různou barvou. Nechyběl hřbitov, resp. „pietní místo”, ze kterého jsem byl zprvu trošku nesvůj, ale ony se tam konají i svatby a mládež si tam hrála fotbal, tak to se roboti k nebožtíkům chovali řádově s větší úctou.

Další vychytávka byl most pro pěší s bezbariérovým sjezdem na ostrov. A pokud vám to stále přijde málo, tak co taková pasáž skrz dům, kterou se dostanete z náměstí do Palackého sadů, kde se každoročně konává Robotem rovně?! Co mne potěšilo, že skoro žádný tým si nestěžoval. Naopak si to několik týmů pochvalovalo, že soutěž byla spojena i s prohlídkou města.

0. a 1. kolo

Nulté kolo, kde si opakujeme startovací proceduru, kupodivu nebylo tak chaotické jako předešlé ročníky. Pro ostré 1. kolo pak platil stejný start a cíl.

Murphyho zákony v praxi jsme mohli vidět u Kamaro Engineering — projeli rovnou parkovou cestičku, přejeli silnici, trefili branku na hřbitov, ale pak se vyhybali stromu ze špatné strany a vyjeli z cesty. To bylo cvičné kolo. V ostrém kole vůbec nevyjeli.

JECC2 jel bez GPS, zatím čistě na odometrii. Robot byl sotva pár hodin starý a tak jsem byl mile překvapený, že celkem spolehlivě jezdil a plný sud mu nedělal žádný problém.

Loňský vítěz Smelý Zajko nastoupil se svojí neuronovou sítí zase s novou dávkou odvahy. Nově přibyl laserový scanner Hokuyo, který robota zrazoval od hřbitovní zdi. Po několikaminutovém rozmýšlení s přejezdy mám tam jet, nemám tam jet, směr udávaný kamerou nakonec vyhrál a v ostrém kole jenom Smelý Zajko dokázal projet branou, místem odpočinku a i vyjet brankou na druhé straně. Skončil ale v jiné pasti: bílé auto na parkovišti. Barevně totiž bílá byla vyhodnocena jako potenciální cesta, ale černé pneumatiky nikoliv. A tak robot osciloval a bílé auto už neopustil. Příští ročník by tuto situaci prý měl už řešit nový LIDAR.

Ze smolařů bych zmínil ještě MarS. Zde také hrála kamera primární roli při navigaci a betonové sloupky v barvě cesty robota nalákaly a uvedly v kolizi.

A co E_liška Radioklubu Písek? Jela pěkně, ale branku na hřbitov netrefila. Chvili koketovala se hřbitovní zdí a pak jsme byli svědky AI v praxi (štouralové by možná řekli štěstí), kdy přeplánovala a zvolila alternativu okolo hřbitova. A to se jí téměř podařilo (selhání 46m před cílem).

2. kolo

Druhé kolo natáčel Dan Polák ze vzduchu, tak se můžete podívat:

Mně osobně to z těchto záběrů připadá jako nějaká hromadná havárie na robotické dálnici. Měl to být snadný úsek, ale nebyl. Startovalo se na cyklistické stezce podél řeky Otavy, mírně do zatáčky. Směr jih — že by slunce byl problém? Na cestě byly nakresleny pruhy pro cyklisty a pěší, problém? Nevím, v každém případě robotům se moc nedařilo a první oblouk nezvládl nikdo. Nedostalo se tak ani na první odbočku na most a druhou na ostrov. Chvíli to byl ale adrenalin, když např. E_liška špatně vyhodnotila změnu povrchu a odbočila vlevo. Vlevo totiž byl příkrý svah dolu a řeka.

3. kolo

Po zkušenostech z prvních dvou kol jsme se rozhodli roboty netrápit výjezdem k Putimské bráně, ale posunout start až na pěší zónu za převýšením. Týmy i baterky se v polední pauze posilnily a bylo to poznat. Někdo by řekl, že toto byl snadný úsek, jiný by tvrdil pravý opak.

Ono nebylo moc kam uhnout: vlevo byla zeď a vpravo domy. Ale nízký obrubník byl smrt pro několik robotů. Také široký tmavý kanál mnoho robotů zastrašil a např. MarS to otočil o 180 stupňů.

kanál jako překážka

zlomené kolo

NDTeam

Tragické bylo toto kolo pro dosud vítěznou E_lišku z týmu Radioklub Písek. Neustálým přejížděním zlomila kolo a zbytek soutěže už nebodovala.

Naopak bodovaly NDTeam a nejvíce Kamaro Engineering. Ti měli problém s palubním počítačem, tak na robota přivázali notebook. A ten fungoval. Po zkušenostech odstranili z kódu návrat z cíle zpět do startu … a věřím, že kdyby to neudělali, tak se do toho cíle nedostanou. Jako jediní tedy dojeli mezi domy a úzkými uličkami po nábřeží až ke Kamennému mostu a tam skončili (poloměr detekce cíle měli 10m, tj. skončili cca 8 metrů od přesné pozice).

4. kolo

To se startovalo na široké silnici, dlažba a do kopce. Tyto podmínky především nevyhovovaly MarSu — malý robot neměl sílu utáhnout vozík s pivem a malá kolečka se protáčela zaseklá ve spáře mezi dlažkami. Kamaro zase bodoval a hodně. Myslel jsem, že pasáže do parku jsou dvě, ale oni našli třetí. Bohužel byla hodně úzká se stolky restaurace po obou stranách a lokální indikace byly nedostatečné. I tak cíl byl hned na druhé straně domu a celkově to stačilo na přesvědčivé vítězství.

Celkové bodování

Pořadí	Tým	1.kolo	2.kolo	3.kolo	4.kolo	Celkem
1.	Kamaro Engineering	0	12	385	221	618
2.	Radioklub Písek	148	74	0	-	222
3.	Smelý Zajko	122	0	3	31	156
4.	ARBot	0	28	12	86	126
5.	NDTeam	0	2	75	0	77
6.	MarS	44	0	2	0	46
7.	JECC2	26	0	0	9	35
8.	Istrobotics	4	-	17	2	23
9.	JECC	0	0	1	0	0

Workshop a PAIR'15

V neděli proběhl „klasický” workshop. Tentokrát byl v koordinaci se studentskou konferencí PAIR'15 (Planning in Artificial Intelligence and Robotics) organizovanou ČVUT FEL Praha. Překryv byl myslím užitečný pro obě strany: studenti se dozvěděli něco ze zkušeností účastníků Robotour a ti zase něco ze současného vědeckého bádání. Zvaná přednáška byla o Roboautu od Honzy Najvárka.

Technologie

Ze zajímavých technologií, co některé týmy letos zkoušely, byly:

Odroid (NDTeam, Istrobotics)
laser scanner z vysavače (Istrobotics, Kamaro Engineering)
FPGA (ARBot)
upravené BLDC motory v kole (Radioklub písek)

Roboauto

Milé zpestření soutěže byla návštěva Roboauta z Brna. Možná je pamatujete z dřívějších ročníků, kdy jejich roboti končili na předních pozicích. Teď už experimentují s upraveným autem Hundai i40 a malé demo předváděli po skupinkách robotikům v Písku. Pokud jste to propásli, netruchlete — budete mít ještě šanci na Robotem rovně 2016, kde je předběžná domluva účasti autonomního auta, které by samo projelo parkem .

Plány na Robotour 2016

Pokud vše dobře dopadne, tak příští ročník bude v Německu (Deggendorf) a plánujeme i drobné změny pravidel. Konkrétně bodované nakládání a vykládání sudu (50 bodů, pokud robot následně projede startovní čárou). Vedle sudu budou povoleny i 500ml plechovky, které si ale robot musí sám naložit (5 bodů za plechovku, max 10ks). Zachováme otočené pořadí startů (nejlepší startuje na konci).

kameraman

Istrobotics

JECC

Poděkování

Ještě jednou bych velice rád poděkoval Radioklubu Písek, za přípravu a skvělou realizaci výročního ročníku Robotour.

Pokud chcete soutěž nějakým způsobem podpořit nebo máte nějaké doplnění/dotaz, tak se nám prosím ozvěte pomocí kontaktního formuláře.

Představení týmů

2015-08-04T00:00:00Z

Týmy

YouTube playlist všech registrací

AmBot (CZ)

youtube https://youtu.be/y_J8i0tHYjw

Robot Ferda pro Robotour 2015 je upravené dětské elektrické autíčko ("ride-on"). Doplňkem je kontrolér na bázi Arduina s ATmega2560, který ovládá motory autíčka, využívá magnetometr jako kompas, tři sonary pro detekci překážek, čte data z externího GPS přijímače a komunikuje s bluetooth převodníkem (aby mohl reagovat na příkazy z nadřazeného systému). Tím nadřazeným systémem je smartphone s autorskou Android aplikací (RoboNav) pro GPS navigaci podle mapy (získané z OpenStreetMap) doplněnou o vizuální navigaci podle obrazu z kamery smartphonu (pro udržení se na cestě).

ARBot (CZ)

youtube https://youtu.be/DsKR7kcO96o

Robot je řízen vývojovou deskou Zedboard s SoC Zynq 7020 od Xilinx. K dispozici je 512 MB RAM, 32 GB SD, srdcem je dvoujádrový ARM Cortex A9 + NEON na 600 MHz a hlavně hradlové pole o 85 tisících logických jednotkách. Zedboard běží na Linuxu a jako hlavní programovací platforma je použito mono a jazyk C#.

Podovzek je diferenciální s 3. pasivním kolem. Modelářská kola o průměru 17 cm a dva motory PG36555126000-50.9K s enkodéry řízené profesionální jednotkou SDC2160 od Robotequ poskytují potřebnou trakci.

Pro lepší odečet pozice jsou použity dva optické odometry založené na ADNS 3080. Dalším smyslem je "hmat". Robot má dva taktilní FSR senzory integrované v předním nárazníku.

Osvědčená AHRS VN-100 od VectorNav poskytuje informaci o orientaci robotu. Globální informaci o pozici dodává GPS uBlox NEO 7M.

Robot je osazen dvěma sonary HC-SR04, které je možné natáčet pomocí serv.

Serva ovládá jednotka SSC-32.

Robot má stereoskopickou kameru s čipy Aptina MT9V032, které mají globální závěrku a jsou schopny pracovat v HDR režimu. Kamera je pohyblivá ve dvou osách pomocí serv.

Energii dodávají 4 LiFePo články o kapacitě 14.5 Ah chráněné SBM.

Šasí je postaveno z letecké 2 mm překližky a smrkových nosníků 7 mm. Prostě modelařina. Jednotlivé dily byly řezány laserem.

Istrobotics (SK)

youtube https://youtu.be/rTmW52ScBX0

Zaklad robota je upraveny RC model TRAXXAS E-MAXX (3903) vybaveny kamerou, GPS, sonarmi HC-SR04, IMU s 3D kompasom a magnetickym IRC. Zakladne senzory spracovava Arduino mega. Oproti minulemu roku sme nahradili tablet, ktory spracovava obraz a GPS za Odroid C1 s linuxom. Robot je naprogramovany v C++ a OpenCV.

JECC (DE)

youtube https://youtu.be/0WH-PPUnL6c

rozpoznávání obrazu pomocí webové kamery
SICK PLS 101 pro detekci překážek
embedded pc modul s Intel Core i7
DRV8432 motor driver

Kamaro Engineering (DE)

youtube https://www.youtube.com/watch?v=txRV6iRba_w

Našeho robota jsme si udělali celého sami, od mechaniky až po software. Robot má čtyři kola, dvě nezávisle zatáčené osy, jeden hlavní motor a váži cca 40kg. Robot byl především vyvíjený pro zemědělskou soutěž Field Robot Event. Spodní část SW je napsaná v C++, vyšší pak v C# a Javě. Hlavními senzory jsou dva LIDARy a kamera.

MarS

youtube https://www.youtube.com/watch?v=xDHrKi1u2z0

Robot je postaven na podvozku terénního RC modelu s nahonem 4x4.

K lokalizaci se využívají data z GPS a kompasu, která umožní následnou lokalizaci na mřížce. Z mřížky se vybere kandidát s nejvyšší pravděpodobností, který zároveň jistým poměrem převyšuje všechny ostatní, čímž je zajištěn výběr až ve chvíli, kdy si je robot svou polohou opravdu jistý.

Z vybraného vítěze se naplánuje cesta do cíle algoritmem A*.

Při průjezdu cesty se robot drží na cestě díky zpracování obrazu z čelní kamery. Zároveň pomocí odometrie a GPS odhaduje vzdálenost od křižovatky. Křižovatky řeší jednoduchým wall-following algoritmem, případně koriguje směr na základě azimutu.

NDTeam (CZ)

youtube http://youtu.be/2vXgi8JW6GU

Robot Robík:

hmotnost cca 20 kg bez sudu
řízen vlastní řídící jednotkou na bázi Cortex M3 (LPC1765)
9 DOF AHRS, GPS
Napájení 8S1P 5Ah LiPol
Credit card sized Linux computer Odroid U3 pro zpracování videa
OpenCV pro rozpoznání cesty
5x sonar pro vyhýbání překážkám

Radioklub Písek (CZ)

youtube https://youtu.be/Elczrq4C2Rw

E-liška má přibližné rozměry 95x60x48 cm a hmotnost je zhruba 40 kg. Palubní napětí 24V zajišťují 2 gelové akumulátory 12V/18Ah. E-liška má odpružený čtyřkolový podvozek s Ackermannovým řízením a pohonem všech čtyř kol, každé samostatnou pohonnou jednotkou.Pro letošní ročník jsme nahradili pohony zadních kol dvěma BLDC . Pro orientaci využíváme Lidar Sick , GPS a 9 DOF inerciální jednotku. Hlavní řízení robota zajišťuje notebook s operačním systémem Linux-Debian, řízení pohonů zajišťuje vlastní modul s STM32. Výkonové řízení řeší vlastní konstrukce H-můstků a 3f řízení BLDC motorů. Řídící navigační program je napsán v Pythonu .

Smely Zajko (SK)

youtube http://youtu.be/aixAzwEohaI

Parallax (Motor Mount and Wheel Kit), encoders, 2xHB25 motor drivers Sbot board (based on AVR ATmega128, low-level control board) PC ASUS UL30V (main control computer) 5x SRF-08 (ultrasonic sensors) GPS NaviLock NL-302U USB SiRF III Compass with tilt compensation (HMC6343) AVR ATmega8 (compass driver) Camcorder Panasonic SDR-T50 or webcam usual usb hub Power: HAZE HZS 12V 9Ah handmade wood & aluminium base red power switch and power circuitry

Pokud chcete soutěž nějakým způsobem podpořit nebo máte nějaké doplnění/dotaz, tak se nám prosím ozvěte pomocí kontaktního formuláře.

Field Robot 2015

2015-06-25T00:00:00Z

Přiznám se, že letos se mi na FREčko do Slovinska (kousek od Mariboru, cca 550km) moc nechtělo. V kombinaci s „trénovacími předvaděčkami” (alias Robotický cirkus) na akcích dnipola.sk a nasepole.cz mi fre2015 sežralo polovinu roční dovolené. Navíc Eduro dosáhlo svého vrcholu loni, kdy zvítězilo v celkové soutěži … co od toho chtít víc?

Asi hlavní motivací bylo oprášit kontakty na lidi, kteří se robotizací zemědělství zabývají. Akce se zúčastnily zhruba dvě desítky týmů z různých Evropských univerzit, tj. spousta nadšených studentů a zkušených mentorů.

Jsem rád, že si Jakub vzal za vlastní přípravu FireAnta a já se staral pouze o Eduro. Jako výzva mi pi přišla hlavně třetí úloha: detekce a mapování plevele (na hnědo nastříkaná kukuřice).

FireAnt

Rozpoznat zelenou kukuřici od zelené trávy vůbec nebylo triviální:

Pohled na políčko z RasPI kamery

Soutěž se totiž letos nekonala na klasickém poli, ale na „zámeckém trávníku”, kde byly vyvrtány díry pro květináče s kukuřicí.

Jakub pro rozpoznání kukuřice nakonec použil statistiku kontur: musí být dostatečně velké a když jich je více vlevo zatoč vpravo a obráceně. K mému překvapení tento přístup při testování fungoval překvapivě dobře . V ostrých jízdách to bylo horší, ale pak se ukázalo, že jednou v kódu „hnil” nějaký testovací krok a podruhé měl mravenec mechanické problémy s předním levým servem. Úspěšná autonomní navigace bez dotyku byla tedy až ve třetí úloze (viz video).

Během soutěžních dní Jakub na mravencovi intenzivně pracoval a finální algoritmus prý používal tři druhy korekce: mírné otočení s krokem vpřed, větší otočení s krokem vpřed a velké otočení s úkrokem stranou. Kód je na githubu, ale poslední verze je prý ještě pouze na mravencovi.

video z testování

Eduro

Eduro jelo na 80% pomocí loňského kódu. Novinka byl skript mapování pomocí frelog2map.py, který ze zalogovaných dat z laserového dálkoměru a výsledků zpracování kamery vytvořil mapku:

Eduro mapka

Vyžadovaný formát byl TIFF, rozlišení je pixel=1cm a červené tečky jsou poničené hnědé kukuřice. Eduro, na rozdíl od většiny robotů, jezdilo ob řádek a mělo vlastně nejlepší mapovací čas 1m:20s (který se nepočítal ).

Druhá větší změna, kterou jsme ladili z úterka na středu, byla detekce překážky. Listy kukuřice občas zcela zakrývaly výhled laseru a aby robot zbytečně nepanikařil, tak byla přidána detekce výstražného kuželu. Otázka byla, jak tyto dva zdroje zkombinovat, což se samozřejmě projevilo v ostré jízdě (viz video), kdy Eduro sice detekovalo spousta červené, ale zároveň dostatek místa na objížďku.

Průběh soutěže

Basic Navigation

V první úloze měli roboti systematicky projíždět jednotlivé řádky. Řádky lehce připomínaly symbol blesku (viz foto).

políčko pro Basic Navigation

. Mravenec měl velké problémy, přestože před tím podobnou řádku prošel bez dotyku, a tak počet trestných bodů převýšil odkráčené metry.

Pro Eduro to byla „klasika”, ale … vyrazilo a hned v prvním řádku špatně odbočilo. Restart naštěstí fungoval a pak už jelo bez problémů, čistě, bez zničené kukuřice a doteků. Bodově se umístilo na šestém místě a já začal silně pochybovat, že letos přivezeme nějakou cenu …

výsledky první úlohy

Mám pocit, že Jurij (organizátor) říkal, že první řádka je o něco užší, ale neověřoval jsem to. Po 180 stupňové otočce Eduro směřovalo do kukuřice a menší rozdíl byl o řádek dále:

špatné otočení na konci prvního řádku

Z logů to odhadem vypadá na cca 5*9 + 14 + 7 ujetých metrů, tj. 66 bodů - 2 z dotek. Oficiálně 62.5m a lepší Cornstar (domácí tým) měl 82m.

Advanced Navigation

Průběh druhé úlohy, kdy roboti měli jet podle vzoru S-3L-1R-2L-3L-5R-F, jsem už nakousl (letos dokonce předem prozradili, ve které řádce bude překážka a jak bude vypadat). FireAnt měl těžké problémy, protože běžel se špatným testovacím kódem — extra úkrok po každé korekci.

výsledky druhé úlohy

Eduro startovalo deváté a tak jsem viděl Banat robot, se strategií, která už mne několik let vytáčí: na konci řádku robota vzít a posunout ho do dalšího řádku podle vyžadovaného vzoru. Banati to navíc dotáhly do stavu, že robot na konci řádku automaticky zastavoval, aby se snáze chytal. 66 bodovaných metrů! Letos za špatný přejez byla malá penalizace a tak můj interní cíl byl porazit tuto „advanced” technologii. Štěstí nám přálo a přestože Eduro ujelo „jen” 59m (ono těch 66m byla asi celá trasa), tak s trestnými body za dotek Banaty porazilo a celkově získalo druhé místo .

Weed Detection

Ve třetí úloze jsem měl radost z obou robotů. FireAnt šel bez jediného dotyku (servo z nohy kluci prohodili za servo na ocasu), ušel několik metrů a dokonce analyzoval průměrnou barvu jednotlivých velkých kontur, klasifikoval obarvené kukuřice a vytvářel mapku.

Eduro jelo bez problémů a po zpětné analýze logů zjištuji, že detekovalo všechny nastříkané kukuřice! Bylo tam ale i několik (4) chybných detekcí, kdy teď na obrázcích vidím nohy rozhodčích — říkali, že šestou řadu kukuřice budou ignorovat (tam přímo rozhodčí šel vedle robota a v kombinaci s ostrým stínem vytvářel „temnou kukuřici”). Jak to nakonec vyhodnotili netušíme, ale třetí místo je pěkné .

Včera jsem koukal na obrázky a od této úlohy jsou všechny rozmazané. Že by nějaký záškodník?! … asi se povolil šroubek u ostření … ale proč bych na to šahal … nevím. Naší detekci to nijak neovlivnilo, ale obrázky nejsou moc pěkné na prezentaci :(.Tak alespoň těch 6 úspěšných detekcí (z vícenásobné detekce vybírám tu, kde si byl nejjistější):

… a ty špatné:

Ještě bych měl zmínit, že pro mapování jsem poprvé použil kompas (díky Standovi

hodnocení třetího úkolu

za nápovědu ). Přemýšlel jsem, jak ty jinak náhodně překřížené řádky narovnat a použití, již napsaného, Kalmanova filtru s kompasem byla nejpřímější cesta. Z dřívějších zkušeností víme, že s dešťníčkem se kompas choval úplně jinak, tak jsem měl připravené dvě různé „kalibrace” (jen pro nakreslení mapy z logu, pro navigaci se nepoužíval).

Free Style

Toto byla úloha, která se mi líbila nejvíce, ale porotu nijak neoslovila. Ono se sice později ukázalo, že mezivýsledky neměly být veřejné (naše ukázka byla úplně první) a sudí by je bývali upravovali/škálovali podle dalších, ale na mé depce to už nic nezměnilo .

Předváděli jsme současně všechny roboty co jsme měli: FireAnt pochodoval „v řádku”, tj. překážky ho mohli vychýlit z rovné trasy. Eduro se naučilo nový tanec spinner.py, kdy místo následování objektu kolem něho kroužilo. Konečně Heidi to vše pozorovala shora a snažila se navigovat na značku na Eduru. Možná trošku chaos??

Aby to nebyla taková nuda, tak se vše odehrávalo v proluce mezi zámkem a novou budovou, takže pro dronu s indoor krytem tam nezdravě foukalo. A na celé akci bylo wifin, že se to nedalo spočítat — spojení s dronou vypadlo asi 10x. Jaký to byl „tanec” je vidět z logu Heidi (růžové body odpovídají úspěšné detekci přistávací plochy, přerušovaná čára výpadek spojení):

Tanec drony

a určitou představu získáte i z Petrova videa:

Závěr

Akce se mi nakonec líbila — ano, přispělo k tomu druhé místo v celkovém hodnocení Edura, o které jsme se dělili s Dánským týmem (proto ta pilka na rozříznutí trofeje) a všeobecně velký zájem o FireAnta (dokonce se nám ozvala BBC, ale asi z toho nic nebude). Líbil se mi zámeček, okolí, příjemní lidé, dobře zorganizované … a nářky nad naší školou si nechám na jindy .

Foto

Video Eduro (Stanislav Petrásek)

Video Eduro (Petr Zábranský)

Field Robot Event: FireAnt and Eduro playlist

kontaktní formulář

Robotour 2015

2015-05-25T00:00:00Z

Pravidla

Pravidla pro pozemní roboty zůstavají stejná jako loni. K dispozici jsou v PDF formátu: česky a anglicky.

Jedinou změnou je startovní pořadí týmu do dalšího kola:

bodově nejlepší tým startuje na konci konvoje

Foto potenciálních průjezdů

Lokalita

Soutěž samotná bude na několika místech v centru Písku. Ohraničit to lze obdélníkem minlat='49.304811' minlon='14.1398335' maxlat='49.3107989' maxlon='14.1518927'. První start a homologace bude v místě blízko ulice "U Výstaviště" (49.308258, 14.143379) mapa.

Pokud chcete soutěž nějakým způsobem podpořit nebo máte nějaké doplnění/dotaz, tak se nám prosím ozvěte pomocí kontaktního formuláře.

Katarina

2015-01-28T00:00:00Z

Toto je další z fandorama blogů o testování a prvních zkušenostech tetokrát s Parrot Bebop drone (pracovní název Katarina … říkal jsem si, že to bude hukot a chtěl jí pojmenovat Katrina, ale pak se mi jí zželelo, dávat jí do vínku tolik destrukce)

Chcete-li si přečíst celý blog o rozchození Katariny podpořte tento projekt.

Stejně jako minidronu Jessica zapůjčil český distributor Parrotu. Díky

krabice

zabalená Katarina

rozměry

Zde je odpovídající fandorama link:

http://fandorama.cz/projekty/921778164/katarina-bebop/

p.s. jsem zvědav, jestli Bebop české publikum zaujme, nebo mi náladu budou muset zase zlepšovat Japonci (viz Jessica github Stargazers)

Odkazy:

Stránky českého prodejce: http://www.icornerhightech.cz/
Parrot Bebop
Parrot Bebop Drone Hacking
ARDroneSDK3

Blog

31. leden 2015 — Hukot i bez létání

Dnes jsem Bebop/Katarinu poprvé zapnul. A byl to hukot . Zatím nikoliv od vrtulí, ale nejspíše od chlazení řídícího počítače. Budí to respekt.

Kryt a čepice

Aplikace Free Flight 3 (FF3) se mi odmítla nainstalovat na pracovní tablet (prý pro nedostatek místa), ale na telefonu běžela. Raději jsem ji rovnou upgradeoval — skoro to vypadalo, že ta starší verze podporovala pouze Rolling Spider a'la Jessica a Jumping Sumo. První obrázky z kamery krásné, ale kam se uložily zatím netuším.

Jako první příručku jsem použil Parrot Bebop Drone Hacking. Potvrzuji, že i u Parrotu mají vývojáři rádi číslo 42, tj. IP drony je 192.168.42.1. Fungoval telnet, podíval jsem se do ftp zóny a přečetl si i pár NMEA vět z GPSky:

/ # cat /dev/ttyPA1
GNRMC,104229.986,V,0000.0000,N,00000.0000,E,0.00,N,00000.0000,E,NNN,00,,-18.0,18.0,,,V*64
GNGST,104229.986,,,,,,,*5C
GNGSA,A,1,,,,,,,,,,,,,,,,1*1D
GPGSV,3,1,12,01,84,173,31,07,66,244,1,63,176,,04,54,145,,1*6A

Celkem mne navnadil popis „černé skříňky” (/data/ftp/internal_000/blackbox), která podle všeho obsahuje stejné informace jako stará AR Drone 2 jen v trošku jiném formátu (129 sloupců dat logovaných na 200Hz).

Klasická otázka: „jak to vypnout?” … viz fórum pro nováčky — stačí zadní tlačítko krátce zmáčknout.

Katarina se po spuštění FF3 chtěla rovnou automaticky kalibrovat. Předpokládám, že je to sekvence jako u staré drony, tj. tanec ve vzduchu s otáčením o 360 stupňů. Na to teď tady není prostor, tak možná později venku.

Zkoušel jsem ještě, zda funguje video kanál jako dříve a zatím neúspěšně (nefunguje ani port 5555, ani 5553 ani 43210).

6. únor 2015 — github

Musím přiznat, že psaní české verze mi jde nějak ztuha. Proč? No když jsem zveřejnil i anglickou verzi, tak mi do dvou hodin přišel mail od Darryla (amík?), že narazil na stránky spíše omylem přes Jessicu a jak je to skvělé, že si s tím hraji a jak je SDK od Parrotu nečitelné atd.

Tady vůbec netuším, zda někdo Bebopa má a z nedávných zkušeností soudím, že o to moc zájem není/nebude.

Ve zkratce: podařilo se mi s dronou navázat spojení, jsem schopen dekódovat většinu zpráv co posílá, ale zatím jsem ještě nevzlétl ani nezískal video/foto.

https://github.com/robotika/katarina

18. únor 2015 — viz anglická verze

Již moc nevěřím, že by prošel tento fandorama projekt. Aleš, kterému díky za mail s komentáři, má asi pravdu, že je to relativně drahá hračka a moc nadšených českých robotiků si jí nekoupí (25kkč s dálkovým ovládáním do 2km, nebo 14kkč jenom Bebop samotný).

Nabídka navíc neustále roste (Aleš zmiňoval ZANO, s úspěchem na Kickstarteru), takže to je těžké.

Možná někteří z vás zaznamenali, že blog v angličtině obsahuje řádově více informací … tak pro ty ostatní, kteří přišli později … viz anglická verze.

Katarina už umí číst video stream, na rozdíl od ARDrone2 je kombinovaný s navigačními daty, umí potvrzovat přijaté zprávy a je skoro připravena na první autonomní takeoff().

první úspěšně přijatý video frame

23. únor 2015 — Fandorama

To mi to Ondra zavařil!!! Už jsem za tu dobu zapomněl, že není dobré dávat konec fandorama projektů na víkend. Banky nefungují a čítač nezobrazuje aktuální stav konta. Katarinu jsem zrušil z titulní stránky … a teď bych jí měl zase vrátit. Zatím netuším přání jejího jediného stoupence.

Jaký je stav? S ARDrone3 už se lze létat s kódem na githubu. Je to celkem adrenalinová zábava. Přestože jsem v obýváku vyklidil nábytek, aby se dalo testovat, tak v hover-stavu opakovaně „plavala” nalevo. Že je to opakovaně mi došlo až časem — vyřešil to trim() před startem.

Příklad kódu:

robot = Bebop()
robot.videoEnable()
robot.trim()
robot.takeoff()
robot.land()

ARDrone3, na rozdíl od předešlé verze, pracuje trošku jinak s videem. Zatím co na Heidi stačilo otevřít TCP spojení a číst, Bebop, Rolling Spider a Jumping Sumo řeší vše přes jedno jediné spojení. Video je opět posíláno v H.264 codecu, ale každý I nebo P frame je rozkouskován až na 128 dílů velikosti cca 1kB. Je nutné se starat o jejich setřídění a potvrzování. To je realizováno 128bitovým číslem, kdy přijaté díly mají nastavenou jedničku. Tak toto mi už celkem pěkně funguje.

Video lze zatím přehrávat pouze off-line pomocí play.py … není zapojena žádná funkce, která by kousky skládala za letu a předávala procesu na zpracování obrazu.

Ke droně se lze připojit také telnetem a ftp. Z toho co jsem viděl mne zatím nejvíce dráždí adresář scripts … že by bylo možné přímo na dronu uploadovat nějaké prográmky?! To by bylo něco.

O čem teď bloumám je rozpoznávání a sledování dvojbarevné čepice:

týpek v čepici

Nápady jsou vítané . Důležitá je určitě kombinace oranžové se zelenou, ale jestli nejprve všechny pixely klasifikovat a teprve pak hledat přechody??

25. únor 2015 — Čepice a capdet.py

Dnes jsem zaspal, tak alespoň krátce …

Začal jsem experimentovat s detekcí dvojbarevné čepice. Používám pravidlo: „když nevíš, zkus něco triviálního”, tj. koukám jak vypadají barvy čepice vůči okolí.

Vzpomínám si, jak na workshopu Robotour 2014 Jirka mluvil o důležitosti klikacích nástrojů … a tak jsem si také jeden vyzoušel capdet.py, který zobrazoval všechny výskyty dané barvy a po drobné úpravě i barvy z blízkého okolí definované poloměrem (spíše polovinou strany krychle) rad=10.

pracovní obrazovka

Na této obrazovce (nerad dělám celoobrazovkový "PrintScreen", ale tady mají smysl všechny čtyři okna), je vidět původní obrázek vpravo nahoře, jeho HSV konverze vlevo nahoře, pak dosud naklikané barvičky a v pravo dole "terminal", kam se vypisuji souřadnice a hodnoty barev. Troufnl jsem si rozlišovat zelenou od oranžové: pokud je barevná složka v G větší než R a B, tak je to zelená, jinak oranžová:

if col[1] > max(col[0],col[2]):
    imgResult[mask] = (0,255,0) # green
else:
    imgResult[mask] = (0,128,255) # orange

Za zmínku asi také stojí bitové operace nad NumPy polem, konkrétně np.logical_and:

maskB = np.logical_and( imgB < col[0]+rad, imgB > col[0]-rad )

… toto vytvoří Boolean pole, kde True je pouze u prvků z daného okolí v modré složce.

Jinak s NumPy maskou jsem si včera odpoledne trošku naběhl (bylo to na robotu Husky a kód pro Follow Me, případně video). Ona ta maska z vícerozměrného pole udělá jednorozměrné a operace jako arr[mask].min() jsou v pořádku, ale běda u arr[mask].argmin(), která vrací index, kde se daný minimální prvek vyskytuje:

>>> import numpy as np
>>> a = np.array([2,0,3])
>>> a
array([2, 0, 3])
>>> a.argmin()
1
>>> mask = a > 0
>>> a[mask].argmin()
0
>>> a[mask].argmax()
1

Je to pořadí prvku, které splňují danou masku. Rozhodně tedy pak není dobrý nápad slepě usuzovat na pozici prvku z návratové hodnoty, když nevíte kolik prvky bylo „odmaskovaných” …

Co se detekce čepice týče, tak jsem ještě přemýšlel, jestli by nestačilo hledat oblasti s dominancí červené a dominancí zelené a jejich přechody. Ale to by asi byly moc velké plochy??

Ještě jsem nezmínil proč to HSV (hue-saturation-value). To je zatím příprava. Skoro v každém článku se dočtete, že dělat min/max barev v RGB není dobrý nápad, ale že v HSV to dopadne celkem rozumně. Možná si vystačím i bez toho, nevím.

26. únor 2015 — Kontury čepice

Dnes to není žádná krása (viz diff), ale nechť to jsou ty třísky co lítají při kácení lesa. Původní klikátko capdet.py jsem teď „lehce” zašpinil několika natvrdo vybranými barvami oranžové a zelené — ano, mohl jsem to číst ze souboru … a asi měl. Šlo mi o to, abych rychle měl stále stejné zadání a mohl experimentovat.

Co tím hackováním zkouším? Myšlenka je následující:

pro vybrané oranžové a zelené barvy vytvořím černobílou masku
trošku jí nafouknu pomocí dilate, aby se mi spojili jednotlivé díly čepice
hledám kontury, kde mne zajímají jen bílé objekty (s tím jsem si myslím už jednou naběhl, když byl daný objekt na hranici obrázku … no uvidíme … mluvím o oriented=True)
pro danou vyplněnou konturu spočítám podíl oranžové barvy

Příklad:

Detekované kontury

Výsledky [plocha, počet oranžových, podíl oranžových]:

3139.5 1854 0.590539894888
51.5 3 0.0582524271845

Na první pohled to nevypadá špatně. Asi bych mohl odfiltrovat malé body pomocí erode(), ale bojím se, abych nepřišel o „švy” čepice. Plán je vylepšit klasifikaci barev a pak to pustit na testovací videa. Výsledkem by měly být odhady na požadovaný podíl barev (59% mi přijde pěkné) a nějaké min/max velikosti. V dalším asi mohu zkoumat pod-objekty, případně tvar čepice. To asi ale nechám až narazím (viděl jsem včera v květinářství krásný protipříklad barevných mističek pod květináč … to by Katarinu určitě spletlo).

Jinak z poznámek pod čarou — nepodařilo se mi rozumně nakreslit masku kontury, tak jsem jí nejprve nakreslil do šedotonového obrázku a pak definoval jako mask = tmpMask > 0. Ono by to asi šlo, ale ty bitové obrázky nutně nefungují všude (pamatují Honzu a pokusy s RasPy na SICK Robot Day 2014).

Co se mi ale zase celkem líbilo je počítání oranžových pixelů pro danou oblast. Rozhodnutí, zda je pixel zelený nebo oranžový dělám porovnáním R a G složky:

cmpRG = imgR > imgG
orange = np.count_nonzero(np.logical_and( mask, cmpRG ))

kde mask je vybraná oblast kontury a imgR a imgG jsou výsledkem cv2.split(img).

27. únor 2015 — Editace barev z videa

Včera večer jsem brousil nástroje. Nejprve jsem upravil hack s tabulkou barev a předělal to na externí soubor (diff), který podporuje i komentáře a mix copy a paste barev s čárkami a '[' a ']'.

Poté jsem to skoro celé smazal a přeházel (diff), aby detektor byla pouze jedna jediná funkce a mohl jsem zkoušet chování na videu. Barvy stále používám jako vzorky s okolím, tj. pole barev, které nejprve v obrázku „vybarvuji”. Je to možná pomalé, ale umožňuje mi to lepší editaci — mezerníkem zastavuji video, klikáním přidávám barvy a Backspace odebírám poslední přidanou barvu. Barvy se vypisují do terminálu, takže je můžu, když chci, snadno přidat do vzorového souboru cap-colors.txt. Konečně přes ESCape, lze program předčasně ukončit.

Asi největší problémy dělají tmavé barvy, resp. tam pro jejich okolí přibude příliš mnoho kandidátů. Zvažuji, zda detekované jasné barvy pak ještě nenafukovat „hraničními”, ale … není to teď kritické. Důležité je to rozběhat za letu, to znamená poskládat a utřídit H.264 kousky a získat obrázek. Na to ale budu muset zatáhnout do projektu Céčkovou knihovnu (použitá byla už na Heidi-cvideo). Dříve se mi nepodařilo OpenCV přesvědčit, aby akceptovalo postupně buffery s daty :-(. Na druhou stranu jsem včera zjistil, ze i obyčejný JPEG snímek lze otevřít jako video. Po pravdě IF jsem tam nakonec přidal (kód), protože video jsem chtěl rovnou spustit přehrávat, ale jednotlivé snímky „pustit zastavené”.

Teď bych revidoval příjem videa. U každého je výpadek a následná duplicita několika paketů, tak jestli tam nemám ještě nějakou chybu. Následně chybí i několik snímků — že by Python nestíhal vyčítat data po síti? Nebo je třeba posílat ještě nějaké extra časové známky??

1. březen 2015 — Víkendové testování

Přemýšlím, co z toho je zveřejnitelné. Vzpomínkám dominuje poslední start, než v neděli začalo pršet: Katarina se vznesla, hodila assert (kterého jsem si nevšiml), přesunula se nad svah a jabloně, udělala jarní řez bříze a spadla vrtulemi směrem dolu. Asi. Byl jsem tak konsternovaný, že tento detail si už pořádně nevybavím.

Když jsem kód opravil (ty asserty se hodí při ladění, ale v letu to fakt není dobrý nápad) (diff), tak už lilo :-(, takže základní poletování nahoru a dolů jsem v reálu funkční neviděl.

A co se tedy stalo? Drona poslala zprávu ARCOMMANDS_ID_PROJECT_COMMON = 0, na kterou jsem měl assert, abych si jí všiml, až nějaká bude. A jak vidíte, trvalo to skoro měsíc, než přišla první! Navíc její obsah mne dost zklamal:

02 7F 61 0D 00 00 00 00 05 07 00 D4 FF

tj. ARCOMMANDS_ID_COMMON_COMMONSTATE_CMD_WIFISIGNALCHANGED s popiskem RSSI of the signal between controller and the product (in dbm). Ta hodnota byla 1280 a vůbec netuším, co tím autoři chtěli říci.

Že se mírně odsunula nad svah mohla být zase nepřesná kalibrace, přeci jenom ta tráva není úplně v rovině. Zvláštní ale bylo, jak se drona zvedla ještě více do výšky — myslel jsem, že běží můj kód, ale spíše detekovala koruny stromů sonarem/spodní kamerou a upravila to na 1 meter „nad”.

Přemýšlím, zda uploadovat to video … ona jedna z věcí, co jsem o víkendu rozchodil bylo zapínaní automatického nahrávání, tj. i když jsem ztratil komunikaci sama dál nahrávala co se děje (autorecording diff). Vtipné je, že na tom videu není pád vůbec vidět!!! Ta softwareová kompenzace náklonu si s tím poradila. Už jsem to viděl na tomto videu, kdy drona dělá kotrmelce a z nahrávaného videa to nepoznáte …

Ne, není to publikovatelné … zas taková sranda to není (let trval 15s), sigh. Ale přežila to a vypadá, že i bez větších šrámů … padla do trávy.

A co jinak? Začaly mi chodit GPS data, dokonce debug info o počtu satelitů (diff). „Indiáni” jsou v pořádku, tj. GPS souřadnice dávají rovnou smysl.

Udělal jsem také několik fotek pomocí drone.takePicture() — ukládají se zase lokálně a mají rozlišení 4096x3072. V názvu souboru je datum a čas, který se ale z GPS automaticky neupravuje, tj. 1/1/1970.

2. březen 2015 — metalog.now()

pohled z drony na krabici

Dneska jsem nějaký unavený. Zadrátoval jsem do startovní konfigurace nastavování času (diff), protože už mne štvalo, že je vše z roku 1970 a není tedy poznat co je nové a co staré. Zlobilo nějak nastavování času — má tam být prý ISO-8601 formát, ale asi zlobily milisekundy. Naformátoval jsem si to tedy po svém a už to funguje. Zde je příklad snímku Bebop_Drone_2015-03-02T201736+0000_.jpg.

Možná za zmínku stojí to zjištění aktuálního času a data. Kdybych to používal ze systému pomocí datetime.datetime.now() tak se mi rozbije přehrávání logů. A na to jsem hrozně alergický . Řešení je logovat i každý podobný dotaz (zavolám ho 1x, takže to není žádné drama) a nechal jsem třídu MetaLog, aby se o to starala. A funguje to dobře.

Do gitu jsem také dal ignorování assertu při parsování dat (diff). Jestli jste četli report ze včerejška, tak tušíte proč. Ono ty asserty jsou užitečné, ale jenom když si pak log v klidu přehrávám, tj. možná try..except ještě obalím podmínkou, zda přehrávám … ale možná ne.

Začal jsem ráno také pracovat na integraci všech kousků (zatím jedno-vláknitě), ale více o demo.py až to začne něco dělat …

p.s. Pavel S. mi poslal video o automatickém přistání Ardu Copter — jó, to by se mi také líbilo … lepší než větve břízy.

3. březen 2015 — roll, pitch a yaw

Kdy já už se konečně naučím, co z toho je co? Dnes jsem lítal ve škole. Nakonec jenom po budově a to ještě malinko, ale … nějaký mikro-progres je snad vidět.

Začal jsem s triviálním testFying:

robot.trim()
robot.takeoff()
robot.flyToAltitude( 2.0 )
robot.wait( 2.0 )
robot.flyToAltitude( 1.0 )
robot.land()

Při prvním pokusu to spadlo ve funkci wait(). Volal jsem tam self.update() bez parametrů, které ale byly vyžadované. Chytnout, otočit vzhůru nohama (naštěstí do dvou metrů dosáhnu), fix a znova.

Při druhém letu to spadlo na klesání:

File "M:\git\ARDroneSDK3\katarina\commands.py", line 39, in movePCMDCmd
    return struct.pack("BBHBBBBBf", 1, 0, 2, flag, roll, pitch, yaw, gaz, psi )
struct.error: ubyte format requires 0 <= number <= 255

No jo no, mají tam být znaménkové bity (diff).

Jako další test jsem chtěl nahrát let chodbou. Nevím jaká je má skrytá motivace, ale drona co systematicky prolétává koridory a straší děti mi asi přijde cool . Ale chyba lávky. Nějak mi zlobí nahrávání videa. Když jsem koukal přes telnet na velikost volného místa, tak vše bylo zaplněné — asi ty pády programu z předešlých testů. Prostě to stále nahrávalo video, dokud nedošlo místo??? Teď je vhodná chvíle na revizi všech logů …

školní chodba

Jo a ten titulek! Já si stále nepamatuji, co z těch třech slov je náklon dopředu … mám i pocit, že na toto téma už je na robotice stažený pěkný obrázek … tak nevím, asi myslím ten z wikipedie. Ono když mi Katarina systematicky uhýbala vlevo, tak jsem zkusil změnit druhý parametr a pak už letěla skoro rovně vpřed.

První log bez videa — ani ťuk zajímavosti :-(. Tedy alespoň je vidět, jak se mění rychlost, takže bude možné doplnit nějakou „pseudo-regulaci”.

Tak obráceně — poslední log se záznamem videa … prostě ho přestal v půlce letu posílat, bez jakékoliv notifikace :-(. Tomu moc nerozumím.

4. březen 2015 — opraveno nahrávání videa

Ano, byla to samozřejmě moje chyba. Pustil jsem si teď dronu „na dobrou noc” s tím, že jsem zrušil automatické spouštění videa ve startovní konfiguraci a změnil to na ruční zapnutí při takeoff() a vypnutí u land(). Přidal jsem testovací rutinu … a nic. Nic to nenahrálo, ale na /data/ftp/internal_000/Bebop_Drone/media/ leželo divné video, které jsem tam včera neviděl. Prostě po prvním startu se spustilo nahrávání a nahrávalo se dokud jsem to nevypnul. Je tam tedy i krátký (poslední) let chodbou:

A jakou chybu jsem udělal? Pro zapínání a vypínání videa je enum, což ale znamená 4 bajty :-( … a já tam měl jenom jeden bajt (diff).

5. březen 2015 — OpenCV okno

Dnes jenom takový „štěk”, něco jako rada, že není dobré si svítit zapálenou sirkou, aby jste zjistili, kolik máte v nádrži benzínu … prostě věděl jsem to, přišel domu unavený, ale zkusil alespoň jednou odstartovat než bude moc pozdě … a zapomněl na dříve „potenciální”, později „reálný” problém s otevřeným OpenCV oknem přehrávajícím živé video.

Modří už tuší, co červení? Jo, to okno převezme focus, takže pak můžete mačkat ANY KEY a žádný Emergency STOP se nekoná. Ono by stačilo si prohodit okna, ale v těch pár sekundách (cca 1.5s) člověk moc racionálně neuvažuje. Reflex už byl vystartovat po droně než narazí do topení a otočit ji vzhůru nohama. Teprve pak mi došlo, v čem byl problém.

9. březen 2015 — video problémy

O víkendu bylo krásně a zbylo i trošku času na létání. Chtěl jsem znova zkusit demo.py, které by sledovalo kšiltovku. V první variantě Katarina vzlétne a jenom „pohybem očí” sleduje cíl z místa. Ve druhé variantně se pak za cílem otáčí.

V realitě to bouchlo už při prvním startu:

File "M:\git\ARDroneSDK3\katarina\bebop.py", line 106, in update
    data = self._update( createVideoAckPacket(data) )
  File "M:\git\ARDroneSDK3\katarina\navdata.py", line 321, in createVideoAckPacket
    assert fragmentsPerFrame < 64, fragmentsPerFrame # lazyness, to get started
AssertionError: 81

… ta lenost je hrozná věc . Navíc oprava byla hotova a vyzkoušena za pár minut (diff) … ale ono dříve bych neměl testovací příklady. Tady byly a bylo jich hodně. Hned další let přišel snímek 69, 74 a mám pocit, že jsem viděl i 92 dílků. Vypadá to, že oprava funguje a dostávám celé i velké snímky (typicky I-frame).

Co je tedy problém? Přestávalo mi chodit video. Podle logů jsem udělal 10 pokusů. Selhání u prvního pokusu je jasné — je fakt, že nahrávání se spustilo a díky assertu už nevypnulo, tj. trošku delší 1.4GB video.

Druhé video chybí, ale podle časů ve jménech souborů vidím, že příkaz stop video funguje. Stejně tak se i video průběžně posílalo ke zpracování. OK

Třetí video by bylo bývalo v pořádku, až na detail při přistání. Katarina nalétala trošku na skleník (ano, po minulém víkendu jsem se poučil a testuji jenom na „robo-louce”) a tak jsem přistál. Přistála ale asi do 10cm trávy a nechtěla se vypnout. V logu jsou nepříjemné hlášky jako:

Altitude -0.50595164299

Asi by to chtělo trávu posekat nebo alespoň naučit Katarinu se vracet na místo/základnu …

Po tomto pokusu jsem dronu zvedl a „zakroutil jí krkem” — ano myslím tím otočením vzhůru nohama, emergency a STOP. Hele, jestli právě toto není důvod, proč mi pak neposílá video??! Ne, v následujícím pokusu ještě pár (doslova, 2x I-frame a 5+1 P-frame) snímků poslala. Je fakt, že 71-dílný snímek posílala ve třech průchodech (normální, opravy a opravy oprav) a následující P-frame musela také opravovat:

…
Video 48 1 64 71
GPSDebugState, numSat = 8
Video 49 0 0 12
Video 49 0 1 12
Video 49 0 2 12
Video 49 0 3 12
Video 49 0 4 12
Video 49 0 5 12
Video 49 0 6 12
Video 49 0 7 12
Video 49 0 8 12
Video 49 0 9 12
GPSDebugState, numSat = 6
GPSDebugState, numSat = 6
GPSDebugState, numSat = 7
GPSDebugState, numSat = 7
GPSDebugState, numSat = 7
Video 49 0 0 12
Video 49 0 10 12
Video 49 0 11 12

… trošku to vypadá, že GPS status to rozhodí a pak už nepřišlo nic. Nikdy, až do vypnutí a testu druhý den. Je tedy potřeba video znova povolovat?? I v dalším logu na začátku vidím Video Enabled State 0 enabled (je to enum, kde hodnota 0 znamená enabled), tj. vše by mělo být OK?!

Druhý den jsem přidal nastavování konfigurace, že jsem venku a používám ochranný štít (diff), ale přišlo mi, že to stabilitě nijak nepomohlo.

Teď koukám na první pokus z neděle a tam je dokonce 101 dílků … jo, asi bylo opravdu na čase přejít od 64-bit potvrzování na 128-bit. Je zvláštní, jak je ten indoor fádní a bohatě si s 64 bity vystačí.

Ono to jenom vypadalo, že to funguje. Video přestalo posílat po skončení takeoff(). Pak další dva starty nic a teprve po výměně baterky zase chvíli pár snímků :-(.

Picture State Changed: 1 0

Co tím autor míní? A přišlo to cca 10x krátce po poslání příkazu k odstartování. Nevím. Podle ARDrone3_commands.xml to znamená, že v PictureStateChanged 1 if picture has been taken a ta 0 je Mass storage id where the picture was recorded … ale já žádný snímek nedělal?! Myslí automatický náhled pro video??

V tomto posledním pokusu se spojení „kouslo”. Přestaly chodit data. Aktuální plán je odsunout video zpracování do vlastního procesu a přidat timeout na spojení, i když zatím nevím co dělat pokud k němu dojde.

9./10. březen 2015 — Hledá se Bebop (Blansko)

Dnes jsem dostal první česky psaný mail od jednoho majitele Bebopa . Bohužel možná bývalého :-(. Radimův Bebop totiž uletěl (na severu Blanska). Netuším kolik lidí z této oblasti čte robotika.cz … asi 0. Pokud přeci jenom někdo najdete Bebopa, dejte mi vědět a přepošlu mail majiteli …

V první fázi mi zamrazilo, jestli nebyl řízen mým kódem … ale asi chyba Free Flight 3. Spojení se přerušilo v náklonu a Bebop uletěl přes pole … a po minutě asi došla baterka. Nebo si špatně definoval Home. Darryl také psal: Since the latest Firmware update from Parrot, GPS, with the associated "Return-To-Home (RTH)" feature have become unreliable/unusable, and has even caused several "fly-a way's" according to the forum. It's hard to say exactly where the issues are, either Firmware, or Free Flight App, but I have a feeling it's actually the Free Flight App. … těžko říci, jenom papouškuji.

11. březen 2015 — Fórum - Holy Crap!

„Trošku” se trápím s tím H264 kodkem pro Katarinu a tak jsem si dovolil (a to jsem si asi dovolil dost) pro zlepšení nálady „hodit návnadu” na britské fórum Parrotu. Nešťastník se sháněl po dokumentaci a tak jsem ho odkázal na github Katariny. No a před chvílí se ozval EnderFFX, že to četl a dal na americké fórum … titulek „Holy Crap, Details about Bebop Protocol, did anyone notice ?” … je čas jít se psem a spát.

15. březen 2015 — Oriented Roundel

Američan, Čech, Němec, Mexičan, Angličan, Francouz … možná to trošku přerovnat a byl by to pěkný úvod k nějakému vtipu . Nedělám si iluze, ale třeba se nakonec najde někdo na světě, kdo ten kód také zkusí. V každém případě při vzpomínce na Darrylův komentář na americkém fóru se musím vždy zasmát (až to přejde v záchvat kašle).

Něco nového? Poskládal jsem „dokument” Parrot Bebop Protocol — je to spíše přehled základních informací, co jsem o Bebopu/Katarině zjistil. Asi je to lepší začátek než odkazovat na Pythonovský kód, resp. takové doplnění, které v oficiálním SDK zatím stále chybí.

Víkend propršel a tak jsem udělal pár pokusů doma. Konkrétně se vracím k dva roky starému problému přistání. Chci použít Oriented Roundel k definici přistávací základny. ARDrone2 ho automaticky detekovala a posílala jeho pozici, ale pro novou dronu to bohužel neplátí. Nechci už přepínat na spodní kameru (resp. mám pocit, že to u ARDrone3 vůbec nejde), tak alespoň pár pokusů s

drone.moveCamera( tilt=-100, pan=0 )

Oriented Roundel z jednoho metru s MSER detekcí

Jenom pozorování, že dokud drona neodstartuje, tak stále posílá nulovou rychlost a výšku, ale úhly jsou snad aktualizovány. V prvním testCamera(), kdy jsem jenom sbíral obrázky data o pozici nebyly. A klasicky, když jsem odstartoval, tak jsem zapomněl sklopit kameru dolu [ale jó, když jsem stáhl videa a vše vypnul tak mi to došlo].

Přemýšlel jsem, kam takovýto kousek kódu dát. Až bude fungovat, tak asi nebude úplně triviální a zároveň by to mohla být poslední scéna po běžném letu, nebo jenom na nějaké tlačítko by se snažil chvíli hledat značku a teprve pak přistál … Je to vlastně behavior z tří-vrstvé architektury, kterou jsme na přednáškách před mnoha lety doporučovali, ale prakticky asi nikdy moc nepoužili. Tož adresář behaviors (je pěkné, že když na githubu do adresáře dáte README.md, tak ho automaticky zobrazuje za seznamem souborů).

Kód navigace na krabici zatím nic nedělá. Volá na snímky osvědčený MSER a pak získané kontury aproximuje obdélníkem a časem i kruhem. Z trojkombinace „klíčové dírky” by už snad vypadl jen jeden kandidát. No zatím mám problém ho vůbec vidět.

Naházel jsem tři pokusy do jednoho videa, jestli si chcete udělat lepší představu, co drona vidí, když se kouká (kamerou směřující dopředu) směrem dolů . Možná značku trošku posunu a budu startovat kolmo na oba symboly … ještě nevím. Nějaké nápady?

16. březen 2015 — BlackBox a NavData

To „zakázané ovoce” je vždycky problém … v případě Kateřiny Bebopové je to modifikace souboru /data/dragon.conf. Jsou tam takové položky, kterým prostě nelze odolat . Odkaz na zdroj jsem dával už na začátku tohoto blogu, ale včera jsem narazil ještě na zmínku na americkém fóru a to už bylo moc. Cvičně jsem nastavil jak blackbox_enable tak i navdata_enable na true.

BlackBox fungoval. Vznikl soubor light_run_0, který během pár minut měl 53MB. Pak jsem zkoušel blackbox_to_csv.py (parametry nejsou úplně zřejmé … –csv <filename>). Vznikl podobně veliký CSV soubor s 129ti sloupci: index, time_s, sensor_acc_raw_x_m_s2, sensor_acc_raw_y_m_s2, sensor_acc_raw_z_m_s2, sensor_gyro_raw_x_rad_s, sensor_gyro_raw_y_rad_s, sensor_gyro_raw_z_rad_s, sensor_mag_raw_x_mG, sensor_mag_raw_y_mG, sensor_mag_raw_z_mG, phi_EST_rad, theta_EST_rad, psi_EST_rad, gyro_filt_x_rad_s, gyro_filt_y_rad_s, gyro_filt_z_rad_s, p_EST_rad_s, q_EST_rad_s, r_EST_rad_s, acc_x_EST_m_s2, acc_y_EST_m_s2, acc_z_EST_m_s2, speed_horiz_x_m_s, speed_horiz_y_m_s, speed_horiz_z_m_s, sensor_ultrasound_height_m, sensor_pressure_Pa, height_EST_m, height_vision_m, sensor_vision_speed_x_m_s, sensor_vision_speed_y_m_s, sensor_vision_speed_z_m_s, phi_REF_rad, theta_REF_rad, psi_REF_rad, p_REF_rad_s, q_REF_rad_s, r_REF_rad_s, r_wanted_rad_s, motor_cmd_pitch, motor_cmd_roll, motor_cmd_yaw, height_REF_m, height_REF_filt_m, speed_z_REF_m_s, motor_cmd_height, motor_cmd_ff, motor_cmd_1_rpm, motor_cmd_2_rpm, motor_cmd_3_rpm, motor_cmd_4_rpm, controler_state, acc_bias_x_m_s2, acc_bias_y_m_s2, acc_bias_z_m_s2, gyro_bias_x_rad_s, gyro_bias_y_rad_s, gyro_bias_z_rad_s, gyro_unbias_x_rad_s, gyro_unbias_y_rad_s, gyro_unbias_z_rad_s, speed_body_x_m_s, speed_body_y_m_s, speed_body_z_m_s, sensor_imu_ref_temperature_degC, sensor_imu_obs_temperature_degC, sensor_barometer_temperature_degC, battery_dV, motor1_obs_speed_rpm, motor2_obs_speed_rpm, motor3_obs_speed_rpm, motor4_obs_speed_rpm, BLDC_error, BLDC_motors_fault, BLDC_status, BLDC_temperature_degC, calage_x_rad, calage_y_rad, biais_pression_m, use_US, estimator_drone_position_m_x, estimator_drone_position_m_y, estimator_drone_position_m_z, estimator_psi_fused_rad, sensor_ultrasound_id, vision_indicator, sensor_ultrasound_mode, magneto_bias_x, magneto_bias_y, magneto_bias_z, magneto_radius, sensor_gps_flags, sensor_gps_latitude_deg, sensor_gps_longitude_deg, sensor_gps_altitude_m, sensor_gps_speed_m_s, sensor_gps_bearing_deg, sensor_gps_accuracy, sensor_gps_num_svs, sensor_gps_used_in_fix_mask, heading_magneto_rad, magneto_calibration_state, altitude_pression_m, altitude_pression_filt_m, dynamic_model_b, dynamic_model_f0, dynamic_model_Cz, dynamic_model_rpm_eq, psi_VIDEOREF_rad, airspeed_body_x_m_s, airspeed_body_y_m_s, airspeed_body_z_m_s, wind_body_x_m_s, wind_body_y_m_s, wind_body_z_m_s, stateFlightPlan, gpsDeviationPostionErrorLat_m, gpsDeviationPostionErrorLong_m, gpsDeviationPostionErrorAlt_m, gpsLatitudeRelative_m, gpsLongitudeRelative_m, gpsNorthSpeed_m_s, gpsEstSpeed_m_s, gpsDataOk, gpsNewValidData, battery_filt, magneticDeclination_rad, magneticDeclinationLocked

No není to nádhera?!

Skoro bych řekl, že to jsou všechna data, jaká kdy posílala stará ARDrone2. Proto ten muj „tik” s navdata. Pokud je drona schopna ukládaná data do černé skřínky i posílat, tak by řízení mohlo být skoro 1:1. Ale zatím bez úspěchu. Možná to chrlí na jiný port?? A možná i Jessica měla podobné nastavení?

17. březen 2015 — Navdata zklamání

Tak to vypadá, že "navdata_enable" : true jenom zase ukládá nějaká data přímo na droně. Vznikl soubor navdatasMykonos3 (70MB), ale je to vlastně blackbox jenom textově, sloupce oddělené tabulátorem. Další zklamání jsem našel na githubu: Access to NavData. Nikolas od Parrotu tam potvrzuje, že ani Rolling Spider ani Bebop navdata na 200Hz neposílají: If you refer to the full navdata/200Hz mode of the AR.Drone and AR.Drone 2, this was a debug feature, which has been removed in the new drones. :-(

18. březen 2015 — Kolečka a obdélníky

Dnes ráno jsem si trošku hrál se základními geometrickými tvary (viz diff):

Příklad špatné detekce

Přemýšlím, koho ten XP přístup, kdy nejprve to naprogramujete „špatně”, tj. co nejjednodušeji, a teprve pak „pořádně”, tak rozčiloval. Jestli to byl Zbyněk nebo kolegové v práci … nevím. Každopádně jsem měl málo času a tak jsem to „schválně” naprogramoval „špatně”. Ale začal jsem psát i unit test, tj. superšpatné to zase nebylo .

A co jde? Je třeba najít značku přistávací plochy. Ta je kombinací kruhu a dvou na sebe kolmých obdélníků. Zatím jsem z MSERu posbíral kandidáty, vybral si takové, které alespoň ze 70% vyplňují nejmenší obklopující kruh či obdélník, vyfiltroval duplicity a pak už jenom to rozhodnutí, co je a co není značka. A tady jsem to zatím odflákl:

když není ani jeden kruh nebo nejsou dva obdélníky, tak značka nenalezena
jinak vrať spojnici středu prvního kruhu a druhého obdélníku

Možná se zeptáte, proč právě druhého obdélníku?! … protože jinak by ten můj první unit test neprošel. Na druhou stranu už takto triviální algoritmus by šel zapojit do zbytku navigačního kódu a kdybych byl hodně drzý, tak s ním i odstartuji, abych nasbíral reálné protipříklady.

Jinak mám stále trápení s videem, které se po nějakém čase přestane posílat a v dalších startech už vůbec nenaběhne :-(. Funguje pouze nahrávání, ale to pak není vhodný vstup jako reference …

p.s. i v tak triviálním kódu lze udělat chybu (přehrávám si včerejší logy):

File "M:\git\ARDroneSDK3\katarina\behaviors\navbox.py", line 54, in matchCircRect
    return (circles[0][0], rectangles[1][0])
IndexError: list index out of range

… opraveno.

20. březen 2015 — Sedm vteřin

Procházel jsem logy z úterního poletování a jediné co mi zatím přišlo podezřelé je, že video se přestalo posílat vždy po sedmi vteřinách?! Počet snímků a přenesených bloků byl různý a zhruba to odpovídalo okamžiku, kdy drona vystoupala do 1.5m a přešla do „levitování”. Po přistání už video nenaběhlo. Bylo nutné stroj vypnout a znova zapnout.

Chtělo by to další test, ale už je zase pozdě a není volný prostor. Když drona jenom leží na stole, tak je schopná posílat video i několik minut (tedy minimálně déle než 7 sekund). Je tam na 90% vazba na to létání, ale jaká?

Pro uklidnění jsem alespoň trošku vylepšil detekci přistávací plochy (viz diff). Konkrétně jsem chtěl ošetřit toto selhání:

špatně vybraný obdélník

Dosud jsem vybíral nejbližší obdélník velikosti průměru kruhu. Co jsem teď doplnil je, že mne zajímá jenom podmnožina z okolí kruhu. Přidal jsem i pár řádek na analýzu celého videa, místo jen jednotlivých snímků, a zpomalování při úspěšné detekci … prostě to co se mi na podzim líbilo na SICK Robot Day videu.

22. březen 2015 — PCMD @40Hz

Tak tento oříšek bych asi nerozlouskl :-(. V sobotu jsem přišel na způsob jak nasimulovat výpadek videa bez létání (viz diff). Následně jsem test ještě zjednodušil (diff), tj. jakmile pošlu první PCMD příkaz, tak přijdu o video. A pak už se nevrátí dokud Katarinu nevypnu a znova nezapnu.

Prima a teď jak to opravit?! Jsem rád, že jsem napsal na ARDroneSKD3/libARCommands/issues a k mému velkému překvapení mne dnes večer čekala odpověď:

When using the PCMDs, you should make sure that your send them with a fixed frequency (we use 40Hz / 25ms in FreeFlight), even if you're sending the same command every 25ms.

A change in the PCMD frequency is considered by the Bebop to be a "bad wifi" indicator. In this case, the bebop will decrease the video bandwidth (up to a "no video" condition if the indicator is really bad) in order to save the bandwidth for the piloting commands. When the PCMD frequency become stable again, the video bandwidth will rise again.

Pro neanglicky mluvící to ve zkratce znamená, že příkazy pohybu je třeba posílat s pevnou frekvencí (Free Flight používá 40Hz) a pokud tomu tak není, tak drona dojde k závěru, že je problém se spojením a minimalizuje počet posílaných paketů až video vypne úplně.

To i vysvětluje, proč to fungovalo tak „na půl”. Když jsem stoupal do nějaké výšky nebo letěl dopředu, tak to byl cyklus s pevným opakováním. Jak ale daný blok skončil časování se rozbilo a už do vypnutí nenaběhlo :-(.

Napsal jsem malý hack s posílacím vláknem (diff), který Nikolasovu odpověď potvrzuje. Teď je třeba to nějak integrovat, aby šly přehrávat logy a nepralo se více vláken o čítač u posílaných UDP paketů.

p.s. ráno mi došla ještě jedna hrozná chyba. Bebop protokol je trošku „naruby”, kdy data ze senzorů přicházejí zřídka (5Hz) a je třeba posílat často příkazy (40Hz) … a že jak mám update() smyčku „jako vždy”, čekej na data a pak pošli příkaz, a to je zde špatně! (fix). Proč? Protože jako příkaz se počítá i potvrzení video paketu … a v kombinaci s 40Hz mám konečně kompletní streamované video!

25. březen 2015 — Revize posílání příkazů

Zapojení vlákna posílajícího PCMD na 40Hz byla trošku otrava :-(. Ale je to teď snad hotové (diff). Asi největší „problém” byla má neústupnost z deterministického přehrávání logů … chtěl jsem jednak vědět jaké příkazy se přesně droně posílaly a dále jaké příkazy jsem já předával z hlavního kódu k poslání. Je to zmatené? No, když máte pevnou vysílací frekvenci a pošlete dva různé příkazy hned po sobě, tak v závislosti na implementaci se pravděpodobně buď první ztratí nebo druhý přijde do fronty a bude poslán „časem”. Vzhledem k tomu, že Katarina posíla informace o stavu jen na 5Hz, tak asi nemá smysl chrlit řídící příkazy … a navíc implementace bez fronty je snazší .

Do logovaných příkazů jsem přidal prefix INTERNAL_COMMAND_PREFIX a EXTERNAL_COMMAND_PREFIX podle toho, jestli jsem příkaz já poslal externě nebo samotné vlákno už mělo potřebu PCMD poslat. Externí PCMD příkazy také loguji, ale pouze jako separátor, tj. jenom ověřuji, že daný blok sedí.

Malá perlička — celou dobu jsem posílal vadné PCMD!!! Příkaz pohybu se totiž skládá z Booleanu (bajt) a čtyř dalších bajtů určující náklon nebo pohyb nahoru/dolu, vpravo/vlevo. Poslední parametr je float (4 bajty) … a modří už tuší, že na to je třeba dávat bacha, protože 5 není dělitelné 4 a tak se to defaultně zarovná a celý příkaz má navíc tři bajty! On ten poslední parametr je nepoužívaný (má znamenat azimut řídícího zařízení), takže jsou tam nuly a asi to droně moc nevadilo. Minimálně příkazy akceptovala.

Když už mám oddělené posílací vlákno, tak jsem tam dodělal i to indexovaní paketů v jednotlivých „kanálech”. Nyní je to poslední krok před posláním a uživatel se o to už nemusí nijak starat. Tímto zmizely z navdata.py všechny ty globální g_seq, g_seq2, g_seqAck, g_seqPongAck, g_seqVideoAck …

30. březen 2015 — Vybité baterky

V pátek jsem byl už nějaký vyřízený — ráno jsem oživoval Arduino Uno s GPS a čtyřmi gyroskopy pro jeden školní experiment, pak se snažil sepsat příklad pro dk863 ohledně zpoždění videa a vznikl video2stdout.py, který streamuje Bebop video na stdout. Do toho v práci „záhada dvaceti sedmi zákazů na španělské tranzitní křižovatce” … prostě bylo toho nějak moc a těšil jsem se na víkend, až vysadím. Prostě programátor na baterky

Na toto téma mne celkem zaujalo 4. doporučení Romana Staňka: v sobotu nepracujte . [Forbes nám minulý týden poslal odkaz na článek Lidem nakonec pravděpodobně zakážou řídit auta, ale ten mne až tak nezaujal … ostatně to tušíme všichni, když i Apple hledá robo-programátory a i spřátelené robotauto na tom již pracuje na plný úvazek …]

Aby alespoň něco málo relevantního k Bebopovi, tak Vincent poslal link, jak upravit nastavení komprese videa … minimálně musím ocenit jeho prezentační schopnosti … jinak to je ten Francouz z vtipu před pár dny.

31. březen 2015 — Video Results Queue

Dnes to bylo dost přemáhání vstát a začít kódovat, do čeho se mi ani moc nechtělo a pořádně stále nevím jak … integraci výsledků ze zpracování videa. Nakonec jsem to udělal pomocí dvou Qeueue, kde zpracování (včetně dekódování z H.264) probíhá v odděleném procesu. Změnil jsem tedy i význam funkce setVideoCallback() — má teď dva parametry, kde první je funkce pro zpracování video dat a druhá vrací poslední výsledek nebo None, pokud žádný výsledek není (diff).

Teď přijde ta zábavnější část na výsledky zpracování reagovat.

p.s. včera jsem ani nezmínil, že už existuje alespoň jeden člověk, který kód Katariny nezávisle na mně zkusil. Soudím tak podle té stížnosti na pomalost videa … Linux (Ubuntu 14.04) … no doufám, že to trošku nastuduje, než zavolá drone.takeoff()

1. duben 2015 — Navigace na přistávací plochu

Včera jsem dělal první pokusy udržet se nad přistávací plochou (diff). Venku fičelo, že by mi Katarina ulítla i zabalená v krabici, a trošku se to projevovalo i v budově. Dávám tedy částečnou vinu průvanu, ale jen malou … prostě to ještě nefunguje.

Důležitou změnou oproti předešlému sběru dat bylo logování výsledků zpracování obrazu. Výsek z logu cv2_150331_155530.txt vypadá takto:

143
(2, None)
210
(32, None)
314
(62, None)
199
(92, None)
344
(122, None)
310
(152, None)
386
(182, ((236, 239), (231, 282)))
280
(212, ((204, 239), (200, 276)))
374
(242, None)
220
(272, None)
…

Je hned jasné, že vzor přistávací plochy byl detekován pouze 2x a to ve snímku číslo 182 a 212. Je také pěkně vidět, že I-frame je jeden z třiceti snímků (32-2, 62-32,…). Počet cyklů mezi jednotlivými snímky je ale spíše zavádějící … ono je to počet zpracovaných paketů, včetně video paketů, jejichž počet je proměnný v závislosti na složitosti scény a pohybu kamery.

Obrázky jsem si uložil a pak ručně procházel. Konkrétně mne zajímaly snímky časově sousedící s úspěšnou detekci:

Snímek č. 152

Snímek č. 272

Na obou snímcích je přistávací plocha evidentně viditelná. Problém u snímku číslo 152 byl, že střed detekovaného obdélníku byl dál než dvojnásobek poloměru. Po změně tolerance na 2.1 už prošel i snímek 242. U 272 byla zase příliš velká deformace kruhu — vyžaduji, že 70% plochy jsou „černé body” a tady bylo nutné posunout hranici na 64%.

Testoval jsem ve dvou sériích: 6 pokusů vzletu a přistání se stoupáním do 1.5 a pak 8 pokusů s korekcemi. Jelikož už v první sérii se stávalo, že přistávací plocha byla vidět pouze krátce po vzletu z výšky 1m, tak jsem i stoupání změnil na „stoupání s korekcemi do strany”. Vtipný byl pokus meta_150331_191314.log, kdy místo stoupání Katarina začala klesat! Je to i pěkně vidět na video záznamu, ale drone.altitude stále stoupá :-(. Fakt mne štvou, že už neposílají odděleně i data ze sonaru, kamery a barometru. Sigh. Nevydržel jsem to a založil libARCommands issue #6.

p.s. na obhajobu Parrotu musím zmínit, že Radimovi opravdu poslali nový kus …

p.s.2 nezmínil jsem, že pokud si chcete sami zkusit detekci, tak stačí zavolat

./navbox.py –test roundelnav_272.jpg

7. duben 2015 — Konec zápůjčky.

Přišlo to dnes trošku jak blesk z čistého nebe. Bebop/Katarina je potřeba na nějakou předváděčku. Asi to není úplně konečná, ale částečně asi jo. Řeší se tím účast na Robotem rovně 2015 (zbývá 7 dní do ukončení registrace!), potřeba dekódovat složitější H.264 video …

Murphy se mi zase šklebí za zády — dnes jsem si stáhl ardupilot-mpng a paparazzi repository, protože o víkendu jsem změnil názor na psaní nízkoúrovňového software pro řízení dron. Po dlouhé době jsem se viděl s Ondrou a bavili jsme se, mimo jiné, o článku Build cargo drones, get rich a o tom, že existují alternativní SW pro hračky od Parrotu … no možná je dobře, že dronu vrátím teď. Na skříni je zaprášená Heidi a tam se to dá zkusit také … jen to nebude tolik bolet.

S Ondrou jsme se také bavili o tom, že je pěkné, že moje práce ostatní zaujala natolik, že si udělali fork Katariny . „Nu wot, što dělať. Děduška stárij i pojezd bystrij”.

16. duben 2015 — Remote Testing

Teď to teprve začíná mít pořádné „grády” . Programování bez drony. Testovací oblast Mexiko: ...in México there are no rules to fly drones yet (zones out of danger) and I have a big area. Zatím mám první logy včetně videa končícího crashem. Ti dobrovolníci (zatím dva Aldo/Mexiko a Charles/Francie) jsou odvážní … ale chtěli nějaké funkce a já nemám jak to zkusit (tedy ten crash byl z nulté iterace testFlyForward). Začal jsem tedy raději oddělenou větev DEVELOP a arénu pro kaskadéry najdete zde:

https://github.com/robotika/katarina/tree/DEVELOP/remote_testing

20. duben 2015 — Mexické video

Ze čtyř současných „testerů” je Aldo z Mexika asi nejaktivnější. Uploadnul i video z první kolize:

Řešíme teď navigaci na Home, kdy lze zadat souřadnice, ale skončí to ve stavu pending — tipoval bych, že ten příkaz bude nutné zadat ještě jednou, ale nechal bych Parrotu ještě 24h na odpověď.

Jinak jsem snad konečně vyřešil import z různých adresářů (diff) a to podle vzoru na stackoverflow.

21. duben 2015 — Skrytá kamera a Nao

Tak jsme s Charlesem snad odladili počáteční inicializaci všech proměnných. Ono to místo AllSettings totiž spíše chtělo AllStates. Tak nechť toto (diff) je první „vzdáleně odladěný” kód.

V posledním pokusu (meta_150420_173419.log) asi ještě běžela kamera, Charles delá nějaké trackování barvy, a tak se z toho stala „skrytá kamera” s pohledem do jeho kanceláře. Snímek sem doplním až po souhlasu Charlese. A co na něm bylo? Humanoidní robot Nao, pózující na druhém stole . Tak se mi to hned spojilo s Tanečně-performačním konceptem postaveném na bázi robotického fotbalu., co jsem viděl před dvěma týdny v La Fabrika.

Jinak v Mexiku prý prší, takže další NavigateHome test se zatím odkládá … ono tedy ještě není jasné, co jsou nutné podmínky, aby to fungovalo — viz Issue #7.

kontaktní formulář

H.264 pro vidění dravce

2013-07-18T00:00:00Z

Motivace

Když jsem před více jak deseti lety kráce pracoval pro firmu IXOS, tak jejich úspěch byl, mimo jiné, postaven na možnosti zpracovávat rovnou zabalené obrázky, aniž by je bylo nutné nejprve rozbalovat. Pokud má video výstup z drony rozlišení 1280x720 v RGB, tak to máte 2.7MB na jeden obrázek. Pokud ale použijete přímo pakovanou verzi, tak jeden „rozdílový” snímek (P-frame) má běžně pod 10kB. P-frame obsahuje informaci o pohybu jednotlivých makro-bloků, ze které by se možná dalo zjistit, zda v daném směru je objekt blízko či daleko…

Fandorama

Toto je první „průzkumný” fandorama projekt. Jedná se možná o slepou uličku, ale možná také ne. Pokud by vás výsledky zajímaly, s tím, že průběžné pozorování budou popisovány již ve třetím „létajícím blogu”, tak projekt podpořte. V případě úspěchu získáte slevu ve výši vašeho příspěvku na nákup Parrot AR.Drone 2.0 či náhradních dílů u firmy Profitec, českého distributora firmy Parrot.

kontaktní formulář

Detaily tohoto projektu: http://fandorama.cz/projekty/921778164/h264-drone-vision/

Blog

Toto je třetí „létající blog” o autonomní navigaci Heidi. Už nevím na kterou soutěž jet (a 450EUR se mi za IMAV 2013 dávat nechtělo), tak toto bude malé „samo-studium”.

Předešlé díly blogu případně naleznete zde:

Stejně jako dříve i tady předem se omlouvám za texty bez korekcí.

22. července 2013 — BEGIN

Teď ráno toho už asi moc nestihnu, tak alespoň začnu. Nejprve díky za první „anonymní” podporu na fandorama.cz (do zprávy pro příjemce prosím dávejte kontaktní mail, ať vám pak mohu napsat).

AR.Drone 2.0 používá pro kódování videa H.264 codec, který je relativně nový (hmm, 2003 == deset let). Vedle online videa se běžně používá třeba Blue-ray discích.

Pro čtení videa z drony stačí otevřít TCP spojení na portu 5555, přeskakovat PaVE hlavičky a co vám zbude jsou obrázky kódované H.264 codecem. Někteří (např. CVDrone) se s PaVE hlavičkami vůbec netrápí a rovnou hledají začátky takzvaných „NAL bloků” (zájemcům bych asi doporučil PDFko Video coding with H.264/AVC: Tools, Performance, and Complexity — je to celkem čitelné a zároveň tam naleznete dostatek užitečných detailů pro první vhled).

NAL bloky

NAL je zkratka za Network Adaptation Layer. Jednotlivý obrázek (frame) je popsán několika díly (slice) a každý začíná kódem 00 00 00 01. Následuje bajt určující typ — když jsem jednoduchý prográmek pustil na jedno z videí, tak jsem dostal 0x67, 0x68, 0x65, 0x61 (mnohokrát), 0x3D (omyl?), … Nás budou zajímat 0x61, což jsou P-slices (predicted) a měly by obsahovat i informace o pohybu jednotlivých makrobloků (oblastí velikosti 16x16 pixelů).

Timeout … musím do práce. Pokračování příště.

23-24. července 2013 — PaVE

Dnes jsem začal úklidem a odstraňováním PaVE (Parrot Video Encapsulation) hlaviček. Zatímco v zabaleném videu je kód 00 00 00 01 velice nepravděpodobný, v PaVE hlavičce je skoro jistý. 0x3D ze včerejška tedy zmizí a dostanete něco jako:

h264.py logs\video_rec_130714_140929.bin | uniq -c
      1 0x67
      1 0x68
      1 0x65
     29 0x61
      1 0x67
      1 0x68
      1 0x65
     29 0x61
       . . .
      1 0x67
      1 0x68
      1 0x65
     29 0x61
      1 0x67
      1 0x68
      1 0x65
     29 0x61
      1 0x67
      1 0x68
      1 0x65
     18 0x61

Videa jsou 30fps, takže každou sekundu je to vždy jeden celý snímek a 29 predikovaných (P-slice).

ffmpeg

Stáhl jsem si ffmpeg, abych měl dokumentaci i z druhého extrému. Zdrojový kód i s git repository má 126MB. Musím přiznat, že používání gitu pro Open Source projekty je opravdu velmi pohodlné (jak už jednou máte git nainstalovaný):

git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg

Asi vhodné místo pro začátek je ffmpeg/libavcodec/h264_parser.c. Pro určení typu části (slice) je důležitých spodních 5 bitů, tedy z 0x67, 0x68, 0x65 a 0x61 dostaneme 7=NAL_SPS, 8=NAL_PPS, 5=NAL_IDR_SLICE a 1=NAL_SLICE. Žádný další typ AR.Drone 2.0 neposílá.

Nás zajímá 1=NAL_SLICE … ale nejsem si jistý, zda je čitelnější zdrojový kód nebo dokumentace (sekce 7.3.3).

Exp-Golomb codes

Po jednobajtové hlavičce, flag a level bajtu jsou v NAL_SLICE čísla už převážně kódovaná proměnným počtem bitů. Používají se „Exp-Golomb” kódy, které se jmenují podle Solomon W. Golomba, jenž je v roce 1960 vymyslel. Pro popis čísel stačí zhruba dvojnásobek logaritmu bitů. 1 => 0; 01x => 1,2; 001xx => 3,4,5,6; atd. Pěkné tabulky najdete např. na wikipedii. Podobným způsobem se kódují i čísla se znaménkem.

Trošku váhám, zda má smysl takto, málem po větách, to dávat na web. Ještě hodně tápu, ale když tam nic nedám, tak se nic nedozvíte … snad to brzy začne mít hlavu a patu.

p.s. díky za další podporu — vypadá to, že minimálně tři další lidi toto téma zajímá

26. července 2013 — firmware 2.4.1

Dnes malá odbočka, flashnul jsem na Heidi nový firmware 2.4.1 s podporou GPS modulu. Jak jsem psal už dříve, získal jsem ho od kamaráda, co má iPhone, a pak i našel na webu vývojářů. Flashoval jsem to z PC Windows, tj. byla to kombinace informaci jak flashnout starou dronu, tak postup pro downgrade firmware nové drony.

Postup ve zkratce:

zapnout dronu (raději s plně nabitými bateriemi)
ve Windows Exloreru otevřít ftp://192.168.1.1:5551/ a Copy & Paste soubor ardrone2_update.plf (zkoušel jsem ještě dva jiné způsoby, ale buď jsem byl málo trpělivý, nebo prostě nefungovaly)
připojit se přes telnet a oeditovat verzi update:

# echo "2.4.1" > /update/version.txt

vypnout a zapnout napájení
počkat 2-3 minuty než se rozsvítí zelené LEDky

Vše snad proběhlo OK, zvedla se verze firmware a zmizel updateovací soubor:

BusyBox v1.14.0 () built-in shell (ash)
Enter 'help' for a list of built-in commands.

# cat /firmware/version.txt
2.4.1
# ls /update/
version.txt
#

A teď důsledky:

zvětší se navdata paket, takže pokud čtete např. pevných 2048 bajtů, vyletí výjimka (to bylo snadné opravit)
přestanou fungovat staré drivery, u mne konkrétně sonar:

insmod /data/video/driver2/cdc-acm.ko
insmod: can't insert '/data/video/driver2/cdc-acm.ko': invalid module format

… změnila se totiž i verze kernelu a je tedy třeba vše znova zkompilovat. Původní 2.6.32.9-gbb4d210 se změnila na 2.6.32.9-g1dd1a2a (tady jsem se teď zasekl, protože zjišťuji, že prostředí, co jsem měl v práci, už není k dispozici, takže to bude náročnější krok, než jsem čekal).

Hmm, tak ono se toho změnilo více, ne jenom nová datová struktura … dříve:

CTRL STATE 2
1 8
2 52
3 46
4 16
5 12
6 88
7 16
8 24
9 76
10 56
11 16
12 44
13 92
14 108
15 364
16 328
17 8
18 40
19 65
20 12
21 18
22 83
23 56
24 72
25 32
26 8
27 12
65535 8

nyní:

CTRL STATE 2
1 8
2 52
3 46
4 16
5 12
6 88
7 16
8 24
9 92
10 56
11 16
12 44
13 92
14 108
15 364
16 328
17 8
18 40
19 65
20 12
21 18
22 83
23 64
24 72
25 32
26 8
27 480
28 6
29 32
65535 8

Struktura 9 (72 na 92), 23 (56 na 64), 27 (12 na 480) a nové 28 a 29. Nepoužívám žádnou z nich a chápu, že některé programy se změnou velikosti struktury mohou mít celkem problémy. NAVDATA_PWM_TAG, NAVDATA_WIND_TAG, NAVDATA_ZIMMU_3000_TAG(?? možná to použili pro něco jiného). No to jsem zvědav, zda to vůbec poletí … pokračování po víkendu.

1. srpna 2013 — Sequence Parameter Set (SPS)

Tak konečně mikro-krůček ve zpracování H264 kódovaného videa …

Jako vždy jsem chtěl nejprve použít zkratku a parsovat pouze P-slice, které snad obsahují ty zajímavé informace. V proudu bitů se ale střídají jak dříve zmiňovaná čísla v Golomb formátu, tak i čísla s pevným počtem bitů. A chyba lávky. Jak velký tento fixní počet je, je zase kódované jinde, konkrétně v SPS-slice(Sequence Parameter Set). Na čem jsem klopýtnul byl frame_num, kde počet bitů je v log2_max_frame_num_minus4.

Dokumentaci používám z linku přes stack overflow a jako velmi užitečnou jsem shledal i C-implementaci, co mi link poslal jeden fandorama přispěvovatel: http://www.w6rz.net/h264_parse.zip. Je tam jak EXE, tak zdrojáky, takže si můžu po kouskách snadno ověřovat, že parsuji to samé co ostatní …

A nějaká pozorování?

log2_max_frame_num_minus4 je zatím všude rovno 10, tedy na uložení pořadového čísla se používá 14bitů.
pic_order_cnt_type je 2, takže jednotlive makro-bloky snad jdou postupně po řádcích
bloků je 80x45, což odpovídá rozlišení 1280x720

Ostatnímu zatím moc nerozumím. Asi bych si přepsal/napsal BitStreamReader, aby se jak čísla tak „golomby” jednoduššeji četly.

19. srpna 2013 — Picture Parameter Set (PPS)

Byl jsem teď 14 dní na dovolené, tak všechno trošku zahálelo. Na druhou stranu suma se ještě nepřehoupla, tak tento „výzkum” zatím není závazný …

Tak co nového, resp. starého, protože informace jsou z před-dovolené? Dostal jsem se snad už konečně až k dekódování makro-bloků, ale nemám žádnou zpětnou kontrolu, tak asi bude nutné dekódovat celý P-slice. Bylo pro změnu nutné použít i několik bitů z PPS (Picture Parameter Set). Skoro by bylo na čase to udělat pořádně, ale to bych nebyl já :-(. SPS a PPS byly stejné ve všech video záznamech co mám, takže nejrychlejší parsování je to přeskakovat (resp. assertovat, že jsou stále stejné).

PPS je bajtově [0xce, 0x1, 0xa8, 0x77, 0x20], což odpovídá výpisu z minule zmiňovaného parseru:

Nal length 10 start code 4 bytes
 ref 3 type 8 Picture parameter set
   pic_parameter_set_id: 0
   seq_parameter_set_id: 0
   entropy_coding_mode_flag: 0
   pic_order_present_flag: 0
   num_slice_groups_minus1: 0
   num_ref_idx_l0_active_minus1: 0
   num_ref_idx_l1_active_minus1: 0
   weighted_pred_flag: 0
   weighted_bipred_idc: 0
   pic_init_qp_minus26: -26
   pic_init_qs_minus26: -14
   chroma_qp_index_offset: 0
   deblocking_filter_control_present_flag: 1
   constrained_intra_pred_flag: 0
   redundant_pic_cnt_present_flag: 0

Ještě doplním SPS, které je také stále stejné:

Nal length 14 start code 4 bytes
 ref 3 type 7 Sequence parameter set
   profile: 66
   constaint_set0_flag: 1
   constaint_set1_flag: 0
   constaint_set2_flag: 0
   constaint_set3_flag: 0
   level_idc: 31
   seq parameter set id: 0
   log2_max_frame_num_minus4: 10
   pic_order_cnt_type: 2
   num_ref_frames: 1
   gaps_in_frame_num_value_allowed_flag: 0
   pic_width_in_mbs_minus1: 79 (1280)
   pic_height_in_map_minus1: 44
   frame_mbs_only_flag: 1
     derived height: 720
   direct_8x8_inference_flag: 0
   frame_cropping_flag: 0
   vui_parameters_present_flag: 0

Tak teď už hurá na makro bloky! … pokračování snad brzy.

22. srpna 2013 — CAVLC vs. CABAC

To jsem si naběhl — teď už nemám žádnou výmluvu . Na druhou stranu mám radost, že existuje několik lidí, které výsledky opravdu zajímají . Zpátky ni krok …

Zatím stále tápu, teď nad souborem m:\git\ffmpeg\libavcodec\h264_cavlc.c. Až včera mi došlo, že jsem možná na špatné koleji a bych měl možná studovat raději m:\git\ffmpeg\libavcodec\h264_cabac.c?! Co to tedy ten CAVLC a CABAC je?

Jedná se od dva různé způsoby kódování, kde CAVLC je zkratka za Context-adaptive variable-length coding a CABAC je Context-adaptive binary arithmetic coding. Celkem pěkný popis je v IEEE článku Video coding with H.264/AVC: Tools, Performance, and Complexity, ze kterého pochází následující obrázek:

CAVLC vs. CABAC

Matice se linearizuje podle vzoru do 1D pole. U CAVLC se nejprve zjistí počet nenulových prvků (po transformaci obrazu je většina prvků nulová) a ukončujících +/- jedniček (často se vyskytují a označují se T1). Ten se vyšle v kombinovaném slově (použité jsou kódovací tabulky). Pak jsou jednotlivé koeficienty procházeny od konce a ukládá se znaménko a hodnota, s použitím předešlé hodnoty, pomocí šesti kódovacích tabulek. Konečně nulové elementy jsou indikovány celkovým počtem nul před posledním nenulovým prvkem. Hm, to jsem to pěkně odpapouškoval, ale moc tomu tak po ránu nerozumím :-(.

Tak ještě jednou podle obrázku. Nenulových prvků je 5, OK. „Trailing” budou pouze ty koncové jedničky, tj. ta 1,1,-1 a počet 3, OK. Znaménka jedniček od konce bude to -1,1,1 a pak následují 2 a 1 (pozpátku), OK. Počet nul/mezer jsou 2, OK. A mezi poslední a předposlední žádná nula není, tj. 0, pak jsou dvě mezery, tj. 1, 1 a zbytek už je nezajímavý (0), protože vím, že nuly měly být 2, OK. Jako hypotéza pochopení CAVLC to teď asi stačí.

Mám se s CABAC vůbec zabývat? Standard H264 podporuje oba způsoby, ale který používá AR Drone 2.0? (timeout, musím do práce…)

p.s. Picture Parameter Set — int cabac; ///< entropy_coding_mode_flag, který pro AR Drone 2.0 je vždy 0, tj. CAVLC byla správná volba.

23. srpna 2013 — ./ffprobe -report s TRACE

Když jsem pročítal zdrojový kód ffmpeg na dekódovaní CAVLC, tak na mnoha místech byl tprintf, který by vypisoval přesně to co mne zajímalo. Implementace této funkce ale je na #ifdef TRACE, který je třeba odkomentovat v m:\git\ffmpeg\libavcodec\get_bits.h:588 a nově zkompilovat. Přešel jsem tedy na Linux, kde příprava a kompilace byla otázkou pár minut.

Bylo třeba udělat následující kroky:

git clone git://source.ffmpeg.org/ffmpeg.git
./configure
editace ffmpeg/libavcodec/get_bits.h
make
./ffprobe -report <moje video>

Výsledek zcela předčil mé očekávání. V automaticky vygenerovaném logu (je nutné použít parametr -report) je vedle mnoha tprintf výpisů i bitový vypis s odkazem do kódu, kde přesně byl dekódován. Ještě varování: ten log je obrovský, protože pár bitů nahrazujete jednou nebo více řádkami textu a není možné parsovat pouze váš P-slice bez úvodních SPS, PPS a I-slice …

Malý výsek pro představu — odpovídající začátku P-slice:

1                           1  1   0 ue      2 in libavcodec/h264.c decode_slice_header:3363
00000000000001              1 14   1 bit     3 in libavcodec/h264.c decode_slice_header:3500
1                           1  1   1 bit    17 in libavcodec/h264.c decode_slice_header:3779
1                           1  1   0 ue     18 in libavcodec/h264.c decode_slice_header:3782
[h264  0x2a02580] List0: ST fn:0 0x0x7f64e315a250
0                           0  1   0 bit    19 in libavcodec/h264_refs.c ff_h264_decode_ref_pic_list_reordering:215
0                           0  1   0 bit    20 in libavcodec/h264_refs.c ff_h264_decode_ref_pic_marking:759
00000111110                62 11  31 se     21 in libavcodec/h264.c decode_slice_header:3870
1                           1  1   0 se     33 in libavcodec/h264.c decode_slice_header:3900
1                           1  1   0 se     34 in libavcodec/h264.c decode_slice_header:3901
[h264  0x2a02580] pic:1 mb:0/0
1                           1  1   0 ue     36 in libavcodec/h264_cavlc.c ff_h264_decode_mb_cavlc:733
[h264  0x2a02580] topright MV not available
[h264  0x2a02580] pred_motion match_count=0
[h264  0x2a02580] pred_motion (-2  0  0) (-2  0  0) (-2  0  0) -> ( 0  0  0) at  0  0 0 list 0
1                           1  1   0 se     37 in libavcodec/h264_cavlc.c ff_h264_decode_mb_cavlc:966
1                           1  1   0 se     38 in libavcodec/h264_cavlc.c ff_h264_decode_mb_cavlc:967
[h264  0x2a02580] final mv:0 0
0001011                    11  7  10 ue     39 in libavcodec/h264_cavlc.c ff_h264_decode_mb_cavlc:1054
1                           1  1   0 se     46 in libavcodec/h264_cavlc.c ff_h264_decode_mb_cavlc:1101
[h264  0x2a02580] pred_nnz L40 T0 n8 s28 P0
1                           1  1   0 vlc    47 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] pred_nnz L0 T0 n9 s29 P0
01                          1  2   5 vlc    48 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] trailing:1, total:1
011                         3  3   1 vlc    51 in libavcodec/h264_cavlc.c decode_residual:581
[h264  0x2a02580] pred_nnz L40 T0 n10 s36 P0
1                           1  1   0 vlc    54 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] pred_nnz L0 T1 n11 s37 P1
1                           1  1   0 vlc    55 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] pred_nnz L1 T0 n12 s30 P1
01                          1  2   5 vlc    56 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] trailing:1, total:1
00011                       3  5   5 vlc    59 in libavcodec/h264_cavlc.c decode_residual:581
[h264  0x2a02580] pred_nnz L1 T0 n13 s31 P1
1                           1  1   0 vlc    64 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] pred_nnz L0 T1 n14 s38 P1
1                           1  1   0 vlc    65 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] pred_nnz L0 T0 n15 s39 P0
1                           1  1   0 vlc    66 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] pic:1 mb:1/0
1                           1  1   0 ue     68 in libavcodec/h264_cavlc.c ff_h264_decode_mb_cavlc:733
[h264  0x2a02580] topright MV not available
[h264  0x2a02580] pred_motion match_count=1
[h264  0x2a02580] pred_motion (-2  0  0) (-2  0  0) ( 0  0  0) -> ( 0  0  0) at  1  0 0 list 0
1                           1  1   0 se     69 in libavcodec/h264_cavlc.c ff_h264_decode_mb_cavlc:966
1                           1  1   0 se     70 in libavcodec/h264_cavlc.c ff_h264_decode_mb_cavlc:967
[h264  0x2a02580] final mv:0 0
000010100                  20  9  19 ue     71 in libavcodec/h264_cavlc.c ff_h264_decode_mb_cavlc:1054
00101                       5  5  -2 se     80 in libavcodec/h264_cavlc.c ff_h264_decode_mb_cavlc:1101
[h264  0x2a02580] pred_nnz L0 T40 n0 s12 P0
01                          1  2   5 vlc    85 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] trailing:1, total:1
011                         3  3   1 vlc    88 in libavcodec/h264_cavlc.c decode_residual:581
[h264  0x2a02580] pred_nnz L1 T40 n1 s13 P1
1                           1  1   0 vlc    91 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] pred_nnz L0 T1 n2 s20 P1
1                           1  1   0 vlc    92 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] pred_nnz L0 T0 n3 s21 P0
01                          1  2   5 vlc    93 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] trailing:1, total:1
0010                        2  4   4 vlc    96 in libavcodec/h264_cavlc.c decode_residual:581
[h264  0x2a02580] pred_nnz L0 T40 n4 s14 P0
1                           1  1   0 vlc   100 in libavcodec/h264_cavlc.c decode_residual:465
[h264  0x2a02580] pred_nnz L0 T40 n5 s15 P0
…

27. srpna 2013 — není všechno zlato …

… co se třpytí aneb snažím se podle výstupu z ffprobe upravit svůj pythonovský skriptík a ono v tom 82MB textovém dumpu ze dvou snímků není všechno :-(. Konkrétně:

00000111110   62 11  31 se     21 in libavcodec/h264.c decode_slice_header:3876
1              1  1   0 se     33 in libavcodec/h264.c decode_slice_header:3906
1              1  1   0 se     34 in libavcodec/h264.c decode_slice_header:3907

Tj. když se přečte slice_qp_delta, která má 11 bitů, s tím, že se začína na 21 bitu ve video streamu (vnitřek slice), tak se bitový čítač posune o 12 a nikoliv o 11 na 33. Důvod je, že tam chybí čtení

tmp = get_ue_golomb_31(&h->gb);

na libavcodec/h264.c decode_slice_header:3895.

Je tedy možné, že některá čtení z podmínky TRACE vypadla, nebo TRACE musí být definované někde trošku jinde (???). Postup je pomalý, ale snad to alespoň lépe pochopím …

27. srpna 2013 — ce(v): context-adaptive variable-length entropy-coded syntax element

No není to krásný název? Doufám, že to je už poslední vychytávka pro parsování CAVLC. Jedná se o sadu tabulek s proměnnou délkou klíče, která např. určuje počet nenulových prvků a jedniček na konci sekvence. O jakou se přesně jedná tabulku určují vstupní parametry. Je to vlastně klasický bitový slovník, tak nevím, proč se tak čertím . Asi se mi nechce přepisovat ty tabulky, ale ani to není až tak strašné, jenom čas už není …

6. září 2013 — zkratka

Kdysi mi bylo vyčteno, že používám nedovolené zkratky … a používám. Stále jsem to celé dekódování CAVLC do konce nedotáhl, a přitom to není „to hlavní”. Na druhou stranu mé chápání H.264 se už trošku posunulo a tak přečtení seminární práce Implementation of a basic H.264/AVC Decoder od Martina Fiedlera byla už radost a většině jsem i rozuměl .

Hledal jsem alternativní implementaci k FFMPEG, pokud možno jednoduchou (i kdyby pomalou) a pro Windows. Ve zmiňované práci byl mezi odkazy link [5] H.264/AVC Reference Software (opravený původní link). Stáhl jsem si jm18.5.zip, rozbalil a našel projekty pro všechna Visual Studia, včetně toho, co používám (stále vc9). Chvíli jsem si krokoval v debugeru, ale chybějící bity pro vlastní implementaci nevykoukal. Tak jsem použil „dočasnou zkratku” a do souboru macroblock.c:405 připsal:

fprintf( stderr, "%d %d %d %d\n", currMB->block_x/4, currMB->block_y/4, curr_mv.mv_x, curr_mv.mv_y );

a dál si hrál už jenom s parsováním stderr výstupu v Pythonu. Dobrá zpráva je, že minimálně první dva snímky měly identické posuny jako TRACE z FFMPEG (včetně podivného (-130, 60), ale většina byla +/-2). Výsledkem jsou 80x45 pixelů veliké „snímky”, kde pro vizualizaci jsem použil součet absolutních hodnot přes 30 snímků a pak přeškáloval, aby maximum bylo 255. Výsledek jsem pak uložil v PGM formátu. Při startu to vypadá např. takto:

Integrace pohybu ze 30ti snímků

nebo chcete-li původní textový soubor v PGM.

p.s. kdyby jste šli v mých stopách, tak si nezapomeňte změnit konfiguraci tak, aby se negeneroval výstupní soubor (je jinak obrovský). Upravené řádky konfigurace vypadájí takto:

InputFile    = "m:\hg\md\heidi\frames\mix2.bin"   # H.264/AVC coded bitstream
OutputFile   = ""   # Output file, YUV/RGB

10. září 2013 — combinePgm ver0

Jelikož procházet jednotlivé pidi-snímky je dost nepraktické, tak jsem jsi napsal jednoduchý skript (spíše 10 řádek) na kombinování několika snímků do jednoho. Výsledek 10x10 se teď počítá …

prvních 100 snímků

… hmm, čekal jsem něco více, asi tomu budu muset podhodit akčnější video. Vypadá to spíše na nějakou chybu, protože výstupní PGM jsou od třetího snímku všechna stejná :-(.

p.s. pro zpestření příkládám video link od Jirky: čtyřtulka a osmitulka jako servírky .

12. září 2013 — programování ve sprše

Přiznám se, že hrozně nerad hledám chyby v programu civěním do monitoru. Daleko přijatelnější je „nasadit si brouka do hlavy” a on se ten „bug” pak sám najde . Stejné to bylo i s předešlým snímkem, proč se opakují stále stejné obrázky?

A rozuzlení? Makrobloky je možné zcela přeskočit, takže ve výpisu se vůbec neobjeví. Místo čekání na makroblok s indexem (79,44), teď čekám na „singularitu”, tj. když x+y*80 náhle klesne, tak to už je další snímek (máte pravdu, dalo by se to udělat pořádně v generátoru toho vstupního textového souboru, ale …).

Další chyba byla, že ten videosoubor opravdu obsahoval jenom 60 snímků a tak vždy dojel na konec. Přestal jsem tedy integrovat po 30ti snímcích, ale změnil to na 7. Proč? No protože video krátkého letu u nás v parku má 707 snímků a já chtěl udělat 10x10 mozaiku . Tady je:

Duch stromu

Referenční video na youtube naleznete zde: http://youtu.be/9NOvif6gtiU

p.s. aby nedošlo k omylu — toto je video z 12. června 2013, kdy jsem se připravoval na RoboOrienteering, tj. sice autonomní let, ale pouze se sonarem.

26. září 2013 — sudé posuny

Práce okolo Robotour 2013 se už pomalu uklidňují (je ještě potřeba vymyslet vhodné místo pro rok 2014), tak se můžu vrátit k hraní s dronou a videem. Krátkých zpráv by za tu dobu bylo hned několik, jako polemika na téma „figura a pozadí”, kdy strom je jednou bílý a jednou černý, nebo že už jsou k dispozici pravidla pro IARC 7th Mission, kde létající roboti budou nahánět uklízecí hordu Roomba iCreate robotů (do vánoc bych o tom asi něco napsal zase podrobnji) a pod. Zpět k H264…

Z PGM obrázků je sice vidět, že „tam něco je”, ale informaci, zda mám odbočit vpravo/vlevo či nahoru/dolů tam zatím nevidím. Chtěl jsem si tedy udělat 2D histogram všech posunů v obrázku a první překvapení — všechna použitá čísla jsou sudá! Ano, testoval jsem to jenom přes jedno krátké video, takže mohu tvrdit že všech 1977841 posunů je sudých, ale nechal bych tam assert a myslím, že bude platit.

Co to znamená? Zase jen hypotéza: ve specifikaci se píše o možnosti čtvrt-pixelového kroku, takže si myslím, že posun 2 je ve skutečnosti posun o půlpixel a jemnějším krokem se video procesor netrápí.

Další pozorování je, že většina posunů je ve čtverci +/- 10 pixelů, ale najde se i pár „ustřelených” jako posun (0,48). Ty pak ale určují šedotónovou škálu a tak bych je buď vyhodil nebo oříznul.

Platí to i pro druhý extrém, kdy je celý obraz v pohybu, a stále zde najdu nějaké statické, tedy s posunem (0,0).

Příklad 1: defaultdict(, {(-2, 0): 20, (6, 4): 1, (8, 0): 2, (-2, 4): 1, (-2, 8): 1, (4, -6): 1, (2, 6): 1, (14, 0): 1, (-2, 2): 7, (-4, 30): 1, (-4, 6): 1, (6, 2): 1, (4, 0): 14, (0, 6): 3, (-6, 0): 1, (0, -8): 2, (4, 4): 2, (2, -4): 1, (6, -8): 1, (-2, -2): 2, (-10, -4): 1, (-2, -26): 1, (0, -4): 6, (4, 10): 1, (-2, -6): 1, (0, 0): 3395, (2, -2): 2, (6, 0): 2, (0, 12): 1, (4, -8): 1, (-4, 0): 5, (0, 4): 9, (0, 8): 8, (8, -28): 1, (4, -4): 1, (12, 0): 7, (-4, 16): 1, (2, 2): 7, (2, 0): 46, (0, 48): 1, (0, -2): 8, (-8, 0): 2, (0, 2): 29})

… uznávám, že toto moc čitelné není. Je tam ale vidět naprostá většina (0,0), desítky posunů (0,2) a (2,0) a zbytek jsou jen drobky(?). Toto byl příklad, když je drona v klidu.

Příklad 2: defaultdict(, {(12, 12): 1, (2, -4): 2, (0, 14): 2, (-4, 0): 6, (-2, 4): 1, (12, -8): 1, (14, 0): 1, (-2, 2): 23, (2, 4): 3, (12, -4): 1, (4, -2): 1, (-2, 0): 5, (0, 6): 2, (-6, 0): 1, (0, -8): 5, (4, 4): 1, (2, 2): 326, (0, 4): 15, (4, 0): 57, (0, -4): 8, (0, 0): 1652, (2, -2): 183, (6, 0): 1, (0, 12): 1, (0, -2): 51, (8, 0): 2, (4, 2): 20, (0, 8): 2, (-4, 4): 1, (12, 0): 1, (0, -12): 1, (0, -20): 1, (2, 0): 759, (-12, 50): 1, (0, 2): 461, (0, 10): 1})

… vzlet. Stále dominuje (0,0), ale srovnatelné hodnoty mají i posuny (2,0) a (0,2), nebo (2,2). Toto je z rozdílového snímku na 30Hz, takže je potřeba to posčítat přes více. Asi čitelnější je to rozdělené přes desítkový logaritmus:

1000 [((0, 0), 1652)]
100 [((2, -2), 183), ((0, 2), 461), ((2, 0), 759), ((2, 2), 326)]
10 [((0, -2), 51), ((-2, 2), 23), ((0, 4), 15), ((4, 2), 20), ((4, 0), 57)]

Další plán je tedy posčítat jednotlivé vektory přes více snímků (znaménkově). Dosud jsem jen dělal obrázky ze součtu absolutních hodnot a třeba ty světlé oblasti jsou jen místa častých zákmitů …

1. říjen 2013 — pygame art

V pátek jsem si trošku hrál s vizualizací posunů makrobloků. Jako nástroj používám už několik let PyGame. Teď jsem do kódu ještě přidal řádku

pygame.image.save( foreground, filename )

ať z toho máte i něco vy ostatní. Jako koncovku souboru doporučuji PNG, protože na podobné trojbarevné obrázky dostanete asi 7x menší soubor než pro JPG a navíc bezztrátově (no 100% si s tou bezztrátovostí jistý nejsem).

Dnes jenom „chybné” obrázky, které mi připomněly robotovi kreace z roku 1992. Tehdy se snažil o naplánování cesty s omezenou křivostí a výsledné křivky byly někdy zajímavější než celý algoritmus:

Ještě proč jsou dané obrázky chybné? Jednak vektor je 16x delší než má být (násobil jsem to velikosti makrobloku), pak má být možná na druhou stranu a konečně ty červené tečky by asi měly být spíše na druhé straně čáry, protože teď označují cílové místo a ne zdrojové. Vše je to integrované přes tři rozdílové snímky.

A ještě špatná zpráva na konec. Zatím co dříve jsem tam tušil „duch stromu” teď už v tom nevidím vůbec nic … ale to se třeba časem zlepší.

4. říjen 2013 — Augmented Reality

Včera jsem zkoušel „rozšířenou realitu”, tedy do původního videa namíchat vektory posunů makrobloků z H264 kódování. Výsledek se mi zprvu celkem líbil i když teď už zase moc nevím - zde najdete AR video na YouTube a zde je původní video. Kvalita je dost mizerná, protože původní video se rozloží na JPG snímky, do nich se přimíchají čáry, znova se uloží jako JPG a pak se to ještě celé postupně zabalí do nového videa. Ale nějakou představu si podle toho snad uděláte.

Ještě malé vysvětlivky. Pokud se makroblok vůbec nehnul, tak nekreslím nic. Pokud ano, tak na jeho místě je červené kolečko a žlutá čára je vektor, kde byla nejlepší korelace v předešlém (?) snímku. Vše je to integrované přes tři snímky, aby bylo vůbec něco vidět.

Některé snímky jsou pěkné/použitelné. Např. na tomto

Malé otočení

je vidět jak jsou skoro všechny posuny stejné a čtyřtulka se otáčí na místě.

Na dalším snímků je zase idealistická ukázka, jak blízké předměty (strom a zem) se pohybují nejvíce a ostatní vzdálenější objekty (tráva na pozadí) téměř vůbec:

Překážky z pohybu

Je nutné vzít v úvahu, do jakého bodu se drona pohybuje, protože v tom místě také k žádnému velkému posunu nedochází. Ale je to alespoň nějaký příklad, kdy bych měl spustit malý úhybný manévr vlevo.

Ještě minimálně jedna situace je třeba vzít v úvahu a to, když se Heidi naklání:

Náklon

Zde je vidět pěkný „vír”, přestože makrobloky povolují pouze posun a nikoliv otáčení.

A co dál? Po pravdě si stále nejsem úplně jist, jestli vektory nemají být na druhou stranu. Dále, jak jsem psal „korelace v předešlém (?) snímku” … on to může být ještě daleko starší snímek, H264 to podporuje, ale jestli to používá čip na Parrot AR Drone 2 nevím. Konečně bych si asi znova přečetl, jak je to s těma sub-makroblokama. Jestli mohou mít také nezávislé posuny nebo zda se liší jen způsobem kódování a jestli to drona používá.

Máte-li nápady, jak z uvedených snímků už usuzovat na příkazy leť vlevo|vpravo|nahoru|dolu, tak napište .

8. říjen 2013 — Bakalářka

Přemýšlel jsem, jak detekovat a kompenzovat „víry” na posledním obrázku z minulého příspěvku a pak jsem si vzpomněl na Bakalářskou práci Karla Doležala, kterou jsem už zmiňoval ve druhém létajícím blogu. Jde konkrétně o kapitolu 5.4, „Potlačení pohybů kvadrokoptéry”.

Základní postřeh je, že y-ová složka vektorů se mění s absolutní X-ovou souřadnicí a nabývá nuly ve středu otáčení. To samé platí pro x-ovou složku vektorů a absolutní Y-ovou souřadnici. Vedle znalosti středu ale ještě potřebujeme všechny vektory kompenzovat a na to prý je dostatečná lineární interpolace. Nějak začít musím, tak proč nevyzkoušet už jednou prošlapávanou cestu?

Nejprve jsem byl zvědav, jak moc je ta lineární aproximace nepřesná. Následující dva grafy odpovídají datům z obrázku „Náklon”:

dy podle X

dx podle Y

Pás okolo předpokládané proložené přímky není úplně úzký, ale třeba to bude stačit. Zatímco s X grafem jsem celkem spokojený (střed vychází někam k 65/80), tak u Y už moc ne (tam přímka protíná osu někde okolo 15/45, ale střed otáčení je téměř ve spodní části obrázku). Hmm, že by bug?! A taky jo!! Zatracený obrázkový souřadnice. Y-ová jde shora dolů, to samé u indexů makrobloků, ale já jsem zvyklý na „normální” souřadnice a tak si automaticky převracím (0,0) do spodního levého rohu.

Hmm, hmm, … po převracení Y-ové vzhůru nohama to hned začne dávat větší smysl a „svatojánské mušky” na začátku videa začnou poletovat na kmeni stromu. Všechno vylejt!

p.s. Excel, který rád na rychlé grafíky používám, také nezklamal …

Celý obrázek do Excel XY grafu přímo nedáte ...

9. říjen 2013 — Kompenzace natočení

Začal bych s linkem na opravené video, tedy prohozenou Y-ovou souřadnicí, kdy už to vypadá trošku věrohodněji .

Dále bych pokračoval s aplikaci nejmenších čtverců na odhad středu a průběhu „víru”. Z bakalářky převzatá rovnice pro výpočet koeficientů v dY=k1*X+k0:

je správně, jen si je třeba dát pozor, že je třeba jí použít 2x a jednou je y=dY a podruhé je x=dX.

Po kompenzaci vypadá výsledek následovně:

před korekcí

po korekci

Jisté zlepšení (hlavně v levém dolním rohu) vidět je, ale jestli už je to dostatečné zatím neumím posoudit.

11. říjen 2013 — Příprava na ver0

Tak nejprve další video. Přiznám se, že koukat stále na to samé mne už pomalu unavuje, ale snad už to brzy skončí . Zde vidíte nejprve kompenzace posunu a natočení. Tj. „žluté vektory” už jsou po kompenzaci a „víry” a jednotné posuny by tam už moc neměly být vidět.

Dále jsem tam přidal různé velikosti „červených koleček”. Pokud je pohyb menší jak 10, tj. 2.5 pixelu, tak se neukazuje nic, pro 100 malé kolečko a více velké (překážka). Je to stále integrované přes tři snímky. Výsledek je, že občas je vidět něco rozumného a občas je celá obrazovka rudá, jak z nějaké střílečky.

Příklad špatného (?) rozhodnutí

Plán pro verzi 0 je teď následující:

pokud je počet překážek (míněno velkých koleček odpovídajících makroblokům s posunem více jak 100) větší než 1000 (cca 1/3 makrobloků), tak nedělej nic … krvavá řež
pokud je na levé straně o 100 více překážek než vpravo, vyhýbej se vpravo
pokud je dole o 100 více překážek než nahoře, leť nahoru

a symetrické IFy.

Teď jsem zvědavý, co to udělá ve skutečnosti. Už jsem si vyhlídnul malý lesík/parčík, kde bych to vyzkoušel „rozflákat”. Pokud nic, tak snad bude alespoň jiné, více relevantní, video k ladění. Čeká mne ale ještě netriviální integrace, aby to vše běželo v reálném čase ze streamovaného videa. Momentálně vůbec neodhadnu, na jak je to dlouho …

16. říjen 2013 — GitHub

Zbyněk mne minulý týden přesvědčil, ať pro robotika.cz založíme GitHub. Používám sice na zdrojáky private repository, ale jo … asi má pravdu. Rozhodně je to 100x lepší než zdrojáky přilepovat k článku, jak jsme dělávali před lety.

Pokud se tedy chcete podívat, nebo ještě lépe přímo zapojit, tak git najdete na https://github.com/robotika/h264-drone-vision.

Popisky bych asi měl dát rovnou tam, ale zase v kontextu tohoto blogu bude jasnější o co jde:

video.py je jednoduchá utilitka na ukládání videa za letu a zároveň na konverzi zdrojového souboru na oddělené frames
h264.py jsou pak (zatím neúspěšné) pokusy jednotlivé frames dekódovat
mv2pgm.py generuje PGM obrázky na základě textového souboru pohybů (po řádcích x,y, dx, dy)
mv2pygame.py pak zároveň vektory kreslí v pygame (vím, že tam mám teď natvrdo adresář, kde se mají brát podkladové JPG, ale nějak začít musím a třeba to vůbec nikoho nebude zajímat …

18. říjen 2013 — HEX

Kamarádi se mi smějí, že se nejraději koukám na videa v hexa-editoru… a už je to tady zase . Po drobném vyhecování Jirkou bych nejprve rozchodil h264.py, než se pokusím o C implementaci. A možná to ani nebude nutné.

Dříve (6/9/2013) zmiňovaný parser má také možnosti zapnutí TRACE:

# define TRACE 2 //!< 0:Trace off 1:Trace on 2:detailed CABAC context information

Trošku matoucí je, že tento define je ve dvou různých souborech pojmenovaných defines.h (jeden pro decoder a jeden pro encoder) a nepřišly mi úplně nezávislé. Tak jsem nakonec změnil oba na 2, pak to nešlo zkompilovat (nedefinovany p_trace jsem přepsal u encoderu na stderr) a pak jsem chvíli hledal, kam že ten výstup zmizel (je to v souboru trace_dec.txt).

Pustil jsem to na naše oblíbené video a během dvou snímků dostal 50MB textový soubor. Trošku trvalo, než jsem v něm našel sekci, která mne zajímala:

Annex B NALU w/ long startcode, len 25412, forbidden_bit 0, nal_reference_idc 3, nal_unit_type 1

@1075083 SH: first_mb_in_slice                                       1 (  0) 
@1075084 SH: slice_type                                              1 (  0) 
@1075085 SH: pic_parameter_set_id                                    1 (  0) 
@1075086 SH: frame_num                                  00000000000010 (  2) 
@1075100 SH: num_ref_idx_override_flag                               1 (  1) 
@1075101 SH: num_ref_idx_l0_active_minus1                            1 (  0) 
@1075102 SH: ref_pic_list_reordering_flag_l0                         0 (  0) 
@1075103 SH: adaptive_ref_pic_buffering_flag                         0 (  0) 
@1075104 SH: slice_qp_delta                              0000001000000 ( 32) 
@1075117 SH: disable_deblocking_filter_idc                           1 (  0) 
@1075118 SH: slice_alpha_c0_offset_div2                              1 (  0) 
@1075119 SH: slice_beta_offset_div2                                  1 (  0) 

*** POC: 2 (I/P) MB: 0 Slice: 0 Type 0 **
@1075120 mb_skip_run                                                 1 (  0) 
@1075121 mb_type                                                     1 (  0) 
@1075122 mvd0_l0                                                     1 (  0) 
@1075123 mvd1_l0                                                     1 (  0) 
@1075124 coded_block_pattern                                       011 (  1) 
@1075127 mb_qp_delta                                                 1 (  0) 
@1075128 Luma # c & tr.1s vlc=0 #c=0 #t1=0                           1 (  1) 
@1075129 Luma # c & tr.1s vlc=0 #c=0 #t1=0                           1 (  1) 
@1075130 Luma # c & tr.1s vlc=0 #c=0 #t1=0                           1 (  1) 
@1075131 Luma # c & tr.1s vlc=0 #c=2 #t1=2                         001 (  1) 
@1075134 Luma trailing ones sign (1,1)                              10 (  2) 
@1075136 Luma totalrun (1,1) vlc=1                                0011 (  3) 
@1075140 Luma run (1,1) k=1 vlc=6                                  111 (  7)

ale … s mým oblíbeným hexa E0 00 E0 10 3F BF 31 mi to nesedělo, ať jsem se to snažil sekvenci napasovat i na dost divná místa. Slice, který mne první zajímá, je až čtvrtý (decoder má jinak bez SPS, PPS a I slice problém), tj. je potřeba se prokousat 134398 bajty zdrojového videa.

Cestou z práce mi došlo, že bych mohl najít přesně místo, když @1075083 vydělím 8 (tj. předpokládal jsem adresu v bit-streamu). A to místo zase nevycházelo. Vypadalo to, že se nezapočítává úvodní 00 00 00 01 plus bajt na rozlišení typu slice, ale stejně. A pak mi to došlo! To co takhle krásně navazuje za sebou (vyseklé řádky jsou někde u 32MB) ve skutečnosti vůbec za sebou není!!! Včera bych za to věšel, dnes už jsem klidnější. Ten první odstaveček (@1075083-@1075119) je hlavička pátého (!!!) slice a to co následuje (@1075120-@1075140) jsou data čtvrtého … sigh.

No nic, další zámek snad už tedy povolil. V Pythonu jsem si dopsal třídu VerboseWrapper, tak teď už snad bude jasnější co mi tam chybí nebo dělám špatně …

21. říjen 2013 — coded_block_pattern

Tak snad jsem našel další dva zakopané psy a jejich společný jmenovatel je coded_block_pattern. První co jsem nechápal bylo, jak tabulka, která určuje dekódování počtu prvků může být adresovaná počtem prvků?! Druhý pak kolikrát je třeba volat funkci „residual block”, která vyčte zabalené zbytkové hodnoty rozdílu dvou snímků/makrobloků.

coded_block_pattern určuje 48 různých rozložení makrobloku do sub-makrobloků. Podle popisu se původní 16x16 buď zachová, nebo rozloží na dva 16x8, nebo na dva 8x16 nebo na čtyři 8x8. Ty je pak dále možno zase rozkládat na 8x4, 4x8 nebo 4x4. Z kódu jsem moc nepochopil, kde přesně se tato informace vyskytuje, ale rozhodující jsou 4x4 sub-bloky, kterých se do 16x16 vejde celkem 16. Převodní tabulka pak bitově určuje, který 4x4 blok je uložený.

V mém předešlém příspěvku se vyskytuje pouze 4x Luma. coded_block_pattern má hodnotu 2 a v tabulce mu odpovídá hodnota 1. Je to tedy pouze kódování jednoho 4x4 bloku (vše berte s rezervou, protože si s tím nejsem jistý … na druhou stranu mne až tak nezajímá, zda to náhodou neodpovídá jednomu 16x16 bloku, jako spíše kolikrát musím zavolat funkci „residual block”, abych se dostal k datům dalšího makrobloku).

A teď ten druhý pes, tedy vlastně první. Jakou mám použít tabulku pro načtení počtu nenulových prvků, když toto číslo ještě neznám? Důležité je chybějící slovo odhad. Mám-li zmíněný makroblok se čtyřmi Luma popisy, tak u prvního nevím nic a tak můj odhad bude 0. U druhého, který je vpravo od prvního, si můžu tipnout, že prvku bude jako u prvního. Třetí, dole pod prvním, také může použít tuto informaci. A konečně čtvrtý prvek pro odhad použije výsledky druhého a třetího. Po převedení indexace od 0 to vypadá takto:

if cbp in [2,3]:
    nC = [0]*4
    nC[0] = residual( bs, nC=0 ) # Luma only 4x
    nC[1] = residual( bs, nC[0] ) # left
    nC[2] = residual( bs, nC[0] ) # up
    nC[3] = residual( bs, (nC[1]+nC[2]+1)/2 ) # (left+up)/2

Teď mi ještě není jasné, zda se na tuto sousednost hraje i mezi jednotlivými 4x4 bloky. Podle složitosti indexování bych tipoval že ano.

Vedle Luma se v makroblocích vyskytuje ještě ChrDC a ChrAC:

*** POC: 2 (I/P) MB: 1 Slice: 0 Type 0 **
@1075143 mb_skip_run                                                 1 (  0) 
@1075144 mb_type                                                     1 (  0) 
@1075145 mvd0_l0                                                     1 (  0) 
@1075146 mvd1_l0                                                     1 (  0) 
@1075147 coded_block_pattern                                     00111 ( 32) 
@1075152 mb_qp_delta                                               011 ( -1) 
@1075155 ChrDC # c & tr.1s  #c=0 #t1=0                              01 (  1) 
@1075157 ChrDC # c & tr.1s  #c=0 #t1=0                              01 (  1) 
@1075159 ChrAC # c & tr.1s vlc=0 #c=0 #t1=0                          1 (  1) 
@1075160 ChrAC # c & tr.1s vlc=0 #c=0 #t1=0                          1 (  1) 
@1075161 ChrAC # c & tr.1s vlc=0 #c=0 #t1=0                          1 (  1) 
@1075162 ChrAC # c & tr.1s vlc=0 #c=0 #t1=0                          1 (  1) 
@1075163 ChrAC # c & tr.1s vlc=0 #c=3 #t1=3                      00011 (  3) 
@1075168 ChrAC trailing ones sign (2,4)                            101 (  5) 
@1075171 ChrAC totalrun (2,4) vlc=2                             000001 (  1) 
@1075177 ChrAC run (2,4) k=2 vlc=6                                 011 (  3) 
@1075180 ChrAC run (1,4) k=1 vlc=6                                 001 (  1) 
@1075183 ChrAC # c & tr.1s vlc=1 #c=0 #t1=0                         11 (  3) 
@1075185 ChrAC # c & tr.1s vlc=1 #c=0 #t1=0                         11 (  3) 
@1075187 ChrAC # c & tr.1s vlc=0 #c=0 #t1=0                          1 (  1)

Podle dokumentace je:

DC transform coefficient — A transform coefficient for which the frequency index is zero in all dimensions
AC transform coefficient — Any transform coefficient for which the frequency index in one or both dimensions is non-zero.

Zase tomu nerozumím, ale pozorování je, že makrobloky buď mají jenom Luma (po převedení tabulkou čísla menší než 16), nebo mají navíc ChrDC (čísla menší než 32) nebo mají ještě ChrAC (od 32 výše), která automaticky obsahují i ChrDC a podle bitového vzoru počet Luma.

Jsem líný přepisovat všechny ty tabulky (ono na to stejně dojde), tak to dělám postupně a zatím jsem se dohrabal k makrobloku číslo 10 (z referenčního videa).

TO BE CONTINUED

24. říjen 2013 — test first (again)

Je to peklo! Skoro bych řekl hotový očistec. Teď si ani nedovedu představit, jak bych to býval implementoval bez referenčního testovacího vzorku. A těch chyb!! Byl jsem hodně naivní, když jsem si myslel, že tento prodloužený víkend bych už to uzavřel s testovacím letem. Ostatně v detailu to můžete sledovat (nebo mi možná i pomoci? ) na githubu. Progres je vidět na řádce 340, ke kolikátému makrobloku jsem se dostal …

Chcete si to sami zkusit? Nainstaluje te si Python, naklonujte git repository a pusťte si

h264.py test\frame0001.bin

a pokud výstup bude alespoň trošku podobný jako frame0001.txt (oříznutý na pouhých 262 makrobloků, tj. cca 600MB textový soubor).

A co je nového? Jednak hodnoty nC pro odhad počtu nenulových prvků se počítají i s již dekódovaných sousedních makrobloků … ale to se dalo tak trošku tušit. Dále jsem doplnil X binárních tabulek a pár bitů opravil. Zatím jsem se dostal k makrobloku číslo 23, tj. ještě ani celou řádku z prvního obrázku nemám … trošku depresivní.

29. říjen 2013 — Foxit

Dnes jsem konečně doplnil coefTokenMapping tabulky v dekódování residual dat. Měl jsem problém, jak dostat použitelný text z PDFka … vtipně tam totiž mají po blocích mezery a mezera je stejně tak na oddělení sloupců. Vyřešit se to ale dá např. jiným PDF prohlížečem (díky za tip Ondrovi). Konkrétně Foxit umožňuje přepojení do textového režimu (View/Text Viewer) a pak dostanete textové tabulky, kde sloupečky jsou oddělené více mezerami.

Aby jste získali co opravdu potřebujete, tak už stačí něco jako:

a = ["".join(x.split()) for x in line.split("  ") if len(x) > 0 ]

a už je možné tabulky poskládat .

p.s. dnes se omlouvám za ještě více překlepů než normálně. Nemám ještě doinstalované některé fonty (?) a tak většinu českých znaků vidím jako čtvereček …

31. říjen 2013 — První řádek

Před časem jsem si říkal, že až dekóduji první řádek, tak to náležitě „oslavím”. Když k tomu došlo (cca předevčírem?), tak jsem žádný pocit dosaženého milníku neměl a pokračoval jsem dál. Včera jsem se dostal na konec referenčního textového souboru, tak teď asi přejdu na větší, ještě vygenerovaný na starém počítači, co má 80MB.

Ze změn, které jinak můžete detailně sledovat na githubu, asi stojí za zmínku dekódování nenulových prvků (level) a pak už konečně ty posuny (mvd). Level je v dokumentaci popsán dvěma stránkami a moc pochopitelné to pro změnu není :-(. Tabulka je tam jenom jedna, ale evidentně se jich používá více (konkrétně 6). V tomto smyslu mi byl více nápomocný článek o paralelním dekódování, kde jsou tabulky vypsané. I ten princip je tam srozumitelnější — ve zkratce když jdete od konce, tak tam jsou většinou 0 a 1 a prvky postupně s vysokou pravděpodobností rostou (v absolutní hodnotě). Přecházíte tedy od jedné tabulky k další. Existuje ještě „threshold table” popisující limity pro přechod na další tabulku. Toto jsem ale zatím ještě neimplementoval a čekám až narazím na reálný příklad.

O nefunkčních příkladech bych se možná také trošku zmínil. Je to jedna ze zásad eXtrémního programování, kdy do unit-testu přidáváte „co se rozbilo” nebo „co nefungovalo”. Vedle referenčního výstupu se mi to osvědčilo i tady, takže h264_test.py postupně narůstá (konkrétně testResidual()).

A co mvd, posuny makrobloků? Je to další hádanka. Jak se dostat z (x,y,dx,dy)

asi vymyslí každý, ale jak od druhého řádku dál zatím s jistotou nevím. Zase jeden příklad

Vedle relativní změny k sousedovi je zde zase odkaz na předešlý řádek, ale nevypadá to na průměr (?). Stejně tak ještě nemám úplně jasno co se má dít s proměnnými při skipMacroblock > 0. Zda se mají nulovat nebo nastavit na nedefinované. Ale to snad také ukáže příklad z těch 80MB.

2. listopad 2013 — mvd median

Tak jsem konečně rozlousknul vektory posunů v celém prvním snímku. Největší hádanka byla, co se bere jako predikce vektoru u druhého a dalších řádků. Ostatně jsem to zmínil už minule. A řešení? V naprosté většině případů se bere prostřední hodnota (medián) ze tří prvků: makrobklok vlevo, makroblok nahoře a makroblok nahoře vpravo. Zvlášť ten poslední prvek byl pro mne novinkou. Ale to není všechno. Na konci řádku už není žádný „nahoře vpravo” a tak se použije „nahoře vlevo”.

Popsaný algoritmus funguje na první snímek, ale selže u jednoho vektoru ve druhém snímku. Další zakopaný pes bude ještě u přeskakování makrobloků. Zatím používám nulové vektory posunutí, ze kterých se pak medián počítá, ale není to 100%. Takže další TODO.

3. listopad 2013 — skip_macroblock

Druhý offline záznam … potvrzuji, že další pes byl spojen s přeskakováním makrobloků, tedy ve funkci skip_macroblock(). Při přeskakování jsem doplňoval chybějící vektory pohybu hodnotou (0,0) a většinou to fungovalo. Kde byla zrada jsem pochopil až při krokování a breakpointu v počítání mediánu, kam se mi program dostal při přeskakování makrobloků! Prostě je tam další podmínka: pokud makroblok vlevo i nahoře má nenulový vektor posunutí, tak použij medián jako při zpracování běžného makrobloku.

Teď už vektory posunutí sedí 100% a zpracování se kousne až u desátého referenčního snímku na nějaké chybě parsování …

p.s. chyba u desátého snímku byla v

@2434573 ChrDC # c & tr.1s  #c=4 #t1=3                         0000000 (  0)

tj. všechny prvky (pro ChrDC to jsou 4) byly nenulové a neměl jsem už číst počet nulových prvků.

6. listopad 2013 — mb_type

Znáte ten pocit, kdy se domníváte, že jste skoro u cíle, ale pak jemně zafouká a realita vám rozboří váš domeček z karet? Tak přesně to jsem prožíval včera ráno. V neděli večer jsem už bezchybně dekódoval prvních 25 snímků, včetně správné interpretace vektorů pohybu. To je cca 90000 makrobloků a přestože byla nějaká chybka ve 26. snímku, tak „cíl přece nemůže být daleko”. Karta se však obrátila, když jsem ten problém lépe analyzoval a zjistil, že typ makrobloku je nenulový. Zalepil to pro jeden případ a bum, další nenulový, ale jiné číslo. OK, další záplata a další a další, to vše jenom v tom 26. snímků. Znova jsem konzultoval dokumentaci (strana 88,tabulka 7-8), abych zjistil, že existuje 25 typů makrobloků, které je třeba speciálně pořešit. Tj. v extrémním/dalším falešném náhledu, jsem zatím ušel jenom 1/25tinu cesty, cha cha …

Po tomto zjištění jsem si chtěl vzít měsíc dovolené (jak je to doslova „dovolená na zotavenou”). Přes den se to trošku rozleželo a asi se na to za chvíli zase podívám . Prioritu by teď měl dostat chodící robot, ale asi to nikoho moc nezajímá, tak to ještě chvíli bude „úloha na pozadí”.

S 25 typy, ono jich je vlastně 26, protože se číslují od nuly, … že by nějaké prokletí 26tky?? Další klíčové slovo je asi Intra16x16PredMode, který je buď DC, Horizontal, Vertical nebo Plane. Někde chybí vektory posunu (vlastně všechny ty protipříklady byly typu DC) … no nevím. Čeho se teď nejvíce děsím je, že bude třeba pracovat s celými 16x16 bloky (případně 16x8, 8x16, 8x8) a nějak odhadovat, kde jsou nenulové prvky v jejich 4x4 podblocích. Predikce počtu nenulových prvků je „centrální dogma”, které dobře funguje pro makroblok typu 0, takže i těch dalších 25 typů na to bude třeba určitě nějak napojit. Prostě radost. Možná si tu dovolenou přeci jenom vezmu a budu raději zjišťovat, jak se dělají střechy a okapy, než začne mrznout …

7. listopad 2013 — frame0026.bin pokořen

Přidal jsem do gitu pro testování 26. snímek: test/frame0026.bin a test/mv0026.txt a klasicky chvíli na to byla oprava na světě . Teď mluvím o opravě vektorů pohybu, které mi dnes dosud u tohoto snímku neseděly. Důvodem byla nutnost ignorovat predikci a natvrdo nastavit (0,0) u těch 25 „nových” mb_type zmiňovaných včera.

Tak trošku tiše přecházím fakt, že už jsem 26. snímek vůbec dekódoval. Matematicky jsem to převedl „na předešlý případ” a programátorsky zase koukám, kdy to bouchne . Dekodér se dohrabal k 94. snímku s tím, že jsou stále drobné chyby na začátku řádků ve vektorech pohybu. Takže příběh stále nekončí …

13. listopad 2013 — levels

Ještě vás to baví číst? Mne už ta 80x45 sudoku občas unavuje. To však po chvíli poleví a jsem zvědavý, na čem se to zase kouslo. Včera jsem revidoval „levels”, tedy nenulové prvky větší než 1. Jedná se o „zbytkové prvky” po transformaci, které v absolutní hodnotě klesají a navíc jsou často prokládány nulami. Kolik je nul mezi jednotlivými prvky se kóduje zvlášť stejně tak pokud je +/-1 na konci méně jak 3.

Kódování dalších prvků je vlastně takový hybrid. Úplně první číslo (jede se od konce) různé od jedničky je kódováno exponenciálně, tedy velikost čísla je daná počtem nul a sekvenci ukončuje jednička. Navíc je třeba sbírat data znaménkově, takže 1=1, 01=-1, 001=2, 0001=-2, … K tomu je hned několik výjimek. Jedna je, že pokud celkový počet prvků je větší než 3 a počet jedniček je různý od tří, tak k načtenému číslu v absolutní hodnotě přičti jedna. To smysl dává, protože když už tam nebyla jednička, nuly se kódují speciálně, tak další nejmenší možné číslo je v absolutní hodnotě dvojka.

Hybrid začíná už od druhého prvku — podle absolutní velikosti se přidává počet bitů pro „suffix”. Ve zkratce přečtete exponenciální prefix, řada nul ukončená jedničkou, a pak přečtete pevný počet bitů a zkombinujete. Počet bitů pro suffix se, zase až na nějaké výjimky a hodně velkými prvky, může zvětšit pro každý prvek jenom o jedničku, pokud absolutní hodnota překročí definované meze:

static const int incVlc[] = {0, 3, 6, 12, 24, 48, 32768};    // maximum vlc = 6

Současná implementace tam má assert na velikost 6. Dostal jsem se ke stému snímku, ale u frame0113.bin se zase něco pokazilo. Z celého referenčního videa jsme cca v 1/6.

p.s. jedna z výjimek je, že z prvního prvku na druhý se může suffix zvětšit na dva bity, pokud první prvek je v absolutní hodnotě větší než 3. Viz H264Test.testLevelTabs2 čtení 1557531 bitu.

15. listopad 2013 — varianta MVPRED_UR

Teď jsem se trošku zasekl na jedné chybě u 113 snímku, 16 řádek, pozice 0. Referenční program se zastavil na breakpointu, který jsem dal na různá místa, která „přeci nemohou nikdy nastat”. To byl případ i MVPRED_UR, konkrétně na mv_prediction.c:216. O co jde? Když se počítá medián pohybu při přeskakování makrobloků, tak, se bere v úvahu levý, horní a horní pravý/levý (podle dostupnosti) blok. Může se stát, že ne všechny informace jsou k dispozici (v Python kódu na to používám None), kde dobrým příkladem je první řádek — tam není ani žádný horní prvek a tak „medián” se bere jenom z levého prvku.

Jak ale na 80x45 velkém snímku docílit toho, že není k dispozici levý a horní prvek, ale pouze horní pravý?! Vypadá to zase na nějakou kličku při přeskakování makrobloků, že (0,16) je úplně vlevo a nemá tedy k dispozici levého předchůdce, informace o pohybu není na (0,15) z důvodu přeskakování (?) k dispozici a tak nastává případ MVPRED_UR a pro odhad se použije pouze horní pravý prvek (1,15).

Rutinu pro medián jsem upravil, ale pokud nahradím nulové prvky při přeskakování nedefinovanými, tak se mi zbytek celý rozsype :-(.

Moje momentální noční můra je, že se jedná o odkaz na starší snímek 112 (no snad to číslo nebudu muset volat) a tam se třeba také přeskakovalo, takže reference není k dispozici???

p.s. dostal jsem ho! Už dlouho jsem ve Visualu nepouštěl breakpoint na změnu hodnoty na daném paměťovém místě … v popisu výše jsem pomíchal (0,15) a (1,15) … první k dispozici byla a druhá ne, tj. celé to byl MVPRED_U, ale princip je stejný. A důvod? Vzpomínáte na „nedávno objevených” dalších 25 typů makrobloků? (1,15) byl typu 22, tj. „intra_chroma_pred_mode”, pro který není vektor pohybu definovaný. Oprava byla triviální — viz diff

19. listopad 2013 — kříženci

Aneb co se stane, když zkombinujete „intra blok” se „skip blokem”? No nedopadne to dobře. Intra blok nemá predikci pohybu. To ale neznamená, že není k dispozici! Zní to zmateně? Ani se nedivím. Prostě jak jsem minule psal, že pokud neznám vektor pohybu pro daný prvek (vlevo nebo nahoře) a používám (None,None), tak to nestačí a je třeba dodat důvod, proč je to None. Medián se použije skoro vždy jen s výjimkou, že jste na kraji (tj. None z důvodu první řádky nebo prvního sloupce) nebo levý či horní prvek je k dispozici a má nulový vektor. Vyřešena další „záhada”.

A jak jsme na tom po čtyřech měsících „trápení”? Jsme zhruba v 1/5 referenčního videa. Teď se to pokazí u snímku 00147.

21. listopad 2013 — Luma lev 17

Dnes ráno jsem měl krásný úlovek:

@1365333 Luma # c & tr.1s vlc=1 #c=1 #t1=0                      001011 ( 11) 
@1365339 Luma lev (0,0) k=0 vlc=0                  0000000000000010001 ( 17) 
@1365358 Luma totalrun (0,0) vlc=0                                   1 (  1)

No není to nádhera? Nemáte trošku pocit, že už mi to leze na mozek?

Dodělal jsem už snad pořádně přechodové tabulky pro Luma Level a Luma lev 17 je příklad tak velkého čísla, že se z 0té tabulky skáče rovnou na čtvrtou a výsledné číslo je zde 17 (frame0187.bin MB: 24). Jo, spadlo mi to tam. Proč? Extra mezera v tabulce kódů. Pro zájemce viz github.

22. listopad 2013 — levelSuffixSize

Tentokrát se to rozbilo „u 18 lvů” (frame0228.bin MB:30) — prostě ta výjimka, co jsem jí popisoval včera, je pouze jednorázová. Nepřeskakuje se tedy na čtrtou tabulku, ale pouze jednorázově se přečtou čtyři bity a dál se pokračuje „jako by se nechumelilo”.

Po opravě se dostávám k frame0305.bin. Naivně bych si teď myslel, že mám tak jednu chybu ve sto snímcích (???) a mohl bych si už dovolit přejít „do výroby”. Je tam ale nutné dodělat rozpoznávání, že byl snímek špatně dekódovan (aktuální představa je, že pokud parsování skončí na posledním bajtu načteného paketu, tak je vše OK) a pak možnost to celé úplně zastavit, pokud je to hodně špatně (např. se opravdu odkazuje na více snímků zpět). Pro to bych asi použil trik, který jsem slyšel tento týden na prezentaci Universal Robots: pokud se ve výrobě objeví dva zmetky za sebou, tak se linka zastaví. To zní jako jednoduchý algoritmus, co myslíte?

23. listopad 2013 — Functional testing

Funkcionální testování je další důležitý prvek eXtrémního programování. Na rozdíl od unit testů, které musí vždy všechny projít, úspěšnost fukcionálních testů je proměnlivá a měla by vystihovat aktuální funkcionalitu programu.

Mým funkcionálním testem vlastně bylo parsování referenčního videa. Číslo snímku, kam až se dostanu, ale není moc vypovídající. Jak jsem psal včera, já vlastně nepotřebuji úspěšně parsovat všechny snímky a např. 99% úspěšnost by mi stačila. Postupné dekódování jsem nahradil statistikou přes všechny snímky. A jak to dopadlo? Ze 707 snímků jich 10 selhává. Všechno samozřejmě za předpokladu, že ten test je správný.

p.s. pamatujete na 17 a 18 lvů? Tak snímek 305 to pokořil: 0000000000000001000000000001 (4097) … teď už prošlo 705 snímků z 707, tj. 99.7% to by snad šlo.

25. listopad 2013 — ESCAPE

Když jsem v sobotu dosáhl stavu, že už jenom dva snímky selhávají (frame0380.bin a frame0706.bin), nechal jsem to trošku uležet. Udělal jsem si unit test na makroblok, kde se výpis rozcházel s referencí, ale ten prošel bez problémů!? Nechápal jsem. Pak mne napadlo jediné vysvětlení a to, že co se píše v trace logu není totožné s tím, co je v binárních datech. Zase chvíle na HEX editor …

A co jsem ošidil tentokrát? Neřešil jsem ESCAPE znaky, které mají zabránit nechtěnému start bloku uprostřed dat snímku. Oprava je taková, že pokud je v sekvenci bajtově 00 00 03 XX, tak jí je třeba nahradit 00 00 XX. Případně viz opravu na githubu.

A ta druhá chyba? Žádná není — jak Heidi havarovala, tak je video přerušené a data posledního snímku tedy nejsou kompletní … . Je to zvláštní pocit, když všech 24MB referenčních pohybu 100% sedí … ale nějakou extra radost z toho nemám. Prostě jak mne kdysi nazval kolega v práci, že jsem „nepotěšitelný člověk” . Podle eXtrémního programování jsem s dekodérem hotov, dokud se neobjeví nějaká další chyba. Je čas na optimalizace a začištění kódu … a hlavně integraci do navigace drony!!! … no trošku škoda, že venku už mrzne.

6. prosinec 2013 — bittables

Minulý týden jsme se s Ondrou a Zbyňkem bavili o aktuální implementaci pythonovského dekódování H264 video codecu. Pustil jsem to tak jak to je v profileru na referenční video a vychází to cca 2 zpracované snímky za sekundu, což není moc. Mimochodem, pokud to neznáte, v Pythonu je rovnou integrovaný i jednoduchý profiler, takže co jsem přesně dostal bylo toto:

265325033 function calls in 373.808 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 15742034  142.370    0.000  238.575    0.000 h264.py:184(residual)
 91092961   94.282    0.000   98.475    0.000 h264.py:27(bit)
 23691275   40.811    0.000   87.999    0.000 h264.py:63(tab)
  2094625   39.971    0.000  345.131    0.000 h264.py:348(macroblockLayer)
 11923219   20.845    0.000   64.202    0.000 h264.py:41(golomb)
      683   12.099    0.018  373.607    0.547 h264.py:461(parsePSlice)
  4483734    7.459    0.000   10.474    0.000 h264.py:445(median)
 14606420    5.612    0.000    5.612    0.000 h264.py:337(mix)
 91096499    4.193    0.000    4.193    0.000 {ord}
  4313872    3.015    0.000    3.015    0.000 {sorted}
  3955682    2.446    0.000   28.555    0.000 h264.py:50(signedGolomb)
   334970    0.291    0.000    0.688    0.000 h264.py:35(bits)
  1977840    0.212    0.000    0.212    0.000 {method 'append' of 'list' objects}
        1    0.077    0.077  373.808  373.808 h264.py:642(functionalTest)
      707    0.058    0.000    0.058    0.000 {open}
      707    0.029    0.000    0.029    0.000 {method 'read' of 'file' objects}
      707    0.020    0.000  373.641    0.528 h264.py:557(parseFrameInner)
      707    0.007    0.000    0.007    0.000 {method 'replace' of 'str' objects}
     3535    0.005    0.000    0.005    0.000 h264.py:57(alignedByte)
        1    0.001    0.001    0.001    0.001 {nt.listdir}
      707    0.001    0.000  373.642    0.528 h264.py:579(parseFrame)
      722    0.001    0.000    0.001    0.000 {method 'startswith' of 'str' objects}
      707    0.001    0.000    0.008    0.000 h264.py:131(removeEscape)
      707    0.000    0.000    0.000    0.000 h264.py:23(__init__)
     2006    0.000    0.000    0.000    0.000 {len}
        1    0.000    0.000  373.808  373.808 h264.py:6()
        1    0.000    0.000    0.000    0.000 h264.py:22(BitStream)
        1    0.000    0.000    0.000    0.000 h264.py:77(VerboseWrapper)
        1    0.000    0.000    0.000    0.000 h264.py:11(setVerbose)
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}

Druhý pokus, který byl skoro zadarmo, byl nainstalovat pypy, což je alternativní implementace Pythonu s „Just-in-Time” kompilerem, a pustit to v tom. Výsledek?

261010454 function calls in 165.356 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 23691275 1563207619897.772 65982.418 -3153386446098.892 -133103.282 h264.py:63(tab)
 91092961 536353730042.098 5887.982 536353741505.578 5887.982 h264.py:27(bit)
   334970 321684266772.059 960337.543 -296438412397.484 -884970.034 h264.py:35(bits)
 11923219 307659624818.975 25803.403 -243097552805.106 -20388.584 h264.py:41(golomb)
      683 163616892732.185 239556211.907  165.020    0.242 h264.py:461(parsePSlice)
  3955682 87309675664.466 22071.965 -244719216.961  -61.865 h264.py:50(signedGolomb)
  2094625 28846.299    0.014 -244579229.288 -116.765 h264.py:348(macroblockLayer)
 91096499 11463.483    0.000 11463.483    0.000 {ord}
 14606420 2244.535    0.000 2244.535    0.000 h264.py:337(mix)
        1    0.218    0.218  165.356  165.356 h264.py:642(functionalTest)
      707    0.036    0.000    0.036    0.000 {method 'read' of 'file' objects}
      707    0.025    0.000  165.095    0.234 h264.py:557(parseFrameInner)
      707    0.021    0.000    0.021    0.000 {method 'replace' of 'str' objects}
     3535    0.020    0.000    0.023    0.000 h264.py:57(alignedByte)
      707    0.003    0.000    0.003    0.000 h264.py:23(__init__)
     2006    0.003    0.000    0.003    0.000 {len}
      722    0.002    0.000    0.002    0.000 {method 'startswith' of 'str' objects}
      707    0.002    0.000    0.023    0.000 h264.py:131(removeEscape)
      707    0.002    0.000  165.097    0.234 h264.py:579(parseFrame)
        1    0.001    0.001    0.001    0.001 {nt.listdir}
        1    0.000    0.000  165.357  165.357 h264.py:2()
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
        1    0.000    0.000    0.000    0.000 h264.py:22(BitStream)
        1    0.000    0.000    0.000    0.000 h264.py:77(VerboseWrapper)
        1    0.000    0.000    0.000    0.000 h264.py:11(setVerbose)
  4483734 -3669274014.929 -818.352 -3669274014.929 -818.352 h264.py:445(median)
  1977840 -4159866550.303 -2103.237 -4159866550.303 -2103.237 {method 'append' of 'list' objects}
 15742034 -2972002711751.617 -188794.073 94047.814    0.006 h264.py:184(residual)

Ta záporná čísla vypadají trošku podezřele, ale v zásadě 707 snímků bylo zpracováno v čase 165.3s a s klasickým Pythonem to trvalo 373.8s. To by už byly zhruba 4 snímky za sekundu (bez práce), ale to je stále málo … možná.

Tak co s tím?

načtení jednotlivých bitů je drahé (ano, není divu — z pohodlnosti si hraji s "0"/"1" stringy místo přímo bity)
tabulky jsou lokální a s každým voláním je tedy třeba je znova vytvořit
dekódování bitového streamu do tabulek dělám tak, že postupně načítám bity a ptám se, jestli už v tabulce nejsou

Třetí bod jsme právě minulý týden diskutovali a Ondra to pak nevydržel a rovnou ten kousek napsal jako příklad, viz bittables.py nebo můj mini pokus o test bittables_test.py. Už jsme tedy na githubu 2 contributors .

O co jde? Jedná se o stavový automat s jednoduchou přechodovou tabulkou. Začínáte ve stavu 0. Když načtete bit 0, tak si další stav přečtete z tab[0] a když 1, tak z tab[1]. Spodním bitem je kódovaná informace, že už jste výsledek našli a zbytek čísla udává index do výsledkové tabulky. Pokud je spodní bit nula, tak pokračujete v tab[stav+0] nebo tab[stav+1]. Je to jasné? Pokud ne, tak možná je to lépe vidět přímo v tom zdroji …

p.s. ještě spíše pro sebe si sem schovám referenční volání:

m:\git\h264-drone-vision>c:\python27\python.exe -m cProfile -s time h264.py -f m:\git\data0\frames\ > tmp.txt

p.p.s.s. globalizace pomohla … je to sice celkově jen o třetinu rychlejší (v klasickém Pythonu), ale např. nejčastěji volaná funkce residual() je 3x rychlejší:

15742034   32.250    0.000  123.116    0.000 h264.py:187(residual)

14. prosinec 2013 — generátor a automaty

Dnes jsem snad plně implementoval generátor bitů (k mému překvapení viditelné zrychlení) a automaty místo hledání v tabulkách (viz úvodní část v h264.py. Je to lepší, ale ještě to stále není dobré. Když jsem to spustil v PYPY, tak jsem dostal nesmyslný čas (344990319 function calls in -19819172.282 seconds), ale volání hlavní funkce je zřejmé:

707    0.001    0.000  105.716    0.150 h264.py:555(parseFrame)

tj. 707 snímků za 105s … a tedy cca 6.7 snímků za sekundu. Pokud bych to pustil ve čtyřech procesech, tak se možná dostanu na 25 FPS, ale to je moc na hranici …

25. prosinec 2013 — Heidi zdrojáky

Dnes jsem dal na github zdrojáky Heidi. Bylo by pěkné je nejprve trošku uklidit, okomentovat a vyříznout jen „zdravé jádro”, ale toho bychom se nemuseli dočkat. Takže tam najdete mix pokusů z AirRace, Robotem rovně i RoboOrienteeringu. Na druhou stranu, pokud jste dostali pod stromeček AR Drone 2.0, tak si rovnou můžete v Pythonu hrát …

A nějaké další motivace? No chtěl jsem začít s tou integraci pro první testy s létáním a současným pársováním H264 kodeku a to se nutně bude odkazovat do už existujících zdrojáků na létání. Pokud toto bude číst někdo, kdo by to opravdu použil/používal, tak mi prosím dejte vědět — věřím, že ten kód půjde přetvořit v něco lépe stravitelného .

27. prosinec 2013 — multiprocessing

Včera večer jsem se v tom nějak zamotal. Nahrávání, a teď nově i zpracování, videa běží v odděleném procesu, aby nijak nezdržovalo hlavní řídící smyčku. Za tímto účelem používám modul multiprocessing a z něj pak Process a Queue. Modul nabízí podobnou funkcionalitu jako threading, ale oddělený Process může běžet na jiném procesoru.

Má to ale drobný zádrhel a to v komunikaci mezi jednotlivými procesy. Python se snaží, ale občas nemá šanci. Pokud si dobře vybavuji, jak mi to Zbyněk kdysi vysvětloval, tak vlastně pustí paralelně další interpreter a pokud se nějaký datový typ používá u obou, tak se serializuje tam a zpátky. A to někdy nejde. Kdy? Například pokud si uděláte třídu PacketProcessor, která slepuje jednotlivé video pakety (jsou celkem dost rozkouskované, typická velikost byla 1460 bajtů), a přidáte si do toho vlákno, které by v mezičase zpracovávalo nejnovější kompletní frame. Pokud hloupě tuto instanci třídy používáte i v hlavním programu (koukal na výsledky analýzy), tak to skončí chybou jako:

pickle.PicklingError: Can't pickle <type 'thread.lock'>: it's not found as thread.lock

Pro účely meziprocesové komunikace existují vhodnější nástroje: Queue, Pipe, Lock … vše z modulu multiprocessing. A kde, že jsem se to zamotal? Chtěl jsem do ARDrone2 přidat, stejně jako je to u robota Eduro, registerDataSource() a addExtension(). První přidá zdroj dat a hlavní smyčka robota se ho pak ptá, zda není něco nového. Druhá přidá konzumenta, který čte „novinky” a podle toho něco dělá nebo nastavuje vnitřní stav robota. Tak do podobného (možná stejného??) rámce se snažím zpracování videa napasovat a první pokus se úplně nepovedl (takže jsem ho zatím ještě ani nekomitoval).

A co jinak? Z výpisů

insmod /data/video/driver2/cdc-acm.ko
insmod: can't insert '/data/video/driver2/cdc-acm.ko': invalid module format

soudím, že po flashnutí nové verze firmware (cca před půl rokem??) jsem ještě nezkompiloval „nové” moduly pro čtení dat ze sonaru po USB (liší se build verze kernelu). Také přišel mail z ARDrone API konference, že nový AR.FreeFlight 2.4.10 aplikace podporuje „GPS flight recorder” a kdy to konečně přidají do SDK? No některé jednohvězdičkové komentáře mne moc neuklidňují: Shame on Parrot Buggy at best. Using the GPS and the return to home button caused my drone to dive into the street from 30' destroying the nose. I am done with Parrot's lies, faulty app, and extremely poor customer service. Tak snad to přes víkend nerozbiji s novou oficiální aplikací .

28. prosinec 2013 — příprava na let H-264-00

Včera večer jsem to nějak upatlal. Zakomentoval jsem pouštění sonaru (včetně přehrávání z logu), přidal logování src_h264_*, obešel asserty … no prostě hrůza.

Plán je odkomentovat řádku 135 (opravdu jde na githubu generovat URL pro vybranou řádku )

#drone.takeoff( enabledCorrections = False )

a pak možná změnit limit na řádce 137:

for i in xrange(100):

resp. to předělat na reálný čas. Heidi by se tedy měla vznést, chvíli logovat data a zase přistát.

V dalším kroku bych změnil příkaz pohybu:

drone.moveXYZA( 0.0, 0.0, 0.0, 0.0 )

drone.moveXYZA( 1.0, 0.0, 0.0, 0.0 )

tj. 1m/s pohyb vpřed a pak to zkoumal doma z logů … tak to by nedopadlo dobře. Už jsem to vše zapomněl. Podle homologace z RoboOrienteeringu 2013 (a ještě nedodělané) to jen nastaví úhel pro let v X-ové ose a musím si hlídat rychlost vx.

K logování bych možná měl také poznámku: teď se loguje počet větších vektorů (definovaných proměnnou THRESHOLD) v jednotlivých kvadrantech, přesněji polovinách, tj. vždy součty dvou kvadrantu. Další TODO. Pro přehrávání tedy není nutné znova zpracovávat video.

Na druhou stranu by se určitě hodila i možnost revize tohoto zdroje — podobně to bylo na robotu Eduro, kdy např. při sbírání puků detektor posílal pozice puků v obraze. Jelikož se nezpracovává každý snímek (zatím to nestíhám), ale ukládají se všechny, tak budu potřebovat nějakou značku, který snímek to byl. Pokud si dobře vzpomínám, tak PaVE video hlavička obsahovala i časovou známku, tak tu tam budu muset do výsledku analýzy snímku přidat. Log momentálně vypadá takto (src_h264_131227_214401.log):

0
(0, 0, 0, 0)
1
(56, 54, 62, 48)
1
(310, 427, 365, 372)
1
(130, 159, 116, 173)
6
(425, 470, 427, 468)
33
(194, 165, 150, 209)
29
(172, 169, 140, 201)
29

Na začátku jsou jedničky, protože zpracování obrazu naběhne o trošku dříve, než samotná řídící smyčka (to by mimochodem řešili ty dataSource, které jsem tam přidal a zatím zase vyhodil). Jakému reálnému času odpovídá číslo 33 nevím, chyba, ale přehráním logu a výpisem drone.time se to dozvím:

…
AT*CONFIG=%i,"video:video_codec","130"
QUEUE 1218.419403 (0, 0, 0, 0)
QUEUE 1218.429443 (56, 54, 62, 48)
QUEUE 1218.439361 (310, 427, 365, 372)
QUEUE 1218.449401 (130, 159, 116, 173)
QUEUE 1218.51004 (425, 470, 427, 468)
QUEUE 1218.841949 (194, 165, 150, 209)
QUEUE 1219.133605 (172, 169, 140, 201)
Landing … (0.0028891020142788417, -0.019957041168367, 0.0)
…

vypadá to na cca 0.33s (1218.84 - 1218.51), tj. 3 snímky za sekundu. Toto zatím běželo v „normálním” Pythonu. Udělal jsem ještě drobné přesuny, abych to mohl celé pustit pod PYPY, tak uvidíme.

V současnosti vím o následujících problémech:

jak už se počítá, tak spojení chvílema zadrhává a PaVE značka nemusí být na začátku paketu (zmiňovaný zakomentovaný assert).
pracuji s nahrávaným videem, které bude mít oproti realitě nějaké zpoždění. Bude třeba přejít na jiný kanál a nahrávání vypnout (v H264 kodeku se posílá pouze jeden kanál, video procesor toho více nestíhá).

29. prosinec 2013 — Let H-264-00

Pokud si myslíte, že něco bude fungovat hned na poprvé, tak jste ještě hodně naivní . Že půjde vše hladce jsem nečekal, ale přeci jenom jsem byl klasický programátor optimista. Tak zase pěkně chronologicky …

Včera jsem poprvé létal s novou Android aplikaci AR.Free Flight 2.4.10 s Flight Recorder modulem. Moc jsem toho nenalétal, ale také jsem s Heidi nehavaroval . GPS funkcionalitu jsem moc nepoužil — je pěkně skrytá v pravém horním rohu. Nahrávání na USB disk fungovalo pěkně. Drona se občas propadala i několik metrů, tak jsem se bál, že narazím do skály, ale konec dobrý, všechno dobré.

Dnes jsem Android aplikaci zkoušel znova a narazil na tlačítko „store map”. Dostanete se tak na Google maps a můžete si stáhnout některé mapové čtverce. Nevím zda stažením dalšího okolí nutně ztrácíte původně uložené mapy, ale minimálně to vypadá lépe něž klikání do šedivé plochy. Po zapnutí čtyřtulky se ukáže GPS poloha včetně kruhu s očekávanou chybou. Lehce foukalo a tak byla drona hned po startu trošku unášená. Podle GPS stopy „o tom věděla”, ale nic s tím nedělala. Při druhém pokusu začal tablet zuřivě pípat, že dochází baterky, a tak jsem vybalil notebook a konečně začal dělat to co jsem měl: test kódu s H264.

Zkoušel jsem rovnou PYPY, ale ještě jsem raději neodkomentoval drone.takeoff(). A to bylo dobře. Při prvním startu vyskočilo okno firewallu. Při druhém startu neustále timeoutoval video kanál. Před tím jsem ukládal video na USB disk, takže to asi dělal i dál. Vypojil jsem GPS modul a znova firewall, ale pak už video data začala chodit.

Odkomentoval jsem start, drona vzlétla, ale na místě se moc nedržela. Větřík udělal své, takže příkaz pro let vpřed ani nebyl potřeba. Druhý test vypadal dost podobně. Třetí test jsem zkoušel ruční řízení a

ManualControlException
Traceback (most recent call last):
  File "app_main.py", line 72, in run_toplevel
  File "h264drone.py", line 192, in <module>
    h264drone( replayLog=replayLog, metaLog=metaLog )
  File "h264drone.py", line 148, in h264drone
    manualControl( drone )
NameError: global name 'manualControl' is not defined

a došlo na převracení čryřtulky ve vzduchu …

Logy zatím nic moc:

0
(0, 0, 0, 0)
1
(1, 0, 1, 0)
1
(7, 31, 0, 38)
1
(0, 1, 0, 1)
1
(135, 129, 3, 261)
1
(0, 0, 0, 0)
1
(1, 0, 1, 0)
1
(0, 0, 0, 0)

a vypadá to, že na rozdíl od normálního Pythonu PYPY skončí nějak divně …

30. prosinec 2013 — Let H-264-01

Dnes jen krátce. Asi bych začal video záznamem letu H-264-01. Letěl jsem s tímto kódem (jen jsem ještě odmazal zbytečný update). V reálu jsem si pouze všiml několika výpadků spojení a následné kolize. To, že se čtyřtulka otáčí kolem své osy jsem viděl až z videozáznamu.

Přemýšlím, co si asi případný čtenář pomyslí, ale toto je ten důvod:

drone.moveXYZA( drone.speed, 0.0, 0.0, vz )

Místo aby se drona zvedla rychlostí vz, tak se tou rychlostí otáčela. Poslední parametr totiž není Z, ale A (angle).

Motivací pro řízení výšky byl jediný nenulový snímek z letu H-264-00:

(135, 129, 3, 261)

left, right, up, down … mimochodem, tento kód jsem nemohl při pygame přehrávání najít a chvilku mi trvalo si uvědomit, že při prvních testech jsem integroval vektory přes 3 snímky, ty ale teď nemám, takže používám jenom jeden snímek. Let H-264-01 měl tedy vyzkoušet regulaci pohybu nahoru a dolu a zároveň lépe logovat číslo snímku a timestamp.

…
52
(203L, 329399L, (0, 0, 0, 0))
179
(217L, 329855L, (289, 290, 182, 397))
75
(246L, 330801L, (0, 0, 0, 0))
…

(289, 290, 182, 397)

… no moc pěkně to nevypadá :-(.

9. leden 2014 — Parrot MiniDrone

Byl jsem celkem zvědavý, s čím přijde Parrot na letošní CES, a je to MiniDrone a skákací robot (Kamile, díky za link ).

Parrot MiniDrone, převzato z mobilmania.cz

Podle fotky z MobilMania to vypadá, že navigace pomocí spodní kamery a sonaru zůstává, ale zbytek je zatím záhadou. Místo WiFi se pro řízení používá Bluetooth. Na hraní po místnosti to vypadá jako vhodnější hračka než velká drona … no necháme se překvapit.

13. leden 2014 — Pohyblivý strom

O víkendu jsem zase udělal malinký krůček vpřed. Skoro mám pocit, jestli to s tím logováním nepřeháním … na githubu je vidět, kdy jsem co kódoval (teď už se tam píše jen „2 days ago”, ale lze to zjistit přesně) a z logů (meta_140112_144903.log .. meta_140112_151852.log), kdy jsem s létáním začal a kdy skončil …

Vznikla nová třída PaVE (samozřejmě současně s PaVETest). Je to Parrotem používaná zkratka za „Parrot Video Encapsulation” a třída skládá přišlá data po TCP do „obrázkových paketů” (začínajících právě značkou „PaVE”). Byla to problémová část u předešlých letů, tak teď už je to snad udělané lépe.

Byla to radost programovat — asi to není učebnicový postup, ale mne celkem vyhovuje:

dummy implementace, která skoro nic nedělá, ale definuje interface
první verze, co řeší triviální příklady
malý refactoring
pořádný test na různých video souborech s různou délkou paketu
integrace a nahrazení starého kódu

Vypnul jsem nahrávání videa a přešel na základní nebufferovaný video kanál. Zdržení by tedy mělo být minimální, ale různé snímky vypadávají a kvalita obrazu je o řád horší. Množství přenášených dat lze regulovat, ale s tím jsem zatím neexperimentoval.

A co to v „letové sadě” H-264-02 dělalo? Úplně první pokus drona vzlétla snad do osmi metrů a manuálně jsem ji musel donutit přistát. Sice se mi nechtělo to moc opakovat, ale „jedno měření, žádné měření” a podruhé a potřetí letěla podle očekávání. Heidi měla pouze regulovat výšku, na základě informací z kamery, tak jsem na analýzu toho prvního letu celkem zvědav.

V další sérii mi skončila na stromě. Už nevím přesně co se dělo (mírně foukalo) a pod dronou byl strom, takže přistát nebyla správá volba. No procvičil jsem si v dalším letu „manuální řízení” a pak už se to neopakovalo.

A co ty „pohyblivé stromy”?? Ale … to byl jen takový nápad, jak simulovat „les” jedním stromem. A jelikož jsem nechtěl bourat do těch mála co na zahradě máme, tak jsem si vzal ulomenou větev (4m dlouhou?) a strom simuloval. Asi bych potřeboval asistenta …

5. únor 2014 — Chodba

Jelikož počasí na testování venku není úplně ideální, tak jsem chtěl vyzkoušet let chodbou na ČZU a nasbírat nějaká další testovací data. V idealistickém případě by fungovala „navigace včelky”, tj. která strana by se pohybovala více, ta je blíž a drona by se držela pryč od ní. Celkově tedy ve středu koridoru. Na test nám zbylo posledních 5min a ani v jednom ze dvou pokusu Isabele neodstartovala dostatečně bezpečně, abych jí nechal dál letět rovně. Tak snad zase za týden …

Pohled od stropu

TO BE CONTINUED

26. duben 2014 — Paralelní slalom

Skoro bych mohl začít slovy „bylo nebylo ...”. Je to hrozné, jak to utíká. V pátek mne vyhecoval PetrS k dalším experimentům s H264 kodekem. Je víkend a uvidíme se až v pondělí v práci, takže to je vlastně paralelní slalom, kdo to posune dál .

A přesnější zadání úkolu? Mozaika . Když jsme připravovali Isabelle na Robot Challenge 2014 (anglická verze), tak jsme k navigaci používali obrázky ze spodní kamery. Nakonec jsme létali s nahrávaným video kanálem, který používá H264 kodek (ano, jedna ze „skrytých motivací”). Detaily si najděte v angličtině, ale ve zkratce jsme používali jenom I-frame obrázky, které chodily jednou za sekundu, a 14 P-frame snímků zahazovali. K věci … ty snímky lze pak poskládat do mozaiky jako:

Mozaika z I-frames

Tuto jsem dorovnával ručně (základní posun a natočení byl podle interní pozice čtyřtulky). V OpenCV2 se mi nepodařilo najít dostatečně spolehlivé funkce (možná bude mít někdo nějaké doporučení?) pro korelaci snímků úpravu posunu o pár pixelů. Po pravdě i to otočení by se trošku hodilo, ale kompas byl v tomto případě skoro dostatečný.

A teď to H264. To dělá korelaci makrobloků, není-liž pravda? A ty obsahují pixelové posuny. Nestačilo by tedy jenom vybrat nějaký globální/převažující posun celého snímku a bylo by to hotové? Tu 1/15 bych „už skočil” na základě extrapolace z 14/15. Co myslíte, má to smysl zkusit?

Pokud chcete skriptík, co skládá snímky do jednoho na základě CSV souboru, tak ten naleznete zde (ano, další repository různých OpenCV drobností).

Už jsem za ty čtyři měcíce (alespoň to říkal github o posledním commitu) dost věcí zapomněl. Mám video. To si můžu přehrát a uložit jednotlivé snímky pomocí airrace.py. Zároveň ho můžu rozložit na jednotlivé frame pomocí utilitky video.py. A pak konečně h264.py vrací posuny jednotlivých makrobloků.

První problém je, že video video_rec_140318_200101.bin má rozlišení 640X360. Když to podělíte 16, tak dostanete 22.5. Hmm. Ono tato informace by měla jít číst z SPS, ale ta je přibalovaná pouze k I-frame, který pro test jednotlivého snímku nemáme. Tj. první hack v h264.py:

WIDTH = 40 #80 # for the first experiments hard-coded (otherwise available in SPS)
HEIGHT = 23 #45

Kupodivu pak už to nepadá a vrací pole čtveřic (souřadnice makrobloku a jeho posun).

Tak to PetrSovi moc nezávidím. Sám se v tom „trošku” ztrácím. Nejprve jsem řešil, že funkce h264.parseFrame() nemá jako parametr jméno souboru, ale už přímo binární data (a dekódovala název jako by to byla video data). Pak skutečnost, že místo pole občas vrátí None … hmm … už si vzpomínám. Ono to nebylo 100% funkční, tj. někdy můj dekodér může selhat. Zde je seznam vadných snímků:

26943 26946 2 frame0003.bin
16374 16376 6 frame0124.bin
17644 17646 7 frame0143.bin
15616 15618 3 frame0241.bin
15355 15357 3 frame0657.bin
16311 16313 6 frame0726.bin
15439 15441 3 frame0760.bin
16149 16151 5 frame0766.bin
18554 18556 4 frame0893.bin
23682 23684 1 frame1486.bin

tj. 10 chyb v 1566 snímcích … chyba 0.6% a další příklady k revizi.

2. červen 2014 — h264show.py

Jak dopadl „paralelní slalom” více jak před měsícem? Bídně. Jeden závodník zakopl hned o první branku a druhý nevyjel vůbec …

… ale to ještě neznamená konec . V rámci příprav na FRE14 jsem si rozchodil dekódování i P-frame a pak už nic nebránilo tomu, abych si mohl přehrávat video a do něj rovnou dokreslovat vektory posunů jednotlivých makrobloků. Zase je to spíše alfa verze, protože parseFrame by asi měl mít na vstupu velikost snímku a pod. Jinak mi h264show.py přijde poměrně jednoduché.

A výsledky? Zkoušel jsem to na datech z AirRace a opravdu tam jsou nějaké divné vektory:

výstup h264show.py

27. říjen 2014 — first-person-drone-racing

V rámci hledání informací pro minidrone Jessica jsem narazil na tento blog a video: first-person-drone-racing

… tak nějak bych si představoval záverečnou prezentaci

5. březen 2015 — Katarina a parsingSPS

Do čeho jsem se to probůh před lety pustil?! Mám teď zase motivaci to posunout o kousek dál, protože Katarina má kompenzaci náklonu a zároveň posílá video data v H.264 kodeku. Už mne přestalo bavit stále přepisovat „konstanty” počtu makrobloků na začátku h264.py a … ono to nebylo zas tak jednoduché (viz diff).

Ano, první překážka byla moje děravá paměť a pak chvíle uhranutí, že to přeci nemohlo být tak strašně složité, když chci přečíst jenom rozměr obrázku?? Pro inspiraci viz nápověda na Stack Overflow … no není to tak triviální. Za zmínku možná stojí i to, že ten popis je jenom začátek — Katarina z nějakého důvodu posíla i časování, ktere je schované v vui_parameters a má tedy bit vui_parameters_present_flag nastavený. Jinak jsem to stále psal „cestou nejmenšího odporu”, tj. pokud se podle daného bitu větvilo další čtení, tak jsem přidal assert, jestli ten kus musím opravdu rozepisovat … a občas jsem musel.

A proč jsem tohoto „kostlivce” zase vytáhl ze skříně? No vedle toho, že mi ho bylo líto bych znova rád zkusil průlet mezi překážkami: jednak školní chodbou a dále v sadu na školním pozemku … a něco o tom sepsat.

8. březen 2015 — ARDrone3 vs. ARDrone2

Že bude trošku rozdíl mezi tím, co posílá Katarina a co posíla Heidi jsem tušil. Ale zároveň jsem si naivně myslel, že možná bude stačit jenom upravit velikost vstupního obrázku. Nestačí.

První „bota” byla celkem jednoduchá:

bs.bits( 14, info="frame_num" ) # HACK! should use parameter from SPS

tj. měl jsem tam natvrdo, že počet bitů na kódování pořadí snímku je 14. Na Katarině jich je 16. To bych nezjistil, kdybych nepoužil už osvědčené nástroje, s TRACE define na 2, hledání výstupního souboru (naštěstí toto jsem si dříve zapsal), pak vzpomínka, že jednotlivé snímky jsou proházené (nejprve se hledá konec snímku a teprve pak se parsuje vnitřek) … a bylo to.

Oprava byla triviální, protože jsem přestal parsovat snímky jednotlivě a SPS jsem řešil před pár dny. Tj. další nastavitelná „globální konstanta”.

Pak ale začalo přituhovat. Narazil jsem na mb_type 2, pak 3, pak 1 … jenom 4 jsem zatím neviděl, resp. nově přidaný assert zatím nevyletěl. Korunu tomu nasadila pětka! O čem mluvím? ARDrone3 už nepoužívá pouze 16x16 makrobloky, ale i jemnější dělení:

@453524 mb_type             010 (  1) 
@453527 mvd_l0              011 ( -1) 
@453530 mvd_l0                1 (  0) 
@453531 mvd_l0              010 (  1) 
@453534 mvd_l0                1 (  0) 

@452700 mb_type             011 (  2) 
@452703 mvd_l0                1 (  0) 
@452704 mvd_l0                1 (  0) 
@452705 mvd_l0                1 (  0) 
@452706 mvd_l0              011 ( -1) 

@451752 mb_type           00100 (  3) 
@451757 sub_mb_type           1 (  0) 
@451758 sub_mb_type           1 (  0) 
@451759 sub_mb_type           1 (  0) 
@451760 sub_mb_type           1 (  0) 
@451761 mvd_l0                1 (  0) 
@451762 mvd_l0                1 (  0) 
@451763 mvd_l0              010 (  1) 
@451766 mvd_l0                1 (  0) 
@451767 mvd_l0                1 (  0) 
@451768 mvd_l0                1 (  0) 
@451769 mvd_l0                1 (  0) 
@451770 mvd_l0                1 (  0) 

@455469 mb_type           00100 (  3) 
@455474 sub_mb_type           1 (  0) 
@455475 sub_mb_type           1 (  0) 
@455476 sub_mb_type           1 (  0) 
@455477 sub_mb_type         010 (  1) 
@455480 mvd_l0              011 ( -1) 
@455483 mvd_l0              010 (  1) 
@455486 mvd_l0              010 (  1) 
@455489 mvd_l0              011 ( -1) 
@455492 mvd_l0                1 (  0) 
@455493 mvd_l0                1 (  0) 
@455494 mvd_l0              010 (  1) 
@455497 mvd_l0              011 ( -1) 
@455500 mvd_l0                1 (  0) 
@455501 mvd_l0                1 (  0)

Jsou to bloky 16x8, 8x16 a i 8x8. Navíc počet posunů mvd_l0 závisí na hodnotě sub_mb_type. Jak se počítají v tomto případě „globální 16x16” offsety zatím netuším, ale to je až druhá fáze.

Konečně k té pětce — na to budete potřebovat odkaz do dokumentace, strana 156, tabulka 9-4. Je tam speciální převodní tabulka pro coded_block_pattern, ale zajímat vás bude tentokrát sloupec Intra_4x4.

Závěr: ARDrone3 má výkonnější procesory a tak si asi může dovolit lepší kompresi videa. Trošku jsem ohackoval i h264show.py, protože ARDrone3 PaVE bloky nepoužívá. Výstupny jsou zatím „divné”, ale doufám, že je to mojí současnou ignorací posunů nových sub-makrobloků. Pro zájemce viz diff.

11. březen 2015 — mikro-pozorování

Ještě jsem ty menší makrobloky nevyřešil, ale jedno malinké pozorování bych měl … a dává to smysl. Ty TRACE výpisy jsou totiž zavádějící — mvd_l0 asi ve skutečnosti popisuje jak x, tak y posun. Pak dává smysl, že při rozdělení makrobloku 16x16 na 2x 16x8 budu mít čtyři mvd_l0 posuny (dva vektory) a pro rozdělení 4x 8x8 těch vektorů bude osm (čtyři vektory posunu). Stejně tak to zapadá do bitového patternu, který se dělá po 4x4 blocích … jen tam musím nějak ty „lokální” posuny integrovat. Mimo jiné to znamená, že posun makrobloku není jedno číslo, ale obecně hned několik. A konečně ignoruji detail, že Luma" a Chroma"" si jdou každá svoji cestou a je třeba se tedy o každou starat zvlášť.

Program je teď ohackovaný pro ladění zmiňovaných nových makrobloků (diff). Opraveny jsou alespoň ty znaménkové Golomby. Možná jsem si měl udělat „pracovní větev” než to bude fungovat alespoň jako předešlý kód … příště.

12. březen 2015 — ARDrone3 - první řada

Teď si naivně myslím, že už zase umím parsovat alespoň první řadu P-slice, který může obsahovat vedle 16x16 makrobloků (mb_type=0) i 16x8, 8x16 a 8x8 (u rozdělení 8x8 na menší 8x4, 4x8 a 4x4 si stále nejsem jistý, resp. tam jsem si ještě stále o řád nejistější ). Narazil jsem v náhodně vyhledaném článku Direct macroblock coding for predictive (P) pictures in the H.264 standard na tento obrázek:

Motion vector prediction

Ono já mám i skoro pocit, že když tady odstránkuji výše, tak narazím na něco podobného (no, nevidím to). Že je aktuální posun makrobloku kombinovaný z levého, horního a pravo-horního posunu vím (tj. A, B, C — D se snad používá pouze pro B-slice(?)). Co mne ale zaujalo byly pozice v rámci 16x16 bloků. Pro A tedy vpravo nahoře a pro B a C vlevo dole. Asi bych si měl ten článek pořádně přečíst a dozvěděl bych se více, ale … já to zatím jenom zkusil s tou levou predikcí a ta na mém prvním příkladu funguje (tedy funguje i na dalších pár prvních řadách co jsem prošel).

Co mi ale zatím nefunguje je druhá a další řady (mimo jiné už tam se nachází jemnější dělení 8x8 bloku). Do gitu to zatím dávat nebudu. Pokud nějaký čtenář tuší o čem mluvím a zná řešení hádanky, tak si klidně nechám napovědět . Je toho teď nějak hodně a nechci tento projekt zanechat na „roky” v nefunkčním stavu (uvědomil jsem si, že dříve jsem důsledně psal unit-testy na špatně rozkódované makrobloky — je na čase se k tomu zase vrátit!).

kontaktní formulář

Na komín

2014-10-07T00:00:00Z

Tak po pořádku. Zvolili jsme relativně jednoduchou a robustní konstrukci , což se ve svém důsledku vyplatilo. Rám byl tvořen z hliníkových profilů jekl, svařen a zbytek byl již spojen šrouby.

Nakonec jsme připustili po všemožných i nemožných návrzích, že konstrukce Fandy je ta, která může přinést úspěch. Konstrukčně relativně jednoduchá, může se dobře přizpůsobit různé rozteči žebříkových stupínků a s relativně jednoduchým řízením a potřebnou rychlostí pro lezení po žebříku.

Po sestavení rámu a motorů ho dostal do ruky Fanda, který mu nandal desku řízení a celou tu chytristiku a ladil a zkoušel a měnil a zase zkoušel. Jako hlavní pohon pro lezení byl použit motor z elektrokola a pro výměnu ramen byl zvolen převodový motor. Protože měl Fanda už vyřešený měnič pro řízení motoru z elektrokola včetně reverzace tak se zdála být realizace snadná . Postavil se simulátor žebříku a zjistilo se, že největší problém je z odskočením žebříku a tak i mechanika a uspořádání doznali další změny. A zase další testy a zkoušení a ladění. Jednou lezl krásně nahoru a dolu, pak se něco stalo a zase nic. Byl z toho hotovej, ale protože je schopen podat bezva výsledky jen ve stresu tak jsem byl docela klidný, já už měl hotovo.

Když mě ale v den odjezdu řekl, když jsme měli kroužek, že to nemá dodělaný a že je nutný, abychom ještě večer šli robota dodělat, tak jsem měl chuť ho uškrtit, já na rozdíl od něj nemám rád práci na poslední chvilku. Takže plánovaný odjezd byl na 22:00 s tím, že pojedeme celou noc a ráno jsme v Košicích akorát na tréning. Co mám líčit prostě soutěž od samého začátku. Tak jsme se ve 20:00 sešli abychom dodělali nutné věci jako tlačítko pro start a stop robota, seřídit táhla a další, s tím že naprogramování už dodělá v Košicích, protože do teď robota spouštěl přes počítač. Jenže když přišel, tak stále testoval robota na zkušebním žebříku. Ale přimontujte něco na robota když je v neustále v pohybu! To už jsem byl fakt naježenej. Do toho všeho nám praskla jedna packa z 8mm makralonu, což si nedovedu moc vysvětlit , tak jsme museli ohnout a vyrobit novou a pro jistotu ještě jednu náhradní. No co mám líčit — nakonec místo odjezdu ve 22:00 jsme vyjížděli ve 23:30. Naštěstí se Kája doma trochu prospal a tak byl schopen řídit. Ač jsme se snažily nespat tak nás to stejně zmáhalo i když to za moc nestálo. Z předpokládané délky trasy 8,5 hodiny bylo těch hodin zhruba 10 a tak jsme dorazily kolem půl desáté do centra dění soutěže, naštěstí v pořádku.

Zaregistrovali jsme se a čekali na čas, kdy bude možnost si robota vyzkoušet v reálu. Pořadatelé byli velice příjemní a z celé soutěže mám fajn pocit i když bylo trochu skřípání a cítit , že takovou soutěž pořádají poprvé. Když jsme se dostali konečně k testům tak byl výsledek víc než katastrofický, k tomu všemu jak se robot nějak špatně zachytil a překroutil se, táhlo ramene nám zkratovalo desku celého řízení a ta zahořela plamenem. Vypadalo to beznadějně. Fanda měl sice náhradní, ale ta na robotu prý měla nějaké úpravy a nám vyhořeli i potřebné odpory, arduino atd. Nakonec to dali s Kájou dohromady, narovnali jsme táhla a oblepily samolepící páskou a čekali na další okno pro testování. Mezitím pořadatelé zjistili, že všichni roboti mají potíže a v současné chvíli by ani jeden robot nedal kvalifikaci což znamenalo vylézt do výšky 5m a slézt zpět. Svolali tedy konferenci soutěžících a hledalo se řešení jak upravit pravidla tak, aby se dalo soutěžit. Většina soutěžících se snažila nechat upravit pravidla tak aby vyhovovala jen jemu. Nakonec asi udělali to nejrozumnější a upravili pravidla tak, že se poleze normálně podle pravidel, ale bez kvalifikace a že pokud někdo vyleze jen nahoru a bude první tak dostane jen polovinu ceny, pokud splní úlohu celou tak dostane i celou cenu.

Mezitím byl čas na úpravy robota, protože již jsme odhalili slabiny, které robot měl díky tomu, že jsme opomněli, že se nejedná o žebřík, ale jednotlivé stupínky. Museli jsme dodělat kluznou plochu z plastu pod celé tělo robota a přišroubovali jsme plastová vodítka kolem těla robota tak, aby ho stupínky vedli. Plast a nářadí jsme měli naštěstí sebou, přece jen nějaké zkušenosti s robotikou už máme. Nakonec jsme ještě sjeli do obchodu kde měli šrouby a hliníkové profily a upravily jsme záchytná ramena. Vše jsme stihly a v pátek v 19:15 jsme šli na 15minut testovat na komín. Jenže se ukázalo, že provedené úpravy robotu pomohli, ale nejsou úplně dostatečné. Na víc se nám jistící lano asi třikrát připletlo mezi mechanizmus výměny ramen a byl konec kýžené čtvrthodinky. Tak jsme ještě dostali čas pro poslední zkoušky v sobotu v 11:15, sbalily robota a pojízdnou dílnu a jeli jsme se ubytovat. Při večeři jsme ještě v klidu domysleli potřebné úpravy a kolem 24 hodiny šli konečně spát.

V sobotu ráno nás vzbudil budík v 7:00 tak jsme se kvapem nasnídali a mazali do obchodu s mechanickými díly, dokoupily vše potřebné včetně spojovacího materiálu a jeli jsme robota předělat. Pak mě napadlo abychom nedělali kašpárky někde na fóru tak jsme zastavily na prázdném parkovišti nedaleko a potřebné úpravy jsme udělali tam včetně ohnutí profilů, nařezání, vyvrtání a montáže. Aby toho nebylo málo tak začalo pršet fakt bezva práce. Když jsme vše dodělali bylo 11:00 a my měli za čtvrt hodinky trénovat. Opět jsme vše letecky vyřešili a vše stihli. Robot šlapal o poznání lépe, ale pořád to nebylo ono, stále problémy s tažným lanem. Robot byl tak rychlý, že zajišťující horolezec nestihl ani lano přitahovat a tím nám vždy zasekl výměnu ramen. A zase konec zkoušek. Co se dalo dělat, museli jsme nechat prostor dalším. Sice jsme chvilku brblali nad tím jak nám to ten horolezec zkazil, ale nakonec jsme si řekli, že to nám nepomůže a musíme udělat takové řešení aby se to nestávalo. Doplnili jsme kus plastu který byl dostatečně tuhý a pružný a přesahoval ramena na něj jsme vždy lano ještě přichytili. Byl to dobrej tah pomohlo to.

V sobotu ve 14:00 bylo slavnostní zahájení soutěže a rozlosování robotů žáků středních škol což byla kategorie I. Celá soutěž byla pojata celkem velkolepě — zahajoval starosta Košic a zástupci podílejících se firem. Běžel doprovodný kulturní program na pódiu pod komínem a vyplňovali se tak chvilky výměny týmů. Večer dokonce byla laserová show a přenášení detailů ze samotné soutěže on line na velké plátno. Běžel i stream na webu na komín a tak mohli zájemci sledovat i průběh soutěže doma. Chvilku jsme se dívali, ale ještě bylo potřeba pracovat na vlastním robotovi tak jsme museli odejít. Co se týká soutěžních robotů tak bylo vidět mnoho zajímavých nápadů a řešení. Je pravda, že většinu jsme navrhovali také při volbě našeho robota, ale z nějakých důvodů jsme je postupně zavrhli. I tady bylo vidět že to bylo opodstatněné, i když leckterý robot byl spolehlivější než v té naší kategorii.

V 18:00 bylo vylosováno pořadí pro soutěž v kategorii II, kam jsme patřili. Jednalo se o vysoké školy, profesionální týmy a nezávislé týmy. V naší kategorii bylo celkem 6 robotů. Docela jsme si věřili, že by to možná to 3. místo mohlo být, i když jsme ani nevěděli kdo s námi soutěží. Vylosovali nám pořadí číslo 4. Docela dobrá volba. Po prvním kole kdy jsme dali celých 10m jsme si řekli, že to 3. místo máme jisté. Pak jsme nervózně sledovali ještě dva následující roboty ale nakonec po prvním kole jsme byli na 1. místě. Za chvilku začalo druhé kolo se zkráceným časem na 10 minut předešlé kolo mělo 20 minut na robota. Šlo to ráz na ráz. Nakonec jsme potvrdili opět dosažením 10m hranice, ale bohužel se resetoval procesor a robot nepokračoval směrem dolu. Škoda, ale prvenství nám zůstalo a potvrzené.

Ve 22:30 bylo slavnostní vyhlášení a předání fiktivních šeků. Jsme 1. a údajně snad i na světe protože prý obdobná soutěž ve světě není.

Výsledková listina

Kategória 1

Umiestnenie	Zdolaná dĺžka	Robot	Škola
1.	8.70m	LCR 2.0	Talentum Cassoviensis Foundation
2.	8.15m	Frankie	SPŠE Košice
3.	6.72m	AirBot	Gymnázium M. Hattalu Trstená
4.	1.32m	Snail	SOŠ Automobilová Košice
5.	0.78m	Galeje Climber	Gymnázium Alejová Košice
6.	0.20m	AR Master	SPŠE Prešov
X	10.00m	Ostrovbot	SOŠ Ostrovského Košice (mimo súťažnej trate)

Kategória 2

Umiestnenie	Zdolaná dĺžka	Robot	Škola/Organizácia
1.	10.00m	Drevo kocúr	Rádioklub Písek
2.	4.65m	Roboteon	Boteon Charkov
3.	2.00m	ROS Climber	SjF TUKE Robotics Košice
4.	1.83m	Molibot	FEI TUKE Košice
5.	1.78m	RuDy	SjF TUKE Robotics Košice
6.	1.15m	Johnny 5	T-Systems Slovakia Košice

V neděli, aby to nebylo jednoduché, vyrážíme v 9:00 k domovu a zastaví nás městský strážník, že nemůžeme vyjet od hotelu, protože probíhá mezinárodní maraton a skončí tak v 15:00. Nakonec jsme ukecali dopravního policistu, že nás nechal ve volné chvilce projet z centra, ale než jsme se dostali z Košic tak byla snad hodina a půl pryč. Pak už cesta skoro vesele ubíhala a tak jsme se dostali do Písku ve 21:00 a to je konec naší cesty za vítězstvím.

Ještě bych chtěl nakonec poděkovat všem, kteří nám všemožně pomáhali a vyšli vstříc včetně pochopení rodin a manželek. Bez tohoto zázemí by to skutečně nebylo možné. Díky moc všem.

Za Radioklub Písek sesmolil Tonda

Odkazy:

Stránky organizátorů: http://nakomin.com/

kontaktní formulář

FireAnt

2013-10-24T00:00:00Z

Toto je další z fandorama článků/blogů (na přesné formě bychom se domluvili s přispěvovateli). Balík se stavebnicí by měl dorazit příští týden. Motivace je vytvoření „zahradního robota”. Je to trošku „šílený česko-francouzko-kanadský projekt”, ale uvidíme. Pro představu, jak si hrál někdo jiný s chodícími roboty na zahradě/poli viz starší článek o robotických farmách.

FireAnt

Pokud máte zájem, aby na tomto místě vznikl článek nebo blog, kde bych sepisoval první zkušenosti se stavbou a oživením robota, tak zde je odpovídající fandorama link:

http://fandorama.cz/projekty/921778164/fireant-hexapod/

Odkazy:

Stránky výrobce: http://www.orionrobotics.com/FireAnt-Hexapod-Robot_p_248.html

Blog

31. říjen 2013 — Balíček dorazil!

Dnes ráno konečně dorazil balíček, no spíše balík, se stavebnicí robota. Tímto jsou splněny nutné předpoklady tohoto fandorama projektu, které bych jinak neměl ve své moci.

Chtěl bych také poděkovat prvnímu přispěvovateli … vždy potěší zpráva, že alespoň někoho by budoucí článek/blog zajímal. První fotografie:

balíček

díly

arduino

5. listopad 2013 — FAQ

Vypadá to, že moc lidí tento potenciální článek nezaujal. Ještě zbývá 25 dní, tak bych zde zmínil několik upřesňujících dotazů a odpovědí:

Co přesně je cílem tohoto fandorama článku?

Moje původní představa byla série dvou až tří článků o „slugs killer”, tedy „autonomním ohnivém mravenci, zabijáku slimáků”. Měl by dělat i další zahradní práce, ale slimáci trápí i mne a přišlo mi to jako dobře definovaný cíl. Aby byl i ten „milník”, tak jsme se domluvili na účasti na Field Robot 2014 v kategorii Free Style. Tento článek měl být první krůček, tj. cca do vánoc rozchodit ovládání robota z PC (za mne z Pythonu, jak jinak ).

Jaké je na robotovi Arduino?

Po pravdě netuším a s Arduinem jsem zatím nikdy nic nedělal. Jestli je něco na tom čipu napsané, tak už nejsem schopen to přečíst. Podle obrázků to matchuje na:

DaVinci je deska s regulovaným napětím, čipem 32kB Flash, 2kB RAM, 1kB EEPROM. Servo deska má 32 kanálový ovladač serv, 2x UART, 56kB Flash, 256kB EEPROM, LEDky a „Speaker”.

Co je na robotovi zajímavého?

Asi nejvíce mne zaujala serva. Slibují The Orion Shield also supports position and force feed back (PPF) using the new Orion Robotics servo HV-220., tj. serva by měla posílat zpět informaci o skutečné poloze a síle, jak těžko se ta poloha drží. Něco podobného co před lety nabízel megarobot.net. Jak to bude fungovat v realitě ale ještě nevím. Minimálně video s nabráním plechovky s kolou mají pěkné .

14. listopad 2013 — un-depressed

Přiznám se, že jsem předevčírem krabici se stavebnicí robota strčil na hromadu pod „pracovní stůl” s myšlenkou, že to holt pořeším někdy později, když o to nikdo nemá zájem :-(. Fandorama mne v tomto případě zatím spíše demotivovavla než motivovala. Velmi mne tedy potěšil včerejší příspěvek a zvýšení šance na úspěch. Zbývá zhruba ještě 14 dní tak uvidíme. Zatím jsem si nainstaloval potřebné prostředí, rozchodil USB driver a při napájení desky trefil polaritu, takže se ozvalo pípnutí a svítila zelená LEDka. Na blikání s LEDkou, tedy můj první test s Arduino deskou, ale ještě nedošlo.

p.s. psal jsem Orion Robotics, co je tam za defaultní firmware a jestli to vlastně nemá něco dělat „samo od sebe”, ale nedostal jsem ještě žádnou odpověď …

21. listopad 2013 — nohy

Minulý pátek a včera jsem si chvíli hrál na konstruktéra. Byla to celkem příjemná kompenzace k dekódování videa . Přemýšlel jsem, co bych o tom mohl psát a napadaly mne pouze hlášky z filmu Pelíšky o „naprosto stejné krabičce sirek”. Stavebnice mi totiž hodně připomínala Merkur, akorát bych si asi vybral tu americkou.

Člověk si u toho může opakovat angličtinu — šroubky, matičky, podložky, vše je baleno po deseti s nálepkami „Screw 3M8”, „Nuts 3M” a pod. V této fázi jsem udělal snad jenom jednu chybu a to když jsem přehlédl, že vedle šroubků a matiček 3M tam jsou ješte o trošku menší (2.5M). Nebyla fatální. Prostě to jen k sobě nešlo .

První trošku větší zklamání byly 20mm distanční sloupky. Ještě bych rád chvíli věřil, že to byl záměr, ale … ty závity jsou fakt mizerné. Šroubek tam zastrčíte 4mm (tj. půlku velikosti), aniž by jste ho jednou otočili! Jsem zvědav, co mi na to kapitalisti napíšou. Zatím stačí problémový (bylo jich špatných asi 5) distanční sloupek otočit — z jedné strany se totiž přichytává rovnou ke konstrukci a z druhé přes podložku přidržuje servo (krok 5 v návodu).

Jinak díly jsou moc pěkně udělané a to jak výřezy, tak povrchová úprava. Už teď je mi skoro „mravence” líto ho pouštět do bahna, ale je to jeho osud. Přes zeď jsem slyšel Vášnivý tanec, tak jsem si říkal, že to by mohla být pěkná aplikace … no jsem zvědav co ty servo-nohy dokážou.

první krok

druhý krok

návod

26. listopad 2013 — tělo

Do konce fandorama projektu zbývají 4 dny, tak už zase pomalu začínám pochybovat, že projde. O víkendu jsem si chvíli stavěl, tak alespoň malá obrázková galerie odpovídající krokům z návodu …

Krok 8

Krok 9

Krok 10

Krok 11

Krok 12

Krok 13

Opět tam byl drobný problém s distančními sloupky (tentokrát 25mm dlouhými) — závit byl u jednoho jenom cca 4mm, tj. šroubek nešel dotáhnout. Robotického nadšence by to asi nemělo rozhodit, ale u profi stavebnice mne to trošku mrzelo. A samozřejmě to byl první sloupek, který jsem ten den montoval…

29. listopad 2013 — Fandorama

Nejprve díky třetímu stoupenci, který tento článek podpořil, a já už nemusím řešit dilema, jak na robotovi pracovat a „netutlat to” . Poprosil bych ho touto cestou o kontakt — uvádějte prosím do zprávy pro příjemce svůj mail. Domluvil bych se pak se všemi co by vás na stavebnici FireAnt nejvíce zajímalo.

Dostali jsme na toto téma zatím dva mailové příspěvky. V prvním mailu byl nápad, že by podobný mravenec mohl i sbírat kameny (zkusil bych to, ale nevím do jaké velikosti/váhy to zvládne) a že je velká podobnost stavebnice s tím, co nabízí Lynxmotion. Jaká je vazba mezi Orion Robotis a Lynxmotion ale zatím nevím … nějaké náznaky jsou na jejich fóru.

Druhý mail byl spíše k Fandoramě: „Myslím trochu ptákovina (na web jsem se podíval), poněvadž odpověď na otázku "O jaké články bude největší zájem?" je víc než nasnadě: O nejlevnější.” Nevím, máte stejný pocit? Mimochodem Fandorama je k dispozici pro všechny a není ani nutně vázaná pouze na http://robotika.cz/ … i když to tak zatím moc nevypadá .

p.s. z jiného soudku: pokud by vás zajímaly LEGO robotické stavebnice, tak je teď (do soboty) celkem pěkná výstava v NTK Galerii v Praze …

LEGO Kobra

… omlouvám se za mizernou fotku z telefonu. LEGO Kobra se umí plazit a i vás uštknout .

2. prosinec 2013 — čas BLINKat

Dnes ráno jsem si chtěl na mravencovi vyzkoušet nějaký triviální prográmek. Příklad BLINK, tedy blikání LEDkou, je rovnou součástí Arduino balíčku. Začít programování jednočipů tímto příkladem doporučujeme už léta. Není to až tak o programu, i když i na něm se člověk naučí nastavit výstupy a základní časování, jako o rozchození nástrojů.

S instalací driveru jsem před časem tročku zápasil (Windows 7, 64bit), ale nakonec fungoval přímo driver od FTDI (arduino-1.0.1\drivers\FTDI USB Drivers). Když jsem viděl COM6, tak jsem si myslel, že už mám vyhráno, ale … nemám. Zasekl jsem se teď na processing.app.SerialException: Serial port 'COM6' already in use. Try quiting any programs that may be using it., podle doporučení na StackOverlow nainstaloval Process Explorer, zabil Nokia SYNC, Android ADB, ale ještě si netroufl na iusb3mon.exe, i když ten je možná důvod (???).

Večer budu zase raději montovat, to má větší šanci na úspěch …

3. prosinec 2013 — ložiska

Krok 17

Dnes jsem reklamní brožury nejprve použil jako výstavku, než jsem se shrnul pryč z kuchyňského stolu . Je to takový průřez minulých čtrnácti dnů …

Sylvio psal, že je u kroku 31, takže evidentně zaostávám. Když navíc uvážím, že mne čeká „rozborka & sborka” (ještě nemám baterku a ona má být tak trošku zabudovaná do těla robota), tak paralelní slalom asi prohraji. No uvidíme, kdo mravencovi první trhne nohou (ne utrhne nohu).

Na rozdíl od programování šla stavba teď celkem pěkně. Mile mne potěšila ložiska — původně jsem si myslel, že ty „tablety” jsou nějaké magnety. Upevňuje se tak druhá strana těla (krok 20 a celkem dost mizerná fotka).

Jinak asi nic extra napínavého … včera jsem si pořídil AKU šroubovák/vrtačku na dodělání jedné střechy a fakt bych nevěřil, co jsou e-shopy schopný prodávat :-(. Jedna baterka byla zničena a dopředný chod vůbec nefungoval, jenom zpětný … ale to dost odbočuji. Představoval jsem si, že kdyby byl mravenec schopen tu vrtačku unést, tak by mohl horní část střechy montovat za mne, ha ha ha. Takový Ferda mravenec, kdyby robotí jméno Ferda nebylo už použito.

Krok 16

Krok 18

Krok 20

Krok 21

Krok 23

Krok 24

4. prosinec 2013 — šestinožka

Dostal jsem se včera ke kroku 35 a je to fakt monstrum, které zabírá půlku pracovního stolu! S montováním klepet a ocasu bych asi počkal, až bude fungovat základní pohyb.

Momentálně se rozhoduji, které baterky a nabíječku, a při té příležitosti jsem narazil na tento článek o stavbě FireAnta. Když si ho přečtete, tak zjistíte, že „Zenta” je norský autor návrhu šestinožky A-Pod a Lynxmotion design převzal (více detailů je pak na jejich fóru).

Krok 25

Krok 26

Krok 27

Krok 29

Krok 35

Krok 35b

5. prosinec 2013 — baterka

Tedy přesněji Li-Po akumulátor … připadám si jako křupan, kterého snadno oškubou :-(. Zase se mnou trošku cloumá vztek, ale noste si voltmetr do obchodu?! Je to jak když jsem v pondělí zjistil, že nová AKU vrtačka se točí jenom v jednom směru a jedna baterka je vadná … možná bych měl počkat do rána, až se trošku uklidním, ale to by jste z toho zase nic neměli . Tak popořádku.

První problém byl, jaký akumulátor vůbec pořídit. V návodu není nic. Jediná, ale asi dost významná nápověda byla u specifikace serv: … high voltage (7.4V), digital servo. LiPo-lky mi doporučil Dan … jsou lehčí, ale bacha na vybití! 7.4V znamená 2 články. Podpora na Orion Robotics mlčela … měl jsem projít jejich fóra a bylo by … viz poznámka o HobbyKing 2200mAh 2S 30C LiPo (dnes mi to potvrdil i Nathan z Orion Robotics).

No nic, v mezičase už jsem trošku jiný LiPo akumulátor pořídil (2S, ale 3300mAh — snad to FireAnt unese). Pominu-li špatný konektor v prvním pokusu, tak teď, s novým konektorem a novou nabíječkou … nic! Ta zkur… špatná baterka má 6V a to je už tak málo, že to odmítá nabít (BATTERY CHECK CELL LOW VOL). Supr. Jsem zvědav, co mi zítra v obchodě řeknou …

k Arduino desce se vůbec nepřipojím (zatím stále předpokládám chybný driver).
primární ovládání ohnivého mravence je přes kabel s PS2 (nemám a neplánuji pořizovat).

8. prosinec 2013 — 8.4V

Jak to dopadlo v pátek v obchodě? Prodavač si vzal nabíječku i s akumulátorem, na pár sekund místo LiPo nastavil NiMH (jaký proud si nevybavuji) a pak přepnul zpět na LiPo a už se to v pohodě nabíjelo . Baterka je prý dobrá (po hmatu je tvrdá) a že jakmile by začala měknout, tak se jí nepokoušet ani nabíjet — uvolňují se plyny a mohla by explodovat!

V práci jsem jí nechal ještě několik hodin dobíjet. Ano, hodin. Překvapilo mne, jak dlouho to trvá, ale v závěru nabíjecího cyklu se tam pouští už jenom 0.2A a je to tedy očekávané. Teď už má baterka 8.4V .

9. prosinec 2013 — datasheets

Asi je pomalu čas klesnout na dno a začít pěkně od nuly. The DaVinci deska je „Arduino compatible”, což si teď překládám jako „obsahuje ATmegaXY” :-(. Mám i pocit, že asociace s názvem Arduino desky Leonardo je zavádějící. Jedna má ATmega32U4 a druhá ATmega328P. Kdyby nic jiného, tak jedna má 26 general purpose I/O lines zatímco druhá pouze 23 …

Čemu se dá věřit? Datasheets. Důležitý je jednočip ATmega328P a možná se bude hodit i převodník FT232RL.

… o 3 hodiny později …

To jsem teda blázen :-(. Na Arduino drivery jsem se už vykašlal a šel jsem přímo po FTDI. Konkrétně je tam VID_0403&PID_A559 … je to tedy trošku upravena EEPROMka a „defaultním” FTDI driverům se to nějak bránilo. Pak jsem četl Application Note 073, kde píšou: In order that Windows successfully match a device with the driver, the VID and PID programmed into the device must be listed in the driver INF file. The following sections of FTDIBUS.INF show text in bold that must be amended to match the desired VID and PID combination... … hm, takže si sám musím upravovat drivery?! Nejprve jsem to udělal pouze u ftdiport.inf, ale to nepomohlo … ale pak jsem místo instalovat ze zadaného místa vybral FTDI a novější driver pro sériový port a vznikl COM7. Hmm, znova problém, že už COM používá někdo jiný. Zabil jsem co se dalo, ale žádná změna.

Zkusil jsem dalši USB port na počítači. Znova COM7, ale This device cannot start. (Code 10).. Update driveru z vybraného místa nepomohl, ale vybrat už z nainstalovaných ano. Před tím jsem ale editoval jak ftdiport.inf tak ftdibus.inf a smazal všechny ostatní záznamy: When changing FTDIBUS.INF to match a new VID and PID combination, all references to these default values must be removed from the file..

Další změnu, kterou jsem provedl, byl způsob puštění arduino.exe. Mám namapovaný disk a začínám mít velké podezření, že si s tím nějak neporadí.

Vznikl COM8 — šel otevřít a deska začala pípat (stejně jako po resetu). To je dobrá zpráva!

Binary sketch size: 4,826 bytes (of a 28,672 byte maximum)
processing.app.debug.RunnerException: Couldn’t find a Leonardo on the selected port. 
Check that you have the correct port selected.  If it is correct,
try pressing the board's reset button after initiating the upload.
	at processing.app.debug.AvrdudeUploader.uploadViaBootloader(AvrdudeUploader.java:153)
	at processing.app.debug.AvrdudeUploader.uploadUsingPreferences(AvrdudeUploader.java:67)
	at processing.app.Sketch.upload(Sketch.java:1671)
	at processing.app.Sketch.exportApplet(Sketch.java:1627)
	at processing.app.Sketch.exportApplet(Sketch.java:1599)
	at processing.app.Editor$DefaultExportHandler.run(Editor.java:2380)
	at java.lang.Thread.run(Thread.java:619)

Reset vypadá, že ovládá přímo přes USB (mimochodem je dost nepřístupný, schovaný pod servo-deskou), takže předpokládám „non-Leonardo” problém.

Binary sketch size: 4,826 bytes (of a 28,672 byte maximum)
processing.app.debug.RunnerException: Serial port 'COM8' already in use.
Try quitting any programs that may be using it.
	at processing.app.debug.AvrdudeUploader.uploadViaBootloader(AvrdudeUploader.java:158)
	at processing.app.debug.AvrdudeUploader.uploadUsingPreferences(AvrdudeUploader.java:67)
	at processing.app.Sketch.upload(Sketch.java:1671)
	at processing.app.Sketch.exportApplet(Sketch.java:1627)
	at processing.app.Sketch.exportApplet(Sketch.java:1599)
	at processing.app.Editor$DefaultExportHandler.run(Editor.java:2380)
	at java.lang.Thread.run(Thread.java:619)

Supr :-( …toto se mi podařilo, když jsem zkoušel RST tlačítko na servo-desce … je čas jít do práce …

10. prosinec 2013 — Duemilanove

Severní pól je dobyt! (a ta potvora naprogramována)

Pokud si myslíte, jako já před pár dny, že „Leonardo” má cokoliv společného s „DaVinci” tak se šeredně pletete. Nemá. Co tedy odpovídá DaVinci řídící desce, v rámci „Arduino kompatibility”, jsem nakonec zjišťoval podle použitého čipu ATmega328P. Vzal jsem to od shora a první na to seděla deska „Duemilanove” a šla naprogramovat s příkladem arduino-1.0.5\examples\01.Basics\Blink\Blink.ino . To by vypadalo jako dobrá zpráva, ale LEDka neblikala a deska přestala i pípat. S tím jsem včera ráno končil.

Večer jsem zkusil jiný příklad: 02.Digital\toneMelody, kde jsem změnil výstupní pin na 3 (původně tam byl myslím 8) a deska začala pípat. Hurá! Další krok byl 03.Analog\AnalogInOutSerial, kde jsem změnil vstupní analogový pin na A2, který by podle Orion_Servo_Shield_R0406.pdf měl měřit napětí na baterce. Na straně PCčka jsem otevřel putty terminál na COM8, 9600 a začal chrlit:

sensor = 377     output = 93
sensor = 377     output = 93
sensor = 377     output = 93
sensor = 376     output = 93
…

Na řadě jsou teď znova LEDky a tlačítka. Jestli jsem dosavadní prográmky pochopil, tak digitální piny se číslují přímo a analogové zprostředkovaně přes define A0, A1, … Ještě je tu jemná schizofrenie propojení dvou desek (DaVinci a ServoShield), kde schéma zapojení mám pouze u jedné.

p.s. ještě jsem se pokusil vrátit na desku původní firmware (support se podle mne mýlil a deska byla předprogramovaná na ovládání kabelem pomocí herní konzole PS2). Zdrojáky jsou ke stažení z FireAnt stránky, ale nešly mi zkompilovat. Chyběly Arduino knihovny, které bylo třeba buď jednotlivě naimportovat, nebo snáze rovnou nakopírovat do adresáře arduino-1.0.5\libraries.

11. prosinec 2013 — první pohyb

Včera večer se mravenec (Fourmis de Feux) konečně pohnul . K prvnímu kroku to má ještě daleko, ale nějak se začít musí. Rozchodil jsem si příklad s LEDkama 01.Basics\Blink (analogový pin A0 je červená a A1 zelená), pak s tlačítkama 02.Digital\Button (digitální piny 2 a 4) a pak si troufl to zkombinovat se servem. Jak to dopadlo je vidět na tomto hodně mizerném videu. Zem (černý kabel) musí být na vnější straně desky a čísla Arduino pinu jsou tam přímo napsaná (použil jsem pin 10).

zapojení

Pokud by vás zajímal i ten dost triviální zdroják, tak jsem to dal rovnou na github.

Třída BMServo je v balíčku ke stažení od Orion Robotics. Klasicky jsem se trošku bál, co se stane, když tam pošlu 0 a jaké jednotky to vůbec má, ale vypadá to, že servo.setAngle(value,time) nastavuje znaménkový úhel v desetinách stupně, 0 je střed a čas je v milisekundách.

Ve zdrojovém kódu BMServo jsem našel i funkce queryFBAngle() a jiném příkladu queryForce(), ale ta je k dispozici přes SPI pouze u Servo Shield desky. To jsem vlastně ještě nepsal — ovládat lze 32 serv s tím, že 8 je prodrátovaných/přímo řízených z DaVinci desky a zbylých 24 přes SPI komunikaci přímo na servo desce. Tam jsem ale zdrojový kód zatím nenašel a možná ani není veřejně k dispozici.

Ještě mne včera trošku uvedl do reality Jirka: ,,Arduino compatible'' znamená, že má stejně rozmístěné piny, takže na to můžeš nasadit různé arduino shieldy. Co se procesoru týče, nejsou stejná ani dvě opravdová arduina

12. prosinec 2013 — BMServo vs. SPI

Dnes ráno jsem zkoušel ovládat servo přes SPI a zatím dost tápu :-(. U BMServo to bylo jednoduché:

BMServo servo( ARDUINO_SERVO_PIN );
servo.begin();
…
  servo.setAngle( angle, 1000 );
  servo.update();

U SPI se komunikuje přes Orion knihovnu a skoro to vypadá, že už je tam nějak předprogramované to chození? (nebo se mi deska stále resetuje a proto se to samo cyklí, ale to bych „slyšel” — mám tam na začátku pípnutí). Jelikož se ovládá hodně serv současně, tak Orion.setAngle() je pouze nastavovací a teprve Orion.execute() něco dělá. Nějakou roli tam ještě určitě hraje Orion.time(ms), ale zatím nevím jakou.

Orion.begin(); 
Orion.tone(NOTE_C6,100); 
Orion.setAngle( SPI_SERVO_PIN, angle );
Orion.setServoMin( SPI_SERVO_PIN, -900 );
Orion.setServoMax( SPI_SERVO_PIN, 900 );
…
  Orion.setTime( 100 );
  Orion.setAngle( SPI_SERVO_PIN, 900 ); // nebo -900
  Orion.execute();

OK, tak teď jsem to už snad pochopil. Ten Orion.setTime(ms) je to samé jako time parametr u servo.setAngle(angle, time), tj. jak rychle do požadované polohy má přejít … jen je to stejný parametr pro všech 24 serv. Když jsem ten čas totiž změnil na 1000 (1s), tak se to začalo chovat rozumně a ano, resetuje se mi deska … jedu ze slabého zdroje. Chcete-li detaily, tak viz servo_test.ino.

13. prosinec 2013 — teleoperation

… aneb každý den není posvícení. Sigh. Dnes jsem chtěl vyzkoušet jednoduchý příklad se zpětnou vazbou na servech. Jedno servo by bylo jako vstup a druhé jako výstup. Na cvičení jsme před mnoha lety zadávali podobný úkol — zapojte potenciometr a servo + naprogramujte jednočip tak, že otáčení potenciometrem se bude otáčet i to servo. Spousty zábavy s touto „teleoperací” .

Orion serva mají zpětnou vazbu, resp. předpokládám, že je tam možnost přečíst právě aktuální odpor na referenčním potenciometru (v servu). Klíčová je tato řádka:

Orion.setAngle( OUT_SERVO_PIN, Orion.queryFBAngle( IN_SERVO_PIN ) );

tj. aktuální polohu IN serva předej jako požadavek na OUT servo. Celý kód pak najdete na githubu. Zkusil jsem to na přední packy a zvedáním jedné druhá šla dolu . To je vlastně očekávané chování, protože serva jsou symetrická.

Druhý pokus byla první a druhá noha na stejné straně robota. A bang - servo šlo do extrému, bouchlo do konstrukce a vůbec to nevypadalo pěkně. Tak jsem si přidal do kódu LEDky, tlačítko a „pseudo-kalibrační” rutinu … a výsledek? LEDky svítí, přepnou se po kalibraci, ale už to nedělá vůbec nic :-(. Dokonce i když jsem kalibraci zrušil a vypnul/zapnul desku, tak stále nic. Celkem dobrá předehra k pátku 13 … . Dnes tedy žádné video.

14. prosinec 2013 — Orion.queryFBAngle()

Kalibrační proceduru jsem ještě nerozchodil, ale o malý kousek jsem se zase posunul dál. Už tuším, proč se včera servo chovalo tak agresivně! Přidal jsem do kódu Orion.setServoMin() a Orion.setServoMax(), což možná byl důvod proč se servo předtím nehýbalo vůbec, a hlavně jsem přidal podmínku na povolený úhel, který mi vrací Orion.queryFBAngle(). Detaily změn najdete zde.

Pokud byly úhly nějaké podezřelé, tak jsem si je nechal vypisovat na konzoli (přes USB-serial) a po resetu jsem typicky dostal tento výstup:

TeleOperation test …
                      -1704
-1704
-1704
-1704
-1704

a na rovinu, úhel -170 stupňů snad to servo ani nedá a pokud dá, tak je to hodně extrémní poloha.

Pokusil jsem se i natočit, co že to vlastně dělám, ale kamera je vybitá a s tím foťákem v temném koutku … ostatně uvidíte sami. Asi nejvtipnější na tom pár sekundovém snímku je, jak mi nejde zapnout napájení — v jedné ruce foťák a tou druhou to nějak nešlo . No nic, pro představu to snad stačí.

16. prosinec 2013 — Kosinova věta

Lomikare, Lomikare … aneb už došlo na středoškolskou matematiku. Včera jsem si celkem dlouho hrál s 3-DOF nohou. Naprogramoval jsem si jednoduchou komunikaci Pyhon-Arduino a při tom přemýšlel, jak někteří dokáží takové věci dělat bez testů a bez logování. Je to jak stavět barák bez lešení. Nějaké problémy? Hned několik.

Komunikační protokol a logování

Protokol jsem si vymyslel celkem jednoduchý — nechtělo se mi pouštět v této fázi do složitější struktury s kontrolním součtem, ale možná to byla chyba. Úhly v desetinách stupně jsem si zjednodušil na stupně a bajt beru znaménkově, tj. teoreticky jsou možné úhly -128 až 127 stupňů. Zúžil jsem to ještě na -120 až 120 a získal tak „řídící bajty”:

const unsigned char START_BLOCK = 0x80;
const unsigned char END_BLOCK = 0x81;
const unsigned char STOP_SERVO = 0x82;
const unsigned char SERVO_OUT_OF_RANGE = 0x83;

Arduino pošle START_BLOCK, pak stavy jednotlivých serv a ukončí paket END_BLOCK. Python na to odpoví START_BLOCK, příkazy pro jednotlivá serva a END_BLOCK. Nesymetrické jsou STOP_SERVO a SERVO_OUT_OF_RANGE a samozřejmě, že jsem v tom udělal chybu (na jednom místě je omylem prohodil, když jsem rutinu z Python přepisoval do Céčka). Pokud je poloha serva třeba 130 stuňů, tak aby seděly jednotlivé pozice se posílá SERVO_OUT_OF_RANGE. A naopak když Python neví, do jaké polohy servo poslat, tak STOP_SERVO vypíná generování pulzů.

A kde pomohl log fa131215_124600.log? Z Arduina mi chodilo nějak málo serv. Chyba byla v typu pole s čísly pinu, který není int, ale char.

Chyba ve firmware Servo Shield??

Teď zpětně si vybavuji, že mi serva zlobila od začátku, ale nezdokumentoval jsem to hned a teď už jen tápu. Při prvních pokusech to byla určitě chyba záměny STOP_SERVO a SERVO_OUT_OF_RANGE, kdy šlo servo do polohy -126 stupňů, ale pak to zlobilo i když jsem posílal přímo konkrétní pozice.

Po opravě jsem ale dostával stále podobnou chybu (teď si myslím, že šlo servo do druhého extrému). Spíše ze zoufalství jsem odstranil nastavovací cyklus v setup():

/*  int i;
  for( i = 0; i < NUM_SERVOS; i++ )
  { 
    Orion.stopPulse( servoPins[i] ); // it is by default, but this way it is more clear
    Orion.setServoMin( servoPins[i], SERVO_MIN );
    Orion.setServoMax( servoPins[i], SERVO_MAX );
  }*/

a ono to začalo fungovat správně!!! Mám teorii, že to šlo do polohy zadané přes Orion.setServoMax(), ale více jsem to nezkoumal. Zatím. Při sepisování, co se vše včera dělo, mi teď došla ještě jedna věc — když nastavíte požadovanou polohu serva, tak nastavujete i za jak dlouho tu polohu má dosáhnout. Prima, ale co když je předešlá poloha nedefinovaná? Nebo co když zadáte čas nula? Možná získáme nějaké informace na fóru.

Čas se pomalu naplnil, tak Kozinovu větu vám nechám za domácí úkol .

P.S. Zdrojáky na toto téma jsou na obvyklém místě.

17. prosinec 2013 — Piano

Opět tuším, že cíl je v nedohlednu, tak zase „verze 0”. Mělo to být překvapení, ale než bych to pořádně rozchodil, tak už bude nutné dělat něco

FireAnt a Piano

jiného (třeba vánoční úklid).

Malé testovací prográmky pro Arduino většinou začínají pípnutím. Je to dobrá indikace, že se deska resetovala, i když se člověk zrovna nedíval. Podle volby tónu si můžete rozlišit i programy: pokud si nejste 100% jistý, že máte nahraný nejnovější kód, tak změníte úvodní tón.

O tohoto pípání už byl jen malý myšlenkový krůček k „pípání na piánu”, na které jsem v pre-historii hrával. Je to pěkný milník na otestování transformace XYZ do prostoru úhlů serv a jak moc to funguje snadno posoudí každý . Co přesně měl mravenec zahrát si ještě nechám pro případ, kdybych to opravdu někdy dotáhl, ale první lekci bych zveřejnil, ať z toho také něco máte. Video je tedy zde.

P.S. pokud nemáte čas a chcete rovnou výsledek, tak Veselé vánoce

19. prosinec 2013 — Ocas a klepeta

Dnes zase jen obrázkově …

Krok 38

Krok 39

Krok 43

Krok 44

Krok 45

Krok 46

Krok 47

Krok 48

Krok 49

21. prosinec 2013 — Force

Občas je skleróza výhodou (opětovné sledování filmů, čtení knížek a pod.), ale v programování robotů to u mne mnohdy vede ke vzteku. Je pravda, že nalezení opakovaných chyb je snazší, ale … a taky by nebylo o čem psát, kdyby hned vše fungovalo, že je to tak?

Hraji si teď s analýzou hodnot získaných pomocí dotazu queryForce(). Mělo by z toho být (zatím teoreticky) poznat, zda je noha robota ve vzduchu, jak moc je zatížená a pod. Přešel jsem tedy na jednoduchou komunikaci s posíláním stavové a příkazové struktury — používal jsem to např. na ATmega8 board nebo u robota Daisy.

A na co jsem za ta léta už zapomněl? Proč nemám rád 16bitová čísla a makra. Postupné rozcházení komunikace jsem si ale celkem užil, tak heslovitě zopakuji. Třeba to také někdo někdy použije:

Nejprve jsem naprogramoval mravence, aby posílal RobotStatus strukturu, včetně kontrolního součtu (jenom triviální součet bajtů aby celkově to vyšlo 0). Na straně PC jsem si v Pythonu jenom napsal for-cyklus:

for i in xrange(1000):
    com.read(1)

… prostě přečti prvních 1000 bajtů a nic víc. com je logovaný COM port.

V druhém kroku jsem ladil část na PC, tj. přehrával jsem si log dokud, neseděl kontrolní součet a výsledná čísla nedávala alespoň trošku smysl.

Ve třetím kroku mravenec pošle data, ale čeká na příkazovou strukturu. Pokud nesedí velikost nebo kontrolní součet, tak rozsvítí červenou LEDku a pípá. Na straně PC se zase snažím rozchodit posílání struktury, dokud mravenec nepřestane pípat. Přijatá data jsou na robotovi pouze parsovaná, ale jinak je ignoruji.

V posledním, čtvrtém, kroku data na robotovi i provádím. Kontrolní součty a packety by v té době už měly sedět v obou směrech a data dávat celkem smysl …

Tak kde se to zadrhlo? No vypadalo to pěkně, až do okamžiku než jsem provedl čtvrtý krok. Noha sebou zuřivě cukla a vypínač byl naštěstí po ruce. Důvod? Indiáni. Byl jsem líný a na straně robota přečetl celou strukturu jako blok bajtů, ale při odesílání indiány (tedy pořadí bajtů u 16ti bitových čísel) dělal ručně. A špatně.

Po přepsání mi ale zase přestal fungovat kontrolní součet. Důvodem bylo lajdácky napsané makro (možná ho asi ještě vyhodím):

#define SEND_WITH_CHECKSUM(X) { Serial.write( (X) ); tmpSum += (X); }

… jo, vyhodím. Prostě jsem byl dříve líný vypisovat jednotlivé části ve struktuře a updateovat tmpSum … a ty složené závorky tam nebyly, takže ve for-cyklu, to tu proměnnou aktualizovalo pouze jednou.

A nějaké výsledky? No zatím je to takové temné. Když se nic neděje, tak je návratová hodnota pro queryForce( číslo pinu ) 30000 nebo -30000. Pokud ale pohybuji byť jedním servem, tak se mění čísla u všech:

m:\git\fireant\force_test>force_test.py logs/fa131221_130511.log
ReplyLog logs/fa131221_130511.log
(8668, 820, 2587, 30000, -1253, -30000, -1464, -30000)
(39156, 820, 2587, 30000, -309, -30000, -1464, 2465)
(2764, 820, 770, -8540, -309, -11147, 94, -15895)
(33120, 820, 770, -8469, -309, -11036, 93, 10878)
(62240, 820, 770, -8503, -309, -11061, 93, 6627)
(30788, 820, 770, -8512, -307, -10971, 93, -9356)
(57476, 820, 770, -8480, -309, -11078, 93, -2126)
(24608, 820, 770, -8640, -309, -11007, 53, 1558)
(51440, 820, 771, -8497, -309, -10944, 14, 878)
(19980, 820, 770, -9693, -307, -11002, 5, 574)
(47964, 820, 770, -9012, -309, -11010, 0, 307)
(13856, 820, 770, -8835, -309, -11032, 0, 112)
(43004, 820, 770, -8633, -309, -11138, 0, 58)
(10160, 820, 770, -8521, -309, -11194, 0, 25)
(37192, 820, 770, -8439, -309, -11073, 0, 1)
(5500, 820, 770, -8403, -307, -11104, 0, 7)
(32176, 820, 770, -8400, -307, -11127, 0, -2)
…

Vysvětlivka k výpisu — čas, napětí baterky (8.2V), pozice serva1, síla serva1, pozice serva2, síla serva2, pozice serva3, síla serva3. Příkaz byl nechat servo1 a servo2 být a posunout servo3 do polohy 0.

P.S. to makro jsem dal pryč. Jinak zdrojový kód k těmto pokusům najdete na githubu v adresáři force_test.

P.P.S.S. „Rolničky”

ServoAngle

ServoForce

Force detail

23. prosinec 2013 — MIDI

Asi bych svoji bývalou profesorku na klavír moc nepotěšil, kdybych jí řekl, že teď elektronické piáno používám na testování chodících robotů … po pravdě ani mne by to dříve nenapadlo, ale ono se to samo nabízí. Vedle testování správné polohy, jde testovat „sílu úderu” a celkové časování. A není to jen slyšet, je to i možné vidět v číslech. Jak? Pomocí MIDI.

MIDI je zkratka za Musical Instrument Digital Interface. Je to cesta, jak si předávat informace mezi elektronickými nástroji. „Shodou okolností” (tenkrát to byl jeden z mých požadavků, aby to piáno MIDI mělo a mohlo se spojit s Atari ST 1040 ) MIDI výstup mám a cca před půl rokem jsem si koupil i MIDI-USB převodník. Původní motivace byla zkusit dodělat nějaký hudební doprovod k němým filmům z AD Drone 2, ale znáte to. Snad jednou.

HW tedy je. Co SW? Zeptal jsem se Google na „Python MIDI” a mezi spoustou odkazů byl i náš oblíbený pygame rovnou s MIDI příkladem:

pygame piáno

Příklad nabízí tři možnosti:

výstup na MIDI zařízení
logování vstupu z MIDI zařízení
výpis MIDI zařízení

Další téma ke studiu tedy je dekódování, co přesně:

<Event(34-Unknown {'status': 144, 'vice_id': 1, 'timestamp': 13878, 'data1': 52,
 'data3': 0, 'data2': 0})>
<Event(34-Unknown {'status': 144, 'vice_id': 1, 'timestamp': 14148, 'data1': 55,
 'data3': 0, 'data2': 39})>
<Event(34-Unknown {'status': 144, 'vice_id': 1, 'timestamp': 14477, 'data1': 55,
 'data3': 0, 'data2': 0})>
<Event(34-Unknown {'status': 144, 'vice_id': 1, 'timestamp': 14552, 'data1': 53,
 'data3': 0, 'data2': 50})>
<Event(34-Unknown {'status': 144, 'vice_id': 1, 'timestamp': 15153, 'data1': 53,
 'data3': 0, 'data2': 0})>

znamená .

8. leden 2014 — Nevěř holka chlapci nevěř

… na micros() časy neměř, uint16_t ti přeteče, robot ti uteče bude tasku konec, uint16_t ti přeteče, robot ti uteče bude tasku konec.

Během offline, robot-free dovolené jsem si jen tak bloumal, jak to vychází s časováním. Serva běží na 50Hz, kdy v 20ms „oknech” robot posílá zhruba 1.5ms pulzy (viz řízení serva), tj. nemá smysl rychleji posílat příkazy ani se ptát na polohu/sílu. Na druhou stranu komunikaci jsem měl na 9600 baud, jeden start bit a jeden stop bit, tj. za sekundu pošle max 960 bajtů a za 20ms zhruba 19 bajtů. Časy při přehrávání logu vypadaly takto:

(11220, 818, 946, -98, -286, 592, -228, -7)
(42852, 818, 944, -98, -286, 286, -228, 1)
(6364, 818, 944, -96, -286, 193, -228, 0)
(37776, 818, 944, -92, -286, 145, -228, 0)

První číslo je v microsekundách a na první pohled vše vypadalo OK, tj. přetečení po 65ms (dvoubajtový int, tj. 65535), perioda zhruba 30ms (42-11 nebo 37-6). Pěkné, není-liž pravda? Jak naznačilo „střevo” v úvodním odstavečku — chyba lávky. V realitě je to jinak. Nějak mi to nedošlo. Jen struktura RobotStatus má 19 bajtů a RobotCmd 12 15 bajtů a jelikož zatím nevysílám a nepřijímám současně tak už ani toto by se za 30ms nemohlo stihnout.

Funkce micros() vrací long int a nikomu nevadilo, když jsem ho rval do uint16_t. Když jsem zvýšil komunikační rychlost 4x na 38400, tak chvílemi začal čas jít pozpátku. Divné co? (pak že se nedá otočit směr času … stačí jen změnit vzorkování) Jasnější to asi bude z obrázku, kdy jsem přešel na milisekundy a v grafu jsou rozdíly časů:

časový krok v ms

Prostě celá smyčka trvá pro 4x rychlejší komunikaci zhruba 62ms a při přetečení u 65ms si snad důsledek už umíte představit. T, d, dm, dam. Huston, máme problém. Pokud pro vyřízení stavů a příkazů pro 3 serva potřebuji skoro trojnásobek cyklu serva, co potom pro 25 serv?!

Ještě poznámka z MIDI světa — přidal jsem logování jak FireAnt mačká klaviaturu, viz midi.py. Generuje to celkem čitelné výstupy:

[ [ [144, 45, 36, 0], 14315] ]
[ [ [144, 45, 0, 0], 15555] ]
[ [ [144, 45, 46, 0], 16664] ]
[ [ [144, 45, 0, 0], 17937] ]
[ [ [144, 45, 43, 0], 19093] ]
[ [ [144, 45, 0, 0], 21647] ]
[ [ [144, 96, 58, 0], 46968] ]

kde poslední číslo je časová známka (snad generovaná piánem), 144 je stav, 45 číslo klávesy (čísla > 90 používám na ukončení logování) nenulové číslo (36, 46, 43) rychlost úderu (?) nebo 0 nota vypnuta.

9. leden 2014 — Dvě oka upletla a tři vypárala

… pokud vám to nic neříká, tak tak to dělala kněžna Bětka v Rumcajsovi. Prostě rychlost komunikace jsem změnil zpět na 9600 a pak i zakomentoval volání queryForce(). Proč? Abych potvrdil podezření, které jsem při čtení zdrojáků Orion knihovny nabyl: queryForce() je pomalé.

Výsledky:

9600 s queryForce() — 96ms, logs/fa140108_195547.log
9600 bez queryForce() — 64ms, logs/fa140108_195739.log
38400 bez queryForce() — 32ms, logs/fa140108_195936.log (ale místy až 46ms)
38400 s queryForce() … starší měření cca 63ms

Závěr? queryForce() si opravdu vezme 10ms+ na každé servo. Pro 20 serv bych se dostal na 200ms a update na 5Hz a to už není dobré. Důvodem je čekání při SPI komunikaci, které je sice v mikrosekundách, ale delay=5000 je opravdu hodně. Navíc se čeká 2x: po odeslání dotazu a v cyklu, před voláním cmdNOP a čekáním na platný výsledek. Pro queryForce() je 10ms tedy dolní odhad. Když SPI komunikace selže (checksum nebo timeout), tak se vše nekonečně opakuje:

unsigned char ReadPacketB(unsigned char cmd,unsigned delay=1000){
		unsigned int incrc;
		do{
			WritePacket(cmd,++ readindex);
			delayMicroseconds(delay);
			for(int i=0;i<20;i ++){
				incrc=WritePacket(cmdNOP);
				delayMicroseconds(delay);
				if(inpacketcrcincrc && inpacket[0]readindex){
					break;
				}
			}
		}while(inpacketcrc!=incrc || inpacket[0]!=readindex);
	
		return inpacket[1];
	}

Předpokádám, že pro delay=5000 je důvod a servo deska musí teprve dál komunikovat se samotným servem a stav zjistit … cestu s experimentálním snižováním této hodnoty tedy zatím neplánuji.

A co komunikace přes USB převodník? Nejprve oprava, že to není 19+12 bajtů, ale 19+15 bajtů (zapomněl jsem na start bajt, délku a kontrolní součet), tj. celkově 34 bajtů. Pro 9600 je spodní odhad 35ms, pro 38400 pak 9ms. Rozdíl tedy zhruba 16ms. V reálu to vypadá spíše na něco přes 32ms, takže předpokládám nějaké „paušální” zdržení spíše na PC straně. Data budu brzy posílat delší a pak bych to znova porovnal.

Co dál? Kurt a Nathan doporučují místo queryForce použít trigger (spouštěč?), kdy při překročení zadané hodnoty servo samo zastaví. Skoro bych tipoval, že tedy existuje další (tajný?) příkaz pro Orion digitální servo, kdy tento trigger se už přednastaví přímo na servu a není tedy nutná žádná další komunikace.

10. leden 2014 — Ubuntu

Dnes malá odbočka aneb jak rozchodit komunikaci mravenec — linux/Ubuntu. Důvod? Druhý „soutěžící v paralelním slalomu” používá Ubuntu a má zatím nějaké problémy …

Vlastně to bylo snazší (ťuk, ťuk, ťuk … ono se ještě určitě něco pokazí) než ve Windows, ale to především z důvodu, že jsem tušil, kde bude zádrhel. A byl. Zase VID/PID USB zařízení:

$ dmesg | tail
[ 1092.032093] usb 2-2: new full-speed USB device number 2 using uhci_hcd
[ 1092.235131] usb 2-2: New USB device found, idVendor=0403, idProduct=a559
[ 1092.235140] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1092.235147] usb 2-2: Product: Communications Port
[ 1092.235152] usb 2-2: Manufacturer: Basic Micro
[ 1092.235158] usb 2-2: SerialNumber: BMVNT4DB

I na linuxu je tedy třeba nějak říci, že ten VID=0403 a PID=a559 odpovídá standardnímu FTDI serial driveru. Asi nejlepší (funkční) nápovědu jsem našel na Basic Micro foru:

vytvořit soubor /etc/udev/rules.d/99-usbftdi.rules s obsahem

# load basicMicro usb2Serial
ATTRS{idVendor}"0403", ATTRS{idProduct}"a559", RUN+="/sbin/modprobe -q ftdi_sio product=0xa559
vendor=0x0403"

(člověk musí mít rootovská práva)

restartovat udev:

sudo restart udev
sudo udevadm trigger

Pak už se objeví vytoužený /dev/ttyUSB0.

Instalace „Arduino IDE” proběhla bez problémů — zase jen detail, že aby člověk mohl používat USB port, tak uživatel musí být ve skupině dialout (a je třeba vystoupit a nastoupit). Pak znova upravený příklad na pípání a hurá, jde to programovat i mravenec pobrukuje .

p.s. původně jsem postupoval podle Arduino Tutoriálu, takže některým problémum jsem se možná rovnou vyhnul (konkrétně konflikt s brltty)

13. leden 2014 — zapojeno 18 serv

Zítra je den D a ještě stále nechodím. Rozhodl jsem se jít cestou Record & Replay s tím, že jsem nejprve upravil kód aby respektoval executeAt parametr a pak přidával serva.

Zatímco přechod ze tří serv na devět vyžadoval drobné změny, přechod na 18 serv už byl triviální. To zní jako vítězství, ale … když jsem po record pustil replay, tak vždy levá přední noha šla do nesmyslné polohy (jiné, než nahrávané). Důvod? Ani kabeláž, ani porouchané servo, ani chyba v kódu … chyba byla v nějakém prehistorickém zápisu do registrů servo-desky. Matně si vybavuji, že mi to kdysi zlobilo už při „hraní na piáno” a „vyřešil” jsem to tak, že jsem začal používat jinou nohu. Ve zkratce řešení bylo zavolat v kódu Orion.resetRegs() a servoMin se změnilo na -2000, servoMax na 2000 a AOffset na 0. Teď se to chová správně, tj. co nahraji, to i přehraji … je čas jít spát.

15. leden 2014 — druhý FireAnt

Včera proběhlo první „pracovní setkání mravenců”. Přestože to jsou příbuzný

2x FireAnt

(stejná stavebnice), rozhodně to nejsou klony nebo jednovaječná dvojčata. Pominu-li vliv prostředí na vývoj jedince, pražská mutace měla jednu nohu obráceně (sám jsem si toho nevšiml, ale vlastně to je jen „kosmetický detail” nemající vliv na „funkci rostlináře” ), rozdíly byly i základních dílech. Mám na mysli především jiné mozky: můj mravenec má v sobě ATmega328 s deskou „Arduino Duemilanove” a ten druhý nevím jaký má čip (deska byla pěkně zadrátovaná v těle), ale deska to je typ „Uno”!

Další rozdíl byl v USB VID/PID. Když jsem to chtěl řešit a koukal do dmeg, tak jsem tam myslím zahlédl PID=6000 (?), ale nejsem si 100% jist. Proč jsem tomu nevěnoval větší pozornost? Protože to bylo standardní FTDI IDčko, na Ubuntu notebooku byl vidět /dev/ttyUSB0 a tato část rovnou fungovala.

Novinkou bylo Playstation2 rozhraní a třída BMPS2. Až když jsme to konečně prokopali jsem pochopil, že je to další převodník, který se pro Arduino desku tváří jako sériový port. Ne úplně zanedbatelný čas padl na chybu v zapojení — přijímač je třeba zapojit na Arduino pin 6, nebo v kódu změnit číslo na této řádce:

BMPS2 ps2x(6,100);	//Use Arduino Pin 6 with 100ms maximum refresh rate

V půl desáté večer už Francouzko-kanadský FireAnt s oficiálním firmware naběhl a přes PS2 šla spustit kalibrační procedura. Je třeba se všemi klouby hýbat do extrémů a definovat mechanické limity. Při této „rozcvičce” ale povolil spoj u konektoru baterky a stejně už bylo dost hodin … nic, pokračování zítra, resp. dneska.

Z věcí, které se nám zatím nepodařilo rozchodit, mne asi nejvíce vadí komunikace z Pythonu přes /dev/ttyUSB0. Přestože pyserial, python i git byly nainstalované, zatím se to nějak bránilo logování pozic serv a zpětnému přehrávání … TODO.

p.s. sešli jsme se na ČZU, kde asi budeme dnes pokračovat s Husky:

Robot Husky

… a spíše jen z plezíru jsem vzlétl i s Isabele, což je klon Heidi jen s modrou „čapkou” (a bydlí na ČZU).

16. leden 2014 — doubleplusungood

Nefunguje to! To = oficiální firmware na chození s řízením přes PS2 :-(. Došlo i na telefonický hovor přes Atlantik … no prostě je to třeba málem celé rozebrat a zkoušet kousek po kousku.

O předvčerejší chybě v zapojení PS2 přijímače jsem psal a teď už i chápu jak k tomu asi došlo. Robot má 25 serv (18 nohy, 5 čelisti, 2 ocas), ale „servo shield” dokáže řídit maximálně 24. Trik je v tom, že z druhé desky (Arduina) je vyvedeno osm pinů a i ty mohou být použity pro řízení serva. Pokud vám někdo tedy řekne, „zapojte PS2 přijímač na pin 6”, tak je třeba zároveň zdůraznit, že se jedná o Arduino-pin 6.

Věřím, že tedy prapůvodně byl přijímač zapojen na pin 6 servo shieldu a ostatní konektory „pěkně vycházely” (ve finále tam má být jeden volný slot, ale číslo 2 a ne 6). Podobná chyba byla v zapojení serva na pin 16. Na toto přijít s dodávanou kalibrační rutinou a jen poslouchat pípání robota jako zpětnou vazbu snad fakt není ani možné.

OK, to byla první část. Pak jsem odkomentoval define na DEBUG (ano, ve zdrojácích oficiálního firmware), trošku znervózněl při pohledu na řádku:

Serial.begin(625000);

jestli to není „trošku moc” (Nathan mi pak po telefonu vysvětlil, že to je maximální rychlost, kterou to stejně nepojede … že to znamená „cpi tam data jak nejrychleji můžeš”) … stejně jsem to pak změnil na 9600, ale to je jedno. Do kódu jsem přidal skoro za každou řádku výpis na seriák, takže výstup pak vypadal třeba takto:

""" .START! xwaking upwaking done.a>>>>>>>>>>>>>>

..START! xwaking upwaking done.a>>>>>>>>

….START! xwaking upwaking done.a>>>>>>>>>>b

…START! xwaking upwaking done.ab

………..START! xwaking upwaking done.abcd

"""

No, tak trochu boj s větrnými mlýny. Část „a>>>...b” je z cyklu 50x opakuj update serv na ocase a jak vidíte, tak program se kousnul vždy po různém počtu opakovaní. Cyklus jsem zkracoval i úplně vypustil, ale stejně se to po chvíli kouslo a program zamrzl a občas se resetoval. Občas vůbec nenaběhl. Prostě prima.

Nathan zmínil ať ještě raději zkusím vývojové studio Arduino 1.0.1 (co má také na webu), ale dopadlo to stejně jako v mém Arduino 1.0.5. Podezření je na přerušení, tj. že kód na řízení Tail serv s tím nemá nic společného (také jsem ho celý zakomentoval, takže to potvrzuji).

A jak to dopadlo, přesněji jaký je stav teď? Sylvio ráno vyrazil na desetihodinou cestu autem zpět do Francie a druhého mravence mi tady nechal. Takže mám teď dva. Někdo by to interpretoval jako dobrý výsledek, ale já moc nevím … rozhodně je teď o něco více času ověřit to servo po servu a veškerou činnost logovat po seriáku.

p.s. pokud vám dnešní název nic neříká, tak viz Newspeak z 1984

20. leden 2014 — Joséphine pod drobnohledem

Joséphine jsem nazval druhého robota — Sylvio mu říká WeedAnt. Za mne to odpovídá dalšímu písmenku v abecedě po Heidi a Isabele („sestra Heidi” na ČZU). Jméno je z knížky „Ostružinové víno” od Joanne Harrisové, kterou momentálně čtu. Potřeboval jsem se od robotů nějak odreagovat a tak jsem s nimi tento víkend nedělal vůbec nic. Mám-li ještě jednou použít zmíněnou knížku, tak bych citoval Jay někde na straně 184: „Garden work clears the mind”. Krásně to sedělo/fungovalo .

Dnes ráno jsem do Joséphine nahrál týden starý kód na ovládání 18ti serv a ohackoval ho, aby místo queryForce() posílal queryAOffset(), pak flashnul na posílání queryServoMin() a konečně do třetice flashnul aby poslal queryServoMax(). Podle logu to byla práce celkově na necelé tři minuty. A už mám minimálně jedno podezření, co je špatně …

Výsledky pro min, offset, max:

(1675, 810, -458, -692, 1935,  -46, 359, -490, 427, -526, 1857,   206, …
(2296, 810, -458,   26, 1935, -892, 359, -425, 427,  -40, 1857, -1160, …
(1674, 810, -458,  972, 1935, 1954, 359, 1054, 427,  541, 1857,  1961, …

Je to zase čas (ze tří různých logů), napětí baterky, pozice serva 1, hackovaná hodnota serva 1, pozice serva2, … ale když o tom přemýšlím, tak je to možná správně. Kdyby kurňa ty funkce někdo zdokumentoval :-(. Co se mi ještě před chvílí nelíbilo byla poslední vypsaná hodnota (206, -1160, 1961). Nějak stále předpokládám, že pozice serv jsou absolutní, ale možná ne?! Pokud jsou absolutní, tak je to určitě špatně, protože středová poloha by měla být mezi min a max, není-liž pravda? Podle toho, jak Nathan říkal, že na pořadí nezáleží bych soudil, že tomu i tak musí být … ale nevěřím jim. Vyžádané zdrojáky na Sevo Shield stále neposlal, tak jdu asi dělat znova triviální testy s jedním servem na prvním FireAntovi.

21. leden 2014 — BASIC je základ!

Nedělám si srandu . Včera se mnou už lomcoval vztek a sršel jsem síru (ještě ji trošku cítím), sepisoval jsem si koncept „Jsem vážně nespokojený s Vaším produktem ...”, když Nathan odpověděl a poslal zdrojové kódy k Servo Sheiledu. K mému velkému překvapení je to naprogramované v BASICu! Ale asi proč ne. Používal jsem ho naposledy na ZX Spectrum a to už nějaký pátek je. Kód je celkem čitelný, jen zatím netuším co je to zpětné lomítko:

hservo [val1&0x1F\-30000+258]

Tak už WeedAnt chodí? Nechodí a „opakovanou kalibrací nakalibrovat nejde”!!! Trošku jsem se nechal o půnoci unést (viz Orion fórum). Ve zkratce, zkalibrovat FireAnt s existujícím firmware jde pouze poprvé a nesmíte prohodit pořadí kroků kalibrace. Nejprve extrémy min a max a teprve pak středový offset. Po pravdě si myslím, že i to nebude správně ani tehdy (viz níže), ale dokud to nerozchodím, tak si nejsem 100% jist.

O co jde? Surová (raw) vs. zpracovaná data. Sevo se řídí délkou pulzů a to není něco, co by jste chtěli v pěkném API mít. Orion Robotics tedy používají desetiny stupně. V jaké je servo poloze se dozvíte pomocí funkce queryFBAngle(). Tento úhel je již zpracovaný (!) — bere v úvahu offset (nastavitelný pomocí setAOffset() a zjistitelný pomocí queryAOffset()).

Dále zde máme limity, koncové dorazy, pro které se noha již dotýká konstrukce. Ty lze nastavit pomocí funkcí setServoMin() a setServoMax(). Zatímco offset je taková obezlička, aby se vám lépe počítalo (asi), tak tyto limity by na ofsetu měly být nezávislé. Souhlasíte? Jsou.

A teď zpět ke kalibrační proceduře. Pro kalibraci středu rozložíte robota do „stabilizované polohy”, prostě ho rozplácnete, srovnáte natažené nohy, aby se celou plochou dotýkaly podložky. Offsety se nejprve vynulují a až zmáčknete tlačítko, tak se uloží hodnota přečtená pomocí queryFBAngle() jako nový offset. OK?

Poloha pro kalibraci offsetu

Pro kalibraci limitů se nastaví proměnné min=3000 a max=-3000, tj. doplňkových 300 stupňů, a průběžně se berou hodnoty z queryFBAngle() a upravují min a max. Po stisku tlačítka se zase všechny uloží.

Je to srozumitelné? Nějaký problém? Ano, hned tři. Pokud máte čistou desku z továrny, tak defaultně jsou registry prázdné a offset je nula. Pokud tedy nejprve kalibrujete limity, tak máte šanci (ve skutečnosti nemáte, ale to později). Pokud ale nejprve zkusíte offsety (to byl náš případ a podle telefonického hovoru s podporou by to i mělo být jedno v jakém pořadí kalibraci děláte), jste na věky ztraceni. Min/max se pak totiž už nesbírá z absolutních čísel, ale z relativních vůči offsetu. Jediná cesta je nějak si resetovat registry Servo Shield desky (je na to funkce, viz jeden starší příspěvek).

A ty další dva problémy? Upravený úhel je nejen posunutý, ale může mít i opačné znaménko (v případě, že nastavíte opačný směr pomocí setServoDir(), což firmware FireAntu používá). Tímto způsobem ale pak kalibrujete opačné limity, které typicky nejsou symetrické.

Do třetice lze i nastavit, kolik tiků časovače je vlastně v realitě jeden stupeň (funkce setServoDegree()) a tato hodnota má vliv snad na všechno. V Servo Sheildu je původní hodnota 178, kalibrace mravence tam nastavuje 176 … to už je relativně drobná odchylka.

Ještě jednu prima chybu na závěr (viz diff). V Assembly Guide se píše: The robot has to be wired based on the default configuration. This configuration can be changed. However it is not recommended. Je to 25 čísel, a tak jsem si vůbec nevšiml, že tato sekce je demo kódu 2x. Navíc piny pro serva na druhé noze byly identické. Zatracený #ifdef CUSTOMPINS). Za mne je to příklad „zbytečného znečtelnění kódu”:

//#define CUSTOMPINS 
…
//Servo pin numbers
  #ifdef CUSTOMPINS
#define LFC 21
#define LFF 22 
#define LFT 23
#define LMC 20
#define LMF 19
#define LMT 18
#define LRC 17
#define LRF 16
#define LRT 0
#define RFC 13
#define RFF 14
#define RFT 15
#define RMC 12
#define RMF 11
#define RMT 10
#define RRC 9
#define RRF 8
#define RRT 1
#define HeadPitchPin 3
#define HeadRollPin 7
#define HeadYawPin 6
#define PincerLPin 5
#define PincerRPin 4
  #else
#define LFC 23
#define LFF 22 
#define LFT 21
#define LMC 20
#define LMF 19
#define LMT 18
#define LRC 17
#define LRF 16
#define LRT 0
#define RFC 15
#define RFF 14
#define RFT 13
#define RMC 12
#define RMF 11
#define RMT 10
#define RRC 9
#define RRF 8
#define RRT 1
#define HeadRollPin 7
#define HeadYawPin 6
#define HeadPitchPin 5
#define PincerLPin 4
#define PincerRPin 3
  #endif

23. leden 2014 — Malé pozorování

Je to divné. Zatím tomu nerozumím. Včera jsem ještě chtěl psát příspěvek „0 1 2 3 SMRT!”, hezky jako v Blesku, ale ráno jsem se to pokusil zopakovat a nepovedlo se mi to. Co jsem teď možná dělal jinak je zapínání — nejprve jsem zapnul robota a pak teprve ho připojoval přes USB k notebooku. Na začátku to vždy pípne, tak jsem si myslel, že se resetuje deska, ale možná jenom jedna z nich??

A co to dělalo předešlé noci (resp. dva dny zpátky)? Nasbíral jsem pro oba roboty polohu středového offsetu a pak místo přehrávání jí celou poslal do robota. Pozice tam stihl poslat 4x (?) a pak už se to kouslo a nic. Smrt.

Změnil jsem kód na

…
  cmdOffset = offset[2::2] # výřez ze stavového pole
  cmdStop = [STOP_SERVO]*NUM_SERVOS
  for selectedServo in xrange(NUM_SERVOS):
    for i in xrange(10):
      print i,
      status = readRobotStatus( com )
      cmd = cmdStop
      cmd[selectedServo] = cmdOffset[selectedServo]
      writeRobotCmd( com, cmd=cmd )
    writeRobotCmd( com, cmd=[STOP_SERVO]*NUM_SERVOS )
    print "END"

Je v tom začátečnická chyba, kdy cmd = cmdStop předá pouze referenci na pole a nechtěně měním původní cmdStop (správně to má být kopie pole pomocí cmd = cmdStop[:]). Výsledkem tedy bylo to, že všechna dosud vybraná serva (selectedServo) zůstala aktivní. Tento kód vždy po chvíli vedl k resetu desky.

Opravená verze, kdy opravdu pouze jedno servo bylo aktivní, se také chovala zajímavě. Každé sudé servo způsobilo po třech vnitřních cyklech chybu kontrolního součtu vysílaného paketu … ale jelo to dál a prošlo to všechna serva.

Zase je tam asi spíš více problémů, ale jeden z nich je „špatné závorkování”. Prostě writeRobotCmd je tam v každém cyklu o jeden více! Nevím, proč by to mělo vadit, ale vadí. Přidáním readRobotStatus() před vypnutí serv se rozhodně „něco” zlepšilo … asi to dává smysl. Zatímco se Arduino snaží realizovat předposlední příkaz, tak poslední příkaz se ztrácí přetékáním Arduino bufferu pro sériovou linku.

Ještě jedno pozorování. To vypnutí serv dělá nějakou neplechu (špatné pozice po následném zapnutí serv), takže ve výsledném kódu jsem plošné vypínání dal úplně na konec programu … ještě tedy ono možná vadí vypnutí všech serv a ne jenom jednoho (???). TODO.

Teď je na čase zopakovat stejný tělocvik s Joséphine …

24. leden 2014 — Self-reset

Tak Joséphine tělocvik nevydržela. Při protahování sedmnáctého kloubu jí to přestalo bavit a resetovala se. To by i vysvětlovalo, proč při ovládání všech serv najednou moc nevydrží. Pokud pohybuji jenom s jedním servem a ostatní vypínám (kód), tak vše funguje a je i dobře vidět, že zapojení všech serv už je správné. Problémy nastanou, když to upravím tak, aby použitá serva zůstala zapnutá.

Čekám na dokončení nabíjení druhé baterky, která je dost nešťastně přidělaná v těle robota (a nedá se snadno vyndat). V plánu mám přidat dotaz queryForce(), který bude sice pomalý, ale mohla by to být taková automatická diagnóza, jestli nějaké servo není problémové. Stejně tak bych v druhém pokusu zkusil vypnout dotazy na polohu, jestli by řízení „normálního” serva nebylo stabilnější.

Trvá to nějak dlouho a musím do práce … tak snad večer …

28. leden 2014 — Uno, Due, …

Říkal jsem si, že bych měl mravence nějak jednoznačně rozlišovat a vzpomněl jsem si při tom na jeden starý vtip o dvou policajtech:

Dvojice policistů dostane na obchůzky dva koně. ,,Jak si poznáme, koho je který?'' ,,Víš co? Já tomu jednomu uříznu ocas a ten bude můj.'' Když ale druhý den přijdou do práce, tak mají oba koně zkrácené ocasy. ,,Víš co? Tak já jednomu uříznu ucho a ten pak bude můj.'' Další den, ale zase oba koně mají uřízlé ucho. ,,Hele co kdybych mu zkusil vypíchnout oko?'' Ale i další den jsou oba koně na jedno oko slepé. ,,Víš co? Co kdyby ty jsi si vzal toho bílého a já toho černého?''

Vtip byl možná ještě morbidnější, ale zapamatoval jsem si ho, protože to byl první (a možná i poslední) vtip, který se mi úspěšně podařil podat v angličtině . No nic, co to má společného s mravencema? Nemám v plánu jim trhat nožičky. Proč je nerozlišovat podle čísla, kdy jeden má řídící desku Uno a druhý Duemilanove .

Jinak je to dost otrava. Přešel jsem na test ověření funkcí setServoMin, setServoMax, setServoDir a setAOffset. A už první pokus přinesl zvláštní poznatky. Nedělám tam nic jiného, než že ve smyčce ověřuji stav baterky a nastavuji polohu jednoho serva. A co se stalo? To jedno servo to nastavilo správně, ale během pár sekund se nastavilo ještě jiné servo! Toto byl FireAntDuo.

Večer jsem to zkusil ještě na FireAntUno. Než se začalo něco podivného dít, tak uplynula delší doba, ale i jemu se po chvíli pohnula pravá prostřední noha nebo levé čelisti. Trošku to podlomilo moji důvěru v implementovanou SPI komunikaci a Orion knihovnu. To by snad měl rozdýchat nebo ne? Uznávám, nebyl tam skoro žádný čas na nádech, ale tak si ho měl zajistit sám?? Možná si ještě zkusím spočítat, kolik těch cyklů se stihne za sekundu …

Když jsem přidal delay(10), tak tyto anomality zmizely, resp. neměl jsem už dost trpělivosti na ně čekat, a mohl jsem přejít k původnímu testu.

Vypadalo to celkem rozumně. Min/max/offset jsou nejspíš absolutní hodnoty pozic serva a je jedno v jakém pořadí se nastaví směr serva setServoDir a offset. I min/max „zařezávaly” požadovaný úhel, že se servo nepohnulo dále. Max je silnější, takže když jsem zkusil nedefinovaný max=-200 a min=200, tak se servo pohnulo do polohy -200.

Konec pohádky. Když jsem omylem nastavil max=-2000 a min=2000, bylo to po pokusu s prohozením min a max, tak se nestalo nic. Když jsem pro správný interval -2000 až 2000 nastavil offset 100 a polohu 1000, tak jednou to šlo do záporného extrému, jednou do kladného a pak to následně nedělalo nic! Napadá mne, že programováním přes USB se asi resetuje pouze Arudino deska a Servo Shield je v nějakém divném stavu. Nebo občas nefungují nastavovací funkce v setup(). Nebo je tam ještě nějaký divný prvek v registrech, který si s tím dělá co chce … dnes ráno mne napadl „force trigger”, který to zabije??

Trošku únavné. Vlastně jsem nezmínil víkendovou motivaci — byl jsem bez robotů bos a tak jsem si četl zdrojáky FireAnt firmware ovládaného přes PS2. Vedle chození všemi směry, otáčení, regulování rychlosti a výšky chůze, by měl mít předprogramovaných deset typů chůze, různé vrtění a protahování … prostě jsem to chtěl vidět v reálném světě . Přepojil jsem PS2 přijímač na Duo (ten se sám od sebe neresetuje), zkusil nakalibrovat a pak zkusil chůzi. Nějaký naznak tam byl, ale nohy byly po jedné kalibraci pod robotem, po druhé hodně natažené a je to celkem agresor a jde z něj strach. Tak postupně 1, 2, …

29. leden 2014 — Gottwaldův koan

Nemyslím nějakého slavného programátora nebo zen-budhistu, ale osobu z dob, kdy se „bojovalo za mír” a skončili jsme ve slepé uličce, protože „zpátky ni krok”. Myslím jedno z hesel … Důvěřuj, ale prověřuj!

Prostě k nastavování parametrů jsem přidal i následné ověření, že daná hodnota byla opravdu nastavena. A kdyby to náhodou nesedělo (velmi nepravděpodobné), tak pípej (viz diff).

… a pípalo to zběsile :-(. Přidal jsem ještě výstup na konzoli a problém je v nastavení offsetu, kdy po setAOffset(100) vracel queryAOffset() nulu. Jak už po delším zápasení ztrácím smysl pro realitu, tak jsem to i napsal na Orion fórum a teprve teď vidím, že tam mám prohozené proměnné. Žádná záhada. „Měl byste se nad sebou soudruhu zamyslet a nestřílet hned na všechny strany...”

30. leden 2014 — Neckerova krychle aneb myšlenkový zlom

Znáte Neckerovu krychli? Pokud ne, tak zkuste např. tento odkaz. Prostě mozek si zafixuje jednu z variant a je hodně těžké přepnout na druhou. A stejný problém jsem měl i já. Prostě setServoMin/setServoMax jsem bral jako fyzické limity nezávislé na čemkoliv, ale ve skutečnosti to jsou „logické” limity a pouze ořezávají vstupní hodnotu pro setAngle(). Teprve pak přichází na scénu offset a směr serva.

Co z toho vyplývá? Především při kalibraci je zásadní nejprve provést nastavení středů (offset) a teprve pak rozsah (min/max). Nastavení směrů pokud možno fixované (jak je v oficiálním firmware). Pokud to uděláte obráceně, tak nastavené limity posunete úplně jinam po změně offsetu.

Nahrál jsem tedy do FireAnta znova původní firmware, ale tentokrát pouze kalibroval rozsah (středy jsem měl už od minule a ty tedy vlastně byly správně a na rozsahu nezávislé). Ovládání přes PS2 je mizerné, ale těší mne, že i ostatní mají problém. Jak to vypadá v reálu se můžete podívat na dost úděsném videu. A ještě jeden dost zásadní detail — aby byl mravenec v nějakém použitelném stavu, musíte ho postavit pomocí opakovaného mačkání kombinace: D-Pad Up + L1.

31. leden 2014 — FireAntUno už běhá!

Je to jak s karetními triky. Když je jednou prokouknete, už nikdy nepochopíte, „jak jste mohli být tak slepí?!” . Takže nejprve díky Ondrovi z práce za rozlousknutí a za RTFM (ošklivá zkratka o čtení manuálu, tady data sheetu). Skoro mám pocit, že u FireAntDuo jsem to na začátku zkoumal, ale u jedničky už jsem to neověřil. A přitom je to tak prosté …

Jumpery pro napájení

Zajímá vás, proč se FireAntUno stále dokola resetoval? Nepomohla by ani Pavlem doporučená Kubáčova magická dioda. Důvodem byly čtyři špatně nastavené jumpery na Servo Shield desce (na obrázku je zakroužkováno, jak to má být správně — je to staré foto z Due(milanove)). Lze pomocí nich nastavit, zda napájení má být VS nebo VCC, tedy zda přímo z baterky nebo přes regulátor Arduino desky. A na Uno to šlo přes desku. T d dam dam … už to funguje. Viz důkaz.

A co dál? To ovládání přes PS2 je stále mizerné, nepomáhá aní Kurtova oprava (ještě jsem mu to nenapsal). Jelikož Sylvio chce s mravencem natočit krátký film, tak pro to je ovládání celkem kritické. Možná bych přešel na posílání příkazů z PC po USB. Ještě nevím. Každopádně první milník je konečně dosažen.

2. únor 2014 — execGait()

Dnes mám spadeno na tuto funkci:

void OrionClass::execGait(
     int BodyYaw,int BodyRoll,int BodyPitch,
     int BodyRotOffsetX,int BodyRotOffsetY,int BodyRotOffsetZ,
     int BodyOffsetX,int BodyOffsetY,int BodyOffsetZ,
     int Xdist,int Ydist,int Zdist,int Rdist,
     int XLegAdj, int ZLegAdj,
     int Rate,
     boolean EnableForce)

Na můj vkus má trošku moc parametrů, ale zase dělá „úplně všechno” co se týká gait. Toto anglické slovo jsem neznal a znamená (způsob) chůze , držení těla při chůzi. Pokud tím mravence nakrmíte, tak chodí deseti ruznými typy chůze (RG6, RG12, QR9, TRI4, TRI6, TRI8, TRIO12, TRIO18, WAVE12, WAVE18) s tím, že tělo může mít různě vysoko, posunuté do strany nebo dopředu, nakloněné, zvedat nohy hodně nebo málo … a asi ještě spoustu dalších věcí.

Zároveň to snad bude i odpověď na dotaz fandorama přispěvovatele Josefa: Máš v úmyslu do budoucna využívat dodaný firmware, nebo naprogramovat vlastní algoritmus chůze? Původně jsem si chtěl každé servo řídit zvlášť, od každého mít zpětnou vazbu o poloze a síle. Postupem času ale narážím na úzká hrdla a tak možná nejprve zkusím co přímo nabízí Orion knihovna: execGait.

Zdrojový kód pro test chůze je zde, ale zatím tomu moc nerozumím. Používá se TRI4, což předpokládám je vždy trojice nohou statická a trojice se pohybuje. Nevím proč, ale stále mi FireAnt(Duo) zatáčí vpravo. Teď výhoda dvou robotů, … flashuji FireAntUno … tak žádná magie. Uno chodí rovně, takže je to pravděpodobně problém kalibrace.

Jinak do „startovní polohy” (tlačítko A používám na start a tlačítko B na stop, takže mne netrápí zákmity), doslova skočí, takže tím poděsil nejen mne, ale i náš pes okamžitě zdrhnul .

Středy jsem teď na Duo znova překalibroval, ale žádná změna. Že by to zase bylo nějak provázané s min/max? Dnes už na to ale nemám moc náladu …

5. únor 2014 — PlayStation2 protokol

Dokumentace trošku zaostává za pokusy … tentokrát bližší zkoumání PS2. Ovládání mravence nefunguje tak jak bych si představoval a jedno z podezření padá na nespolehlivý příjem příkazů z dálkového ovládání. Původně jsem si myslel, že třetí kabel u přijímače v troj-pinovém servo konektoru je pouze výstup (z pohledu Arduina vstup), ale není tomu tak. Je to vstupně/výstupní seriák a už u tohoto faktu mne trošku zamrazí :-(. Chtěl jsem přepnout vysílání na „stream”, ale nevím jak a asi to ani nejde. Z jedné pseudo dokumentace vyplývá, že je třeba neustále posílat příkazy, na které dostanete odpověď se stavem tlačítek a páček.

Tak to je jeden HW potenciální problém. SW lze zkompilovat s DEBUG a vypisuje na konzoli případné problémy (přidal jsem si tam i výpis, „případného” úspěšného příjmu). Vypadalo to asi takto:

Bad packet FF FF 0 0 0 0 0 0 0 0 0 FF 0 FF 0 0 0 0 0 0 0 0 30 36
Bad packet FF FF 0 0 0 0 0 0 0 0 0 FF 0 FF 0 0 0 0 0 0 0 0 10 36
Data OK
Data OK
Bad packet FF FF 0 0 0 0 0 0 0 0 0 FF 0 FF 0 0 0 0 0 0 0 0 35 32
Data OK
Bad packet FF FF 0 0 0 0 0 0 0 0 0 FF 0 FF 0 0 0 0 0 0 0 0 35 32

Takže se mi to nezdá a něco tam opravdu je špatně!

Chvíli jsem si nahrával výpisy a udělal malou „statistiku”:

count:
     24	Bad packet FF FF 0 0 0 0 0 0 0 0 0 FF 0 FF 0 0 0 0 0 0 0 0 10 36
     85	Bad packet FF FF 0 0 0 0 0 0 0 0 0 FF 0 FF 0 0 0 0 0 0 0 0 30 36
      5	Bad packet FF FF 0 0 0 0 0 0 0 0 0 FF 0 FF 0 0 0 0 0 0 0 0 35 12
     88	Bad packet FF FF 0 0 0 0 0 0 0 0 0 FF 0 FF 0 0 0 0 0 0 0 0 35 32
      1	Bad packet FF FF 0 0 0 0 0 0 0 0 7F 36 0 FF 0 0 0 0 0 0 0 0 15 CC
      1	Bad packet FF FF 0 0 0 0 0 0 0 0 7F 38 0 FF 0 0 0 0 0 0 0 0 46 A3
      2	Bad packet FF FF 0 0 0 0 0 0 0 0 7F 7F 0 FF 0 0 0 0 0 0 0 0 21 CF
      1	Bad packet FF FF 0 0 0 0 0 0 0 0 7F 80 0 FF 0 0 0 0 0 0 0 0 80 C4
      2	Bad packet FF FF 0 0 0 0 0 0 0 0 7F FF 0 FF 0 0 0 0 0 0 0 0 80 65
      1	Bad packet FF FF 0 0 0 0 0 0 0 0 7F FF 0 FF 0 0 0 0 0 0 0 0 A0 65
      1	Bad packet FF FF 0 0 0 0 0 0 0 0 80 7F 0 FF 0 0 0 0 0 0 0 0 16 3C
      2	Bad packet FF FF 0 0 0 0 0 0 0 0 80 80 0 FF 0 0 0 0 0 0 0 0 A7 36
      1	Bad packet FF FF 0 0 0 0 0 0 0 0 80 AB 0 FF 0 0 0 0 0 0 0 0 CF 38

V prvních čtyřech případech má být kontrolní součet 35 36, takže všechny chyby jsou nuly v místech, kde mají být jedničky. Ale ne obráceně. Netuším, zda je to jenom náhoda nebo z počítání kontrolního součtu to je přece jasné?? V plánu mám test bez dalšího kódu pro serva, test s jiným PS2 ovladačem a logování po delší dobu.

7. únor 2014 — test_ps2

Dal jsem teď na github kód testování PlayStation2. Vlastně nedělá skoro nic, jenom dokola čte z PS2. Magie se skrývá v upravené knihovně BMPS2X, kterou kompiluji v DEBUG módu a výpis úspěšných a špatných paketů jsem zkrátil do jednoho bajtu. Dokud nezapnu ovladač, tak je vše OK. Pak začnou chodit špatné pakety, ale systém v tom zatím nevidím — vy ano?

.=OK, B=BAD

Nepříjemné pozorování je, že chybových paketů je poměrně hodně. Skoro bych si troufl říci, že 50%. Navíc data sbírá poměrně pomalu:

BMPS2 ps2x(6,100);

tj. na PINu 6 poslouchá a čeká 100ms, tedy 10Hz update. Zkusil jsem to snížit na 10 a vůbec se nepodařilo navázat spojení. Posunul jsem to na defaultních 30 a dostal jsem následující obrázek:

chyby pro 30ms

Možná je to jenom klika, ale nikde nevidím dvě Béčka po sobě? Často je každý druhý paket špatně, ale stále to znamená rychlejší a spolehlivější komunikaci než při 100ms. Zkusím to obalit a nahradit jedno čtení dvěma. Nebo ještě chvíli experimentovat s tím časem …

8. únor 2014 — Travel Light

Včera už mi došla trpělivost a dálkový ovladač jsem hodil do koše. Skutečnost, že to pro 30ms vycházelo dobře minimálně každý druhý příjem, byla náhoda. Ještě jsem si chvíli hrál s původním kódem mravence a čtení nahradil troj-čtením s čekáním, jestli se to alespoň jednou nechytne, ale nijak viditelně to nepomáhalo. Takže konec a zpět k „verzi 0”.

Extrémisti mají na toto pravidlo: Travel Light, v překladu „cestuj nalehko”. Jinými slovy: „vše, co nutně nepotřebujete, hoďte přes palubu.” Tak už to lítá … žádné dálkové ovladače, žádný Orion.executeGait, žádné kalibrace, žádné setServoMin/setServoMax, žádný setServoDir/setServoDegree. „Proletáři všech zemí, vyližte ...” však víte … to se mi ulevilo . Předpokládám, že se vracím cca 2 měsíce zpět, ale už vím o trošku více a budu si jednoduchosti zase náležitě vážit.

Co teď robot dělá? V zásadě je to kód na ovládání serv přes USB, kdy jako stav vracím aktuální polohu serva a příkaz je požadovaná poloha serva. Nic víc a nic míň. Složitost přesouvám na PC do Pythonu. Kód na chození rovně najdete zde. Při kopírování kódu s použitím Kosinové věty bych si zase nafackoval:

ta,tb,tc = triangleAngles( b, c, d-a ) # TODO z-coordinate

… se skoro divím, že to na to piáno hrálo … když oprava je tak „hrozně složitá”:

ta,tb,tc = triangleAngles( b, c, math.hypot( d-a, z ) )

… ale možná jsem teď jenom „hrozně chytrej” a zanesl jsem tím jinou chybu (viz triangle.py).

Styl chození je ten nejjednodušší, kdy každou chvíli jsou na zemi právě 3 nohy. Úhly pro jednotlivá serva počítám z požadované relativní souřadnice (x,y,z) vůči prvnímu kloubu na těle robota. Přidal jsem tam ještě lineární interpolace mezi starým a novým příkazem a tam končím. A po X měsících jsem „neustálým přešlapováním na místě” konečně vybil baterku …

9. únor 2014 — První zničené servo

Když jsem včera zkoušel ver0, tak jsem slyšel nějaké nepříjemné zvuky. Dnes jsem mravenci „prohmatával klouby” a opravdu minimálně jedno servo je zničené :-(. Je to prostřední servo u prostřední nohy, tj. při 3+3 chůzi je na tuto nohu největší váha, ale že by to vytrhalo zuby?!

bezzubé kolečko

20. únor 2014 — Obezita

Obezita není dobrá na klouby. A platí to i pro mravence. Přestože Nathan mi přislíbil poslat náhradní převody (na webu mají krásnou (dost americkou) větu: All Orion Robotics servos come with a no questions asked 2 year warranty. Send us your servo and we will repair or replace it free of charge.) tak mám vážné obavy, že se celý scénář rychle zopakuje.

Kolik FireAnt váží?

FireAnt má skoro 3kg

Většinu váhy jsou serva, Weighs 2.1oz, česky Unce (1 unce [oz] = 28,3495 g), což i zhruba potvrzuje měření:

hmotnost serva

Dále je třeba zmínit, že číslo u HV220 digitálního serva znamená 220 oz/in, což je 6.226kg/254 milimetru (viz Palec) a zhruba 2.4kg na 1cm.

A teď páky — noha je běžně 22cm od středu robota, prostřední servo pak 13cm. Při „šťastném” rozdělení váhy 3kg na tři nohy je to 1kg, při nešťastném 1.5kg a více. Na první pohled tedy skoro desetinásobné přetížení specifikace serva?! To nemůže dobře dopadnout!

Je dost pravděpodobné, že mám ve výpočtech/odhadech nějakou zásadní chybu. Hlavní fyzik z bývalého Short Circuits týmu mi na toto téma napsal: „Myslim, ze ty tvoje uvahy jsou principialne dobre. Jen mi prijde, ze zapominas, ze ty sily, co vznikaji jednak musi kompenzovat vahu robota (to uvazujes), ale pak jeste (a na to mozna zapominas) zrychleni robota. A to je hur predpovidatelny, protoze muze byt do vsech smeru...”

Tak nevím — bude to dynamicky ještě horší nebo naopak lepší a vysvětluje se tím, že to občas vůbec funguje? Komentáře vítány .

21. únor 2014 — Robotici sobě!

Tamtamy fungují!

Na pracovním večírku mi kolega říká: „Četl jsem, že už jsi zničil servo?!” … a trošku to znělo jako „slyšel jsem, že jsi Pražákovi naboural sloupek” (Vesničko má středisková) … ale informační kanály fungují! A co víc pod-skupinka se hned vrhla na počítání rozložení sil na mravencově noze . V mezičase přišel mail od Martina Lockera. Poučný. Skoro se stydím. Zase špatné asociace … měl jsem pocit, že Hitec serva měla podobný kód a vycházelo to nějak okolo 3kg/1cm, ale …

,,Ahoj Martine, díval jsem se na tvůj rozbor obezity FireAnta. Trošku bych to poopravil (předpokládám, že tvůj omyl vznikl používáním zcela nesmyslné jednotky "krouticího momentu" - správně má být N.m - resp. v nejhorším kg.cm !!!): 220oz.in odpovídá tedy:

220 x 28,3495 g = 6,237 kg

1 (in) palec = 2,54 cm

220 oz.in = 6,237 x 2,54 = 15,842 kg.cm

(tvůj výpočet 2,4 kg.cm by byl horší než nejlevnější servo, ty mají cca 3kg.cm)

a tedy na rameně 22cm je maximální zatížení 0,72kg.

Jinak dynamické zatížení ti může odlehčit, ale ve většině případů ti naopak přitíží. Při běžné rychlosti pohybu to asi nebude nijak zásadní (předpokládám, že se tam nebudou vyskytovat zrychlení srovnatelná s tíhovým zrychlením g = 9,8 m.s-2). Přesto to není žádný zázrak: pokud předpokládáš maximální statické zatížení 1,5kg, tak je servo dvojnásobně přetížené.''

Tak veřejné díky . Teď to dává smysl.

6. březen 2014 — Náhradní převodovky

Možná se, stejně jako Sylvio, ptáte, co nového s mravencem? Odpověď vás asi zklame — nic. Naplno se věnuji Isabelle a Air Race, kam se letos přihlásilo 17. týmů. FireAnt tedy stojí na druhé koleji …

Můj „momentální mentální blok” je asi spojen se skutečností, že servo, se zpětnou vazbou a detekci sil, se může samo rozbít. To odporuje třetímu robotickému zákonu — „Robot se musí chránit před poškozením, kromě případů, kdy je to v rozporu s prvním nebo druhým zákonem.” A to Servo Shield nedělá. A jsem přesvědčený, že by na to měl schopnosti a defaultně by měl být v nějakém „self-protective” módu.

Prostě výmluvy, výmluvy, … . Stále mám podezření, že vedle přetížení serv si zuby vylámal při počátečním zákmitu. V plánu mám zase přejít na jedno servo, navíc ovládaného přímo pomocí časovače Arduina, a ověřit, že s tím servo nemá nic společného a že je to všechno jenom chyba Servo Shieldu. Stejně jako jsou nesmyslné informace o poloze po startu, tak servo může být asi dost zmatené??

Jinak včera dorazil balík s náhradními ozubenými kolečky od Nathana:

náhradní převodovky

Murphyho zákony fungují dokonale — ráno jsem psal Nathanovi, jesli vůbec něco poslal a v poledne mi to už leželo na stole . Není mi moc jasné, proč mi poslal i náhradní (a hned několik) horní kryty … evidentně Nathan ví něco více, na co já musím teprve přijít …

13. březen 2014 — Výměna ozubeného kolečka

Včera jsem si od Heidi s Isabelle dal na chvíli pohov (verze 0 konečně funguje ) a relaxoval jsem s FireAntem. Výměna ozubených koleček (vyměnil jsem rovnou raději obě) byla až překvapivě snadná. Základní trik je vytáhnout cca 5mm osičky kolmo nahoru a je to. Otázka pár sekund a není třeba žádné násilí! K čemu náhradní kryty ale stále nevím — jedině mne napadá, že pokud by se osička vylomila, tak usazení v tom krytu není dost spolehlivé … hmm. Možná jsem ho opravdu měl rovnou vyměnit. Teď je opravované servo na ocase a tam snad taková zátěž nebude.

2. duben 2014 — Resuscitace

S létáním jsme skončili, tak zase zpátky na zem. Udělal jsem ráno pár rehabilitačních cvičení s mravencem na bedně a šlo to. Především jsem schopen 100% zopakovat smrtelné záškuby pokud ho mezi jednotlivými pokusy zcela nevypnu. Ještě jsem nezkoušel vyndat a zandat jenom USB kabel, ale to počká do zítra.

Je to hrozný, jak se člověk po měsíci nevyzná ve vlastním kódu — asi přijde na řadu „jarní řez” a vše co není bezpodmínečně nutné půjde pryč. Ale znám se, takže to bude spousta přemáhání se . Alespoň, že je tam to README.md a vím, že mám používat ver0.

Při kalibrování vyměněných serv jsem si uvědomil, že to je vlastně taková lékařská preventivní prohlídka. Není vůbec jasné, zda aktuální stav (představte si N-tici celých čísel) je dobrý či špatný, ale podle lékařských záznamů lze poznat, jak moc se změnil. A pokud je to výrazně jiné, tak je něco hodně špatně. Takže teď každý výcvik začne kalibračním testem. Já mu dám sebedestrukci!

8. duben 2014 — nový cíl: Robotem Rovně

Včera prošel fandorama projekt na Robotem Rovně 2014, takže mám teď definovaný krásný mezicíl s deadline 17. května 2014 … ujít autonomně co nejdál to rovně půjde . Zrevidoval jsem kód na chození s tím, že jsem opisoval co to šlo z Orion.execGait() a původního firmware pro FireAnt. A vůbec jsem se nestyděl. Ani trošku.

Ono to totiž spíše připomínalo „reverse engineering” i když jsem měl k dispozici zdrojové kódy. Je to tak strašně univerzální až je to téměř nepoužitelné a celkem nečitelné … nebo prostě už neumím číst komplikovaněji formulované programy.

Pár (možná zásadních) pozorování:

všech šest nohou si drží stejný úhel s odstupem 0.125m od kloubu na těle (ověřeno přes math.hypot(1083,625) je 1250.4055342167997)
střídá se poloha, kdy jsou všechny nohy na zemi s polohou přesunu trojice nohou
dopředný pohyb je symetrický (nohy na zemi se posouvají dozadu zatímco nohy ve vzduchu jdou dopředu)
přední a zadní noha je vytočena o 30 stupňů (math.degrees(math.atan2(625,1083)) je 29.98927208927858)

Věřte nevěřte, vypadá to o řád lépe. Prokládám to vypnutím celého robota před každým pokusem a pak už ani ty ošklivé záškuby nenastávají. Celkem mi dost pomohlo staré video, kde je vidět, že ty nohy nejsou v řadě:

základní poloha nohou

Co dál? Přemýšlím, zda v rámci robotického úterka na CZU neudělat nějaký test chůze po dlažbě. Asi jo — test first. Na soutěž Robotem Rovně bych totiž chtěl vyzkoušet „ohmatání si dlažby” a srovnáváním se podle mezer. K tomu bude potřeba ještě pochopit tento řádek:

enableIKForce(LegIndex,1,1);	//enable force detect and clear force flags

v kombinaci s tímto IFem:

if(!Orion.queryIKForceTrig(LegIndex,1))
				//lower leg

Pak si naivně představuji, že se nohy přizpůsobí terénu.

Co jsem zatím moc nepochopil (a tedy zatím nekopíroval) je podivná interpolace mezi dvěma pozicemi:

GaitPosX[LegIndex]+=(Xdist-GaitPosX[LegIndex])/(totalsteps-step);

Podobných řádků najdete v Orion.cpp mnoho. step = (legstep*Rate)+SubStep a totalsteps = UpSteps*Rate, takže je to jasné? V zásadě to vypadá, že step jde od nuly do totalsteps-1, tj. v X-ové se posune o ??? Je-li totalsteps třeba 10, GaitPosX[LegIndex] nula a Xdist jedna. Pak budu mít řadu 0.0, 0.1, 0.1+(1-0.1)/9=0.2, 0.2+(1-0.2)/8=0.3 …

konec záhady hlavolamu. Alespoň chápete, co jsem měl na mysli tím „zpětným inženýrstvím”. Takže já to interpoluji stejně akorát bych to psal jinak, např.

GaitPosX[LegIndex] += Xdist/totalsteps;

Ale možná je tam magie se zaokrouhlováním (to mne ale na PC v Pythonu až tak netrápí, zatím). Vlastně to nedělám stejně — já interpoluji pozici kloubu a ne souřadnice. Teď mi to přijde jedno, ale to uvidím časem …

9. duben 2014 — první outdoor test

Včera jsem vzal mravence poprvé na procházku. A nebylo to tak špatné. Pro přihlížející hrozná nuda, ale vem je ďas . Prodloužil jsem chůzi na 10 metrů a po pokusu v mechu zvedl úroveň zdvihu nohou. Jinak jsem to pouštěl stále do kolečka. Chvíli po dlažbě, chvíli po trávě, jednou do kopce podruhé z kopce …

Dobře pozorovatelná a opakovatelná chyba byla (asi) v komunikaci. Jak když na srnu posvítíte dálkovýma … mravenec chvíli ztuhl a po pár sekundách (?) se zase pohnul dál. Toto se stalo skoro pokaždé v 10m testu, občas i dvakrát.

Druhé pozorování bylo, že homologaci v Písku by nedal. Celkem opakovaně ušel 12 dlaždic rovně a 3 vlevo, tj. cca 7m (dlaždice mají 50x50cm). Toto může klidně být posunutým těžištěm — přeci jenom baterka je tam jen tak položená a kabeláž je právě na levé straně.

Baterka se celkem držela. Vidím 12 logů z nich 8 je kompletních, začínal na 8.14V a končil na 7.42V, plus mínus. 60m by tedy na jedno nabití ušel, snad i násobně více.

Tak problémy s časem jsou v logu viditelné:

…
TIME	13733	146
TIME	13879	1461
TIME	15340	152
…
TIME	12103	143
TIME	12246	573
TIME	12819	148
…

Toto jsou absolutní milisekundové tiky a rozdíl po sobě jdoucích čísel. První zásek je tedy skoro 1.5s a druhý půl sekundy. Zvláštní. Na straně Pythonu žádný timeout a obnovení komunikace není, na straně Arduina je blokované čtení. V případě problému se tedy ani jedna strana nesnaží situaci vyřešit … tak kde se to kousne? Že by moje oblíbené SPI a komunikace se Servo Shield deskou? Jiný viník mne zatím nenapadá.

p.s. koukám teď ještě na průběh chůze u kloubů levé přední nohy:

3 serva status+cmd

Sloupce ABC jsou aktuální pozice a DEF jsou pak příkazy. To, že je stav opožděný za příkazy, je očekávané — výpis jsem přidal do funkce update(), která čte stav a posílá nové příkazy. O něco horší je to s množstvím měření. V kódu mám ale opravdu def setLegsXYZ( self, legXYZ, num=2 ):, tj. každý přechod rozfázuji pouze na dva (jeden mezikrok).

Zatím mi nejdivnější přijde soupec F. Není symetrický, protože se jedná o levou přední nohu, která je trošku (30 stupňů) vystrčená dopředu. Nahoru dolu je jasné, ale když je na zemi (hodnoty okolo -600), tak ten zlom se mi nelíbí. Že by to byl ten důvod proč interpolovat v XYZ a nikoliv jednotlivé klouby?

10. duben 2014 — triangle.Unsolvable

Tak jsem to nějak splácal dohromady … brrr. Divný souřadnicový systém noh, offsety, otočení znamének a do toho vylítne výjimka triangle.Unsolvable …

Jsou to věci, které člověk podvědomě dávno ví a zná, ale dokud se znova nespálí, tak zapomene, že kamna jsou občas žhavá. Prostě lineární interpolaci mezi dvěma pozicemi v XYZ prostoru občas nedokážete udělat, protože rameno/noha by muselo projít nedosažitelnou oblastí. V mém případě to byl samozřejmě bug, kdy jsem od úhlů zapomněl odečíst offsety a změnit některým znaménka, ale je to spíše varování, že dříve funkce setLegsXYZ() byla schopná interpolovat odkudkoliv kamkoliv a teď už ne.

Původně jsem chtěl prezentovat nový graf a jak je to na něm jasné, že teď už je to opravené (jenom křivky příkazů, přehrávám staré logy s vypnutým identity assertem) a ono to zas tak moc vidět není … ostatně posuďte sami:

upravená XYZ interpolace

15. duben 2014 — Bluetooth

Dnes ráno jsem se konečně rozhoupal a zapojil (přesněji přilepil) Bluetooth modul k Arduino desce FireAnta. Jedná se o starší verzi JY-MCU Bluetooth Wireless Serial Port Module for Arduino, kterou mám zapůjčenou od kolegy z práce. Čtyři piny: zem, napájení, RX, TX … co by mohlo být jednoduššího?

Nejprve jsem zapojil pouze napájení. Na modulu není žádná indikace, ale na notebooku se objevilo nové zařízení H-C-2010-06-01. Klasicky to chtělo PIN, ale naštěstí fungoval jeden ze tří, které jsem kdy v životě na Bluetooth zařízeních potkal: 0000, 1111 a 1234. Připojilo se to a vytvořil se COM10. Tato část šla až moc podezřele hladce …

Bez velkého přemýšlení jsem zapojil zbývající piny na Arduino porty 8 a 9 s tím, že to zkusím a případně v kódu následně prohodím … to nebyl dobrý nápad :-(. Nejen že to nefungovalo, ale když teď nad tím trošku přemýšlím, tak jsem mohl obě strany snadno odpálit (a BT modul možná odpálil?). HW rozhodně není moje silná stránka. Pokusný kód je na githubu, ale zatím to nefunguje.

A k čemu to má celé být? Chci mravence ovládat z Android telefonu a nejsnazším řešením se zdá být právě modrozub. Asi bych si měl pořádně přečíst zdroj, ze kterého čerpám.

16. duben 2014 — Bluetooth revised

„Pěkný obrázek, polovina příkladu”, alespoň tak to říkala moje profesorka matematiky (Jahelková) na GWP … a měla pravdu . Původní obrázek jsem našel na DealExtreme.com:

Zapojení BT modulu

Je z něj pěkně vidět zapojení pinu RX, TX, kde je PIO11, pro přechod na posílání AT příkazu (dokumentace je např. zde) … tak uvidíme. Druhý pokus.

Vedle správného zapojení PINu se chystám změnit rychlost komunikace. Nějak mi nedošlo, že na modulu není žádná autodetekce a musím tedy použít co je tam právě nastavené. Ondra, kterému modul patří, říkal, že zkoušel maximální rychlosti, takže by to mělo být spíše někde okolo 57600. A nebo přepnout do AT modu a zeptat se na 38400.

BMSerial(uint8_t receivePin, uint8_t transmitPin, bool inverse_logic = false);

Tj. jestli koukám správně na zapojení, tak BMSerial bluetooth(8,9); bylo v pořádku. No ale nefunguje to. Čas na snídani …

… tak to vidím na test v práci. Modul je na 3.3V, ale podle dokumentace je modul možné napájet 5V a i UART piny by měly 5V zvládnout. Nikoliv však Logic HIGH level input voltage all other IO pins, který je 3.35V. Pavel S. mne v mailu uklidňoval, že prohozenim RX/TX bych modul odpálit neměl, tak uvidíme. Čeká vás minimálně ještě jedno pokračování .

Křemíkové nebe

A je hotovo. Ptal jsem se ještě Ondry na „permission to kill”, ale nemyslel jsem to moc vážně. No nic, modul je mrtvý a já nepoučitelný. Hlavně mi nikdo nic už raději nepůjčujte …

BT modul je na 3.3V a ta dokumentace, co jsem zmiňoval dříve je k nějakému úplně jinému modulu. V práci mi Ondra potvrdil, že modul stále funguje a že ta záhadná rychlost je 38400baud. I zkusil test, že to běží na 5V, i když to už bylo mimo specifikaci … not good idea.

No zapojil jsem to blbě. Vlastně hůř už to snad ani nešlo. Nejprve modul nešlo detekovat, tak jsem uzemnil PIN 34. Podařilo se mi znova získat COM10 (Pavle, potvrzuji, že je tam zrada se dvěma COMy … COM11 byl k dispozici stále ale byl k ničemu a šlo ho otevřít i když se zařízení tvářilo jako odpojené). Napájení 5V je na krajním trojpinu s jumperem, ALE na všech ostatních trojpinech je v tomto místě signál. A uprostřed je neregulovaných 8V. Sigh. Malá rána a smrad spálené elektroniky …

Tak dobrou noc.

p.s. na 90% jsem ten BT modul odpálil prvním úspěšně poslaným bajtem a časová souslednost tomu odpovídala. Dokud se nesnažil na výstupní pin psát tak se statečně držel, ale když měl mít na výstupu 0V, tak baterka byla příliš silný soupeř :-(

17. duben 2014 — Zádušní mše

V rámci zádušní mše za BT H-C-2010-06-01 jsem na uklidněnou dodal mravencovi trošku inteligence (když už já ji nemám). Celkem pěkné cvičení s generátorama. Do první polohy se už nevrhá slepě, ale v závislosti na aktuální pozici nohou to protažení chvíli trvá … ale stejně jsem myšlenkama trošku jinde a přemýšlím, jak tu smutnou novinu Ondrovi dneska řeknu. Asi ať si přečte novinky na robotika.cz.

18. duben 2014 — Basic Micro Studio

Původně jsem chtěl psát o něčem úplně jiném, ale nová vlna poznání trumfla polemiku na téma volně dostupných informací. Jen ochutnávka na následujících dvou fotografiích:

FA Due - nečitelný nápis

FA Uno - H8/3687

Jak vypadá ten vyšší trumf? Konečně jsem pochopil, proč ve dříve zmiňovaných zdrojácích k Servo Shieldu (psaných v BASICu) nemůžu najít velikosti pulzů pro zjišťování aktuální pozice a síly serva. Ono to tam totiž není! A kde to tedy sakra je? Vše je to zakopané ještě o další vrstvu hlouběji v knihovnách pro Basic Micro Studio.

RTFM … tak jsem si kousek z manual.pdf přečetl a na straně 123 jsem narazil na hservo [pin\pos\spd, ..., pinN\posN\spdN] HSERVO uses a back ground hardware system to control one or several servos at a time.. Řeší to i záhadu zpětných lomítek, prostě se tak kóduje N-tice. Zajímavá byla i další informace: Notes 1 Analog servos may need to be deactivated. To accomplish this set its position to –24000 on the BAP 24 and BAP 28 modules and to -30000 on the BAP 40 module and ARC32 dev board. Takže teď i vám je jasný „příkaz”

hservo [val1&0x1F\-30000+258]

… no tedy úplně jasné to není. Proč těch +258? V každém případě je to PIN daný proměnnou val1 a pozice je -30000+258.

A jak se to tam celé dostane? Odpověď naleznete na Orion fóru: 6) At top of ide, you will see some Drop down lists. In the first one choose: BasicATOMPro, in the 2nd one choose: "BAP Orion" and in the third one choose the Com port associated with the DaVinci. Prostě je to další speciální Orion knihovna.

V binárce: c:\Program Files (x86)\BasicMicro\Basic Micro Studio\bin\872v3we_18432.bin si moc nepočtu, i když pro případné hackování vidím c:\users\acidtech\desktop\basicmicro source\atomprofirmware\872v3we_18432\872v3we.asm a G našel jediný relevantní odkaz … takže zase Nathan, ale před osmi lety … no nic.

p.s. tak už jsem snad u jádra pudla resp. na dně, ze kterého se budu moci odrazit . Pokud v Basic Mircro Studio odšrktnete v Tools/Preferences/Basic/Delete Temporary Files, tak vám zůstane 223kB orion.ASM … a tam už to musí být. Ideální čtení na Velikonoce A on nějaký „Hello World!” zas tak veliký nebude …

22. duben 2014 — FTDI Latency Timer

S tím assemblerem to tak slavné nebylo :-(. V zásadě se klíčová slova převedou na kódy a ASM mezikrok vyřeší odkazy na proměnné a velikosti skoků. To zajímavé je v LIB souboru a ten snadno čitelný není.

Chci zkusit ještě jednu variantu: naprogramovat H8 Servo Shield v BASICu a komunikovat přímo s ním. První pokus ve mne nevzbudil příliš důvěry — mám takový XP tik, že nejprve mačkám build/test ještě než vůbec něco naprogramuji — no spadlo to:

První pád

Můj první program basic.bas zatím nefunguje, ale to se snad podá. Největší obavy mám z toho, že si tímto pokusem uzavřu přístup dalšímu programování, ale asi nemám na vybranou. Snad to nebude jako s BT, kdy první úspěch znamenal konec. Servo Shield a Arduino sdílejí stejný USB-serial převodník, tak jsem napsal ještě nop.ino pro Arduino, který vůbec nic nedělá a je tedy krásně bezkonfliktní

Před mým prvním BASIC programem jsem zkoušel ještě původní firmware. Šlo to, ale strašně dlouho to trvalo (454s … skoro jak z dob ZX Spectra a kateťáku). Důvodem je defaultní nastavení „zpoždění” (Latency Timer) u USB FTDI driveru. Zenta o tom psal na fóru, ale už jsem to pozapomněl. Konečně něco, co se může hodit i jinde … Device Manager > USB Serial Port (COM8) > Port Settings > Advanced … > Latency Timer (msec) … změnit z původních 16 na 1. Pak naprogramování Orion knihovny trvalo necelou minutu .

FTDI Latency Timer

23. duben 2014 — BASIC Hello World!

Dnes ráno mne to programování v BASICu chvíli celkem i bavilo . Ukázkový „Hello World!” z manuálu mi nejprve zadřel terminál a vypisoval nesmysly, ale přidáním 10ms pauzy už jsem dostal to co chci:

main
	serout s_out, i9600, ["Hello Word!",13]
	pause 10
	goto main

Je pěkné, že Basic Micro Studio má rovnou integrované terminály a tak stačí kliknout na TAB a člověk vidí aktuální výstupy. Potěšil i DEC, což je „příkaz” pro konverzi čísla na textový desítkový zápis:

ADCSR = 0x30	;start scanning AD conversion
serout s_out, i9600, [DEC ADDRA,13]

… tento příklad posílá stav baterky.

Co se mi zatím nepodařilo rozchodit jsou nezdokumentované funkce „HSERVOFEEDBACK', ,,hservofbpos” a „hservofbpwr”. Domnívám se, že tou první celou mašinérii zapnu a pomocí dalších dvou funkcí pak můžu číst polohu serva a aktuální sílu. Když je dám obě do kódu, tak to řve na undefined reference, ale přitom Orion.prj žádnou specialitu s extra knihovnou nemá?! (resp. jí zatím nevidím)

24. duben 2014 — Pomoz si sám …

To byla zase úžasná hodinka s kompilátorem … přistupoval jsem k tomu matematicky, půlením intervalu. Když Orion kód funguje a můj malý kód nefunguje, přesněji nejde zlinkovat, tak někde na půli cesty musí být ta magická instrukce/parametr/define/čert ví co. Nakopíroval jsem všechny zdrojáky do jednoho a to zkompilovat šlo (32kB). Pak jsem odmazával a odmazával, rušil závislosti a stále to zkompilovat šlo (16kB, 13kB, 12kB, 6kB). A pak to přišlo . Po smazání relativně malého kousku kódu se objevila hláška:

C:\Program Files (x86)\BasicMicro\Basic Micro Studio\bin\ld.exe : Unsupported .stab relocation
c:\md\git\fireant\basicv0\basicv0.o(.text+0x568): undefined reference to `HSERVOFBPWR'
C:\Program Files (x86)\BasicMicro\Basic Micro Studio\bin\ld.exe : Unsupported .stab relocation
c:\md\git\fireant\basicv0\basicv0.o(.text+0x56e): undefined reference to `HSERVOFBPWR_OFFSET'

V programu se musí vyskytovat příkaz hservo[cokoliv\cokoliv] … a pak

tmp var word
HSERVOFEEDBACK
tmp = hservofbpwr( 21 )

zkompilovat jde. Průzračné, není-liž pravda?! … F … někdy mám pocit, že je ten život na podobné nesmysly příliš krátký.

… tak ještě malé ranní pokračování. Když se hservo v programu vyskytuje, tak to stačí k úspěšnému linkování, ale stejně to nefunguje . Je to třeba ještě zavolat (pro detaily viz github). Servo 21 tedy slepě posílám do polohy 0, což je naštěstí celkem rozumná poloha. A výstupy mne zprvu zmátly, ale vás určitě ne …

LogIt: logs/fa140424_062022.log
24768 SERVO 11
24768 SERVO 9
24768 SERVO 8
24768 SERVO 7
24768 SERVO 14
24768 SERVO 7
24768 SERVO 8
24768 SERVO 65506
24768 SERVO 65345
24768 SERVO 65227
24768 SERVO 65224
24768 SERVO 65348
…

Ano, správně, je to 16bit se znaménkem, tj. místo word stačí použít sword, není-liž pravda?

LogIt: logs/fa140424_062341.log
24768 SERVO 4294967219
24768 SERVO 4294967217
24768 SERVO 4294967184
24768 SERVO 4294967186
24768 SERVO 4294967177
24768 SERVO 4294967179
24768 SERVO 4294967185
24768 SERVO 4294967180
…

WTF by řekli amíci … sword bude mít tedy spíše něco společného s mečem (fráze „dostat se do křížku” by možná v této situaci byla také vystižná) … tak už tak nadšený s DEC výpisu nejsem. Ona i ta tabulka typů v manuálu je nějaká divná:

Byte 8 0 to 255
SByte 8 -128 to +127
Word 16 0 to 65,535
SWord 32 -32,768 to +32,767
Long 32 0 to 4,294,967,295
SLong 32 -2,147,483,647 to +2,147,483,648

…. buď je to překlep nebo Word je opravdu 16bit a SWord 32bit. Nic, kašlu na ně. Stejně to budu chtít posílat binárně a pak se teprve uvidí.

Jdu teď zkusit pozici -30000, která by měla servo zastavit … ale asi už jste získali nějakou představu, jak moc tomu důvěřuji …

Jo, pěkné! Když to bylo ještě v původní pozici 0, kdy se to bránilo, tak to nic nedělalo a bránilo se to dál. Když to vypnu a zapnu, tak servo polohu nemění a data jsou:

LogIt: logs/fa140424_065105.log
24768 SERVO 35536
24768 SERVO 35536
24768 SERVO 35536
24768 SERVO 35536

… volně si tedy pozici 35536 interpretuji jako neznámá pozice, servo vypnuté. Je tedy čas na magickou -30000+258 opsanou z execute.bas v Orion projektu?? Tak trošku se bojím, aby mi to neuseklo ruku … přeci jenom je to predátor.

funguje to … no nic … no comment. Prostě 258 není kompenzace délky vykonávání rutiny přerušení. Tak ještě force feedback, ale to až po snídani …

p.s. čtení hservofbpwr něco dělá. Zkopíroval jsem i servohandler, ale obratem ho musel zase vyhodit … trošku podle očekávání to rozbije komunikaci po sériové lince:

m:\git\fireant\ver0>fireant.py Due walk
LogIt: logs/fa140424_074407.log
1440 : 1548 SERVO 5&077 FORCE 50351
1700 : 1548 SERVO 52077 FORCE 50348
1940 : 1548 SERVO 52073 FORCE 50350
2180 : 1548 S♣RVO 52074 FORCE 50348
2420 : 1548`SERVO 52076 FORCE 50349
2660 : 1548 SERVO 52077 FORCE 50350
2900 : 1548 SERVO 52075 FO$CE 50354
3140 : 1548 SERVO 52077 FORCE 50346
3380 : 1548 SERVO 5207f FORCE 50348
3620 : 1548 SERVO 52075 FORCE 50351
f860 : 1548 SERVO m2071 FORCE 50354
…

25. duben 2014 — Pseudo-pomocníci

Dnes ráno bych zase plakal . Původně měl být tento příspěvek o časovačích na H8, ale třeba na to ještě dojde. Sigh. Jsem fakt tak naivní? (případně si doplňte ošklivější synonyma). Ten BASIC, pěkný jazyc, hlavu mu urazic. Má pěknou funkci HSEROUT:

Syntax
hserout {uart,}[{modifiers}data1,…,{modifiers}dataN]

V BASICu jsou (asi nenadávám teď na všechny, ale jenom na tuto micro edici) jsou proměnné typované (pochybně, alias meč/sword z minula), ale jsou … musí být, nemáte na vybranou. Jinak to nejde zkompilovat. No problem.

Pak máte „super univerzální” funkci na posílání viz výše … pošle vám úplně všechno na světě … k tomu modifiers udělá z čísel případně různé textové reprezentace (desítkovou, šestnáctkovou, binární, …). Tak co by jste čekali, že tato funkce pošle, když jí předáte 16ti bitovou proměnnou (Word)?Já bych čekal, že ví, že je 16ti bitová a tak pošle dva bajty. Čert vem indiány … ale možná v tom je zakopaná ta válečná sekyra. Zkrátím to. Pošle jeden bajt.

Proč tak vyšiluji kvůli takové blbosti? … prostě mi toto zjištění „chvíli” trvalo a hledal jsem chybu úplně jinde, jako přetékání času (ale ve skutečnosti to byla časo-baterka), jak for-cyklus v BASICu zvládá for i=0 to 0 (teď si myslím, že zvládá a jednou to projde) a pod … No nic, měl bych to ještě dorazit, jestli je to alespoň pravda. Tady je případně původní nefunkční kód.

Pavel S. (fandorama přispěvovatel) mi ráno psal povzbudivý mail a že by původní řídící software vyhodil a napsal vlastní. Asi k tomuto závěru také brzy dojdu. Po Heidi se mi stýská, ale přeci to nevzdám? Zbývá 30-25+17 dní …

p.s. bylo by pěkné, kdyby z tohoto fňukání a mlácení kolem sebe vzniklo něco užitečného, pozitivního … jako příklad mne napadá Feynman a jeho revize učebnic pro střední (nebo základní?) školy

29. duben 2014 — Šicí stroj

„Wow, to byl fofr!” Verze 1 konečně běhá. Nakonec jsem se rozhodl používat stejné interní API jako má Orion knihovna, tj. desetiny stupňů pro určování polohy serv. Také přeindexování pozic serv na jednotlivých pinech jsem dal do nejhlubších funkcí readStatus() a writeCmd(), takže zbytek kódu funguje jako dříve včetně kalibrace .

Abych byl úplně přesný, tak stejně (naštěstí) nefunguje . Je to zhruba 10x rychlejší a navíc sbírá info jak o poloze serv tak o aplikované síle. To ale i znamená, že FireAnt i 10x rychleji šel! Měl bych spíše říci běžel, protože místo třech pohybu za sekundu (update byl okolo 150ms a jedna interpolace) jich teď možná udělal třicet. První asociace byla šicí stroj, od toho název dnešního příspěvku.

Všechno jsem 10x zpomalil, případně 10x zjemnil interpolaci a teď už ušel po podlaze první metr (ten sprint byl „na robotickém špalku”). V plánu mám ještě do posílaných zpráv přidat index příkazu (něco podobného jako je v AR Drone API). Přešel jsem totiž na stream, který spíše připomíná CAN na Eduru — mravenec posílá svůj stav i když se ho nikdo neptá. Myslel jsem, že jednou za sekundu, ale soudě podle zmiňovaného diffu vidím u TIMEOUT hodnotu 100 (ms). Opravím. Problém byl totiž v navazování komunikace. Na rozdíl od Arduino desky, kde to bylo bez problémů, to tady chvíli trvá, než se rozjede cyklus „pošli stav, přijmi příkazy”. Po timeoutu tedy pošle chybovou hlášku ERROR timeout (moc jsem se s tím nepáral — nemám ani LEDky ani bzučák) a aktuální stav.

S tou desetinásobnou rychlostí to zatím stále jenom odhaduji. Možná bych měl podrobněji zmínit ty H8 časovače. Mimochodem dokumentace k H8/3687 je přímo součástí Basic Micro Studio, takže fakt nechápu, proč si někdo dal práci s odstraňováním potisku čipu na Servo Shield desce :-(. Tento čip má tři časovače: Timer B1, Timer V a Timer Z. První dva jsou 8mi bitové poslední 16ti bitový. Problém v kombinaci s BASICem je, že netušíte, které používá „systém”. Timer V byl vypnutý, ale dovoluje pouze 128 prescaling a s 8mi bity je moc rychlý. Timer Z je pak pravděpodobně používán na řízení serv včetně zpětné vazby. Zbývá tedy pouze Timer B1, který má dokonce 2048 a 8192 prescaler, ale už je zapnutý. Použil jsem ho — čtu jenom čítač TCB1.

1. květen 2014 — BASIC Force

Možná to nebude s tou sílou tak marné, jak jsem si ještě před hodinou myslel. Ostatně posuďte sami:

Síly při chůzi přes práh

Na grafu vidíte průběhy pozic a sil pro přední nohy, prostřední kloub. Důležité pozorování je, že jak směry serv, tak měřená síla jsou znaménkové a symetricky obrácené. To jestli se mravenec s něčím pere a „neměl by tak tlačit na pilu” záleží tedy na znaménku! A jak je mým špatným zvykem, koukal jsem na ten nezajímavý extrém. Na grafu zelená nad 4000 znamená přetížení … snad .

Upravil jsem trošku kód pro Servo Shield i PC, aby bylo zřejmé jak moc jednočip zaostává s realizací příkazů (viz diff), opravil dekódování síly se znaménkem a teď se chystám (se psem na procházku, ale to sem nepatří) vyzkoušet ty forceIKTrigger, tj. když prostřední kloub překročí daný limit, tak se nebude snažit danou nohu dávat níž. Konečně snad tedy také chápu, proč odlišuje forceTrigger a forceIKTrigger … zastavit totiž jenom jedno servo je nedostatečné.

Slimáci

Sbírka

Skalničky

… jenom připomínka, co má vlastně ohnivý mravenec dělat. Slug Killer. Ten pohled mne na zahradě moc nepotěšil — tak alespoň kompenzační pohled na on-line napojené skalničky.

5. květen 2014 — rrv0.bas

Dneska jsem vypotil opravdu pěkný kus kódu … fujtajbl. Ale doba je zlá a RR nepočká. Už necelých 14 dní. A nemít funkční verzi 0 mne opravdu hodně znervózňovalo, tak jsem to tam zadrátoval natvrdo. Do Pythonu jsem přidal výpis:

print "\tgosub execute", cmd2

a výstup rovnou použil jako BASIC program. Jelikož nevím, jak v BASICu předávat pole, tak jsem to raději rozepsal. Všech 24 serv. No jak říkám, fuj!

A proč ta hysterie? Bluetooth moduly ještě nedorazily a navíc BASIC kód mi stále timeoutuje. Teď mám podezření, že se mu ztrácí některé bajty a jelikož čeká určitý počet, tak nastane timeout. Zároveň si myslím, že nějakou chvíli trvá než vstupní buffer přes HSERIN je dosupný i kódu v BASICu a jak ho zpřístupní, tak už je pozdě. To je zatím jen teorie.

Jeden pozitivní závěr je, že alespoň tuším, jak rychle běží čas (časovač TCB1). Nechal jsem mravence pár minut běžet naprázdno a 269.662s na PC odpovídalo 656.654s na H8 … tj. jeden tik netrvá 1ms, ale 0.41066ms. A to už je poměrně blízko času pro 20MHz oscilátor a 8192 prescaler (8192/20000000. = 0.0004096).

Dnes snad zkusím udělat pár kroku s RaspberryPi a pak bych hard-coded verzi nemusel použít.

p.s. když jsem do kódu chtěl původně přidat i postavení se na nohy, tak už se to do H8 nevešlo:

C:\Program Files (x86)\BasicMicro\Basic Micro Studio\bin\ld.exe : region text is full 
   (m:\git\fireant\robotem-rovne\rrv0.bin section .text)

Až mne tedy uvidíte, jak startuji s mravencem ve vzduchu a pak ho teprve pokládám, tak vám bude jasné s jakým programem běží …

6. květen 2014 — status (11 dní do konce)

Je to bída. Zkoušel jsem včera „Hello World!” v assembleru, rozchodit spojení FireAnt-RaspberryPi … o oboje špatně. Ale dokumentovat se mají i neúspěchy, tak to hackování je v gitu.

RaspberryPI

První kroky šly relativně dobře. Malinu mám zapůjčenou (už zase?! to se mne nebojí?!! ) včetně instalační SD karty. Napájení přes micro-USB dobíječku, video kabel jsem musel dokoupit přes vodu v GESu (HDMI-DVI) a pak rovnou zapojil do monitoru, USBčková myš a klávesnice. Vybral jsem si první doporučený Raspbian a už si nevybavuji žádné problémy/další detaily z pátku, kdy jsem to instaloval. Ethernet stačil také jenom zapojit … skoro bych řekl, že tato fáze lepší ani být nemohla .

Git už byl předinstalovaný a stejně tak SSHčko, takže z přepínání monitoru a klávesnice jsem rychle přešel na další otevřený terminál ve spoustě jiných oken. Stejně tak Python byl přeinstalovaný, takže dostat tam nejnovější zdrojáky a githubu byla otázka pár sekund.

První zádrhel:

piraspberrypi ~/git/fireant/ver1 $ python fireant.py
Traceback (most recent call last):
  File "fireant.py", line 8, in 
    import serial
ImportError: No module named serial

Ale nápovědu člověk rychle najde např. zde, tj. stačilo doplnit:

sudo apt-get install python-serial

Když už jsem byl v tom instalování, tak jsem tam rovnou dal i OpenCV, jak mi poradil Jakub:

sudo apt-get install python-opencv

Chtělo to extra sudo apt-get update, ale jinak OK. Jen ta verze je taková divná — cv2.__version__ vypisuje '$Rev: 4557 $'. No nic, časem uvidíme.

Pak jsem připojil mravence přes USB a inspiroval se vlastními poznámkami k Ubuntu

piraspberrypi ~/git/fireant/ver1 $ lsusb
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 006: ID 0403:a559 Future Technology Devices International, Ltd
Bus 001 Device 005: ID 0603:00f2 Novatek Microelectronics Corp.

Toto bylo OK, stejně tak

piraspberrypi ~/git/fireant/ver1 $ dmesg | tail
[   21.735417] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[   23.388347] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[   27.175692] Adding 102396k swap on /var/swap.  Priority:-1 extents:1 across:102396k SSFS
[ 1280.515285] usb 1-1.2: USB disconnect, device number 4
[ 1323.765045] usb 1-1.2: new full-speed USB device number 6 using dwc_otg
[ 1323.893246] usb 1-1.2: New USB device found, idVendor=0403, idProduct=a559
[ 1323.893287] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1323.893306] usb 1-1.2: Product: Communications Port
[ 1323.893324] usb 1-1.2: Manufacturer: Basic Micro
[ 1323.893341] usb 1-1.2: SerialNumber: BMVNT4DB

Pak jsem přidal zmiňovaný soubor /etc/udev/rules.d/99-usbftdi.rules. Nešlo mi restartovat pomocí:

piraspberrypi ~/git/fireant/ver1 $ sudo restart udev
sudo: restart: command not found

ale fungoval podobně znějící

piraspberrypi ~/git/fireant/ver1 $ sudo /etc/init.d/udev restart
[ ok ] Stopping the hotplug events dispatcher: udevd.
[ ok ] Starting the hotplug events dispatcher: udevd.

… tak možná ta pravidla jsou v Debianu a Ubutu jinak?? Zkusil jsem ještě reboot a zatím nic.

Assembler

Říkal jsem si, že napsat ten bufferovaný příjem a vysílání nebude takový problém, ale zatím je. Civět do těch pár řádek kódu je celkem otrava. Zkoušel jsem jak BASIC verzi, tak skoro čistou ASM verzi (vše kompiluji v tom Basic Mirco Studio) … ale to se snad podá.

Jako inspiraci používám SPI komunikaci z původních Orion zdrojáků. Přečetl jsem si něco o registrech (jak er0 je 32bit ale přístupný i jako e0 a r0 16bit nebo dokonce r0l a r0h 8bit … … jenom si nejsem jist, jestli všechny kombinace jsou u všech příkazů povolené). Když jsem toto pochopil, tak mi přišlo, že má Nathan chybu v obsluze přerušení … ale třeba z ostatního kódu ví, že e1 je vždy 0 a nikde se nepoužívá?? A nebo to vždy adresuje 16bit prostor, takže je to jedno …

No nic, jedna zrada byl PMR1 registr, kde se nastavuje TXD výstupní pin. Kde je ale problém teď moc netuším. Sigh.

Šroubky

Ještě jednu „vtipnou” poznámku — povolují se šroubky. Skoro jako u starých Merkurových robotů, kde je bylo nutné před každým kolem všechny dotáhnout. Pár jsem jich tedy už asi poztrácel v trávě a možná je to i vysvětlení, proč levá zadní noha trošku pokulhávala …

Robotům zdar!

12. květen 2014 — 2D pohyb (5 dní do konce)

Soutěž „Robotem rovně” je sice o tom jet/jít/letět rovně, ale k tomu je potřeba, přestože to možná na první pohled není zřejmé, i umět trošku zatáčet. V lepším případě chybu rozpozná robot sám a vyrovná ji, v horším (což bude můj případ) robota 3x pustíte, upravíte konstanty a třeba mírným zatáčením dorazí dál.

Pohyb do strany byl ještě relativně triviální. Horší to bylo s otáčením, které jsem trošku odflákl — všechny nohy totiž otáčím o stejný úhel, ale měl bych to dělat podle jejich absolutní pozice. Střed otáčení není tedy úplně dobře definovaný … ale možná pro tu korekci 0.3 stupně, co teď používám, je to jedno.

Řízení robota přes kabel mi stále selhává (timeout). Přidal jsem do reportů i číslo bajtu, na kterém to selhává (viz diff) a kupodivu je to zatím vždy první bajt (hlavička) a nikoliv nějaký chybějící bajt uprostřed paketu. Co je ještě divnější, že se mi pakety neztrácí, „jenom” jsou občas (i v řádu sekundy!) opožděné. Nathan si myslí, že je to mým USB portem a možná má pravdu. Dnes ráno mi došlo, že je asi trošku jiná situace, když mám notebook v napájení než když s ním chodím venku s mravencem a běží z baterky. Na krabici teď „ušel” 10 metrů bez timeoutu.

Mám teď vybitou baterku, tak pokus hned nezopakuji (jo jo, jsou věci, které nechávám na poslední chvíli … dnes koupím druhou … ano měl jsem to udělat dávno!).

Na 90% budu „soutěžit” s rrv0.bas, který před tím vygeneruji v Pythonu s „korekcema šitýma na míru Písku”. Sigh. Za toto asi pivo od Pavla nevyhraji .

A co jinak? V pátek dorazily Bluetooth moduly:

Bluetooth zpředu

Bluetooth zezadu

Je na nich celkem přesvědčivé 3.3V, tak se mi to hned na těch 5V připojovat nechce. Teoreticky je to stále stejný modul, jen obalen převodníkem a LEDkama … nevím. Ještě mne trošku odrazuje skutečnost, že když to zkoušel kolega v práci, tak přes Bluetooth se připojil, ale žádná rozumná data nepřenesl (zatím doufám, že to bylo jen chybnou komunikační rychlostí).

Baterka je dobita a Bluetooth zapojen … kdybych si minule napsal, jaký že to mělo PIN … 1234 a opsal jsem to zase z toho původního článku a navíc je tam i rychlost 9600. Jen ten čas už mi teď pomalu chybí …

p.s. tak další 10m test na krabici selhal … jenom ten timeout tam probliknul :-( … CRLF … výpis opraven.

p.p.s.s. test se starým notebookem prošel (jak 10m na krabici, tak 10m chození po chodbě) — zatím žádný timeout. Pokud se to potvrdí i venku, tak dlužím Nathanovi omluvu …

13. květen 2014 — Puzzle (4 dny do konce)

Je to taková skládačka a je to se mnou divný: když něco nefunguje, tak je to „očekávané chování” a když to funguje, tak je to „podezřelé” … při zpětném pohledu se mi tento posun moc nelíbí. Ve zkratce nový Bluetooth modul funguje . Zapojil jsem ho tentokrát správně (ano, 3x jsem to raději kontroloval — zase tolik munice na ohňostroje nemám), změnil komunikační rychlost na 9600 a už to kopíruje znaky z COM8 na COM12 a obráceně. Potvrzuji, co mi dříve psal Pavel S. — vznikl COM12 a COM13 s tím, že pro přímou komunikaci funguje jen ten první. Druhý je asi pro nějaké nastavování, ale to v této fázi zkoumat neplánuji.

Proč „puzzle”? Mám teď kousky skládačky, jenom mi úplně nepasují a nevím, jak je spojit. Servo shield lze ovládat přes USB/sériový port, ale nevím jak s_in a s_out nahradit, aby používal (v BASICu) RXD_2 a TXD_2. S čísly pinů to nesedí. To vidím v generovaném assembleru, že s_in je ve kódované jako 0x20, což by odpovídalo pinu P32, ale na H8/3687 je to ve skutečnosti P21 nebo nožička číslo 45 … no jsem zvědav na rozuzlení. Nathan zatím mlčí a na fóru též.

Je tedy čas na malou pauzu a „context switch” do přípravy Heidi/Isabelle (včera Jakub poslal „větrné logy” a ještě jsem je neprošel … nějak moc robotů …

15. květen 2014 — SW drát (2 dny do konce)

Mravenec už chodí přes Bluetooth! Tedy pomalinku (9600bps), trošku se u toho klepe, ale chodí.

V čem byly problémy? No skoro škoda slov a čas odejít do důchodu . První byl s HSERIN piny … ono to totiž nejsou piny, ale číslo UARTu. Tj. stačí tam dát 1 pro první HW UART a 2 pro druhý HW UART. V detailu to ale až tak zřejmé není. Důležité je, zda zavoláte sethserial1 nebo sethserial2 (nastavuje rychlost komunikace, počet bitů, paritu a pod). Když totiž zavoláte jenom sethserial1, tak pro jakékoliv číslo budete používat první port, včetně dvojky. Nevím, zda podobná situace platí i pro setserial2, ale asi jo. Co mi teď funguje je nastavení obou a použití 2 jako první parametr u HSERIN.

Druhý problém byla oblíbená zvířátka MOSI a MISO (viz programování jednočipu). Že to je Master, In, Slave, Out vím, ale při volání BMSerial jsem to otočil.

Do třetice to byl pull-up na vstupním pinu Bluetooth modulu. Asi by mi to nedošlo, ale pozorování divně blikající zelenou LEDku, kde jsem odpovídající pin zapomněl přepnout na výstupní, trošku pomohlo . A je to i ve zdrojácích BMSerial, který mi předtím fungoval:

pinMode(tx, OUTPUT);
if (!_inverse_logic)
  	digitalWrite(tx, HIGH);
pinMode(rx, INPUT);
if (!_inverse_logic)
    digitalWrite(rx, HIGH);  // pullup for normal logic!

… teď koukám, že bych asi měl otočit i výstup na TXD. Nevím. Jak je to teď to funguje.

Co by to chtělo dál? Změnit rychlost AT příkazy na 38400, naprogramovat mobil, aby si společně pokecali a pak už to jenom několik dní zkoušet … ha ha ha.

p.s. pokud se ptáte, co že to byl ten SW drát, tak jsem z Arduina udělal propojovací desku — prostě místo drátků jsou tam IFy, a na základě přečtené hodnoty se zapne druhý výstup … viz wire.ino

16. květen 2014 — Vylepšený SW drát (1 den do konce)

Dnes ráno jsem zkoušel přepnout Bluetooth modul na vyšší rychlost, ale zatím neúspěšně. Udělal jsem si k tomu přímé zapojení, které by tolerovalo všechny rychlosti. Pak jsem na chvíli propojil KEY a 5V a přepnul se do AT režimu. Chvilku jsem si hrál s CR LF v putty (nevěděl jsem, jak poslat LF … tak příště Ctrl+J), ale pak se dočetl It’s different from HC-04 and HC-06 (They don’t need terminator)., tj. na AT to po chvilce odpoví OK. Ale to je všechno :-(. Verzi, adresu nebo rychlost UARTu jsem z něj nevyrazil.

Ještě tam psali: When PIN34 keeps high level, all commands can be used. Otherwise, only some of them can be used. Ale asi by jim ublížilo říci, které AT příkazy fungují a které ne. Je tedy možné, že to zapojení bylo nedokonalé (což asi bylo, protože to neskočilo na rychlost 38400). Zkusím to ještě v práci s pomocí HW oddělení …

Ještě poznámka k drátování — v gitu je teď verze, která kombinuje USB s Bluetooth. Je mi jasné, že si koleduji, ale … nepřijde vám ideální mít možnost mravence připojit buď po kabelu nebo bezdrátově aniž by bylo nutné ho znova flashovat??

19. květen 2014 — FireAnt na RORO14

Znáte ten pocit, kdy si myslíte, že extra den nebo dokonce jenom hodina by stačila k dodělání soutěžní verze? Zkusili jste to pak dodělat ještě po soutěži, jestli jste si jenom „nelhali do kapsy”? Podobné myšlenky jsem měl i já s mravencem a modro-zubem …

Jak jsem psal, tak mravenec už chodil připojený přes Bluetooth na rychlosti 9600 (i Sylvio ho tak viděl chodit, za což jsem byl rád). Ale nedařilo se mi změnit rychlost na vyšší. AT+UART? nic nedělal :-(. Už jste si pomalu zvykly na různé obskurnosti, tak tady je další: „je naprosto zásadní, jaký firmware v Bluetooth modulu máte!”. Hardware je stále stejný (ten základní BT modul), ale HC-03, HC-04, HC-05 a HC-06 používají různé piny a různé AT příkazy! Já mám firmware HC-06 a tam je pro nastavení rychlosti příkaz AT+BAUD6. Ne, nebudu se rozčilovat.

Na toto zase přišel Ondra a tak jsme překonfigurovali modul na 38400, ale tím to přestalo fungovat úplně. Ten SW drát nebyl úplně dobrý nápad. Vyhodil jsem blikání LEDkama, zakázal přerušení a stále se mi ztrácela půlka bajtů po kabelu a přímé propojení se Servo Shieldem nefungovalo vůbec.

Ještě bych zmínil, že ani nevím jak se dostat zpět na funkčních 9600. Key pin slouží k přerušení spojení s masterem. Na původních 9600 jste automaticky přešly do AT příkazů, pokud nebyl vytvořen pár. Teď už se tam dostat neumím.

Co ten SW drát? Ondra říkal, že je dobré pokud na pulz padnou alespoň 3 vzorky. Pro rychlost 38400 bps, to je 384000 změn (10 bitů = start bit, 8bitů, stop bit) a 3x to jsme na 1MHz. A to už ten Atmel moc věcí udělat nestihne.

Ještě bych zmínil vyhraný boj Ondry, když připojil modul k jeho RS232 převodníku. Nefungovalo to a musel si odpájet jednu ochrannou diodu … prostě je do modul pro Arduino a jinde můžete mít problém.

K RORO14 se teď už asi nedostanu, tak alespoň malá upoutávka, kdy jsem nestačil s dronou včas odstartovat (stahovala staré video):

p.s. na 9600 to lze vrátit příkazem AT+BAUD4, který ještě na původní rychlosti odpoví OK9600

20. květen 2014 — Hrátky s Assemblerem

Zkouším v tom „extra dni navíc” rozchodit mravence a zatím mi to podle očekávání moc nejde. Pro inspiraci používám Inline Assembler Cookbook a data sheet ATmega32. Dobrá zpráva je, že už se zase umím přepnout do AT příkazů — je nutné na notebooku vypnout Bluetooth, aby se nemohly párovat, a pak se k modulu připojit na dané rychlosti. Zkoušel jsem tedy 19200, což bylo o něco lepší, ale nikoliv ideální.

Tak tady je první pokus:

// PD0 = RXD … PIND=0x09, PORTD=0x0B
// PD1 = TXD
// PB3 = MOSI … PINB=0x03, PORTB=0x05
// PB4 = MISO
// PB0 = 8 BT_RXD
// PB1 = 9 BT_TXD

// Bluetooth <-> Servo Shield
void loop()
{
  asm volatile (
    "cli"  "\n\t" // disable interrupts
   "1:" " sbis 0x3,0"   "\n\t"
    "cbi 0x5,3"    "\n\t"
    "sbic 0x3,0"   "\n\t"
    "sbi 0x5,3"    "\n\t"
    
    "sbis 0x3,4"   "\n\t"  // 1/2/3
    "cbi 0x5,1"    "\n\t"  // 2
    "sbic 0x3,4"   "\n\t"
    "sbi 0x5,1"    "\n\t" // 2
    "rjmp 1b" "\n\t" // 2
    ::);
}

Funkce setup() je stále stejná a tu najdete v gitu. cli vypíná přerušení, sbis (Skip if Bit in I/O Register is Set) přeskakuje když je vstupní bit nastavený a sbic (Skip if Bit in I/O Register Cleared) naopak když je nulový, sbi nastav bit, cbi vynuluj bit a konečně rjmp je relativní skok.

Trošku zrada je to se čtením portů, kdy je nutné číst PINB, ale zapisovat do PORTB, ale to je ve všech jazycích, takže zas tak velké překvapení to není.

Je to tedy hotové? No není. Ty dvojky jsou časy kolik to trvá a pokud chceme na 16MHz mít tři vzorky pro komunikační rychlost 38400, tak máme jenom 16 tiků. Nevím, jak se to přesně u sbis a sbic počítá (jedno číslo je když je podmínka splněna, ale co je to třetí nevím … možná v závislosti na typu portu) — pokud počítám správně tak 18?

Do kódu jsem přidal while smyčku, aby přesněji detekovala změnu na portu (tj. využívám faktu, že jak MISO/MOSI, tak BT_RXD/B_TXD jsou na stejném portu).

"2:"
    "in r0, 0x3"   "\n\t" // 1
    "eor r0, r1"   "\n\t" // 1
    "breq 2b"      "\n\t" // 1/2

celý diff … no na první pohled to moc nepomohlo. Je pěkně vidět, že bitové operace jsou dvojnásob dražší a my navíc potřebujeme sledovat dva piny a nastavovat dva piny. Konečně 1 se přenese s jiným zpožděním než 0.

Jak to paralelizovat? Čtu bit 0 a 4 a zapisuji je do 3 a 1. Pokud budu mít bitové masky, tak 0 -> 0, 1 -> 16, 8 -> 2 a 9 -> 18. Tomu říkám kvíz Celkem by mne zajímalo, jaká vás napadají řešení … něco jako když sedí holka s klukem v parku na lavičce a kluk se po chvíli zeptá „myslíš na to na co myslím já?”. Dívka odpoví „Ano, a kolik ti to vyšlo?” (starý vtip o matfyzácích)

Sigh, tak je to zase prohra. Zkusil jsem verzi přímo se čtením a zapisováním portu a dostal nejprve Error: register number above 15 required, takže jsem r0 a r1 posunul na r20 a r21, ale je tam asi ještě nějaká bota. Nefunguje to.

p.s. matfyzáckou úlohu jsem chtěl řešit přes +24 a prohazování nybble (instrukce swap), ale přes ty bity v registrech mi to přišlo čitelnější a zhruba stejně rychlé … ale stále nefunkční.

21. květen 2014 — CBI vs. CBR

CBI — Clear Bit in I/O Register
CBR — Clear Bit(s) in Register

Táááák a teď v všichni koukejte jak umím plavat/programovat v assembleru!!!!!! (Mach a Šebestová/Školní výlet). Včera jsem nečekal a rovnou volal o pomoc … MartinaL. Obratem mi odpověděl, ... tak jsem na to kouknul a na 99% procent je tam obvyklá chyba. Instrukce cbr, sbr nepracuje s číslem bitu, ale s bitovou maskou (můžeš nastavit, resp. nulovat více bitů zároveň).

Proč proboha? Vždyť kdybych to takto chtěl udělat tak už na to mám instrukce ANDI a ORI, tj. bitový AND/OR s konstantou, která také trvá jeden tik. Je fakt, že to Bit(s) mi přišlo divné, když jsem to poprvé četl, ale nevěnoval jsem tomu dostatečnou pozornost. Chyba! Ale ne moje .

Troufale bych si dovolil tvrdit, že je špatně navržená instrukční sada, přesněji název je zavádějící a navíc celá instrukce redundantní. Jako argument bych použil citaci je tam obvyklá chyba, tj. když tuto chybu dělají často i ostatní, tak je to designově špatně. Před lety mi kolega z práce „vnutil” knížku The Design of Everyday Things - Don Norman (nevím, jestli toto naskenované PDFko bude stále k dispozici) … je to starší knížka a je o každodenních věcech jako jsou kliky u dveří a pod. Norman popisuje základní psychologické přístupy a např. vysvětluje, co bylo skutečnou příčinou výbuchu atomové elektrárny v USA … a podle mne CBI/CBR do této kategorie patří.

Mile mne potěšilo, že během včerejška přišel ještě další mail od VlastimilD: tak mě napadlo "vzít to přes STATUS", taková vzpomínka, že to nějak šlo, a ono asi ano - zkuste instrukce BST a BLD. Jinak SBR nebere číslo bitu, ale masku, je to vlastně alias pro ORI.

Martinovi i Vlastimilovi díky. Úpravy už jste mohli vidět v gitu: oprava CBR a použití T bitu.

Myslíte, že mne teď mravenec poslouchá? Komunikuje, ale se spousty timeouts a tak je neustále „v křeči”. Takže jenom rychlostí smyčky to asi nebylo. Ale už také vím, že ani extra den přípravy do soutěže by k „inteligentní chůzi” nepomohl.

MartinL navíc psal, že tam mám chybu ve výpočtu: A tedy pro rychlost 38400bd (bitů za sekundu) to dává více než 46 vzorků na bit (16e6 / 9 / 38400 = 46,3 což je více než dostatečné). Ty tvoje hodnoty se mi nezdají (nevím jak jsi na ně přišel). … a má samozřejmě pravdu. 38400 je přenosová rychlost v bitech a nikoliv v bajtech tj. žádné násobení 10 … bylo by naopak třeba dělit deseti, kdyby člověk chtěl vědět, kolik se přenese bajtů za sekundu.

Tak že by to bylo tou ochrannou diodou, co s ní Ondra zápasil v práci?

23. květen 2014 — The Ant End

Když jsem se před mnoha lety bavil s jedním amíkem, jak je to tam u nich hrozné, že se na kole nedá nikam jet, protože jsou všechny cesty slepé (dead end), tak se divil, jaké mrtvé mravence mám na mysli (dead ants) . Je pomalu na čase tento blog skončit. Pokud se vám bude stýskat, tak můžete podpořit blog/článek o Field Robot Event 2014, kde se s mravencem budu snažit o nějakou autonomous show … slimáky jsem si převedl na žluté golfové míčky (budou použité v Task3) a až jednou FireAnta nasadím ve skleníku, tak si tam nejspíše udělám kontrastní „zónu smrti”, kde budou slimáci snadno rozpoznatelní.

vicemiss Robot z RORO14

autorem snímků z RORO14 je Zdeněk Kakáč

Poděkování

Nejprve děkuji čtyřem fandorama přispěvovatelům: Josef S., Pavel S., Dušan K. a Robert F.

Dále bych chtěl poděkovat aktivním čtenářům, kteří mne opravovali a pomohli mi z různých depresí , tj. Martin L. a Vlastimil D.

Konečně velký dík mají moji HW kolegové z práce Ondra a Honza za ochotnou pomoc s nejrůznějšími problémy.

kontaktní formulář

Testování leteckého gyroskopu

2013-10-11T00:00:00Z

EXPLORER – druhý rok plný změn.

Explorer

Po úspěšném absolvování naší první robotické soutěže jsme začali přemýšlet, co by tenhle náš drobeček ještě mohl zvládnout. Závěr byl rychlý. Nic. Na ostatní soutěže, založené na jiné strategii prostě nemá šanci. Nejzajímavější pro nás byla soutěž RoboOrienteering, ale s touhle technikou – určitě ne. Vzhledem k naší neznalosti systému GPS a zpracování obrazu z kamery jsme rychle skončili zase u gyroskopu a odometrie. Se stávajícím systémem to ale nešlo, neboť ten umí měřit úhly jen v rozmezí cca 60°. Bylo zapotřebí vyměnit gyroskop za jiný. Opět spíše náhodou se podařilo zakoupit starý vojenský, asi letecký gyroskop na Aukru. Ten umí měřit v rozsahu celých 360°. Optimální přístroj pro navigaci v terénu. Bylo rozhodnuto. Vyměníme gyro, doplníme měřicí kolečko na odměřování ujeté vzdálenosti a hurá na další soutěž. Jak se později ukázalo, tak jednoduché to zase nebylo.

Začalo se s výměnou gyra, aby se stihla alespoň soutěž RORO. Nový přírůstek se naprosto liší od původního tankového. Z celého systému vedou jen tři dráty – vinutí motoru. Všechny ostatní kompenzační cívky jsou doslova s vojenskou precizností uloženy uvnitř takřka nedobytné kovové konstrukce. Roztočit ho nebyl žádný problém – stačilo ho napojit místo původního a hle – ono to vše funguje. Koukali jsme na něj jako na zázrak, neboť všechny ty kompenzace, které mi trvaly alespoň částečně zprovoznit několik měsíců má v sobě. A naprosto funkční. Pokud se s ním moc neklepe, tak dokáže „stát” na místě bez hnutí i celé hodiny a to, že se Země otáčí, je mu fuk. Optimální navigace na RORO.

Bylo třeba dodělat jen elektronické snímání úhlu natočení, mírně přizpůsobit řídící program motorů a mohl vyrazit na soutěž do Písku. Po zkušenosti z loňského kola byl opět zvolen magnetický snímač a magnet připevněný na osu gyra. Vzhledem ke zcela odlišnému výstupu ze snímače nebylo z původní elektroniky použito téměř nic a vznikla nová deska s několika procesory Picaxe. Už od počátku téhle přestavby bylo počítáno i s přidáním odměřování ujeté vzdálenosti a struktura byla navržena jako otevřený systém, do kterého se budou postupně doplňovat další komponenty jako např. sonary. Přidalo se odměřovací kolo umístěné uprostřed podvozku, aby ujetá vzdálenost byla ovlivněna otáčením co nejméně a začaly přípravy na Písek. Opět nespočet zkušebních jízd na dlouhé chodbě naší školy, kde se dá trénovat i za nepříznivého jarního počasí. Vynaložená práce přinesla své ovoce. Výsledky byly vynikající. Alespoň jsme se to v tuhle chvíli domnívali. První úkol byl splněn – na Písek jsme připraveni. Můžeme začít uvažovat o soutěži RoboOrienteering. Dali jsme dohromady program pro výpočet vzdáleností a azimutů jednotlivých bodů vypočtených ze zadaných souřadnic GPS a naivně si mysleli, že odometrie bude to pravé ořechové.

Mezitím se udělalo venku počasí, které dovolovalo vyjet do terénu. Záhy se ukázalo, že vše je jinak. Stabilní gyroskop si dělá na trávě co chce, kolečko neměří tak, jak bylo od něho očekáváno a náš milý robot se šine naprosto jinam, než by měl.

Soutěž Robotem rovně je za dveřmi, a vrátit zpět původní tankový gyroskop vhledem k provedeným úpravám už nebylo myslitelné. Zbývalo tedy jediné. Odpružit nový gyroskop a tak alespoň částečně eliminovat vibrace způsobené při jízdě po nerovném povrchu. Systémem uložení na pružiny se to částečně podařilo a s nejistým pocitem jsme se vydali vstříc osudu do Písku. Zaměřování laserem na odrazovku jsme ponechali a čekali na výsledek.

Ten nebyl vůbec špatný – druhé místo bylo velmi pěkné. I když popravdě – očekával jsem, že dojedeme dál. To ale asi každý. O tom tahle soutěž vlastně je.

A závěr – vcelku stručný – ne každá změna je změna k lepšímu. Pro příští sezónu vrátíme zpět tankové gyro.

Rozcestník

RoboOrienteering 2013

2012-06-20T00:00:00Z

Toto je verze 0 fandorama článku. Do konce června bych ho rád ještě nechal „živý” a přidával postupně příspěvky od jednotlivých týmů, jestli dorazí. Stejně tak bych nechal ještě otevřený blog a vymyslel, co dál …

2013-06-21 — doplněné info od Short Circuits Prague
2013-06-24 — doplněné info od Plecharts

Projet parkem přes kontrolní body (oranžové kužele) a dostat se do cíle není vůbec triviální. Zatímco pro kolové roboty jsou celkem výzva kořeny dosahající i několik metrů od kmene, pro létající roboty jsou to obrovské koruny stromů a větve i 10m velké (a až k zemi). Kolem kuželů je křídou označený kruh o poloměru 2.5m, kde musí robot nějakým způsobem naznačit, že kontrolní bod/cíl dosáhl. Extra body jsou za dotek kužele, který se ale letos už nesměl shazovat. Tým dostane GPS souřadnice bodů 10 minut před startem a na jejich průjezd má 30 minut. Pro rok 2014 budou pravidla trošku jiná, ale to bych si nechal na závěr.

Robotický klub Mariánské lázně

Výkonem dominoval Robotický klub Mariánské Lázně, pod vedením Karla Čermáka. Loni ve Svinařích bych býval měl „drobné” výtky, až se mi z toho ani nechtělo sepisovat článek na robotika.cz, ale letos to byl neodiskutovatelně nejlépe připravený tým, který si plně právem zasloužil vítězství.

Povídání se pravděpodobně dočkáme později (zatím si můžete přečíst o integraci gyroskopu z tanku T72, ve frontě už čeká pokračování experimentů s leteckým gyroskopem, pak bude RoboOrienteering 2012 ve Svinařích … ve zkratce, buďte trpěliví a budete odměněni rozsáhlejšími články).

Co jsem já mohl na robotu snadno pozorovat a z povídání zachytit bylo: pěkné odpružení během jízdy, laserový dálkoměr (pouze jeden paprsek, nikoliv skener) a zvláštní integrace pneumatiky, kdy robot si u kužele pro skenování prostoru natvrdo „sednul”, aby to pružení nerušilo. Z kamery se pak ověřovala barva detekovaného objektu a pokud byla oranžová, tak robot vyrazil vpřed dokud ho nezastavily infra nárazníky kombinované s mechanickým nárazníkem.

Co jsem stihl robota vidět v akci, tak fungoval bezchybně jen v posledním kole se zasekl ve svahu cca 1m od cíle.

Short Circuits Prague

„Šorti” podcenili přípravu, resp. z toho co povídal Pavel na to nezbyl de-facto žádný čas. Jelo se s loňským kódem s částečně integrovaným laserem. Na RoboOrienteeringu je tento tým často smolařem — nezapomenutelé bylo poslední kolo loni ve Svinařích, kdy robot dojel do cíle, ale nezastavil a vyrazil na Prahu. Po několika minutách jízdy tak ztratil všechny body. Pokud by ho tenkrát ručně zastavili, tak by byl robot diskvalifikován.

Letos to bylo podobné a zrada číhala na zemi, v kořenech. Minimálně ve dvou, ale možná dokonce ve všech třech, kolech robot najel na nízký kořen a břichem se o něj zasekl. Do příště Dan zkusí zaříznout mírně vyčnívající šroubky a vyleštit podvozek, aby se snáz smýkal. Ale on si Murphy zase něco najde …

Doplňující info od Pavla Jiroutka:

Letošního Roboorienteeringu jsme se poprvé zúčastnili v naší nejnovější konfiguraci, tedy s lidarem, novým notebookem a karosérií. Kvůli nedostatku času (většímu než standardně) jsme se dostali jen k nejnutnějším úpravám. V první řadě to bylo zprovoznění hlavního programu a debugovacích nástrojů na novém notebooku s i7 procesorem a Windows 8. Ačkoliv už jsme na tomto systému odjeli soutěž v Písku, ještě pořád se občas objeví nečekaný problém s kompatibilitou ovladačů hardwaru a knihoven, nebo problém způsobený jiným operačním systémem a procesorem. V kódu, který fungoval roky stabilně, se nám začaly dít divné věci. Nutno říct, že za vším byly doposud identifikovány chyby v kódu - zejména použití vláken na non-thread-safe modulech, které na pomalejším HW překvapivě problémy nezpůsobovalo. Další úpravy od loňska se týkaly použití lidaru pro detekci překážek místo sonarů. Lidar jsme pro tento účel nasměrovali přímo dopředu, aby jeho rovina nekolidovala pokud možno s trávou. Ještě večer před soutěží jsme měli zapojenou novou inerciální jednotku, kterou chceme používat jako kompas s kompenzací náklonu. Po testech se ale ukázalo, že jednotku ještě nemáme plně pod kontrolou a výsledná data vykazují menší stabilitu, než data z našeho tradičního kompasu. Do soutěže jsme šli tedy bez IMU.

Soutěž samotná nebyla žádné drama. Tedy snad kromě homologace, při které jsme mezi řečí zjistili, že se od minulého ročníku změnila pravidla. Návody, pravidla a podobné typy dokumentů samozřejmě nečteme. Během asi hodiny před závodem jsme upravili robota tak, aby neporážel kužely, ale snažil se jen dotknout, a aby hlasitě oznamoval dosažení waypointu. Dotek kuželu jsme vyřešili úpravou náklonu kamery, kterou jsme umístili tak, aby ztratila kužel ze zorného pole právě v okamžiku, kdy je potřeba zabrzdit, aby se kužel nezvrhnul. Jednoduchá metoda zafungovala při testech i v závodu překvapivě dobře. První kolo závodu bylo pro nás poněkud divoké, protože robot jel o poznání jinam, než kam měl. Chvíli jsme si dokonce mysleli, že jsme mu zapomněli změnit trasu z testovacích waypointů. Nakonec se ukázalo, že problém byl v hodně rozhozené GPS na začátku závodu a v hodně posunutém kompasu. Před sezónou jsme přesunuli kompas ze stožáru pod kapotu robota a nevšimli jsme si, že se začal chovat hodně jinak než na stožáru. V Písku se problém díky rovné cestě a relativnímu požití kompasu neprojevil. Při Roboorienteering ale používáme kompas absolutně a to se ukázalo jako problém. Pro druhé kolo jsme tedy kompas přesunuli zpět na stožár a nově ho nakalibrovali. I přes tyto problémy robot dojel v prvním kole poměrně daleko. Bohužel skončil - stejně jako ve všech dalších kolech - uvíznutý na kořenech stromu, které nevnímal jako překážku. Do druhého kola jsme zavedli drobnou změnu pro stabilizaci GPS - robota jsme nechali jet prvních několik desítek sekund rovně, až pak jsme přešli na standardní RO plánování. Ve druhém a třetím kole jel robot celkem stabilně, bohužel se v obou případech zaseknul podvozkem o nízké překážky na zemi. Tento problém budeme kompenzovat pravděpodobně pouze hardwarově - vyztužením odpružení podvozku a odstraněním všech šroubů, které vyčnívají pod robotem.

V soutěži jsme skončili na druhém místě z celkem čtyř soutěžících robotů. Děkujeme organizátorům za příjemnou soutěž s dobrým zázemím. Pořád máme potenciál na zlepšování, proto se rádi zúčastníme i v dalších ročnících.

Heidi (čtyřtulka)

Heidi už znáte a detailnější info z příprav si můžete přečíst níže v blogu, tak alespoň jak to na soutěži vypadalo.

Navigační program pro RO2013 v kostce:

převeď GPS souřadnice do roviny a spočítej úhly a vzdálenosti
pro každý směr a vzdálenost leť v 1m širokém koridoru ve výšce 1.5m (korekce v Y, Z a A)
pulzně udržuj rychlost 1m/s (pokud je vyšší nastav úhel 0 jinak „20% výkon”)
pokud je překážka blíže jak 1m, couvej 1.5m, udělej 360 stupňový sken na místě a natoč se směrem největší mezery
jinak pokud je překážka blíže jak 2m, posuň osu koridoru na další 4m letu o 1m vlevo
během přechodu 0.5s ignoruj další překážky (aby nenasbíral nesmyslný offset ještě z původní překážky)
po uletění požadované vzdálenosti zastav a indikuj dosažení kontrolního bodu změnou letové hladiny na místě na 0.5m, 2.5m a zpět na 1.5

První kolo: H-video D-video

Heidi odstartovala, vyrazila správným směrem na kužel a přeletěla ho. V cestě měla strom a tak udělala 360 stupňový sken. A nic. Zůstala viset ve vzduchu. Na konzoli jsem viděl:

Hover…
Traceback (most recent call last):
  File "M:\hg\md\heidi\ardrone.py", line 1440, in 
    roboorienteering( replayLog=replayLog, metaLog=metaLog, dirDist=dirDist )
  File "M:\hg\md\heidi\ardrone.py", line 1360, in roboorienteering
    ROVer2( drone, dirDist )
  File "M:\hg\md\heidi\ardrone.py", line 1344, in ROVer2
    ROStep( self, desiredSpeed=desiredSpeed, desiredHeading=desiredHeading, dist
=desiredDist )
  File "M:\hg\md\heidi\ardrone.py", line 1174, in ROStep
    turnToAngle( gapDir )
TypeError: turnToAngle() takes at least 2 arguments (1 given)

… sigh, hrubka. Kus kódu, který jsem nevyzkoušel. Ani v simulátoru. Mám padáka.

Za zmínku ještě stojí 4x „Navdata TIMEOUT!”, kde v první nastal cca 3m od startu. Následuje skok v pozici cca 0.5m zpět. Je dost možné, že takto se chyba v pozici snadno zhoršila.

Druhé kolo: H-video D-video

Druhý start byl na nakloněné cestičce v blízkosti hned několika stromů. Nejprve „oblíbené” couvání cca 3m a pak téměř ukázkové vyhýbání překážce. Na videu to vypadá jako náraz, ale byl to spíše jemný dotek, rychlé couvání, sken a vyrazil do volného prostoru . Nevím, jak ostatním, ale mne se ten začátek líbil.

Tanec na startu

Pak už zase video-dokumentace chybí. Podle odometrie se dostala až na (12.1, -48.0), tj. cca 50m od startu. Kontrolní bod ale zase minula a tak bodově pouze přímá vzdálenost k cíli … a v realitě zase byla dál.

Algoritmus jsem načrtnul v úvodu, tak teď realita. Sonarových měření moc není (měřil jsem s frekvencí 10Hz), takže každé měření jsem bral vážně (to obecně nedoporučuji, ale nějak začít musíte). Ze sonarového logu vidím: …, 2.58, 1.02, 1.09, 1.05, 2.61, 0.86, 0.73, 0.63, 0.53, 0.39, 0.26, 0.19, 2.65, 1.65, 2.12, 0.23, 0.32, 0.43, 0.57, 0.74, 5.09 … těch 10cm za 0.1s zhruba odpovídá požadované rychlosti 1m/s. Horší je to v „integračním logu”:

(105, 261)
43
(107, 73)
43
(109, 53)
66
(112, 19)
43
(113, 265)
22

První měření pod 1m tedy nezachytil, pak mu jedno vypadlo, pak dvě … ale stejně už na tu naměřenou vzdálenost 0.73m reagoval. Zajímavé by teď bylo zjistit, jaký podíl na tom nárazu má setrvačnost (přechod z dopředného letu 1m/s na couvání) a jaké opožděná informace (tj. že už byl 19cm od stromu, když zaregistroval těch 73cm). Zkusil bych to později porovnat s časovými známkami u videa.

Třetí kolo: H-video D-video

Poslední kolo bylo rozhodující. Před Heidi startoval ostravský Aegis, který z neznámého důvodu vyrazil přesně opačným směrem, než byl cíl. Když Heidi krátce po startu nabourala do první lampy a získala by tak jen 1 bod, tak byl všeobecný souhlas pokus opakovat. Třetí kola byla tedy dvě.

V prvním pokusu 2x detekoval překážku do dvou metrů a posunul tedy koridor o 2m vlevo. Následuje detekce ve 14cm a celkem tvrdý náraz. Ze sonaru žádné včasné varování nepřišlo: 3.33, 2.07, 0.14, 0.12. Sloup byl nejspíš moc vlevo.

Následovalo couvání, sken, lokalizace Davida a hrr na něj . Mezeru si sice vybrala pěknou, ale v kódu „trošku” chybí myšlenka co dál. Drona se tedy „vrátí do starých kolejí” a má stejný problém s lampou jako krátce po startu. Znova couvání, znova sken, ale třetí „vyjednávání” s lampou už nepřežije a silný boční náraz končí automatickým vypnutím motorů.

Třetí kolo, druhý pokus: H-video D-video

Druhý pokus se neměl počítat — ono na pořadí by to nic nezměnilo, jenom ten rozdíl mezi 3. a 4. místem by byl bodově méně výrazný. Ale jsem za něj rád. Vlastně to byl nejlepší let. Ono to soutěžení je i psychologická záležitost. Kdybych si se čtyřtulkou hrál na zahradě, tak metr od větví stromu už v panice mačkám emergency stop. Tady to byl poslední pokus, který ukázal, že když je to nutné, tak si drona dokáže cestu i prosekat. Většina video záznamu bohužel chybí, tak si to užilo jenom pár svědků naživo. Ano, skončilo to zase zamotáním do větví jiného stromu, ale až po několika desítkách metrů …

Závěry

RO2013 se mi líbil a zase jsem se něčemu přiučil. I Heidi se posunula dál. Shrnul bych, co se změnilo ve srovnání se soutěží v Písku, která byla před měsícem:

integrace nového HW (sonar)
částečné vyřešení ztráty komunikace (bohužel jen navdata, třeba opravit i video kanály)
regulace rychlosti (i když teď už to není tak zajímavé/dramatické)
skenování prostředí a první pokusy s vyhýbáním se překážkám

Mezi nevyřešené úlohy patří např. občasné couvání na startu. Dosavadní pokusy sice vedly k tomu, že drona byla „papírově” na místě (podle odometrie) ale v realitě to bylo ještě horší a asi si i pokazila vnitřní kalibraci během jinak automatizovaného startu. Parrot a fórum na můj dotaz zatím mlčí …

Aegis

Aegis byl pro mne zcela nový tým. Z Ostravy. Z Prahy do Ostravy je to daleko a stejně tak v opačném směru, ale Rychnov nad Kněžnou je kompromis. Vtipné bylo, že když jsem se zeptal, zda neznají Petra Nováka, co napsal knížku Mobilní roboty, tak se ukázalo, že je to vedoucí jejich katedry, školitel i spolupracovník . Tak po letech střípky pomalu zapadají.

Jejich robotu se ale letos příliš nedařilo. Hlavní programátor nedorazil a obsluha robota byla o to náročnější. V prvním kole vyhořel na parsování vstupního textového souboru - očekával mezery, ale v souboru byly tabulátory. Druhé kolo už bylo lepší a získal 77 bodů. V posledním kole asi zlobila GPS a robot se rozhodl jet zcela opačným směrem, než byly kontrolní body a cíl. Mimochodem je to snad jeden z nových týmů, který uvidíme na Robotour 2013 v Polsku.

Plecharts

Plecharts už známe jak z loňského RoboOrienteeringu, tak i z Robotour. Robota byste ale nepoznali. Je několikanásobně větší a ještě vícenásobně těžší. Je to trošku cesta na které si vylámal zuby Kamil ze Sirael s robotem Hana a z prvních let Robotour i Short Circuits s Kryplíkem. Prostě velký robot zní lákavě, ale typicky to znamená i velké problémy :-( … a i letošní příspěvek Plecharts to dokazuje. Pokud máte podobné myšlenky a ještě příliš zkušeností s robotama nemáte, tak vám to nedoporučuji. Vedle toho, že vám může robot snadno ublížit, na jeho testování (a to by jste měli dělat skoro non-stop) budete potřebovat vždy minimálně dva lidi a řádově více sil a energie. Robot měl hned několik problémů a skončil na mechanických, které byly v danou chvíli fatální. Snad příště.

Doplňující info od Jardy Peška:

Každý rok jsem se potýkal s tím, že robot byl příliš malý nebo měl málo místa na všechny prototypy modulů, tak jsem na letošní rok postavil opravdu monstrum. Rozměry robota jsou okolo 100x70x40 cm a váží s baterií okolo 70kg, takže se mu dá říkat tank. Zde byl asi první problém, protože takto velký robot vyžaduje velký výkon, který sice motory dodávaly, ale nakonec se zničila jedna z řemenic které přenášely výkon od motoru k převodovce a tak se robot nakonec ani nemohl pokusit ujet rovně několik metrů abychom měli alespoň pár bodů.

Dalším letošním problémem byla celková nepřipravenost, protože stavba nového podvozku vyžadovala více času než jsem předpokládal. Jako by to nestačilo, při vývoji softwaru se ukázalo, že jsem několikrát zvolil cestu, která nikam nevedla, což jen přidalo ke zpoždění. Musel jsem tedy na poslední chvíli upravit již otestovaný software z loňského Roboorienteeringu ve Svinařích, kde robot fungoval výborně. Po přepsání jednoho modulu aby robot místo vlastního regulátoru ovládal dva modelářské regulátory přišlo na řadu testování, již v Rychnově. Zde ovšem nastal problém, loňský software si příliš nerozuměl s notebookem nebo novým modulem řízení a místo toho aby jel když nemá před sebou překážku tak dělal opak, nebo se dokonce jenom „cukal“ na místě.

Snad se mi povede vyladit všechny tyto problémy do Robotour 2013, kde již bude moci nový podvozek a software plně zazářit.

Závěr

Nejprve bych rád poděkoval fandorama přispěvovatelům Pavlu Skotákovi a Janu M, kteří mne vyhecovali se soutěže s Heidi zúčastnit. Dále bych rád poděkoval Tomášovi z Eduro Teamu, kolegům Zonkovi a Šimimu z práce za pomoc s integrací sonaru (USB konektor, linux prostředí a možnost zkompilování driveru, kabeláž). Díky patří i Davidu Obdržálkovi (viz D-video), že celou soutěž natáčel a mám tak vůbec nějakou dokumentaci, když většina H-video-logů chybí. A konečně velké díky organizátorovi Martinu Lockerovi, bez kterého by soutěž nebyla. Dík patří samozřejmě i údržbě Zámeckého parku a dalším sponzorům.

p.s. zmiňoval jsem změnu pravidel do roku 2014 — budou se rozvážet golfové míčky a různé kontrolní body budou různě hodnocené. První náčrt najdete zde.

Odkazy:

Stránky organizátorů: http://www.vosrk.cz/roboorienteering/
Výsledková tabulka: http://www.vosrk.cz/roboorienteering/2013/vysledky.htm
Videa od Davida Obdržálka: http://www.youtube.com/user/RobonikaCZ.

Fandorama

Detaily tohoto projektu: http://fandorama.cz/projekty/921778164/roboorienteering-2013/

kontaktní formulář

Blog

Toto je druhý „létající blog” o autonomní navigaci Heidi, tentokrát ve venkovním prostředí. Úkol je doletět na první kontrolní bod (kužel), dotknout se ho a přitom nenabourat cestou do stromu. Nic víc a nic míň. Pro rozjezd plánuji využít soutěže Robotem rovně — tento blog bude zase mix z příprav na obě akce.

Předešlý díl s prvními pokusy případně naleznete zde. Stejně jako u IARC se i tady předem se omlouvám za texty bez korekcí.

19. dubna 2013 — cross-compiled Hello World

AR Drone 2.0 má USB port, ale jak jsem psal na konci prvního blogu, nové senzory (USB <-> I2C převodník a GPS modul) nebyly rozpoznané a nešlo z nich tedy číst data. Je potřeba si tedy drivery sám zkompilovat, což je krok, kterému jsem se původně chtěl vyhnout.

Princip cross-compilace je mi snad jasný: jiný procesor, jiná instrukční sada a je tedy třeba donutit kompilátor generovat výstup pro jiný procesor než na kterém sám běží. Stejným způsobem jsme programovali i ATmega8 čipy, když jsme před osmi lety blikali s LEDkou. Máte-li Ubuntu Linux na vašem PC, tak můžete zkusit postupovat podle vzoru na http://paparazzi.enac.fr/wiki/AR_Drone_2/getting_started. Já jsem použil pracovní Debian, kde mi kolega „přikouzlil” ještě cpp-4.4-arm-linux-gnueabi, g++-4.4-arm-linux-gnueabi, gcc-4.4-arm-linux-gnueabi, libstdc++6-4.4-dev-armel-cross, s tím že problémy byly s knihovnou libgmp3c2, která zrovna zaniká (?). Nevím. Koukal jsem jen přes rameno a neměl z toho moc dobrý pocit.

Je mi jasné, že správně vybraný procesor ještě není všechno (na AR Drone 2.0 je 1 GHz 32 bit ARM Cortex A8 processor s 800MHz video DSP TMS320DMC64x). Program se bude odkazovat na existující knihovny a pod. Ale asi mi nezbývá než to zkusit. Pro test jsem použil jednoduchý příklad z Raspberry Pi fóra.

Nevím jak vás, ale mne tento výsledek:

rozhodně potěšil .

23. dubna 2013 — logování videa

Ukládat obrázky nebo videa z autonomní jízdy či letu je obecně užitečná věc. Pokud nejste důkladní a důslední (že by slovo „dad” vzniklo od toho?), což ja bohužel nejsem (i když k většině testů si alespoň jednořádkovou poznámku napíšu), tak „video vám napoví”, co že se to vlastně stalo. I po několika letech. Možná mne to donutí vyhledat obrázky z jízdy v Rychnově na prvním RoboOrienteeringu (rok 2010), abych si připomněl ty obrovské stromy, občas s větvemi až k zemi, vystouplé kořeny i 2m od kmenu … no možná později, nebudu se přece v této fázi sám zastrašovat …

Pokus o nahrání videa jsem dělal už v samém počátku experimentování s Heidi, ale moc jsem si s tím nevěděl rady a byly urgentnější záležitosti. Stačilo rovnou ukládat data z TCP spojení na portu 5555:

HOST = '192.168.1.1'    # The remote host
VIDEO_PORT = 5555
…
  drone = ARDrone2()
  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # TCP
  s.connect((HOST, VIDEO_PORT))
  f = open( datetime.datetime.now().strftime("video_%y%m%d_%H%M%S.bin"), "wb" )
  for i in xrange(1000):
    drone.update()
    data = s.recv(10240)
    f.write(data)
    f.flush()
  f.close()
  s.close()

Je jasné, že dokud nedokážu soubor parsovat, tak to celé trošku pozbývá smyslu. Rozhodl jsem se přeskočit „kovaříčky” a šel rovnou za „kovářem”, tedy na stránky http://www.ffmpeg.org/, kde najdete jak knihovny tak nástroje, které používá většina programů spolupracující s AR Drone 2 (CV Drone, SDK 2.0, …). Proklikal jsem se na instalaci pro windows, stáhl si Shared Version, rozbalil 7-Zipem, objevil vedle ffmpeg rovnou i ffplay, přidal název uloženého souboru z Heidi a … ono to rovnou fungovalo!

A teď má skrytá motivace. Chtěl bych získat jak video z dopředné kamery, tak z kamery, co je namířená dolu. AR Drone 2 už nenabízí „obraz v obraze”, ale video je možné nahrávat. Při nahrávání by drona měla vysílat na VIDEO_RECORDER_PORT=5553. Když jsem zkoušel kdysi dronu s tabletem a nahrál si svůj první pokus venku, tak přestože jsem přepnul na dolní kameru, tak aplikace vždy nahrávala z té hlavní, dopředné kamery. Tenkrát mne to mrzelo, ale … už vidíte, kam mířím? Když přepnu pohled na dolní kameru a pustím nahrávání, tak bych měl dostat stream z obou kamer současně . Zní to až moc jednoduše, že ano? Taky to hned nefungovalo (snad už platí minulý čas).

Multiconfiguration

Pro nahrávání videa jsem použil příkaz:

drone.confirmedConfig( "AT*CONFIG=%i,\"video:video_codec\",\"136\"\r" )

kde 136=0x88=MP4_360P_H264_360P_CODEC, tedy zobrazování a nahrávání v rozlišení 640x360. Změnil jsem číslo portu na 5553 a nic. Žádná data. Na rozdíl od autonomní navigace na značku toto zajímá daleko více lidí a tak jsem odpověď snadno našel na fóru. Ten „podraz” je multi-konfigurace a je dost možné, že to bude i rozuzlení k té navigaci na značku, co mi ve Vídni chyběla …

Co to ta multiconfiguration je? Z důvodu kolize některých příkazů se starou generací AR Drone je povinnost před některými AT*CONFIG příkazy posílat ještě AT*CONFIG_IDS s hash kódem pro aplikaci, uživatele a session. Pokud to neuděláte, tak sice dostanete ACK, ale nic se neprovede. V dalším příspěvku na fóru je i návod jak si nechat vypisovat chybová hlášení drony, což může být příště užitečné:

When the AR.Drone refuses a configuration, it writes an error on its stdout stream. To see the output of program.elf on the AR.Drone, you may just connect to it using telnet, kill the currently running program ("killall program.elf"), then run it again ("/bin/program.elf"). The stdout will the be redirected to your telnet console, and you'll be able to see why the AR.Drone is refusing your configurations.

Po přidání AT*CONFIG_IDS to sice už nahrává, ale výsledek ffplay přehrát nelze :-(. Tady by asi stálo za to rozumnět H.264/MPEG-4 formátu. Detailům nerozumím, ale problém je podobný jako u spojovaní MPEG-2 video … prostě né všechny snímky jsou si rovny (první je celý a následuje X rozdílových) a pokud začnete špatným snímkem, tak to ani ffplay nezvládne. Který snímek je vhodný začátek lze vyčíst z extra PaVE (Parrot Video Embeded) sekce, konkrétně vás zajímá frame_type. Střídá se číslo 1 následované 29x 3 … alespoň u statického pohledu, v akční scéně to možná bude jinak. Při šanci 1:29 se ani moc nedivím, že mi to nefungovalo. Řešení je najít první typ 1 a před ním to smazat.

Případ vyřešen? Zatím ne. Vypadá to, že teď je zase problém s dekódováním druhého videa. Drona má jenom jeden video čip, takže jeden video stream je zpracovávaný softwareově … ale nechci předbíhat, nejprve nasbírám více „stereo” vzorků.

24. dubna 2013 — PaVE 64 vs. 68

Nevím. Nefunguje to. Je mi jasné, že jsem to včera zakřikl. Když otevřu obě spojení (pro nahrávání port 5553 a normální video 5555), tak nějaká data nasbírám. Ale nejdou přehrát, ani když je odříznu na první I-frame (princip komprese videa a co je I/P/B frame je celkem pěkně popsaný na wikipédii).

Kde teď vidím možný zadrhel je už samotná PaVE (Parrot Video Encapsulation) hlavička. Začíná značkou "PaVE" a následující informace o použitém codecu, velikosti hlavičky a dat, rozměr obrázku … speciální zarovnání je na 64bajtů. Když si ale přečtete velikost z uint16_t header_size; /* Size of the parrot_video_encapsulation_t */ tak dostanete 68! Počítal jsem to snad 5x, ta struktura má opravdu 64batjů a různé programy s tím počítají, ale v popisce je něco jiného.

Předpokládám, že ffplay.exe žádny PaVE nezná a přeskakuje na sekce začínající nějakou signaturou pro H.264 kódování, ale nevím. To by vysvětlovalo proč by přehrávání mohlo fungovat ať už PaVE sekci smažete nebo jí tam necháte. Přišlo mi, že CV Drone to vůbec neřeší, Tomáš Krajník dohledává ztracené začátky (a čte jen 64bajtů hlavičky). Zkusím header_size ubrat 4 a payload_size zase 4 přidat … žádná pozorovatelná změna.

Co mne ale ještě více trápí je, že ze třech pokusů jsem dostal dost podobný úvodní obrázek (asi bych měl před čtyřtulku dát digitální hodiny nebo místo na lednici budu koukat na elektrickou troubu s displayem) … extra cache u ffplay.exe nepředpokládám (jako, že by pokračoval na přehrávání staršího souboru stejného jména), tak mi spíše drona posílá staré video. Dokud ale spolehlivě nerozlousknu jeho přehrávání, tak to asi ještě nemá smysl řešit.

Asi to chce klid, více Nutelly, a začít možná s jednoduchým C prográmkem inspirovaným z různých zdrojů …

26. dubna 2013 — video timestamps

Dnes jen telegraficky:

velikost PaVE struktury u AR Drone 2 bývala 64 bajtů (např. stroje vyrobené loni v létě) a teď je 68 bajtů, i když ani poslední SDK 2.0.1 tuto novou strukturu neobsahuje. Podle Firmwares 1.11.5 (AR.Drone 1) and 2.2.9 (AR.Drone 2.0) are included a toho, že sám mám 2.3.3, soudím, že ke změně došlo „někde mezi”. Správně je tedy respektovat velikost headeru, jak přichází v datech.
při čtení PaVE bloku a dekódování každého snímku zvlášť vše funguje jak má. Sice při míchání dvou Céčkových zdrojáků se mi chvíli pletly alokace a natvrdo to padalo, ale … konec dobrý, všechno dobré. Jeden video stream má CODEC_ID_H264 a druhý CODEC_ID_MPEG4.
pro debugování jsem si nemohl vynachválit jednoduchý OpenCV kód :

cvShowImage( "camera", img );
cvWaitKey(100);

s čekáním 100ms nebo s 0 a procházení po snímcích (čeká to na stisk klávesy)

potvrdilo se mé podezření, že nahrávané video na portu 5553 je z jiného času než video z 5555. Důvodů mne napadá hned několik: nahrávání explicitně nevypínám, TCP buffer na začátku nevyprazdňuji, sychnroně čtu (navdata, video1, video2), jeden video stream může být úsporněji zabalený, … je to pěkně vidět na časových známkách (timestamp):

navdata:
TIME	73.279479	0x92443b7 
TIME	78.425933	0x9c67fcd

video3311:
TIMESTAMP	74686
TIMESTAMP	78631

video3311_rec:
TIMESTAMP	73643
TIMESTAMP	76479
----
navdata:
TIME	347.396301	0x2b660c0d 
TIME	353.056152	0x2c20db58

video3745:
TIMESTAMP	348770
TIMESTAMP	353269

video3745_rec:
TIMESTAMP	76675
TIMESTAMP	79316

domnívám se, že timestamp v NavData struktuře je něco jiného než v PaVE bloku u videa … tj. že na fóru se pletou … navdata jsou v podivně zabalených mikrosekundách a videa v milisekundách.

29. dubna 2013 — registrace

Nejprve díky příznivcům fandorama za podporu (částka na RoboOrienteering reportáž je teď už nasbíraná). Přihlašuji Heidi jako dalšího účastníka, viz. http://www.vosrk.cz/roboorienteering/index.php?year=2013&page=tymy. Zatím jsem tam jenom s Pavlem ze Short Circuits a je těžké uvěřit, že jsme před deseti lety spolu poprvé tvořili tým na Eurobota 2003. Tehdy Daisy byla sedmá na světě, … jo to bývaly časy … .

Pavel psal: „Situace se změnila. Ta druhá akce mi nakonec odpadla, takže jsem se dodatečně přihlásil na RO. Navíc jsem chtěl vidět, jak lítáš mezi stromy.” Tak nás v tom nenechte samotné! Těším se na další přihlášené týmy …

30. dubna 2013 — všechno vylejt!

Pamatujete ještě scénku Kaisera s Lábusem, Staníka, gumičky a nálev? Tak si teď připadám. Když jsem vše udělal pořádně, jak by to mělo být, tak výsledek je, že současné nahrávání videa z jednoho kanálu a sledování druhého nejde :-(. Ale popořádku …

Po minulé zkušenosti, kdy jsem si nebyl jistý, zda právě natočené video je aktuální, jsem udělal to co jsem slíbil a dronu otočil, aby sledovala sporák místo lednici … a vyplatilo se. Přiložené jsou referenční snímky první a poslední záběr.

05:57

07:31

Ráno začalo hrozně, jak jinak. Zkusil jsem připravený prográmek s použitím modulu multiprocessing, aby nahrávání videa probíhalo v jiném procesu a nezdržovalo hlavní řídící smyčku. Skript proběhl, ale video bylo jen černé nic (cvičně jsem nahrával jenom jeden kanál). Opakoval jsem to 3x a stále stejný výsledek. Začal jsem to vidět dost černě a raději přepnul na minulou implementaci … a zase nic!

Problém byl, že jsem video dekódoval špatným codecem. To je ale situace, kterou snadno a rychle poznáte z pohledu do konzole, kde vyskakuji chybové hlášky, ale nic tam nebylo. Došlo mi to až když jsem v Céčkovém kódu viděl fprintf TIMESTAMP … já jsem si ten chybový výstup minule přesměroval do souboru, abych ty časové známky mohl lépe studovat! Prima. Dobré ponaučení a vhodný moment pro alokaci obou codeců a doplnění následujícího kousku kódu:

if( pave.video_codec == 4 )
  cSelected = cH264;
else
  cSelected = cMPEG4;

Jinými slovy, v PaVE struktuře je informace, o který codec se jedná, jen to zapojit. Supr, tak už vidím všechna videa co jsem dnes nahrál.

Dopsal jsem funkce startVideo() a stopVideo() do ARDrone2 třídy pro oba kanály a ten co chodí z portu 5553 byl stále z doby úplného začátku. Upravil jsem kód aby se video přestalo nahrávat, ale stále stejné. Heidi jsem vypnul a znova zapnul a pak to začalo být rozumné. Důvodem je pravděpodobně „video:video_storage_space = 15360” konfigurace (nezdokumentované jednotky předpokládám MB), která umožňuje v případě výpadku wifi spojení použít takto velký vyrovnávací buffer.

Na informaci o bufferu jsem narazil, když jsem hledal, jak se přepíná dopředná a spodní kamera — mimochodem nepoužívejte příklad z dokumentace. Není to úplně zřejmé, ale ta nabízená varianta 2 není na AR Drone 2.0 podporovaná … enumy jsou od 0, tj. pro pohled dolů potřebujete nastavit 1.

Dobrá zpráva - přepnul jsem pohled dolů a chodí mi data z pohledu na stůl. Špatná zpráva - data chodí z obou kanálů stejná. Závěr? Nevím jak dostat video současně z obou kanálů a prapraprapůvodní zmatení, kdy jsem nahrával a přepínal pohled dolů, ale dostával nahraný pouze pohled dopředu, byl nejspíše stejný problem s bufferem i u aplikace AR.FreeFlight 2.0. Jako fatální důkaz mi posloužil následující kód:

drone = ARDrone2()
drone.startVideo()
drone.wait(2.0)
drone.confirmedConfig( "AT*CONFIG=%i,\"video:video_channel\",\"0\"\r" ) # HORI view
drone.wait(2.0)
drone.confirmedConfig( "AT*CONFIG=%i,\"video:video_channel\",\"1\"\r" ) # VERT view
drone.wait(2.0)
drone.stopVideo()

A na obou video záznamech jsem viděl chvíli stůl (spodní kamera), chvíli sporák (přední kamera) a pak zase stůl. To nezachrání už ani čulibrk.

3. května 2013 — test first

Test first je oblíbená praktika z eXtrémního programování. Nebudu se teď pouštět do vysvětlování, proč je to dobré při psaní kódu, spíše vysvětlím, jak si to interpretujeme v robotice. V kostce, pokud lze nějakou vaši teorii ověřit/vyzkoušet, tak to udělejte jako první. Vlastně je to takové „ověření předpokladů”, které když neplatí, tak je celá další teorie zbytečná …

Co to má společného se životem čtyřtulky Heidi? Pamatujete, jak jsem se holedbal, jak do Písku pojedu s kódem: „drone.moveForward(380)”? Tak jsem si to o svátcích na zahradě konečně zkusil. A když už umím nahrávat a parsovat to video, tak jsem vám průběh z pohledu Heidi dal i na YouTube:

Test Zero

No měl to být test1, ale zapomněl jsem odkomentovat volání testovací funkce, takže Heidi pouze vzlétla a hned zase přistála. To by běžně byl i doporučený první pokus, ale … nejsušší místo na zahradě byla střecha auta, takže když šla čtyřtulka na přistání, místo aby letěla 10 metrů vpřed, tak jsem se dost lekl. Konec videa není useknutý nějakým nárazem, ale prostě jako to přistálo, tak se vše vypnulo. Do dalších testů jsem tam ještě přidal 1s pauzu na konec.

Test One

Ten byl téměř ukázkový. Zase start z auta, ale pak se drona stočila mírně vlevo (větřík?) a proletěla těsně vedle konstrukce skleníku. Přistání do vysokých pampelišek nic moc, ale člověk si musí definovat priority …

Test Two

Druhý test jsem udělal se startem ze země a výsledek skončil pěkným kotrmelcem. Nenapadlo by mne, že ta naše loučka má nějaký sklon, ale na 10 metrů to těch 50cm asi dá + vyšší tráva … no, viz video. Takže lze možná dronu používat i k nivelaci.

Ještě možná krátkou historku ke konci tohoto testu. Naše Sindy (kokršpaněl) má lovení a donášení zastřelených ptáků v genech, a tak místo aby se Heidi bála, tak po tom jejím kotrmelci se na ní vrhla a chtěla mi ji v zubech přinést!

Test Three

Po pravdě mezi 2 a 3 byly ještě dva pokusy odstartovat, ale drona nechtěla přejít z emergency stavu, takže jsem ji nakonec musel vypnout a znova zapnout (logy jsem ještě neprošel, abych se dozvěděl více). U posledního testu jsem nejprve vystoupal do 2m a pak teprve pokračoval v letu vpřed:

drone.flyToAltitude( 2.0, timeout=10.0 ) 
drone.moveForward(10.0, timeout=20.)

Tentokrát ji vánek zanesl cca 3m stranou, ale jinak asi OK.

Závěry

testování doma není jako testování venku
drona si snaží udržet absolutní výšku nezávisle na překážkách
„emergency stop = přistání” je nedostatečné (poryvy větru, vyšší letová hladina)
malé rozlišení kamery (640x360) je nepoužitelné — zkuste ve videu najít kužel (potřeba přepnout do 720i)
hodila by se funkce „návrat na základnu”

Video konverze

Ještě bych zmínil konverzi videa z PaVE streamu z AR Drone 2.0 do AVI. Nakonec jsem to udělal v CV Drone „quick and dirty” pomocí příkladu z OpenCV. Je v něm jednak vysvětleno, co je to „video containter” a pak celý převod je těchto pár příkazů:

#include <opencv2/highgui/highgui.hpp>  // Video write
VideoWriter outputVideo;
outputVideo.open( "output.avi" , -1, 30, Size( 640, 360 ), true);
…
  outputVideo.write( img );
  …

kde „img” je „IplImage *”, který při parsování a zobrazování průběžně máte k dispozici.

Abych nelhal, tak úplně bezproblémové to nebylo, resp. stále není. Je to možná mix DLLek, který vytvoří nesmyslně pojmenovaný soubor a destruktor se také nezavolal správně, takže u AVI asi chybí index. Mým cílem bylo rychle (během 1h) dostat video na web a to šlo. Ideální to není a ani touto cestou dále nechci chodit — ono totiž ta kvalita … je to 3x přebalované (drona, CVDrone, Windows Movie Maker). Líbilo by se mi jen ty datové pakety poskládat, ale zatím to není priorita.

p.s.

Ještě jsem si hrál na Járu Cimrmana a ověřoval, že vyfukováním tabákového kouře do vody zlato nevznikne … konkrétně jsem zkoušel různé „AT*CONFIG video:video_channel”, jestli tam není nějaká nezdokumentovaná hodnota, která by přepnula na nahrávání jiný kanál než se zobrazuje … a minimálně do hodnoty 10 tam nic použitelného není.

7. května 2013 — NAVDATA_ALTITUDE_TAG

Dnes jsem konečně trošku koukal na logy z prvních outdoor testů. Co mne zajímalo mezi prvními je jak je to přesně s tou výškou, aby se znova neopakoval kotrmelec na mírném svahu. K prozkoumání tedy stojí NAVDATA_ALTITUDE_TAG a s ním spojená struktura:

typedef struct _navdata_altitude_t {
  uint16_t   tag;
  uint16_t   size;

  int32_t   altitude_vision;
  float32_t altitude_vz;
  int32_t   altitude_ref;
  int32_t   altitude_raw;

  float32_t		obs_accZ;
  float32_t 	obs_alt;
  vector31_t 	obs_x;
  uint32_t 		obs_state;
  vector21_t	est_vb;
  uint32_t 		est_state ;

}_ATTRIBUTE_PACKED_ navdata_altitude_t;

Komentářů k tomu moc není, ale odhaduji vision je výpočet podle kamery, vz je rychlost v z-ové souřadnici, ref moc netuším a raw je měření ze sonaru. Celkem pěkný je graf z „Test One”, kdy čtyřtulka startovala z auta:

kombinace kamery a sonaru k určení výšky

Další skupinku proměnných tipuji na detekci a odhad velikosti překážek (obstacle). Zatím jsem ale dostával u prvních dvou floatů jen samé nuly, tak je zatím ignoruji.

Na grafu je pěkné, jak v jednu chvíli vision zaostává za sonarem — to se asi už ultrazvuk odrážel od země, zatímco kamera ještě koukala na kapotu… TO BE CONTINUED

10. května 2013 — NAVDATA_ALTITUDE_TAG cont.

Nejprve bych začal tím, co jsem před pár dny nakousl, ale už nestačil ráno dodělat. Prošel bych tedy ještě další logy k referenčnímu videu.

test two: kolize

U druhého pokusu je celkem dobře vidět, jak se mírně zvedl (že by díra nebo vyšlapaná tráva?) a pak už to šlo z kopce, náraz a vzhůru nohama sonar hlásil 1.5m.

test three: altitude_ref

Offset cca 5m

Při posledním pokusu nejprve stoupal do 2m a pak to celkem zvládal, i když se zem přibližovala. Z grafu lze také odhadnout, co že to ta altitude_ref asi je. Vypadá to na „globální referenci” nebo „relativní nadmořskou výšku”, kde start je 0.

Co mne potěšilo dokládá přiložená šachovnice, 2D pohled shora. Je tam vidět, že při stoupání Heidi trošku odnášel vánek, ale že o tom věděla. Je tedy možné zapojit nějaké korekce, které budou vycházet přímo z odometrie.

Za zmínku také stojí chvilkový výpadek sonaru těsně před přistáním.

Co dál?

Jak byla volná středa, tak jsem chvíli lítal s následujícím prográmkem:

def flyAtHeight( self, altitude, dist, timeout=20.0 ):
    print "flyAtHeight", altitude, dist, timeout 
    refX = self.coord[0]
    refY = self.coord[1]
    zTolerance = 0.5 # +/- no action
    startTime = self.time
    while self.time-startTime < timeout:
      altSonar, altVision = altitude, altitude
      if self.altitudeData != None:
        altVision = self.altitudeData[0]/1000.0
        altSonar = self.altitudeData[3]/1000.0
      if max(altSonar, altVision) < altitude-zTolerance:
        self.moveXYZA( self.speed/2.0, 0.0, self.speed, 0.0 )
      elif min(altSonar, altVision) > altitude+zTolerance:
        self.moveXYZA( self.speed/2.0, 0.0, -self.speed, 0.0 )
      else:
        self.moveXYZA( self.speed, 0.0, 0.0, 0.0 )
      if distance( (refX, refY), self.coord ) > dist:
        print "DIST REACHED"
        break

Asi by to šlo napsat lépe. Ve zkratce, když jsou měření vzdálenosti k zemi malá, tak čtyřtulka začne stoupat a naopak, když jsou moc velká, tak začne klesat. Měla by tedy s mírným zpožděním, a celkem velkou tolerancí, kopírovat terén.

Ještě možná zmínim funkci moveXYZA():

def moveXYZA( self, vx, vy, vz, va ):
    "make one step update with proper orientation"
    self.movePCMD( -vy, -vx, vz, -va )

prostě už mne přestalo bavit dlouze přemýšlet nad tím, jakou že má Parrot tu soustavu souřadnou … otočená znaménka a prohozené X a Y.

První pokusy jsem dělal s papírovým „skokanským můstkem”

skokanský můstek

Trošku dramatičtější byl pak přelet auta. Zbaběle jsem odmontoval anténu, aby se moc nepletla do vrtulí a sám se schoval dovnitř. Celkem sranda, jen jsem trošku znejistěl, když jsem dronu po přeletu nikde neviděl a tak rychle mačkal emergency stop … ale tou dobou už byla schovaná ve vysoké trávě.

Pokusy jsem ještě několikrát opakoval a pokud byly úspěšné, tak hodně na těsno. Ono to teď z toho grafu je celkem dobře vidět — než překážku zaregistruje a přidá nebo ubere, tak ho ta setrvačnost žene do kolize. Asi by bylo potřeba ještě více „přidat plyn” pro pohyb v Z-ové souřadnici a zmenšit toleranci.

A co jinak?

Jinak to začíná být poměrně křeč. Příští víkend je soutěž v Písku, venku prší/leje, takže nevím jestli o tomto posledním víkendu budou nějaké testovací lety, učím se jak kompilovat linuxový kernel a získat funkční modul usbserial.ko z Parrot zdrojových kódů (zatím neúspěšně), na seznamu týmů RO nic nového …

14. května 2013 — homologace 5m: FAILED!

O víkendu jsem trošku zkoušel prográmek, který se snažil držet ve směru startu a X-ové osy. Bylo to hrozné. Teď jdu zkoumat detaily. Navíc přišel mail od organizátorů Robotem Rovně, že homologace začínají už v 8h a pro jejich úspěšné splnění je třeba ujet/uletět 5m. Mně ale potvora Heidi zahýbá … a hned po startu si to klidně otočí o 45 stupňů, takže ani tu homologaci by 5dní do soutěže nedala …

Na druhou stranu musím uznat, že v neděli celkem foukalo a bylo by to na celkem pěkný windsurfing … tak schválně co si myslela, že se děje.

První start, 42. měření skok o 45 stupňů vlevo :(. Přirozená korekce byla tedy zatáčet vpravo do růží, což vlastně čtyřtulka udělala.

{'vy': 5.758006319661097e-29, 'phi': 504.0, 'psi': -40628.0, 'battery': 60,
'altitude': 0, 'ctrl_state': 6, 'vx': -1.3149668872027192e-29, 'theta': 169.0,
'vz': 0.0}

{'vy': -4.3075449891044615e-13, 'phi': 505.0, 'psi': -97467.0, 'battery': 60,
'altitude': 0, 'ctrl_state': 6, 'vx': 1.490124112990543e-08, 'theta': 187.0,
'vz': 0.0}

Vypadá to na první roztočení motorů a jako by 'phi' brala z kompasu, který je v té chvíli úplně mimo.

Koukám na data z kompasu a strukturu navdata_magneto_t … ty raw data vypadají úplně náhodně. Jak když otočíte indiány. Pro představu pár měření:

compass: -103 27 113 1135868020673378100847233746463621120.000000 95579191465795697321761957262393344.000000 -1394810.750000 compass: -103 27 113 897022365180776029934830915319496704.000000 113103193363350740568052382373511168.000000 -1394810.750000 compass: -103 27 113 897022365180776029934830915319496704.000000 113103193363350740568052382373511168.000000 -1394810.750000 compass: -96 26 114 7319102271164370434775037509632.000000 214.262695 -1394810.500000

… a podivovali se nad tím i jiní, viz fórum.

Přiznám se, že to v tom úplně nevidím, ale … např. offsety jsou:

compass offset:	0xe0a1c1fcL	0x99d842f3L	0xc44e

kde poslední malé číslo naznačuje, že první dvě by měla být spíše záporná a opravdu to jsou otočený indiáni.

Tak ne … je to něčím jiným. Ten alignment, ten mne jednou zničí! Tj. chyba byla v parsovaní dat, kdy

values = struct.unpack_from("hhhffffffffffffcIfff", "".join(values))

po prvních třech shortech zarovná strukturu na 4 bajty a pak dostávám nesmysly. Správně to má být

values = struct.unpack_from("=hhhffffffffffffcIfff", "".join(values))

… tak nevím, zda ten dnešní příspěvek vůbec publikovat. Závěr je, že kompas není dobře nakalibrovaný a natočení čtyřtulky to výrazně ovlivní. Jak se to bude chovat pak zatím netuším. Nutno otestovat.

20. května 2013 — Robotem Rovně

Byl jsem teď 4 dny offline, tak se omlouvám za malou odmlku. Heidi ale nezahálela, zkoušela létat v nárazovém větru, kalibraci kompasu a konečně soutěžila na „Robotem Rovně”. Tam jsem naší účast bral trošku jako divadlo pro účastníky Cipískoviště, ale organizátoři to pojali jinak a založili nám novou kategorii „Létající roboti” … a tak si Heidi přivezla domu i medaili.

Z pohledu létání beru za největší úspěch, že čtyřtulka nikomu neublížila, když úspěšně odstartovala, tak způsobila mexickou vlnu následovanou potleskem a splnila i úkol překonat dosavadní rekord 28 metrů Tomáše Krajníka z roku 2010. V průměru si ale vedla hůře, viz letošní výsledková listina. Dojmy a detaily z RR si nechám do článku, který snad během týdne sepíšu. Tak ještě jedno převzaté foto. Předpokládám, že je to zrovna situace, kdy si Heidi prosadila svou a odmítla se se mnou dale bavit, ale z obrázku to není úplně zřejmé .

Hedi na startu - převzato z webu Radioklubu Písek

p.s. ještě dobrá jedna dobrá zpráva na závěr — RoboOrienteering se pojede! Teď jsou už 4 týmy a možna ještě 2 přibudou…

23. května 2013 — Status quo

Do soutěže „RoboOrienteering” zbývají už jen tři týdny. Vedle vyřešení problémů z Robotem Rovně je nutné především implementovat detekci překážek. Ta je potřeba už pro samotnou homologaci.

V plánu jsem měl jednak úpravu LKDemo z OpenCV a tak mne potěšila informace od Davida Hermana z týmu Roboauto — jeho student něco podobného řešil v bakalářské práci. Používal sice první generaci AR Drone, ale problémy asi budou dost podobné.

Druhá varianta je použití sonaru, který ale zase vyžaduje rozchození USB serial driveru. Jak najít a zkompilovat kernel jsem snad už pochopil, ale problém byl (?) se správnou konfigurací. Heidi teď nemám doma, ale rozdíl mezi starou a novější verzí mi dává zase naději:

martindnexus:~$ file usbserial.ko
usbserial.ko: ELF 32-bit LSB relocatable, ARM, version 1,
  BuildID[sha1]=0x06bdc0c7558101bc587b35393f570a792fbb80b5, not stripped

vs.

martindnexus:~/drona$ file usbserial.ko
usbserial.ko: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), 
  BuildID[sha1]=0x54754d367f5e3d6ea49a7e5fe024ad5b6db5d901, not stripped

Všechny moduly měly to „(SYSV)”, což je zkratka pro Systém V. Nevěděl jsem, jak to tam dostat, až jsem narazil na Building and Installing USB/Serial Drivers. Po neděli uvidíme, zda to pomohlo. Jen korekce linku na zdrojové kódy, který má být správně https://devzone.parrot.com/projects/show/oss-ardrone2.

p.s. pamatujete, jak jsem řešil problém, jak přepnout na automatickou navigaci na černobílou značku? Tak rozuzlení nejspíše je, že to v mém firmware 2.3.3. vůbec nejde :-(. Viz odpověď Grega …

26. května 2013 — metalog

Jirkovi Išovi trvalo skoro rok, než mne donutil zavést na Eduru metalogy. A přitom je to práce cca na 1h a následně vám to značně usnadní život. O co se tedy jedná? V kostce to je „logování logování” . A je pomalu na čase to zavést i na Heidi …

Neprve motivace: Eduro mělo hned několik zdrojů/logů — komunikace po CANu, NMEA data z GPS, obrázky z kamery, data z laseru, data z druhého laseru, data z RFID tagů, data z joysticku a možná jsem ještě na něco zapoměl. Každý jednotlivý log měl formát prefix_DATUM_CAS, ale DATUM a CAS nebyly nutně identické, jak se jednotlivé senzory připojovaly. Pokud jich k přehrání bylo třeba více, tak bylo nutné je nějak sjednotit a k tomu se hodí metalog.

A když už máte jednou metalog, tak si tam můžete napsat více než, kdy se který senzor připojoval a pod jakým jménem souboru je uložený. Triviální je přidat příkazovou řádku, máte-li krátký konfigurační soubor, jako je u RoboOrienteeringu seznam waypointů, tak se vyplatí si jeho obsah do metalogu zkopírovat. Při startu můžete připsat větu, co že by to mělo dělat a po skončení připsat jak to v realitě dopadlo. A kdyby jste byli opravdu důslední puntičkáři a před každým testem všechny zdrojáky komitovali do gitu či mercurialu, tak můžete přidat i hash repository.

Pro zavedení metalogu na Heidi si ho nejprve vytvářím ručně sám. Testovací příklad meta_130518_130615.txt vypadá takto:

navdata: logs\navdata_130518_130615.log.gz
atcmd: logs\atcmd_130518_130615.txt
video: video_130518_130617.bin
video_rec: video_rec_130518_130617.bin

Všimněte si, že i tady od startu Heidi uteklo pár sekund, než se začala logovat kamera …

Až do teď mne na Heidi z pohledu programu zajímala jenom navdata a vystačil jsem si s tím i na soutěži Robotem Rovně. Teď bych rád ale přidal další senzory (GPS, sonar), které budou chodit nezávisle na navdata, začal zpracovávat kameru a konečně potřebuji průběžně uklízet kód, aniž by se změnilo jeho chování (refactoring).To je natolik užitečná zaležitost, že bych jí tady ještě rozepsal … i když už se asi budu opakovat a někde na robotika.cz to určitě najdete.

U logů je důležité ukládat jak data ze senzorů, tak vaše samotné příkazy. V případě AR Drone to je ukládání AT příkazů. Proč? Pokud program pouštíte a ladíte na různých počítačích, tak tímto způsobem máte větší jistotu, že v obou případech používáte stejný kód.

Další použití je již zmiňovaný refactoring: je to vlastně triviální test, že z pohledu příkazů/rozhodnutí se nic nezměnilo. Také vám nic nebrání test pustit na posledních 10 pokusů, pokud všechny běžely se stejným programem.

Ještě bych zmínil jednu deset let starou historku spojenou s přehráváním logů: na robotu Daisy bylo řízení ze starého iPAQu. Kód byl psaný v jazyce C, ale choval se jinak na robotu a jinak na notebooku (už jenom toto je bez logu netriviální zjistit). S vysvětlením tenkrát přišel Zbyňek — k navigaci jsme používali Monte-Carlo lokalizaci s floatovou aritmetikou. Ta je na iPAQu řešena softwarově a notebooku hardwarově. Matematický koprocesor ale vše počítá v double a teprve pak výsledek převádí na float, zatímco softwarově byly i mezivýsledky floatové … pěkně, že? Přešli jsme na double a od té doby to bylo 1:1. Nezapomenutelné ponaučení .

27. května 2013 — usbserial.ko

Test nového buildu modulu usbserial.ko jsem nechal až na neděli a dopadlo to podle očekávání — nefungovalo to.

# insmod usbserial.ko
insmod: can't insert 'usbserial.ko': invalid module format

AR Drone 2 s GNS GPS

Dvakrát sdílný ten popis není, ale možná existuje nějaký verbose parametr, který jsem měl použít, ale nevypadá to. V použitém návodu popisovali změnu verze z „2.6.32.9” na „2.6.32.9-g0d605ac”, ale build mého 2.3.3 firmware má jinou verzi! Konkrétně na droně najdu adresář /lib/modules/2.6.32.9-gbb4d210/ … nová naděje . Doma jsem se udělal nový build a nastal magický okamžik:

BusyBox v1.14.0 () built-in shell (ash)
Enter 'help' for a list of built-in commands.

# cd /data/video/
# mkdir driver2
# cd driver2/
# insmod usbserial.ko
#

Pro ty, co ten úžasný pokrok nevidí, tak insmod už nenásleduje chybová hláška . Pokud každý nový firmware potřebuje jinak zkompilované moduly, tak to je možná i důvod, proč nejsou na webu běžně ke stažení …

Teď bych použil frázi „getting there but not there yet”. Ze zmiňovaného návodu jsem pochopil, že budu potřebovat ještě další moduly. Nápověda z Windows a dokumentace GPS GNS 5860 byla, že ten driver bude začínat „cp21” a opravdu se zkompiloval i „cp210x.ko”. Insmod už fungoval bez problémů, ale USB zařízení nebylo vidět. Zkusil jsem to snad 5x vypojit a zapojit než se hláška změnila:

# lsusb
Bus 001 Device 001: ID 1d6b:0002
# lsusb
Bus 001 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc.
Bus 001 Device 001: ID 1d6b:0002
#

Jestli toto má pak být spolehlivý robot, tak potěš … no nic. V dalším kroku jsem si chtěl podle wiki na Paparazzi nechat vypisovat NMEA data a zase nic:

# stty -F /dev/ttyUSB0 ispeed 38400 && cat < /dev/ttyUSB0
stty: /dev/ttyUSB0: cannot perform all requested operations

Na to, že jsem chtěl změnit jenom jeden parametr a nemohl změnit všechna mne pak zaskočilo, když tu rychlost opravdu změnil, ale stále to není ono. Příkaz „cat /dev/ttyUSB0” mi začal sypat tato data:

GPGGA,195048.644,5048.6133,N,00609.2?Err?493,E,0,0,,102.4,M,47.6,M,,*4B

GPGSA,A,1,,,?Err?,,,,,,,,?Err?,,,?Err?,*1E

$GPRMC,195048.644,V,5048.6133,N,00609.2493,E,0.00,0.00?Err?,260513,,,N*7F

což je lepší než nic, ale dobré to rozhodně není (pokud to nevidíte, tak jsou tam ty divné ?Err?).

Z pohledu soutěže je GPS až druhotná a měl bych se spíše zaměřit na rozchození modulu k sonaru. USBISS zařízení ale rovnou vyžaduje oboustrannou komunikaci a jak pokus s GPS naznačuje, asi ani tam cesta moc přímá nebude.

28. května 2013 — /dev/ttyACM0

Dnes jsem narychlo vyzkoušel jinou GPS (GPS BR-355 USB), která ma Prolific driver (modul pl2303.ko) a ta na rychlosti 4800 fungovala pěkně. Konečně ta chybová hláška stty: /dev/ttyUSB0: cannot perform all requested operations se týká pravděpodobně klíčového slova ispeed a rychlost samotná se vlastně stane nezávislý parametr a nastaví se.

Další test byl s USBISS — ono bych ho mezi /dev/ttyUSB* ani nenašel, i kdyby to fungovalo. Zkusil jsem to na linuxu u kolegy v práci a tomu se vytvořilo nové zařízení na /dev/ttyACM0 … celkem pěkné vysvětlení najdete zde. Inkrementální krůček už je řádově snažší než první krok a tak jsem oeditoval .config:

martindnexus:~/linux0523$ diff .config config-orig
1429c1429
< CONFIG_USB_ACM=m
—
> # CONFIG_USB_ACM is not set

zkompiloval moduly, zkopíroval vytvořený drivers/usb/class/cdc-acm.ko, nahrál do drony a …

# cd /data/video/driver2/
# insmod cdc-acm.ko

# ls /dev/ttyACM0
/dev/ttyACM0

Tak to bylo až podezřele snadné. Uvidíme, až z toho budu chtít přečíst alespoň jeden bajt…

31. května 2013 — sonar SRF02

Marnost nad marnost, vše je marnost … alespoň tak jsem to viděl před více jak 24h, ale už to trošku vyprchalo.

Ve St večer jsem byl v práci u Tomáše a zapojovali jsme nový senzor do AR Drone 2: sonar. Nejprve Tomáš nahradil původní USB B konektor přímo za USB A konektor. Z pohledu nezávislého pozorovatele to nebylo až tak triviální a sám bych se do toho rozhodně nepouštěl. Psal jsem před časem i výrobci, zda neplánují změnu konektoru a odpověď byla If we ever used a different connector it would be the mini B type. Na ten mini by už byly i krátké redukce, tak možná někdy bude integrace snazší.

Toto proběhlo dobře — Tomáš je důkladný a k žádnému prohození + a - nebo datových kabelů nedošlo. Modul USBISS komunikoval a bez propojovacího kabelu jsem ušetřil hned několik gramů a hlavně už nepřekážel. Už jenom úspěšnost tohoto kroku mne naznačuje, že úvodní tvrzení je zavádějící, ale pojďme dál.

K převodníku jsem si koupil dva sonary SRF02. Jelikož jsou dva, tak je musíte každý jinak adresovat. Z továrny mají přednastavanou adresu E0 a ta funguje. Po drobné úpravě prográmek v Pythonu (změnil jsem port z /dev/ttyUSB0 na COM19 a zakomentoval os.system('clear')) vypisoval vzdálenosti v centimetrech, které na první pohled vypadaly rozumně. Další protipříklad, že jsem to v úvodu přehnal.

V této fázi jsme to měli zabalit, spokojit se s jedním sonarem do HW verze 0, udělat cca 10cm propojovací I2C kablík a přichytit sonar těsně nad kameru, kam krásně pasuje. Ale ne, to hloupému Martinovi nestačí. On musí mít sonary hned dva. Musí z drony hned dělat predátora (to asi znáte, jak mají ptáci oči … většinou stačí jeden pohled a víte, zda jsou to dravci nebo lovná zvěř, tj. zda oči používají na stereo-vision nebo na pokrytí pokud možno celých 360 stupňů pohledu).

Ke změně I2C adresy je třeba vyslat posloupnost kódů se zápisem do registru 0, konkrétně 0xA0, 0xAA, 0xA5 a novou adresu zařízení, třeba 0xF2 (viz detailní popis). Změnili jsme to a nic. Odpojili, připojili a nic. Koukali na to na profi-I2C-analyzátoru, viděli všechny bajty i s potvrzením od zařízení a nic. A to vše nějakou nezdravou dobu, až se žena doma divila, kde jsem tak dlouho byl …

Kdybych to zkusil teď, tak by to určitě fungovalo, ale mne to už vůbec nezajímá!!! … vidíte, ještě to úplně nevyprchalo, tak třeba po víkendu. Jak jsem psal, pro HW verzi 0 to stačí. A jelikož Rychnov je už za 14dní, tak je na čase udělat „HW freeze”. Prostě naučit se žít s tím, co člověk momentálně má, zjistit co to má za mouchy a cca za týden udělat i „SW freeze”, na nic nesahat a „jenom” testovat …

p.s. možná je tam nějaký problém s časováním, podobně jako jsem psal v IARC blogu, a pomalu se přiznám, že takové protokoly nemám rád …

2. června 2013 — voda

Tento víkend jsem toho na zahradě moc nenalétal. Je na čase implementovat „návrat na základnu” — emergency tlačítko bych jinak použil nejvýše jednou …

... jen pro hydroplány a kachny

5. června 2013 — stty

To byl zase zásek na několik hodin :-(. To je tak, když si někdo naivně myslí, že poslat 5 bajtů, chvíli počkat, poslat další 4 bajty a přijmout 3 bajty je práce na pár minut. Měla by být! V Pythonu je. Do čtyřtulky ale Python nedostanu (není tam moc volného místa a nevěřím, že to vše hned bude fungovat), takže hezky v Céčku. O co mi jde? Potřebuji naměřit vzdálenost pomocí sonaru SRF02.

Pamatoval jsem si, že už kdysi jsem něco se seriovým portem pod linuxem dělal. Chvíli jsem hledal až to našel na našich stránkách v článku ATmega8 board . Napsal jsem si krátký prográmek:

#include "SerialCommLinux.h" 
int main()
{
  SerialCommLinux com( "/dev/ttyACM0", B9600 );
  int i, j, val[3];
  BYTE sonarStep1[] = { 0x55, 0xE0, 0x00, 0x01, 0x51 };
  BYTE sonarStep2[] = { 0x55, 0xE1, 0x02, 0x02 };
  for( i = 0; i < 10; i++ )
  {
    com.sendBuffer( sonarStep1, sizeof(sonarStep1)/sizeof(BYTE) );
    com.sendBuffer( sonarStep2, sizeof(sonarStep2)/sizeof(BYTE) );
    for( j = 0; j < 3; j++ )
      val[j] = com.waitForByte( 100 );
    printf( "sonar:\t%d\t%d\n", val[0], val[1]*256 + val[2] );
  }
  return 0;
}

a nejprve mi nešel zlinkovat. Po chvíli mi došlo, že gcc není to co pro C+ + potřebuji a s g++ už kompilace proběhla bez problémů:

martindnexus:~/sonar$ arm-linux-gnueabi-g++ -o sonar-arm SerialCommLinux.cpp sonarMain.cpp

Přepojit se na dronu, upload … a nic, přesněji:

# /data/video/sonar-arm
sonar:  -1      -257
sonar:  -1      -257
sonar:  -1      -257
sonar:  -1      -257
sonar:  -1      -257

tj. samé timeouts. Dobře raději to vyzkouším i ve Windows. U článku jsou i další zdrojáky a projekt pro Vistual Studio 2005 (také je to všechno z roku 2005), takže to šlo rychle (programování mazáním). Pustil jsem to a zase nic. Ještě zmíním, co jsem změnil (přesněji to byly ifdefy na __unix__ ): použil jsem SerialComm com( L"COM19:", 9600 ); místo SerialCommLinux.

Tady jsem čerta tušil — Windows nemají rády COMy s číslem vyšším než 10 a USB-ISS se detekoval na COM19. Jedna varianta je COM přemapovat, druhá je najít řešení v kódu Navigátora a to je:

SerialComm com( "\\\\.\\COM19", 9600 );

Fajn, fungovalo, několik 65535, že sonar ještě nestihl nic naměřit (v té době mi tam chybělo to čekání), takže novým kódem to není.

Ještě jsem nezmínil, že jsem původně chtěl kompilovaný kód úplně obejít a jenom pomocí cat pěti a čtyřbajtového souboru na /dev/ttyACM0 si vynutit měření sonaru a pomocí hexdump -n 3 si ho zase přečíst. LEDky blikaly (tj. sonar vysílal), ale čtení se vždy bloklo. V kombinaci s mým Céčkovým kódem to ale občas pár znaků přečetlo, takže nějaka naděje zůstala.

Včera jsem vzal modul do práce a zapojil ho do jednoho ze serverů … a kupodivu stejné chování jako na droně . To byl úspěch, protože jsem po každém kompilování nemusel přepojovat sítě a pod. Zkusil jsem pythonovský prográmek pod linuxem a ten mi hned vracel měření ke zdi. Zase naděje. Pak marné zápolení s parametry v kódu SerialCommLinux, abych výstup z stty dostal stejné jako po puštění pythonovského programu:

martindnexus:~/sonar/python$ stty -F /dev/ttyACM0
speed 19200 baud; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; 
start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>;
werase = <undef>; lnext = <undef>; flush = <undef>; min = 0; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

Když jsem náhodné hackování vzdal, tak jsem narazil na webu na linux_srf02.c, zkompiloval a hned to fungovalo. Hurá!

Udělal jsem si ještě verzi pro ARM a jak myslíte, že do dnes ráno při testování dopadlo? Nijak, program se bloknul a nic nevypsal. LEDky blikly, takže minimálně se mu podařilo psát, ale nikoliv číst. Při pohledu na výpis:

# stty -F /dev/ttyACM0
speed 19200 baud;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-brkint -imaxbel

modří už vědí … a já zrudlý do červena už pomalu také. Je to modem, který používá speciální znaky. Co se asi stane, když sonar naměří něco podobného speciálnímu znaku?? Interpretuje to. Ta magie je v tom <undef>, tj. „všechno vypnout”! Asi je na to nějaký speciální příkaz, já to dělal dřevácky po jednom:

# stty -F /dev/ttyACM0 intr ^- quit ^- erase ^- kill ^- eof ^- start ^- stop ^-
susp ^- rprnt ^- werase ^- lnext ^- flush ^-

a pak už to začalo fungovat. Vtipné. Prostě podle toho jak moc jste byli od překážky to buď částečně fungovalo nebo ne …

A co jinak? Do soutěže zbývá týden a poslední víkend na testování. Ten ale spíše strávím odstraňování důsledků záplav z minulého víkendu. No snad alespoň tu homologaci dám…

7. června 2013 — AVI s raw H264 snímky

Včera jsem konečně zkonvertoval pár zajímavějších video záznamů z a „skrytě je zveřejnil” zde. Přestože se na webu dočtete, že H.264 + AVI is not a good move. You should go with MKV or MP4 as your container, tak cesta existuje. Binární data snímků v H264 kódování jsou uložena bez konverze (tedy bez dalších ztrát kvality) a s výsledkem si poradí jak YouTube, tak třeba VideoLAN.

Výchozí pro mne byl příspěvek na Stack Overflow: Raw H264 frames in mpegts container using libavcodec. Sice už je postarší a se současnou verzí ffmpeg si úplně nerozumí, ale můžete se inspirovat radami z blogu Deprecated functions in ffmpeg library pro opravu dvou volání funkcí a jedné proměnné. Pro kompilaci pod Windows použít, třeba jako já, připravené projekty a knihovny v CVDrone. Jestli chcete přeskočit rovnou k cíli, tak zde je upravený originální kód.

p.s. omlouvám se, že videa jsou bez zvuku (drona vrčení nenatáčí) a s komponováním si budu hrát někdy příště …

10. června 2013 — Deterministická vlákna

Byla neděle, krátce před 17h. Udělal jsem pár oprav, které by si zasloužily test venku. Slyším ale divný rachot … bouřka nebo bagr u sousedů? Oboje. Vybíhám na louku dokud ještě neprší. V prvním testu (meta_130609_170501.log) Heidi odmítne rozpoznat připojené USB zařízení. Letí celkem OK. Odpojit, připojit a druhý pokus (meta_130609_170646.log). Pomalu se zvedá vítr, ale sonar už běží a chodí z něj data. U třetího pokusu (meta_130609_170803.log) už padají první kapky a začíná slejvák. Hážu dronu do kufru (auto stojí na louce) a s notebookem běžím zpět do chaty. Nějak se zbláznila wifina, takhle blikat jsem jí posledních 8(?) let neviděl a vypínám ho natvrdo. Po deseti minutách žena hlásí, že na louce už je voda a to jak v pásech po kolech auta, tak napříč. Vyrážím v holinách do bouřky přeparkovat. Klouže to, ale vody je zatím jen cca 15cm a dostanu se k brance. Za dalších 10min se zahrada změnila v řeku a je to v horším stavu než při kulminaci minulou neděli. Před tím se voda sbírala celý den, teď to ale vše bylo za 20min … tak to je nudná realita a teď zpět k té virtuální.

Dál ani krok!

O čem jsem chtěl psát jsou „deterministická vlákna”. Není to úplně výstižné, ale … jde o to, aby váš program mohl být více-vláknitý (multi-threaded) a přitom, pro pozdější analýzu, se choval zcela deterministicky. Řešení, které používám jsem přebral od Zbyňka, když ještě programoval Esterku.

Princip je v zásadě celkem jednoduchý — oddělené vlákno se s hlavním programem „potkává” jen v jednom bodě (míněno v jedné funkci) a v ten okamžik se i logují předávaná data. Příkladem může být pomalé zpracování obrázku z kamery, např. s cílem lokalizovat kontrolní kužel, a loguje se souřadnice v obraze (nebo i další parametry, jako výška, šířka, věrohodnost, alternativní cíle …). Při přehrávání/debugování hlavního programu pak už neběží „kamerové vlákno”, ale pouze po X-krocích, kolik je X se také loguje, si hlavní program přečte další data z logu.

Co jsem tento víkend podobným způsobem zapojoval byl sonar. Běží nezávisle s telnet připojením, kdy na začátku ověřuje dostupnost /dev/ttyACM0 a pak čte výsledky z výpisu z malého céčkového prográmku. Protože je rozdíl, jestli jednou přečtete vzdálenost 0.5m a tu pak stále vracíte a situací, kdy stále čtete 0.5m, tak ještě ke každému měření přidávám pořadový index. A už první test přinesl své ovoce. Začátek souboru sonar_130608_190101.log vypadal takto:

52
(0, 493)
45
(2, 138)
13
(3, 325)
41
(5, 46)
…

Loguji textově. Data nejsou velká a na jejích dekódování nepotřebujete nic speciálního. Střídá se řádek s počtem dotazů z hlavního programu, než dostanete novou odpověď. Tedy po 52 dotazech (cca 0.25s od startu programu při 200Hz update) dostal první měření od sonaru, které má index 0 a naměřenou vzdálenost 493cm. Princip je snad jasný.

A kde jsou tedy ty chyby? Nuže, sonarová měření by měla mít index souvislý, bez děr. Ztratilo se měření s indexem 1, 4 a časem jsou tam i díry velikosti 10, což při 10Hz znamená, že dorna celou sekundu nezískala informaci o překážkách! Napadá mne, že chybí flush v programu, případně, že telnet má také nějaké buffery a hned s každým bajtem nepospíchá … to je ještě třeba ověřit.

Můj homologační prográmek byl celkem triviální: když je překážka méně jak 1 metr daleko, tak zastav (hover), jinak leť požadovanou rychlostí rovně. S drobnými poryvy větru a vrtochy čtyřtulky se ale klidně vyhnula velkému skleníku (jo, byla to trošku destruktivní myšlenka pouštět jí tím směrem) a tak jsem jí nasměroval do volného prostoru a snažil se ji zastavit máváním rukou před sonarem. Marně. Buď nezastavila, nebo až o několik metrů dál … hmmm.

V programu jsem našel hned dvě velké hrubky (našel jsem je tak, že jsem měnil limit pro zastavování a divil se, že se chování programu nijak nezměnilo, tedy že přehrávání logu neassertovalo). První věc byla, že jsem zapomněl na zmiňovaný index měření. V Pythonu, trošku překvapivě, lze porovnat N-tici se skalárem:

>>> (27, 391) < 1.0
False

takže má podmínka nebyla nikdy splněna. Druhou chybu asi také tušíte. Správně tedy hned po přečtení dat ze sonarového vlákna zahazuji index a to druhé číslo dělím 100.0 … jj, ty jednotky.

Mezi daty ze sonaru jsem měl ještě několik 0 a to je bylo špatné znamení :(. Kouknu se ještě do dokumentace, ale předpokládám nepotvrzenou komunikaci na I2C. Navíc teď koukám, že ty tři zmiňované pokusy v úvodu jsou všechny prázdné a sonar nějak vůbec nefungoval, no nic, prima, ostatně já mám pondělky stejně nejraději (těžká ironie). Pokračování až po úpravě C-prográmku a dalších testech …

p.s. co si myslíte, že se stane, když uděláte paste do terminálu: M:\hg\md\heidi\logs>m:\git\cvdrone\bin\vs2008\test.exe video_rec_130608_194358.bin?

… smažete si přehrávací program. Přeji pěkné pondělí …

11. června 2013 — 3 dny …

Do soutěže zbývají 3 dny. Nevypadá to růžově. Včera jsem ještě koukal, jak je to v tom Pythonu s porovnáváním různých typů a je to tak, že N-tice bude vždy větší než číslo. Díky tomu pak můžete setřídit pole (list), který obsahuje různé typy — podrobnější vysvětlení najdete např. zde.

Dále jsem si četl, jak je to s těma nulama při čtení sonaru … a je to divné. Z dokumentace, mne trošku vyděsila poznámka: You can take advantage of the fact that the SRF02 will not respond to any I2C activity whilst ranging. … to skoro nechci ani vědět, jak tam chodí ty potvrzovací ACK. Doporučují číst verzi sonaru a když je 0xFF, tak že ještě echo nepřišlo. To jsem do kódu vrátil (v originálním příkladu to bylo, ale přišlo mi to zbytečné). Teď loguji jak verzi sonaru, tak potvrzení vyslání echa. Teoreticky by to měl být test spolehlivosti I2C v blízkosti čtyř motorů — pokud dostanu jinou verzi sonaru než číslo 6, tak to zlobí. Včera v noci jsem to ale už se zapnutými motory nezkoušel … bylo mi líto sousedů (ale to se asi s blížícím termínem soutěže změní).

Další (nové) poučení je s detekcí USB zařízení. Nejen, že se občas neobjeví, ale někdy lsusb trvá přes minutu! Myslel jsem, že se to nějak kouslo, ale pak to skončilo. Připojil jsem se rovnou a obalil to zjišťováním času:

# date && lsusb && date
Sat Jan  1 00:08:25 UTC 2000
Bus 001 Device 001: ID 1d6b:0002
Sat Jan  1 00:09:34 UTC 2000
#

Pěkné, že? Teď mi skoro přijde na hlavu to zapojení sonaru přes wifi-usb-seriak-i2c …

Pro uklidnění jsem ráno trošku „uklízel”. Zapojil si zobrazování sonaru do vieweru (2 řádky) a doplnil čtení souboru s kontrolními body na RoboOrienteering. Sám dobře vím, jaký je to stres v těch 10min vše spolehlivě připravit, neprohodit X a Y a pod … bohatě bude stačit to trojité bootování, aby sonar naběhl.

12. června 2013 — 2 dny (listy a větve)

Myslel jsem si, že největším problémem bude vyhýbání se kmenům stromů, ale podle dnešních ranních testů v sídlištním parčíku to to vypadá, že to budou spíše listy a drobné větvičky. Další pozorování je, že bych se měl naučit číst a ne jenom přeskakovat řádky. Konkrétně větu: A value of 0 indicates that no objects were detected. jsem včera nějak přehlédl. I2C potvrzení i verze sonaru byla ve všech 1969 dnešních měřeních správně.

Slalom mezi stromy

Včera večer jsem trošku testoval doma na chodbě a musím přiznat, že ten přechod outdoor -> indoor ve mne vyvolával klaustrofobické pocity. Našel jsem dvě další chyby, kterých jsem si v neděli nevšiml a je to pravděpodobně důvod, proč z „předbouřkového” testu nemám jediné sonarové měření. V kódu mám, že pokud se /dev/ttyACM0 najde, tak se rovnou pustí sonarový prográmek. Problém je, že to systému trošku trvá, než /dev/ttyACM0 zpřístupní a tak se může stát, že mi selže jeho konfigurace pomocí stty. Oprava je triviální — konfigurovat je třeba v každém běhu.

Druhá chyba byla v podmínce, aby se čtyřtulka otáčela na místě pokud je směr k cíli pod příliš velkým úhlem. Korekce pro navigaci v koridoru jí ale rychle správně natočí a tak jsem tu nefunkčnost úplně přehlédl. Jo, jo, chyba, že jsem to netestoval nejprve odděleně.

Co teď koukám do logů, tak v reálu to vypadalo lépe, než z pohledu robota. Pro představu uploaduji krátké video kličkování mezi stromy. A co na to sonar? All clear … a v té 45s jsem jí zastavil, protože to sekání listů mne příliš znervózňovalo…

p.s. stromy v měření ze sonaru „vidět” jsou, ale je třeba se koukat i 4m daleko (viz téměř neviditelné zelené tečky, čtverec=1m):

detekce stromů sonarem

13. června 2013 — 1 den (letové koridory)

Toto asi bude poslední příspěvek před samotnou soutěží a jelikož nic moc nového nemám, tak alespoň zmíním náznak plánu. Přemýšlel jsem co s tím jedno-sonarem podniknout a chtěl bych vyzkoušet dva algoritmy: letové koridory a sken s „náhodnou procházkou”.

Aktuální verze programu naviguje čtyřtulku v 1m širokém koridoru (podle odometrie) a pokud se příliš vychýlí, tak dělá jak korekce do strany, tak nahoru a dolu. Pokud Heidi získá pocit, že je před ní překážka, tak jedna z možností je koridor „posunout” v Y-ové ose čtyřtulky a po nějakém čase či vzdálenosti tento posun zase vrátit na nulu. Druhá varianta je, že v případě blízké překážky, udělá otočku o 360 stupňů, zmapuje celé okolí v dané výšce a vydá se směrem, kde je volno. Buď náhodně, nebo ideálně nějak v kombinaci s cílem, kam má letět .

První verze je riskantní, protože při přesunu do „levého pruhu” může narazit na překážku. Na homologaci a v parku, kde v dané výšce jako překážky převládají kmeny stromů by to ale teoreticky mohlo fungovat. Druhá je zase zdlouhavá a ty otáčky na místě jí úplně nejdou — snadno „odpluje” i nějaký metr stranou.

Ideálně bych použil kombinaci obou přístupů. Když už se dostanu na 1m od překážky, tak si možná i kousek couvnout, scan, odskok a znova koridory. Ano, žádná zmínka o kameře, LKDemo a zpracování bodů v obraze. Přiznám se, že jsem to trošku zkoušel, ale moc mne to zatím nepřesvědčilo. Raději, ve zbývajícím čase, zkusím vymačkat z toho jediného sonaru co se dá.

Ještě jedna, snad pozitivní, poznámka na závěr — jeden z rozdílů sonaru umístěného na pozemním a létajícím robotu je, že sonar směřující dopředu na létajícím robotu zem detekuje až ve větší vzdálenosti. To mi prvně úplně nedošlo. Na Eduru je sonar cca ve 40cm a ve 2m už „vidí” trávu. Heidi ale letí ve výšce cca 1.5m, tak si možná mohu dovolit důvěřovat i 4m měřením. Jak je to v realitě až po víkendu…

14. června 2013 — aquaphobia

Dnes začalo pršet v 6:41. Vím to poměrně přesně, protože jsem venku stihl udělat jeden jediný test se skenováním „na místě”. Je to v úvozovkách, protože při otáčení se Heidi posunula cca 1.5m, nabourala do sloupku a spadla na levou zadní vrtuli. Auto jsem přeparkoval tentokrát těsně vedle potoku, což, pokud se nesesune břeh, vypadalo na jediné místo, kde minulé víkendy neproudily „nové potoky”. Kde jsou ty časy, kdy mi déšť dělal radost …

Během raní směny jsem stihl udělat pár drobností: vylepšené stahování nahrávaného videa (vypnu nahrávání, ale ještě chvíli volám update, dokud video kanál netimeoutuje), asserty on/off (prostě když máte nový kód, tak je občas chcete vypnout a je otrava stále jeden řádek dokola zakomentovávat), logování stisku klávesy a ještě pár drobností.

U toho logování „ANY KEY” bych se ještě pozastavil. Všem vnucuji logování jako neodiskutovatelný základ pro vývoj a ladění robotů a … asi jsem dříve nečekal, že budu emergency tlačítko používat tak často, resp. skoro každý pokus tak končí. Pokud máte ale asserty zapnuté, tak není na první pohled zřejmé, zda se něco pokazilo, nebo běh programu je jiný (chybí ta informace, že je problém a přecházíme na nouzové přistání). Původní zapojení funkce kbhit jsem jenom trošku změnil:

self.console = SourceLogger( msvcrt.kbhit, filename ).get

Jinými slovy všechny výstupy funkce msvcrt.kbhit se uloží do souboru se jménem filename. Pak je třeba ještě doplnit situaci, kdy log přehráváte:

self.console = SourceLogger( None, filename ).get

a v kódu používáte volání self.console(). V případě dnešního pokusu log vypadá takto (má 18 bajtů):

tj. drona udělala 1882 cyklů, než jsem zmáčknul emergency. Chcete-li i detaily, tak zde je zdrojový kód sourcelogger.py.

(musím přestoupit, pause)

17. června 2013 — RO2013 mini info

Pokud chcete rychle vědět, jak to dopadlo, tak viz výsledky. Pro ty, co se těšili na videa z drony, mám ale špatnou zprávu :-( … po timeoutu navdata socketu a jeho restartu se přeruší jak nahrávané video, tak i streamované video :-(. Problém z Písku, kdy čtyřtulka visela na startu a nedalo se s ní nic dělat než jí ve vzduchu chytnout a převrátit na záda, se mi tedy už nestal (provede se ten restart komunikace), ale videa jak Heidi prolétá mezi větvemi (občas, kolize byly častější) bohužel nemám.

Pro nedočkavce:

19. června 2013 — Simulátor

Řeším, jaké kusy textu nechat v hlavním článku a co přesunout do tohoto blogu, kde se můžu snáze pitvat v detailech ... a tak úvod o simulaci přesouvám sem. Blog bych asi ještě nechal tak cca 14 dní aktivní až skonči Field Robot v Praze a bude chvíle na ,,doklizení''.

Do Rychnova jsem nakonec jel vlakem a získal tak další 3h na programování. Jelikož ve vlaku to moc na létání není (i když scénář, kdy si drona bude umět otevřít dveře přes červené tlačítko a celý vlak proletět zní jako výzva), tak jsem si první hodinu napsal jednoduchý simulátor a zbytek času ladil v něm. Proti simulátorům jsem obecně zaujatý, ale důvodem je spíše jejich „mámení”. Ono je to pohodlnější než někam muset chodit s robotem, dobíjet baterky a pod. Ale nesmí to tak skončit — simulátor nikdy není realita, ale může to být dobrý pomocný nástroj a v některých fázích vývoje je to asi i nejlepší způsob, jak „odladit znaménka” a nezničit při tom robota.

V simulaci jsem zjistil, že se mi Heidi vyhýbá vpravo, přestože jsem očekával, že to bude vlevo a to bylo vše. Přidal jsem „simulaci větru”, což je hodně nadnesené pojmenování pro posun o (dx,dy) v každém kroku, a začal ladit otáčení na místě. Prostě není to na místě. A stačí i drobný větřík a čtyřtulka je po 360 stupňové otáčce někde úplně jinde.

Druhou úlohu, kterou jsem řešil, bylo vyhodnocení sonarového skenu. Hledal jsem největší mezeru a tím směrem vyrazil.

7. července 2013 — Přistání z výšky 4 metrů

Původně jsem chtěl ještě přidat odstaveček o FRE (Field Robot Event), kde Heidi nastoupila do Freestyle kategorie. Použil jsem tam totiž kód z RoboOrienteeringu, ale moc zajímavá show to nebyla. Ostatně si to můžete přečíst v připravovaném článku.

Daleko větší „drama” jsem ale zažil včera a získal tak další zkušenost, o kterou bych se rád podělil. Chtěl jsem kamarádovi předvést létání čtyřtulky po zahradě s parametry:

dirDist = ((0,1), (math.radians(90), 2), (math.radians(180), 2), (math.radians(-90), 2),)*3

tj. třikrát opakuj let 1m na východ, pak 2m na sever, pak 2m na západ a 2m na jih. Nejprve jsem létal v hladině 1.5m, pak 2.5m a když to fungovalo, tak jsem tam dal 4m. Naštěstí jsem rovnou nezkoušel 10m, i když jsem měl cukání.

Heidi udělala 3 kolečka a pak nic. Visela nad autem, že jsem si chvíli myslel, že vypadla wifina. Nic takového. Pomalu se posouvala ve výšce cca 4m směrem nad potok a na emergency tlačítko nereagovala! Vlastně je dobře, že u potoka máme vrby, zamotala se do větví a prásk, „standardní” akrobatické přistání.

Nedalo mi to a pokus jsem zopakoval, akorát o trošku dál od potoka. A znova to samé — drona visela ve 4m a jako by provokovala „chyťte si mne”. V této výšce ale trik s převrácením na záda bez žebříku nedáte … a tak jsem byl rád, když z ničehož nic spadla těsně vedle vrbového domečku.

Mám teď teorii, že drona nereaguje na příkaz automatického přistání, pokud je výšce větší než X, kde X jsou možná ty čtyři metry. Je tedy třeba buď předělat emergency na přechod na manuální řízení, nebo nejprve klesat do cca 2m …

11. července 2013 — control.altitude_max

Na fóru měl Vince dobrou poznámku, že můj problém může být svázaný s nastavením maximální povolené výšky. Defaultně je control.altitude_max nastaven na 3m a mně drona odmítala přistát v 3.376m a 3.185m.

Včera jsem to zkusil změnit na 5m (tedy nastavuje se to v milimetrech — 5000) a Heidi začala létat „strašně vysoko”, ale přistání fungovalo. Většinou. Byl tam jeden výpadek spojení zrovna když byla hodně nakloněna vlevo. Vypadlo to za sebou hned několikrát a náraz. Trošku mi to připomnělo Rychnov, kdy v jednom okamžiku „zdrhla”. Změnil jsem tedy timeout na navdata (z testovací 1s na 0.1s) a to vypadá lépe, zatím.

Přidal jsem i jednoduché ovládání z klávesnice, ale test selhání přistání při autonomním letu s nízko nastavenou maximální povolenou výškou jsem ještě nedělal.

Ještě jedna dobrá zpráva na závěr: přišel mi mail od českého distributora Parrot profitec.cz, že už dorazily GPS moduly a větší baterky pro AR.Drone 2.0. Bohužel to není úplně levná sranda, ale uvidíme. Mají jen pár kusů, takže pokud si to zvažujete pořídit v ČR, tak neváhejte a zboží si rezervujte.

15. července 2013 — video odkazy

V pátek jsem dostal tři zajímavé odkazy, o které bych se rád podělil. První je o čtyřtulce, resp. čtyřech vrtulích a řídicí elektronice, které se přidělají „na cokoliv” a dá se s tím létat. Autor to předvádí na klávesnici, knize i dětském prkně. Nechápu, jak se to popere s vyrovnáním váhy, ale nějak asi ano … http://www.rozhlas.cz/leonardo/technologie/_zprava/1234092.

Druhý link je droně, zde rozuměj bezpilotní letadlo, které automaticky přistálo na letadlové lodi a byl tak dosažen další milník ve vojenské robotice: http://www.ibtimes.com/first-drone-lands-aircraft-carrier-salty-dog-pushes-limits-unmanned-aircraft-video-1342827

Třetí link je o čtyřtulce poháněné lidskou silou: http://www.youtube.com/watch?v=syJq10EQkog. Padla tak Sikorsky Prize (Human Powered Helicopter, $250000). Případne viz Sky News. Pro získání ceny se vrtulník musel po dobu jedné minuty udržet ve výšce alespoň třech metrů …

16. července 2013 — nové hračky

Včera jsem si u českého distributora Parrotu koupil dvě nové hračky: GPS/Flash Disk modul a 1500mAh baterku. Tímto bych asi RoboOrienteeringový blog uzavřel — je to senzor, který jsem potřeboval na začátku, před několika měsíci. Ani integrace nebude zase triviální: potřebuji firmware 2.4.x (na fórech jsem viděl nejvyšší číslo zatím 2.4.5) a to je ke stažení pouze přes iPhone. Pro Android to má být k dispozici někdy v září a tak dlouho asi čekat nevydržím.

GPS modul — první dojem je, že je hrozně těžký! Samozřejmě přeháním, stejně jako po pár měsících létání cítím každý vánek, tak váhu na droně rozlišuji v gramech. Papírově má vážit 31g, reálně, když už ,,vyvíjím v kuchyni a je tu ta micro-váha, 36g. Jen pro srovnání GPS GNS 5860 s TMC, co mám půjčenou z práce, stojí zhruba polovičku a váží 16g. Co tam mají tak těžkého?? Proto asi ta velká DO NOT OPEN, kterému možná ani já neodolám .

Zkusil jsem modul v notebooku — windows hlásili: „Obecný rozbočovač, disk, ...” a pak to chtělo drivery, které nemám. Jako disk to ale funguje a ve složce Windows Parrot GPS drivers snad bude to co potřebuji. Install failed, no nic. EXE tedy moc nepomohlo, ale s výběrem adresáře se zdají být Windows spokojené a driver je tedy nainstalovaný.

Po připojení na dronu to vypadá takto:

# lsusb
Bus 001 Device 004: ID 19cf:3000
Bus 001 Device 003: ID 0424:4050 Standard Microsystems Corp.
Bus 001 Device 002: ID 0424:2640 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002

Moc z toho nevykoukám, jen že je tam více zařízení. Co mne potěšilo bylo, že po připojení sonaru (i když fyzicky to vypadá strašně nepoužitelně) jsem dostal:

# lsusb
Bus 001 Device 005: ID 04d8:ffee Microchip Technology, Inc.
Bus 001 Device 004: ID 19cf:3000
Bus 001 Device 003: ID 0424:4050 Standard Microsystems Corp.
Bus 001 Device 002: ID 0424:2640 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002

Tj. zatím hodně teoreticky bych mohl používat současně jak sonar, tak GPS a nahrávat video na USB … ale to až někdy v nějakém jiném vlákně/blogu …

GPS modul a 1500mAh baterie

22. července 2013 — THE END

Dnes tedy už definitivní konec, s tím, že už vím, kde bude pokračování. Vymyslel jsem si téma „trošku více prozkoumat video codec H.264”, kdy z hrubých dat od AR.Drone 2.0 možná jde i něco vypozorovat o okolí. Uvidíme. Pokud by vás to zajímalo, tak zde začíná III. létající blog.

Sem bych ještě doplnil informaci o firmware 2.4.1, který lze buď stáhnout přímo na iPhone, nebo volně leží na stránkách digitalsirup.com. Získal jsem firmware z obou zdrojů a výsledky jsou identické. Jenom jsem dronu ještěý neflashnul, takže nové navdata s tagem číslo 27 (GPS, zatím nezdokumentováno, první hack je na paparazzi webu) ještě nemám. Zatím není dostupné nové SDK a podle fóra je těch změn asi více, protože přestala např. fungovat ROS ardrone_autonomy. Předpokládám nějaké nové stavy jako „čekám na GPS” a to může se stavovým automatem zamávat …

Tak díky za podporu a na viděnou na III. létajícím blogu.

------------ THE END ------------

kontaktní formulář

Integrace mechanického gyroskopu

2013-05-24T00:00:00Z

A tak se zrodila myšlenka něco sestrojit.

gyroskop z tanku T72

Začal vznikat stoj určený pro tuto soutěž, ale stále nebylo jasné, jak a čím bude řízen. Připadaly v úvahu kompas a snímače na kolech. Jako motory byly použity podobné jako má LOKO pořadatelů soutěže, ale záhy po dokončení podvozku se ukázalo, že jejich síla je příliš malá. Byly tedy vyměněny za podstatně větší – 12V stěračové motory z vozu Š120. Ty se válí v kde jaké garáži a jak se ukázalo, volba to byla dobrá. Pro výkonové řízení jsem použil modelářské regulátory FUSION AQUAPOWER s max. proudem 90A. Malá, programovatelná a cenově dostupná krabička je velice odolná a mohu jí vřele doporučit. Bezproblémová regulace o nuly na obě strany ovládaná servo signálem.

Rám a pohon byl tedy vyřešen a odzkoušen pomocí vysílačky. Ale co dál. Po přečtení článků na roborických stránkách jsem pomalu začal opouštět myšlenku kompasu a odometrie. A náhoda mi přihrála kus tajemného železa, pocházejícího z vojenské techniky. Tím byl gyrokompas pravděpodobně z tanku T72. Bohužel jsem ho dostal s ustřiženým svazkem asi 30 drátů bez jakékoli elektroniky. Byla to výzva.

Začal jsem tedy shánět literaturu a snažil se pochopit, jak toto monstrum pracuje. Problém – teorií je na netu dost, ale nic konkrétního. Zjistil jsem, že nejlepším zdrojem informací jsou diplomové práce. Zvláště jedna se zdála být velmi přínosná, ale když jsem se prokousal ke konkrétním faktům, text na stránkách byl nahrazen jen nápisem „ vzhledem k utajení, kterému text podléhá, nemůže být zveřejněn“. A byl jsem zase v ……( na začátku ).

A začalo období pokus – omyl. To asi každý dobře znáte.

3-fázový H můstek

Úkol č. 1 bylo roztočit motor setrvačníku. Z toho mála, co se podařilo zjistit je to třífázový 36V motor s kotvou na krátko zapojený do trojúhelníku ( vyvedeny jen 3 dráty ). Frekvence 400Hz, tedy cca 22 000ot/min. Byly zkoušeny střídavé modelářské regulátory, ale bez úspěchu. Indukčnost vinutí je pro ně patrně příliš vysoká a ony nemají patřičnou odezvu naindukovaného napětí. Ani impedanční převodník v podobě třech transformátorů se neosvědčil. Použil jsem tedy 3-fázový H můstek, tvořený 6-ti kusy L149, napájený 24V. Jako zdroj impulsů procesor PICAXE 20M2. Ten kdo si zkusil roztočit krokový motor do takových otáčet asi zjistil, že bez orig. elektroniky se mu moc nechce.

deska stabilizace gyra

No, nechtělo se mu. Několikrát jsem to vzdal a zase začal znovu. Nakonec vzniknul program, který postupně pomalu zvyšuje frekvenci Doba náběhu do otáček je potřeba min. 10min. a pak ještě dalších 10min. na jejich stabilizaci. S napájením 24V se dalo ale dosáhnout max 15000 ot/min. Pak už ztratil motor sílu. Stačilo s ním zatřást, magnetické pole se „utrhlo“ a bez ohledu na napájení začaly otáčky klesat až se zhruba po 15min. setrvačností dotočil. Aby se dosáhlo vyšších otáček , bylo by potřeba zvýšit napětí. Další baterii jsem už ale odmítl. I tak to byl úspěch a vypadalo to celkem postačující.

Gyroskop se sice točil, ale dělal si co chtěl. Celý systém má tři stupně volnosti a ve dvou osách celkem čtyři elektromagnety s pohyblivým jádrem. Dva udržují setrvačník ve svislé poloze při bočním náklony. Druhé dva vytváří sílu působící potřebnou proti rotaci země. Roztočený setrvačník si musíme přestavit jako těleso, které stojí a okolo něj se otáčí zeměkoule. A ta se pohybuje rychlostí 15°. za hodinu. Přesně o tento úhel se pootáčí i gyroskop. Úkolem těchto elektromagnetů je tedy na něj působit takovou silou, aby zůstal stát na místě. Ale máme tu elektromagnety, které mají při stejném proudu jinou sílu když je jádro na kraji a jinou pokud je více zasunuto. Nevím jak to vyřešili tvůrci systému, já se dal dlouhou cestu vytváření datového pole, kde určité výchylce je přidělen patřičný proud, respektive PWM signál. Není to sice nejlepší, ale je to postačující. Vzhledem k tomu, že během jízdy jsou výchylky někde na max. desetinách až jednotkách stupních, bylo možná zbytečné tomu věnovat tolik času.

O trochu snadnější byla stabilizace bočního náklonu. Tam se dalo použít kontaktů asi k tomu předurčených a doplnit pár tranzistorů a odporů. Pokud se gyroskop nakloní, elektromagnety pomalu vrátí setrvačník zpátky do svislé polohy. Funguje to ale pouze při náklonu pár stupňů.

Tak gyroskop se točí a celkem i stojí na místě. Teď tedy vyhodnotit měření směru a velikosti pohybu. Mechanické snímání nepřipadá v úvahu. Jakékoli sebemenší tření ho totálně rozhodí. Nakonec padla volba na snímač magnetické pásky AS5304 s rozlišením 0.025mm.

Výstup je jako z inkrementálního snímače. Konečné rozlišení úhlu je asi někde na setinách stupně. Přesně jsem to nepočítal. Každý gram navíc přidaný na pohyblivou část gyra je potřeba samozřejmě vykompenzovat.

Celá tahle sranda mi zabrala zhruba 5 měsíců skoro každodenní práce.

Kamera

Zbývalo už „jen“ převést výchylku gyroskopu na rychlost motorů a vyřešit zaměření osy závodní dráhy. Jako nejlepší se ukázalo laserové ukazovátko. Ta zaměřovací lať s odrazovkama při startu je nutná, protože tak slabý laser jinak není ve dne vidět. Červený laser na červené odrazovce ale ano. A začal nespočet zkušebních jízd na perfektně rovném a hladkém povrchu. Bylo nutné sladit laser s gyroskopem alespoň na desetiny stupně. Když totiž vezmeme v úvahu, že závodní dráha je dlouhá 314m, široká cca 3m, tak při zaměření na odrazovku ve vzdálenosti nějakých 20 – 30 m daleko máme povolenou chybu někde v jednotkách několika málo centimetrů. A to ještě nepočítám chybu celého systému na nerovném povrchu.

Pro náš první závod byla osa zaměřena pomocí laserového ukazovátka. Nic moc. Laser z tržnice od Vietnamců udělá totiž na 300m celkem pěkně velké kolečko. I tak se to v deštivé noci pře závodem celkem povedlo. Označili jsme si osu dráhy a nechali to osudu. Osud nám přál. Dojeli jsme třikrát až do konce. I když ve třetím kole to bylo s odřenýma ušima. Coby nováčci v této soutěži jsme vyhráli.

Pro robota byl narychlo zvolen název GŘAS aneb Gyroskopem Řízený Autonomní Samochod. Dobrá plácanina, ne.

Snad se mi tímto úvodem do problematiky mechanického gyroskopu podařilo odpovědět na většinu otázek a nastínit, o čem to vlastně všechno je. Pokud se do toho někdo někdy pustíte, přeji opravdu pevné nervy. Ale jde to. Možná přijdete na mnohem jednodušší systém, jak ho potvoru zkrotit. Rád se s vámi podělím o mé poznatky. Je to opravdu zajímavé. O tom jakými úpravami prošel tehdy ještě GŘAS před dalším ročníkem závodu RORO zase příště.