Robotika.cz

Robotour 2026

2026-02-14T00:00:00Z

live.robotour.cz

aktuální průběh soutěže, nakládky a vykládky

Pravidla

Základní pravidla jsou stejná jako loni s rozšířením o 1/10 kategorii, umožnující soutěžit s menším nákladem (500ml plechovka s nápojem).

Lokalita

Planetárium Praha

Pro záběry z parku viz např. obrázky z 2007.

Týmy

Pořadí	Tým	Video
1.	ARbot	Zb02CVqTJJA
2.	BestBase	tw5Ph1qRU6E
3.	Cogito	4EZqp2OGVDM
4.	Helhest	_nutBOcv0pk
5.	Istrobotics	Aydfo9QcBm8
6.	Matty-maticians	JK5Hds3u5kA
7.	MRVK Team (FEI STU)	YxJl1biXnCI
8.	R-team	I3Yvc9dVQoc
9.	Short Circuits Prague	ofVcR1l0MUM
10.	SynthCat Robotics	toKcZB3giUE
11.	Ultimo Minuto	9Bj753HiAnU
12.	Unidroids	XJgiis5s4CM

Rozvrh soutěžních kol

9-10 ... neoficiální testovací předkolo
10-11 - 1. kolo
11:30-12:30 - 2. kolo
14-15 - 3. kolo
15:30-16:30 - 4. kolo

Prostor soutěže

Soutěžní polygon pro Robotour 2026

ořez OSM mapy na cesty v rámci soutěžního polygonu — robotour2026-ver1.osm.gz nebo vyčištěná verze (odstraněné way deleted) od Cogito týmu
Varování — pokud robot opustí prostor soutěže bude zastaven pomocí Emergency STOP tlačítka a jeho pokus bude ukončen (podobně jako by vyjel z cesty)!

Blog

2. února 2026 — Registrace

Stejně jako v posledních ročnících, pošlete prosím do konce července 2026 mail na adresu webmaster-at-robotika.cz se subj. Robotour 2026 - jméno týmu. Pokud je robot nový, připište detailnější HW/SW popis. Součastí registrace je i link na letošní YouTube video s titulkem ROBOTOUR 2026 REGISTRATION - jméno týmu, dokazující, že váš robot (stále) funguje. Jízda 10m po cestičce, detekce překážky, funkčnost Emergency STOP tlačítka.

16. května 2026 — Změna termínu soutěže!

Po dohodě s týmy z loňského roku a zástupci Planetária Praha jsme se rozhodli o posun termínu soutěže o týden, tedy na sobotu 19. září 2026. Hlavní motivace je souběh tématicky stejně laděné výstavy Den chytré mobility, která se bude konat „přes ulici” na Výstavišti Praha. Jako bonus nám tam běží odpočet, tj. do Robotour 2026 zbývá 125 dní!

22. července 2026 — Připomenutí uzávěrky registrace

Blíží se konec července a tedy termín uzávěrky registrace na Robotour 2026 ve Stromovce v Praze. První videa už jsem viděl, tak se těším na další!

Díky a přeji pěkný zbytek letních prázdnin …

9. srpna 2026 — Registrované týmy

(v pořádí jak je nacházím v mailech)

Matty-maticians

Video: https://youtu.be/JK5Hds3u5kA?si=bLFmfZRgdrI0axVw

Níže uvádíme detaily a technické specifikace zcela nového a neznámého robota:

Robot: Matty02 HW: Odroid motherboard, Luxonis OAK D-Pro stereo camera, emergency button SW: osgar + osgar_apps + depthaiv3

BestBase

V Stromovke sme sa v roku 2010 zucastnili vasej sutaze. Ked som sa dozvedel, ze sa sutazi na rovnakom mieste tak som si povedal, ze sa znova zucastnim. Zial tento krat iba ako jednoclenny team. Dal som dohromady detske auticko s Raspberry Pi 5 beziacom na ROS2. Projekt je verejne dostupny na https://github.com/daniel-zilinec/robot-ros2

Registracne video: https://www.youtube.com/shorts/tw5Ph1qRU6E

Helhest

účastník Mobility day
na stanku budeme pripadne streamovat data z robota, ktery pojede v soutezi
missing registration video

Cogito

https://www.youtube.com/watch?v=4EZqp2OGVDM

Tým Cogito s robotem H3-LGA Nebo bych měl tým pojmenovat Fénix? Na Robotour už jsme byli. Je to už nějaký ten pátek. Robot H3-LGA - Location & guidance Automaton, H3 series, přezdívaný Helga - je nový, nezaježděný. Kód roste už dlouho. Uvidíme, ja to dopadne.

Cogito Team with robot H3-LGA Or should I call the team Phoenix? We participated on Robotour in the past. A long time ago. Robot H3-LGA - Location & guidance Automaton, H3 series, also called Helga - is new, unproven. Code has been growing for a long time. Let's see how it goes.

TomíkK (to be renamed)

… soutěže robotour bych se velice rád zúčastnil i tento rok. Kategorii určitě kde se vozí plechovky. Popis robota a registrační video pošlu o víkendu. Doufám že to stihnu dokončit. Jinak v srpnu plánuji začít trénovat ve Stromovce tak by se mohlo udělat klidně i společné trénování jak to bylo v prvních ročnících. Pamatuji si ze par týmu z Prahy je.

missing registration video

R-team

Robot HW: https://robotika.vosrk.cz/robots/matty/cs

Robot SW: ?

Video: https://youtube.com/shorts/I3Yvc9dVQoc

MRVK Team (FEI STU)

radi by sme sa registrovali na tohtoročnú Robotour s naším študentským tímom z Ústavu robotiky a kybernetiky FEI STU. Registračné video sa nachádza na nasledujúcom linku: https://youtu.be/YxJl1biXnCI

V prílohe zasielam stručný popis HW a SW robota. mrvk_hw_sw_description.pdf

ARBot

… rad bych se prihlasil na letosni robotour, ale zatim jsem nedokazal portovat SW z Win na Linux. Usilovne na tom pracuji, uz toho mam 90% upraveno, ale obavam se, ze casove mam pred sebou jeste 90%

missing registration video

Ultimo Minuto

Zlozenie by malo byt rovnake, ako minuly rok. Robot bude ten isty, oproti minulemu roku ma novy driver pre pohon a novy softver. Odkaz na video: https://www.youtube.com/watch?v=9Bj753HiAnU

Dakujem a tesim sa na stretnutie v Prahe

Unidroids

posílám registrační video na Robotour 2026 https://www.youtube.com/watch?v=XJgiis5s4CM

Tým: Unidroids
Robot: Tříkolka

CTU Robotics (?)

http://www.cturobotics.cz/
missing registration video

… rádi se Robotouru zúčastníme.

Pending …

Istrobotics

Short Circuits Prague - Dupák

CZU K2

???

24. srpna 2026 — update

Istrobotics

slubovane videjko: https://youtube.com/shorts/Aydfo9QcBm8

Sice kratke a nie v parku, ale zatial takto cez ros serial bridge a lidar.

Nastastie neplanuje vsetko zahodit. Rado ma v tomto pud sebazachovy Skusime preklopit nase thready do ros2 nodov a potom sa uvidim kam nas to zavedie.

CTU Robotics

chtěli bychom se omluvit, ale nakonec se Robotouru 2026 bohužel nezúčastníme.

26. srpna 2026 — update2

Helhest

https://youtube.com/shorts/_nutBOcv0pk

Matty 02, Stromovka, 2026.08.29 13:06:57 (Matty-maticians)

Matty-maticians o víkendu testovali ve Stromovce a přišlo mi, že by to mohlo být zajímavé i pro další soutěžící … tak než získám GPS pozice pro marathon tak alepoň to video …

p.s. odpovídající mapa:

Matty M02 mapa

19. září 2026 — Bylo nebylo

Zdálo se mi to nebo dnes proběhla nejakčnější robotour v dějinách soutěže?! Za hodinu bude půlnoc, ale asi musím alespoň první črty hodit na web, abych mohl v klidu spát …

Začalo to už v pátek a měl jsem velké cukání připsat nějaký komentář už k homologacím prvních týmů, ale pak jsem si to rozmyslel, že to nechám až po boji, což je teď. V pátek se homologovaly dvě výrazně jiné skupiny týmů — nazval bych je „vysokoškoláci” a ,, rodinné''. Za první skupinku to byl MRVK a Helhest, za druhou pak BestBase, Cogito a Unidroids. První mne doslova vyděsily, řekl bych skoro s agresivní strategií vyhrát! No a rodinné týmy byly tak na pohodu, ukázat kam se dostaly, poklábosit.

MRVK studenti měli platformu, která vznikla již před 19ti lety (hledej URPI FEI STU Bratislava). Pamatuji si toho robota jako celkem dost drahého ale jezdil tak v klídku. Noví členové týmu si ale spočítali, že pokud chtějí vyhrát a na nakládku je to až 1km, další kilometr na vykládku, pak ještě jednou a hurá domu … suma sumárum 5km a mají na to 1h, tj. průměrná rychlost musí být více jak 5km a je třeba jet tedy ještě rychleji … no potěš!

Helhest by zase svým „ocasem” (tím myslím třetí kolo vzadu) mohl lehce odpálkovat malé děcko několik metrů, kdyby při otáčce jen trošku chtěl. A už v pátek bylo jasné, že tito dva rivalové do toho dají všechno! Jako na rovinu, fakt jsem se bál … a jako absolutní nutnost byl remote stop … prostě riziko nebezpečí v těchto dvou případech bylo opravdu zřejmé. A ano, až do dnešního dne byl remote de facto zakázaný.

Oba adrenalinové týmy se v pátek homologovaly, ale tu rychlost MRVK asi budu ještě chvíli vstřebávat. Jo já to vlastně nedopovědel — spočítali si, že to musí jet fakt rychle, aby to stihli objet, a tak nahradili, převodovky, drivery, spousta věcí … ale to nám snad řeknou na online webináří, který bude první středu v říjnu na robotika.sk …

Předkolo (9-10)

Řekl bych, že předkolo v 9h tak trošku „vyšumělo”. Několik týmů to použilo k otestování čtení QR kódu s pozicemi nakládky a vykládky, ale někteří to zkoušeli už v pátek a v zásadě kdo chtěl jel, ale „hlavní rozhodčí” na to extra netlačil …

1. kolo (10-11)

Na druhou stranu 1. kolo už bylo maso. Byl jsem rád, že jsem přítáhl desky pro rozhodčí, co jsme pořídili před dvaceti lety a málem jsem je nestíhal rozdávat — trošku jsem si připadal jak večerníček (ta stará verze před mnoha lety, kde vyhazoval na konci znělky noviny). Pokud máte vysoké cíle, tak je každá minuta drahá a tak mnoho týmů moc neotálelo. A už v tomto kole BINGO! MRVK i Helhest daly maximální počet bodů (51) s opakovanou nakládkou! Navíc MRVK cestou předjelo Helhest, protože „jel moc pomalu”. Neviděl jsem to na vlastní oči jen toto byl report od sudích. Drsný začátek soutěže …

Jezdily i ostatní týmy i když né tak úspěšně a třeba Matty-maticians si „vylámali zuby” v poslední zatáčce těsně před nakládkou, kterou jsem zrádně umístil do nepřímo dostupného trojúhelníka (viz. node 4407938771).

2. kolo (11:30-12:30)

Ve druhém kole se „něco pokazilo” a našim rivalům se úplně nedařilo. MRVK rozebírají robota a řeší odpálené H-můstky (??? zde prosím o korekci) a získávají pouze jeden bod. Také Helhest někde udělal chybu, ale 21 bodů by ještě loni znamenalo vítězství. Překvapení je Unidroid — 51 bodů, tj. úspěšná opakovaná nakládka a vykládka!

3. kolo (14-15)

Třetí kolo byl zlom. Nemáme teď 2 rivaly ale rovnou 3 a co hůř v rámci jízdy Unidroids omylem zadávají na startu QR kód vykládky (tato sekce byla dříve uzamčená a přístupná adminum a sudím, ale prože mnoho týmu si kódy muselo zobrazovat samo, tak jsme od restrikce opustili a toto je druhá strana mince … během jízdy si to uvědomil a robota zastavil. Co s tím? Dali jsme Unidroids druhou šanci … a znova 51 bodů, které zamotaly bodování. Hmm.

4. kolo (15:30-16:30)

V posledním kole jsem vyrazil s Cogito na procházku ať také něco ze soutěže mám. Nakládka byla na hraně povoleného soutěžního polygonu a když jsme tam dorazili, tak proti sobě stáli dva nesmiřitelní roboti (Unidroids a Helhest) a vedle ještě Istrobotics a k tomu se přilepilo zmíněné Cogito. Fakt super deadlock :-(. No mohlo mne napadnout, že nakládka je místo kde se budou roboti shlukovat!

Nějak jsme to rozuzlovali, ale je to rozhodně jeden z bodů k řešení. A když se pak všichni roboti v klidu rozdělili (rozejděte se! neshlukujte se!), tak se přiřítil MRVK a byl z toho čelní střet s Cogito. Moje teorie je (resp. očítých svědků, já to tak uplně nezavnímal), že MRVK na poslední chvili zpomalilo a začalo se vyhýbat, ale už bylo tak blízko Cogito, že s delší reakční dobou nestačilo ani zastavit. Jak to bylo doopravdy možná ukážkou logy. Pro Cogito to bylo de facto konečná, protože otřes vyřadil počítač (po druhé rozborce-sborce nastartoval … ale za zatáčkou sjel z cesty).

Výsledky?

Well, čert je vem … ne sorry, to jsem nechtěl napsat. Řekl bych, že letos se vytvořily tři shluky:

základní mobilita
funční nakládka+
opakované doručení

V první skupině skončily: BestBase, R-team, Ultimo Minuto, SynthCat Robotics, Matty-maticians a Short Circuits Prague.

Druhá skupina jsou pak: Cogito, ARBot a Istrobotics.

A konečně „dravci” ve třetí skupině (možná jsem měl to pořadí otočit?) jsou: Unidroids, Helhest a MRVK.

Je půlnoc, tak pokračování „pohádky” zase někdy příště.

20. září 2026 — Není všechno paráda co hraje

Nečekal bych, že budu pokračovat v psaní tak brzy — je 5:11 ráno a nemůžu spát a s touto písní v hlavě jsem se probudil … aneb nebylo vše zalito sluncem přestože, co jsem včera nezmínil, počasí jsme měli vskutku suprové!

Jednu indicii (možná více) jsem už dal a to, že v pravidlech zmíněných 2.5m/s tj. 9km/h už je v některých částech parku holé neštěstí a možná jsme toto pravidlo měli tak nadsazené s myšlenkou „ať týmy sami poznají, že o rychlosti to není”. Ale to se letos změnilo — MRVK byli schopný jet poměrně rychle (mimochodem, od týmů bych si rád vyžádal data k přezkoumání ani né tak jestli byl míček už v autu spíše jak pravidla do příště upravit a jestli vůbec) a přesto byli schopný dobře navigovat. Bylo to ale nebezpečné, resp. z pohledu návštěvníka parku se to jevilo nebezpečné, a pak souhlasím s rozhodčím z posledního kola, který zakázal v této rychlosti projet mezi stoly v zahradní restauraci Vozovna.

Co se týče rozměrů, tak Helhest mi přijde přes limit. Vidím za tím spiše „bojového delivery robota”, než ze by mi to přivezlo do parku pizzu. V tomto kontextu jsem se dozvěděl, že byl problém v lázeňském městě Piešťany (Robotour 2023), kdy autíčko týmu Slnava, podobné co letos měl BestBase, už byl problém. Obávám se, že Helhest by v této lokaci vůbec nemohl soutěžit. Vím, že jeden čas se celkem zvedla vlna proti Segway (hmm, vyhledávač mi teď ukazuje samé koloběžky, ale já mám na mysli balancovací dvoukolák) a cvičně jsem zkusil co tedy hoverboard? AI generovaná odpověď zní: Jízda na hoverboardu (samovyvažovacím osobním přepravníku) není v parku Stromovka na pěších a parkových cestách povolena. … je tam ještě pokračování o zákazu motorových vozidel, ochraně chodců a legislativní status … hmm takže i Unidroids by byl vlastně problém?! Pomalu začínám chápat zděšení správy parku …

Co tam máme dál? Asi to trénování v soutěžním prostoru a GPS. Co se nám organizátorům nelíbilo na řešení z roku 2009 - Lužánky/Brno bylo, že jeden tým na místo vyrazil o týden dříve a kompletně si park zmapoval a pak jezdil podle takto nasbíraných dat. Rok na to v Bratislavě jsme už jezdili na základě společného mapového podkladu OpenStreetMap. A teď vznešena námitka k Unidroids, kteří jezdili podle nahraných GPS dat z pátečního večera a fungovalo jim to sakra dobře … a to byl možná ten problém. Ale jestli sledujete kariéru Unidroids, tak loni na Robotour v Buchlovicích nezískali ani jeden bod, protože to celé bylo postavené na GPS … de facto nikdy neopustili servisní oblast. Já tenkrát říkal, že jen s GPS to nikdy (ano, nikdy neříkej nikdy) fungovat nebude, že už ve zmíněných Lužánkách test s RTK korekcema pod stromy byl o řád horší než obyčejná GPS a podobná situace byla i Žilině (tam to myslím dokonce byl nějaký předchůdce MRVK??). Nic, Jarda z Unidroids se odradit nenechal, prošel si Robotem Rovně v Písku, kde se GPS nechytala, pak jízda po čáře na Tuláku po krasu 2026, kde mu zase GPS nefungovala, tak jí vypnul a jel čistě z dat z kamery a aplikace Yolo Pose na detekci čáry (za mne fakt moc pěkně, elegantní svižná jízda, zasloužené vítězství … a mimochodem všechny kódy i některá data jsou veřejně k dispozici). Další krok bylo Dobývání hradu před šesti týdny — zase ta GPS pod krásnou starou lípou byl neřešitelný probém … a teď ta Stromovka, kde to jezdilo srovnatelně s Tulákem, ale tady už bez čáry. V hospodě mi ostatní říkali, že jsem 20 let za GPS opicema, že teď už se to udrží s přesností na 1.5m i bez RTK korekcí, ale zároveň jsem slyšel, že luxusní GPS s korekcema pozice uskakuje až o 7 metrů?! Tak kde je sakra ta pravda? Jj, proto bych rád viděl data minimálně ze skupiny dravců, protože si myslim, že budou moc zajímavá.

A Unidroids měli ještě jeden trik, který nikdo jiný dříve neměl … to se mi zase vybavuje píseň o sedlákovi, co jede na pole se dvěma hodinkama. My teď už víme, že spravný sedlák by měl mít ty hodinky troje! — místo detekce synchronizace i možnost zotavení z chyby a jeden ze zdrojů eliminovat. A Unidroids jeli se třema GPS přijmačema (možná anténama, ale to se také snad dozvíme na webináři v říjnu), konfigurovanýma do rovnostranného (?) trojúhelníku a pokud jedna ze 3 pozic začala driftovat, tak byla ignorována. Za mne je to podobné, jako tvrzení, co jsme na začátku milénia učili studenty, že odometrie je časem nepoužitelná, ale R-team nám dokázal, že dobrá odometrie v kombinaci s kompasem může udržet robota přes 1km i na úzkých parkových cestičkách, včetně skákání přes koleje a kořeny, které tam i po 18(?) letech stále jsou.

… pokračování později aneb není natrénovaná neuronka dneska už také mapa?!

21. září 2026 — Nedělní workshop

Jestli mne něco opravdu mrzí, tak je to zrušení nedělního workshopu. Je to prvek, který jsme si „odladili” už druhý rok soutěže (tj. před 19 lety) a bylo to to místo, kde se všechny týmy podělily o své zážitky, poznatky a dojmy a kde se diskutovalo jak dál. Letos by se dalo vzpomínat jak na posledních 20 let, tak bylo hned několik dost zásadních věcí, které by si zasloužili pozornost. Toto je rozhodně má velká chyba, skoro bych řekl totálně fatální a přitom jsme velmi pravděpodobně mohli ještě jednou využít podpory Planetária (za to ještě jednou díky!) a prezentovat v malém kinosále.

Moje druhá chyba, ale řekl bych naprosto zanedbatelná vůči té výše, byla, že jsem se nechal ovlivnit a nepublikoval výsledky 3. a 4. kola jak mi je dodali sudí. Bylo by tak jasné o čem se vedou „přátelské zákulisní rozhovory” a znova odstavec 1 by to řešil. Desky mám teď doma v Praze a jsem mimo (kupodivu i já mám svůj život a nesoutěžní program), takže to vyplním až v úterý večer. Skupiny nahrubo platí, jak jsem psal již v sobotu. Co si pamatuji, tak ve vedoucím pelotonu měl MRVK něco přes 80 bodů, Helhest 144 (jak říkal Bědá „veletucet”, když už máme ten tucet týmů) a Unidroids 156(???), prostě více než Helhest. Předmětem sporu je, že Unidroids používal GPS data nasbíraná v pátek večer a nikoliv hrubý OSM podklad. Zároveň se tím nijak netajil. Další námitka byla, že Unidroids vozili sud pořád (Helhestu jsem to vysloveně zakázal), ale o této chybě jsem byl informován až po 4. kole.

Za mne jsou všichni vítězové a to nemyslím jen ty tři týmy, o kterých se zde převážně zmiňuji. MRVK si odvezl pohárek pro vítěze a dal bych mu tak ocenení skokan roku. Helhesta bych pokáral, že se nepodělil o zkušenosti ze Stromovky a neudělal update OSM map, jakožto lokální expert. Pokud je pozice křižovatky o 7 metrů špatně (je tomu opravdu tak??), tak rozhodně opravit! Co ale na druhou stranu v žádném případě nedělat je situace z 5. ročníku v Bratislavě/Botanická zahrada, kdy borci chtěli všem týmům pomoci a s DGPS navzorkovali cestu po 15cm a né náhodou jsme byli pokárání slovenskou OSM komunitou. Helhest nechť je vítěz v kategorii OSM based solution. A konečně Unidroids prolomil možná GPS bariéru, že pokud by býval upřesnil na základě nasbíraných dat danou sekci OSM, tak už nikdo nemusí řesit detekci cesty a můžeme Robotour zabalit. Takže další vítěz!

A ostatání? Možná jste si všimli Pavla (Short Circuits Prague) se čtyřnožkou na kolech, který bez problémů jezdil po schodech nahoru a dolu k Apolu 11? Ale neskóroval ani jednou. Proč? Mne by tedy detaily zajímali.

Ultimo Minuto dělají čest svému jménu a vždy na poslední chvíli tam ještě nějaký bod přihodili. … ale co se stalo a co odpálili na přijezdové cestě hned ráno cestou k Planetáriu? Podobný problém co měl ND Team loni v Buchlovících?

BestBase jsem moc rád po letech znova viděl v akci a navíc s celou rodinou! To plastove Audi nemělo zpětnou vazbu na zatáčení, takže řídící algoritmus nevědel, jestli jede rovně nebo má zatočená kola. Ale pak Dano zjistil, že bezpečnostní lidar vpředu pod kapotou (předpokládám 360deg) vidí i ta kola, tj. z laseru zjištoval natočení kol. Dobrý ne?

Matty-maticians byl náš anglicky mluvící, skoro by se dalo říci zahraniční tým — ale to by mi Georgi s Amritem možná vynadali. Je to nový tým a robot Matty (zelený, M02) z dílny Martina Lockera (R-team) měl svoji Robotourovou premiéru. A jezdil někdy opravdu pěkně, ale na bodovanou nakládku těsně nedosáhl.

Navážu R-teamem — modrý Matty se seriovým číslem M01. Martin je nejen autorem celého návrhu a „výrobcem” pěti robotů na DARPA Triage Challenge, ale také programátorem EPS32 na řízení všech serv, GPS, měření pozice kloubu, IMU … A pro Robotour to navíc bylo programování vyšší vrstvy v C++ (použít Python jsem Martina stále nepřesveědčil) a tak si kutá svoji cestu, řekl bych tou nejtvrdší skálou! GPS byla hodně nepřesná a občas skočila k přistávacímu modulu a nebylo jak se napojit na ostatní cesty … zase bych byl zvědav na detaily.

No a teď skupinka mazáků — Cogito / Jirka dorazil Curychu i s rodinkou a myslím, že letošní soutěž ho rozhodně neuspokojila … „proč jste mi proboha neposlali pár vzorků cest ze Stromovky?!” Jinak "Helga" je úplně nový robot s novýma kamerama, symetrický … spousta vychytávek a na soutěž se intezivně rok připravoval. Pripadně viz jako důkaz průběh Robotour Marathonu.

ARBot také prošel „Fénixovou fází”, což úplně není zvenku vidět. Windows po letech nahradil Linux, což je teď zase Alešův boj a důvod jsem pozapomněl, i když mi to v mailech psal. Aleš se také po mnoha letech dožil menšího nákladu (500ml plechovka), protože váha robota je srovnatelná s váhou sudu (myslím, že by stále byl schopen ho vozit). Také nám organizátorům trošku zamotal hlavu s bodováním, protože jako jediný s 1/10th kategorie dorazil na nakládku a vykládku (jestli si to správně pamatuji).

Zbývá ještě Istrobotics, loňský vítěz a dlouholetý šampión. Pro něj byla změna termínu soutěže o týden problematická a polovina týmu nemohla dorazit. A stejně jako Aleš prošel zásadní SW evolucí. Myslím, že cílem byl ROS2 a vrhli se na to jak Rado, tak jeho AI agenti, ale co dali a co naopak pokazili nevím?

Tak jo, utekla hodina, zkusím restartovat spánek …

p.s. na Tomáše s SynthCat Robotics jsem pozapomněl a přitom v myšlenkách jsem s ním chtěl začít, hmm. Jestli jste neviděli, tak doporučuji super-držák na 500ml na plechovky. Nevím, zda je to na kolo, nebo jak k tom Tomáš přišel, ale říkal, že to řešil na poslední chvíli a toto bylo just plug-and-play. A díky „maskotovi” už je jasné, který robot že je ta kočka. A jen tak mimochodem MartinS zmínil, že tam vidí jistou podobnost s Ichikaze.

p.s.2 bude to až za 14dní, ale raději si to sem předem napíšu hned, ať na to nezapomenu"

Veřejně přistupný webinář o Robotour 2026

Robotika.SK: Robotour Workshop I.
Wednesday, 7 October · 19:00 – 21:00
Time zone: Europe/Prague
Video call link:

https://meet.google.com/wua-qvgh-nyg

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.

Robotour Marathon 5km

2024-08-13T00:00:00Z

Pravidla

Pravidla pro Robotour Marathon 5km jsou podobná samotné Robotour. Robot má za úkol předvést své schopnosti autonomně navigovat po cestách bez lidského zásahu. Může to být libovolná cesta zmapovaná na OpenStreetMap. Hlavní rozdíl je v tom, že je to vaše výzva, realizovaná kdy vám to vyhovuje a kde vám to vyhovuje. Pravda, že si sami budete i sudími, což je trošku divné, ale … vyberte si místo, spusťte vás Robotour kód a podělte se o vaše video s GPS logem. Tato testovací výzva končí až se objeví robot, který první autonomně ujede alespoň 5km během jedné hodiny, ale zajímají nás i průběžné pokusy!

Průběžné bodové hodnocení

Pořadí	Tým	Vzdálenost	Čas	Datum	Video	GPS log
1.	Cogito	3.28 km	48 min	2026-09-16	FU8DAEP9y64	12473357
2.	Unidroids	2.8 km	37 min	2026-06-16	PN_RkdeMycw	—
3.	Matty train	1.48 km	50 min	2026-06-19	iTrGIKtDv-w	—
4.	Istrobotics	1.32 km	29 min	2024-09-01	nCEaeuZEGEY	11449780
5.	Freyja	1.1 km	19 min	2025-07-03	CnzEavuOVWM	12012921
6.	Pat	1.1 km	36 min	2025-05-10	dhqQ7sGSQVE	—
7.	Matty M03	0.5 km	16 min	2025-05-20	ETXFpEgZRhM	—
8.	ND Team	0.43 km	9 min	2025-06-07	5kCnv1JORj4	11996215
9.	Matty M04	0.28 km	9 min	2025-09-17	jT8siQApwOU	—

Submissions/Backlog

Report Generator: https://www.trackreport.net/

Istrobotics: Robotour Marathon 2024, attempt 1 — 9/1/24 22:33

Distance:	1.32 km		Average speed:	2.71 km/h
Total ascent:	0 m		Avg. moving speed:	2.85 km/h
Total descent:	0 m		Maximum speed:	4.83 km/h
Total time:	0:29:15.0		Moving time:	0:27:48.0

Istrobotics: Robotour Maraton 2025, attempt 1 - Zámocký park Buchlovice — 11/10/24 11:59

Distance:	0.40 km		Average speed:	2.39 km/h
Total ascent:	0 m		Avg. moving speed:	2.41 km/h
Total descent:	0 m		Maximum speed:	3.79 km/h
Total time:	0:09:56.0		Moving time:	0:09:49.0

Pat: Robotour Maraton 2025, attempt 1 — 5/10/25 22:00

https://youtu.be/dhqQ7sGSQVE

Distance:	1.10 km		Average speed:	1.80 km/h
Total ascent:	45 m		Avg. moving speed:	1.83 km/h
Total descent:	49 m		Maximum speed:	2.32 km/h
Total time:	0:36:31.0		Moving time:	0:35:55.0

Matty M03, attempt 1 — 5/16/25 10:00

Toto byl „test narychlo”, než budu muset jít do práce, a v zásadě to byla generálka na Robotem Rovně 2025, který je zítra (v sobotu 17. května 2025) v Písku. Matty jel pěkně svoji maximálkou 0.5m/s, dokonce vybral zatáčku u železničního přejezdu, ale … při přejíždění druhé koleje to asi drclo už trošku moc a zase vypadlo napájení ODroidu, takže konec a ztratil se i ten nejzajímavější kus logu. Nicměně považují za vtipnou situaci z času 1:53, kdy tam zrovna projel vlak.

https://youtu.be/KQZAQiuleyA

Distance:	0.14 km		Average speed:	1.74 km/h
Total ascent:	4 m		Avg. moving speed:	1.74 km/h
Total descent:	13 m		Maximum speed:	2.10 km/h
Total time:	0:04:46.0		Moving time:	0:04:46.0

Matty M03, attempt 2 (Písek, Robotem Rovně 2025) — matty-follow-road-250517_114139.log

Toto je záznam z druhé jízdy na Robotem Rovně 2025, kdy Matty M03 opět dosáhl cílové mety 314m (otočka se mi úplně nepovedla, ale to snad doplním v článku k RORO25). Nechal jsem ho ale jet dál. Spokojeně detekoval cestu, sjel na silnici (ano, nějaka auta tam projížděla), ale pak předvedl několik teréních triků. Nejprve jízdu napů na obrubníku, pak nájezd na obrubník nakolmo a nakonec to „napálil” do zaparkované Audiny (majiteli se omlouvám). Zastavil na náraznících, což mi přišlo takové praktické uzavření pokusu.

https://youtu.be/Z4qoPoxUVWM

Distance:	0.49 km		Average speed:	2.15 km/h
Total ascent:	61 m		Avg. moving speed:	2.21 km/h
Total descent:	67 m		Maximum speed:	3.89 km/h
Total time:	0:13:39.0		Moving time:	0:13:11.0

Matty M03, attempt 3 (Tour de Frymburk) — matty-follow-road-250518_*.log

V rámci post-Pískové eufórie jsem Mattyho M03 ještě trošku testoval na Frymburku u Lipenského jezera. Byla celkem kosa, fičelo, chvílema i mírně pršelo = na cyklostezce téměř nikdo nebyl.

Říkal jsem si, že typicky nejzajímavější jsou „poslední slova před smrtí”, tak 10s před koncem logu je přehravání v normální rychlosti (no fakticky jsem v konfigu zapomněl fps=10 a video je generované fps=20, tj. ta pomalá rychlost je 2x rychlejší než realita). Do Marathonu bych „příhlásil” nejdelší čast, kdy jsem ale robota zastavil, ať mi nevjede pod auto …

https://youtu.be/ETXFpEgZRhM

Distance:	0.50 km		Average speed:	1.81 km/h
Total ascent:	73 m		Avg. moving speed:	1.81 km/h
Total descent:	22 m		Maximum speed:	3.15 km/h
Total time:	0:16:28.0		Moving time:	0:16:24.0

Saya, attempt 1 (TulakPoKrasu2025) — (6/7/25, 08:48)

Distance:	0.43 km		Average speed:	2.92 km/h
Total ascent:	0 m		Avg. moving speed:	3.04 km/h
Total descent:	0 m		Maximum speed:	3.52 km/h
Total time:	0:08:54.0		Moving time:	0:00:19.0

Freyja, pokus 1, 1.1km/19:05 — (7/3/25, 21:45)

Distance:	1.10 km		Average speed:	3.45 km/h
Total ascent:	28 m		Avg. moving speed:	3.57 km/h
Total descent:	78 m		Maximum speed:	4.92 km/h
Total time:	0:19:05.0		Moving time:	0:18:25.0

Matty M04, pokus 1, 0.28km/09:27 — (17/9/25, 23:43)

https://youtu.be/jT8siQApwOU

Distance:	0.28 km		Average speed:	1.75 km/h
Total ascent:	23 m		Avg. moving speed:	1.77 km/h
Total descent:	31 m		Maximum speed:	2.65 km/h
Total time:	0:09:34.0		Moving time:	0:09:27.0

Unidroids, pokus 1, 2.8km/37:26 — (6/16/26 04:03)

Ahoj Martine, dal jsem dohromady video z Tuláka, ale když koukám na pravidla Maratonu, tak je to spíš jen info pro radost a progres. Podle výsledků je to 2800m a 37 minut. Odometrie a čas ve videu má cca 5% chybu. Jarda

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

challenges/Tulak_po_Krasu_2026/tulak_po_krasu.md

Matty M02+M04+M05+M03, pokus 1, 1.48km / 49:53 — (6/19/26 19:34)

https://youtu.be/iTrGIKtDv-w

mapa a profil

Distance:	1.48 km		Average speed:	1.78 km/h
Total ascent:	114 m		Avg. moving speed:	1.79 km/h
Total descent:	77 m		Maximum speed:	3.14 km/h
Total time:	0:49:53.0		Moving time:	0:49:39.0

Cogito, pokus 1, 1.47km / 23:16 — (8/30/26, 22:52)

Distance:	1.47 km		Average speed:	3.78 km/h
Total ascent:	43 m		Avg. moving speed:	3.84 km/h
Total descent:	60 m		Maximum speed:	6.48 km/h
Total time:	0:23:16.0		Moving time:	0:22:55.0

Cogito, pokus 2, 2.13km / 28:42 — (9/8/26, 23:58)

Distance:	2.13 km		Average speed:	4.46 km/h
Total ascent:	35 m		Avg. moving speed:	4.48 km/h
Total descent:	71 m		Maximum speed:	16.14 km/h
Total time:	0:28:41.8		Moving time:	0:28:32.8

Cogito, pokus 3, 3.28km / 48:13 — (9/16/26, 21:21)

Distance:	3.28 km		Average speed:	4.08 km/h
Total ascent:	186 m		Avg. moving speed:	4.24 km/h
Total descent:	121 m		Maximum speed:	19.24 km/h
Total time:	0:48:13.7		Moving time:	0:46:18.2

Pro nové pokusy prosím zašlete link na GPS trace z OpenStreetMap a link na vaše/robotovo YouTube video na adresu webmaster-at-robotika.cz se Subj. Marathon jméno týmu.

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

Dobývání hradu 2026

2025-11-21T00:00:00Z

Obsah

Pravidla (rev1)

(revize 6. července 2026)

Cílem robotů je „dobýt hrad” — plně autonomně se do hradu dostat, nalézt klíčové předměty a zase z hradu uniknout.

Dobývání bude mít tři fáze:

obsazení tábora pod hradem
dosažení brány
dobytí hradu

Obsazení tábora (9:00 - 12:00)

Začátek soutěže bude na parkovišti u železniční zastávky Trnov (viz mapka). Doporučujeme na místo dorazit již na 9h, dokud bude kde parkovat. Během tří hodin se soutěžící pokusí dostat do tabořiště pod hradem jednou ze tří zvolených tras (Svatojakubská, Rožumberská nebo Cyklistická). Po vzoru Tuláka po krasu pojedeme „na pohodu”, tj. soutěžící tým může startovat kdy chce a počítá se nejlepší pokus. Počítá se jak daleko se robot autonomně dostane — pokud do cíle dorazí více týmů, tak vyhrává ten, který tam bude dřive (nezávisle na startovním čase).

Dosažení brány (13:00 - 14:00)

Po obědě (buřty na ohni v tábořišti) se pokusíme „dobýt” bránu, která je hned za rohem a cesta vede okolo pokladny (100Kč za osobu). Podle schopností týmů možná volně přejdeme na hlavní, závěrečnou, etapu.

Dobytí hradu (14:00 - 17:00)

čas pokusu je omezen na 1 hodinu
předměty jsou 4 dopravní kužely rozmístěné v prostorách hradu (robot se musí kuželů lehce dotknout nebo zastavit na 3 sekundy v poloměru 2 metrů od kužele)
roboti nesmí nijak ohrožovat navštěvníky ani historickou památku

Lokalita

Soutěž bude probíhat ve zříceninách hradu Dívčí kámen.

https://www.openstreetmap.org/#map=19/48.889090/14.357355&layers=P

Foto převzato z https://www.ckrumlov.info/cz/pamatky-a-kultura-241-hrad-divci-kamen/.

Registrace

Stejně jako v soutěži Robotour, pošlete prosím do konce března 2026 mail na adresu webmaster-at-robotika.cz se subj. Dobývání hradu 2026 - jméno týmu s popisem HW a SW. Součastí registrace je i link na aktuální YouTube video s titulkem Dobývání Hradu 2026 REGISTRATION - jméno týmu, dokazující, že váš robot funguje: jízda 10m, detekce překážky a funkčnost Emergency STOP tlačítka. Termín registrace pro soutěž samotnou je pak do konce června 2026.

Partneři

Blog

Etapy (2025-11-13)

Jelikož se jedná o poměrně náročnou úlohu, padl návrh rozdělit úlohu na jednotlivé etapy, např.:

cesta z parkoviště ke kiosku
cesta od kiosku ke vchodu do hradu
průzkum hradu

Motivací pro toto rozdělení je následující snímek (Prostor po první vstupní bráně):

(zdroj Google Maps)

Noční Multi-Mula [NMM] (2025-11-16)

Řikal jsem si, proč jezdit na vojenskou "soutěž" do ciziny, když kategorii Mula si můžeme zorganizovat sami?! A navíc se k „Dobývání hradu” celkem hodí.

Základ bych nechal stejný:

robot jede za člověkem (průvodcem) z místa A do místa B
po dosažení místa B původce vyšle návratový signál
po dobu 30 minut robot začne pendlovat mezi místy B-A-B-A-…

Aby se to od originalu případně trošku lišilo, tak je povoleno více robotů a transport může probíhat i v noci.

Upřesnění termínu konání workshopu a soutěže (2025-11-24)

Dnes jsme dostali potvrzení, že 1. května 2026 (pátek) a 1. srpna 2026 (sobota) se na hradě zatím žádná akce nechystá, takže je to možný termín pro organizaci workshopu a soutěže!

4. dubna 2026 — 4 týmy registrovány na testovací workshop 1. května 2026

Je to tak — čas hrozně letí a ukončení registrace na workshop bylo na konci března 2026! Pokud se nějaký tým teď chytne za hlavu, že na to (podobně jako já) zapomněli, tak mi prosím napište přimo (i formulář by již měl fungovat) a domluvíme se, snad.

Registrované týmy:

Lioncar
Unidroids
~~R-team~~
~~Helhest/VRAS (?)~~

… plus referenční Robotika tým (Matty04 + Matty05).

1. květen 2026 — 1. pokus o dobytí nedobytného hradu

Veni, vidi, vici … nebo jak je to? Máme za sebou první návševu Dívčího Kamene — hradu založeného rodem Rožmberků v roce 1349 (a opuštěného 1506). Naše sestava byla spíše komorní (6 účastníků, 4 roboti), ale …

počasí bylo super luxusní
ten hrad je opravdu velké sousto, takže výzva, jak má být
celý den se nesl v pohodové procházkové amosféře

Začnu od konce — kamarádi říkali, že ten příští termín 1. srpna 2026 je sobota … a řádky výše to potvrzují . Termín platí, soutěž platí.

útočné stezky

Dále, aby bylo možné hrad dobýt, tak je třeba se k němu nejprve dostat a to už je první challenge. Autem se tam přes zákazy nedostanete, takže základní plán je nechat na parkovišti v Třísově. Na hrad vedou dvě hlavní cesty: červená turistická značka (Svatojakubská) a cyklistická (1127) jestě s možností různých „zkratek” (Rožmberská cesta). Dostat roboty z parkovistě do podhradí (louka s ohništěm a kadibudkou) bude zároveň Úloha I. (10:00-12:00). Volba trasy je na robotovi/programátorovi, ale je klasicky vyžadovaná plná autonomie. Lidský zásah by byl penalizován (v plánu je měřit čas jízdy a penále by mohlo být třeba 10 minut).

louka pod hradem

Úloha II. (12:00-13:00) bude dostat autonomně robota z tábora pod hradem ke vstupní bráně (přes kasu a závoru).

Úloha III. (13:00-16:00) „dobytí hradu”, resp. jeho průzkum. Cílem je nalézt a „zneškodnit” co nejvíce „obránců” = dopravních kuželů. Povolený je pouze „jemný detek” ať jsou kužely ještě použitelné i pro ostatní soutěžící!

Unidroids

27. července 2026 — Revize pravidel 2

Zbývá pár minut do půlnoci, což je ideální čas se ventilovat …

Dnes jsem se vrátil z krátké dovolené a procházel maily. Vedle registrací na Robotour 2026, za které jsem vděčný, to bylo ale nějak moc mailů typu: musím se omluvit, ale v sobotu nepřijedeme, bohužel to letos nedám, musím se omluvit ze soutěžní účasti, prijedeme na otocku ... jen pokecat … hmm, ve „hře” tedy zůstává jediný tým, ale potenciálně několik diváků. Co s tím? Myslím, že by doma uvítali, kdybych nikam nejezdil … a poslední varianta byla vzít to na otočku … hmm.

Ale když jsem o tom v posteli přemýšlel a nemohl usnout, došel jsem k další revizi pravidel. Aneb nedá se to ořezat ještě více? Co toto: Robot, který ze startovní pozice první autonomně dosáhne cílové pozice (definované GPS souřadnicemi a dopravním kuželem) vyhrál.

48.8890564N, 14.3576761E

nový cíl

Žádné omezení na cesta/necesta — ono to vlastně není potřeba, když z jedné strany je tam sráz a z druhé skála … prostě „rozumní roboti” stejně pojedou po cestě. A jestli místo přes most preferují brod, tak proč ne? Je to takový RoboOrienteering s jediným kuželem a lehce nepřátelským prostředím. OK/NOK?

28. července 2026 — Show must go on! (84h)

Můj včereší nářek mohl vyznít tak, že se nic nekoná, ale to by byla chyba! Jádro zatím drží a možná se objeví i další.

… a teď mám najednou pocit, že nevím co dříve … v každém případě se těším v sobotu 1. srpna 2026 na viděnou!

30. července 2026 — Vačnatec a tři kamarádi (48h)

Včera jsem zmiňoval, že zvažuji vzít Pata a na něj dát Mattyho, kde v jedné verzi by skupince dodával pouze kompas případně oko. No a PavelS to komentoval slovy: „no jasně, vačnatec”. Ale myslim, že budu rád, jestli za dva zbývající večery vůbec updateuji systém na Patovi … no všichni víme, jak to dopadne.

A tři kamarádi? To jsou tři soutěžící týmy, které snad uvidíte:

2. srpna 2026 — Soutěž

Soutěž proběhla včera (1. srpna 2026) jen už jsem neměl dost energie zapsat ani hrubé výsledky … tak to napravuji teď.

S Georgi (Matty-maticians) jsme dorazili na startovní místo krátce před 9h. Nebýt cestou několika padlých stromů a větví po páteční bouřce bych řekl, že cesta byla celkem v pohodě. Krátce po nás dorazil Jarda (Unidrods) a k polednímu pak Béďa a spol. (Helhest). Posledně jmenovaný tým dorazil ve dvou autech HW auto a SW auto. Ona taky ta jejich tříkolka není žádný prcek …

Startovali jsme od prastaré lípy u parkoviště v Třísově (výška 32m, obvod 763cm). Byla tam i lavička ve stínu, tak za mne pěkné místo na první základnu. … ale GPS pod stromem uplně kvalitní nebyla a stejně tak její korekce. Z tohoto pohledu na tom byl nejlépe Matty M02, ale i ten se rozhodoval, kterým směrem po cestě vyrazit a ano, směr nebyl přímo na hrad!

Pata jsem bral jako „referenčního soutěžícího”, takže jsem si na startu hrál také. Integrace detekce hladké cesty (4:30am-5:30am) podle očkávání měla své mouchy. Kupodivu jsem trefil levou a pravou stranu, ale třeba detekci překážky jsem měl špatně, ale o to více efektní: „Pokud není překážka stůj. Pokud je překážka jeď maximální rychlostí!” Nikdo nebyl zraněn, protože naštěstí byla splněna první podmínka a robot tedy nejel. Nicméně k problémové startovní lokaci si užil i Pat — vpravo byl příkrý svah (ne tak příkrý jako vlevo, kde si to zase na začátku oblíbil Helhest), ale bylo to tam hladké a tak tam robot opakovaně vyrazil. Dnes mi dochází, že kdyby robot jel vedle domu/hladké zdi, tak si dost možná vybere zeď (myslím algo ver0).

A výsledky? Hrad nebyl dobyt! Jakub tam sice donesl kužel, aby se neřeklo, a tak nás to donutilo na hrad znovu dojet/dojít. Částečné výsledky (díky ŠtěpánoviL za nezávislého rozdhodčího) jsou k dispozici — nejdál dojel Helhest, pak Matty-maticians (nažloutlá tráva připomínající cestu), pak Unidroids (GPS) a peleton uzavírala Robotika (první hladký svah). Z pohledu Robotika Teamu bych řekl, že dobrý a žádný ze soutěžních týmů by nepřišel o DARPA sponzoring. (vtip, vysvětlení — na SubT Tunnel to skoro vypadalo, že pokud jsme se dostali před nějaký sponzorovaný tým, tak v dalším roce už sponzorovaný nebyl).

… tolik hrubé výsledky a detaily a foto snad doplním večer …

Unidroids

Účastníci zájezdu

Helhest a spol.

3. srpna 2026 — Robotika - referenční soutěžící

Tak trošku doufám, že během tohoto týdne dostanu pár odstavečků od jednotlivých soutěžících týmů, ale proč nezačít tím posledním? Navíc nesoutěžním, jen pro referenci.

Na DH26/2 jsem vyrazil tentorkát s Patem na kterém byl položený Matty M03. Původní plán byl, že Matty bude detekovat cestu a přeposílat přes WiFi příkazy Patovi, ale pak jsem raději přešel na jednodušši variantu a to detekci hladkosti z LIDARu, což by mohlo odpovídat cestě. Kód je případně k dispozici na PR #35.

Asi bych začal s videm z Matyho, kde je vidět pár detailů:

Pat se vrhá do svahu vpravo
Georgi nese zeleného Mattyho M02
Helhest jezdí po poli vlevo

U informační tabule jsem robota ručně otočil a nechal ho navigovat zase autonomně zpět. Co není zřejmé, a chtělo by to zkombinovat oba logy, je kdy je Pat v autonomním módu a kdy jsem musel převzít řízení, ale to dnes už nepřipravím, tak raději alespoň tato surová verze. Z závěru tam jede auto v protisměru a Matty detekoval vedle cesty i YOLO objekty, tj. vidím v datech:

0:07:09.941864 20 ['car', 0.86181640625, [0.8564453125, 0.3040364384651, 0.99951171875, 0.58268225193023] ]

A vlastně tam byli i dva cyklisti:

0:06:06.547099 20 ['person', 0.7490234375, [0.1168212890625, 0.17350262403488, 0.34375, 0.73307293653488] ],
                  ['bicycle', 0.7138671875, [0.022583007812, 0.372395783662, 0.333984375, 0.8626301288604] ],
                  ['backpack', 0.63134765625, [0.078796386718, 0.196940109133, 0.2165527343, 0.38118487596] ],
                  ['person', 0.56201171875, [0.493896484375, 0.37239581346511, 0.5625, 0.5875650644302368] ]

… tedy prý s baťůžkem.

Koukám na časy, kdy jsem převzal řízení:

0:00:00.648474 Vehicle mode: 1
0:00:29.797809 Vehicle mode: 0
0:00:53.556491 Vehicle mode: 1
0:01:09.795869 Vehicle mode: 0

a zde je přehled detekované cesty (autonomně jel 29s až 53s):

Detekce cesty z lidaru

Tj. pokazí se to krátce před 50s.

Hladký svah u 50s

A důvod na 90% je ten, že hledám příliš velké okno! V kódu mám default 300, kde 360deg scan má 1800 — tady cesta ale o něco uzší a lepší kandidát se najde na svahu vpravo, přestože tam jsou dva velké skoky. Ještě poznámka, že tolerance rozdílu dvou sousedních měření je 10 tedy 1cm. Cestu jsem si pod Lípou měřil a měla 290cm a co mi teď nahrubo vychází pro 300, což je 1/6, což jsou vlastně rovnostranné trojúhelníky, tj. poloměr rovná se šířka a lidar mi vrací 3.7m. Ano, je to ještě sklopené 10 stupňů dolů, tj. takový kužel … cos je 0.98 … skoro zanedbatelné.

Tady tedy bude třeba pracovat s proměnlivou velikostí okna a hlavně bych tam chtěl zkusit zapojit ty samotné vzdálenosti. Naivně si teď představuji, že to svahy okolo a budovy musí vyrušit. Ano, škodolibý nepřítel (nebo přítel?) by řekl, že bych si na to téma měl přečíst nějaký článek, ale pak by to nebyla až taková zábava … todo later.

Cesta na hrad

Ta asfaltka na videu z M03 vypadá celkem pohodově, ale není. Zlomí se to v okamžiku rozdvojení na Rožumberskou cestu a následuje více jak 18% padák (číslo soudím podle dat z prastaré GPS). Jestli má Pat opravdu 125kg a jede 1m/s, do toho občas „ustřelí” z cesty — no je to adrenalin! Cestou se něco pokazilo, takže Matty už nenahrával, ale stalo se to nějak takto:

ostré sluníčko Pata zastavilo a stočil kola ostře vlevo do škarpy
silnice je sypaná jemným štěrkem (skoro písek), takže šel do smyku
remote jsem přepnul na manuál ale i doprovodné osoby se lekly a začaly robota chytat
stisk nárazníku odpojil autonomní řízení i dálkové ovládání rychlosti
robot byl v neutrálu a znova nabral rychlost
brzda na vzdáleném ovladači sepnula

… jen se to vše stalo ve slomku sekundy, nebo mi to teď tak připadá.

Že fyzické nárazníky odpojují autonomní i remote řízení vím — bezpečnostní prvek. Je třeba robota vypnout a znova zapnout (možná existuje i jiné řešení, ale zatím jsem na něj nepřišel, konkrétně bych doufal, že když stiskne přední nárazník, tak je šance couvat). Co jsem ale netušil je zachování posledního stavu brzd, což tady bylo odbržděno. A jsem rád, že jejich aktivace byla možná a i na tom písečku relativně úspešná!

A co na to černá skříňka?

pat-dh26-260801_124356.log
Total time 0:18:51.672916

0:15:54.055071 Vehicle mode: 1
0:16:08.276248 Vehicle mode: 0
0:16:41.132048 Vehicle mode: 1
0:16:46.752133 Vehicle mode: 0
0:17:20.230240 Vehicle mode: 1
0:18:51.646308 Emergency STOP True

app.desired_steering
0:17:19.591284 1 [1000, -400]
0:17:19.690906 1 [1000, 1160]
0:17:19.790578 1 [1000, 819]
0:17:19.890860 1 [1000, 1280]
0:17:19.987704 1 [1000, 2180]
0:17:20.089425 1 [1000, 1220]
0:17:20.187439 1 [1000, 1360]
0:17:20.230240 Vehicle mode: 1
0:17:20.286596 1 [1000, 1180]
0:17:20.385103 1 [1000, 960]

… naposledy v čase 17:20.23 jsem přepnul na manuál, ale to je zároveň čas, kdy došlo ke smyku. Krátce před tím, ale robot zatáčí 21.8 stupňů vlevo ze silnice (v plné rychlosti 1m/s). Stav nárazníků teď přímo nemám k dispozici (to je vždy konečná), takže rozšírím pársování a doplním, ale na 95% to bylo až po přepnutí do manuálu.

No nic, to byla taková komická vložka a pak už jsme byli skoro dole, Matty zase v klidu nahrával, ale přejíždění mostů asi zase nemám …

Stejně tak spousta kamenů na kterých oba roboti poskakovali tak, že přichycení Mattyho rozhodně nebylo dostatečné!

Návrat z restaurace (19:00)

Na závěr jsme si to dali ještě jednou cestou zpět. Bylo třeba zapracovat nově spořádanou kachničku a Pat podle všeho ještě nějakou energii měl. Toto prolítnu už jen pomocí obrázku, který mi ale přijde dobrý:

Návrat z restaurace na parkoviště

Distance:	2.87 km		Average speed:	2.77 km/h
Total ascent:	261 m		Avg. moving speed:	3.07 km/h
Total descent:	174 m		Maximum speed:	5.66 km/h
Total time:	1:02:12.0		Moving time:	0:55:47.0

Poučení zní, že z kopce je třeba jezdit pomalu (1m/s mi přišel jako hazard) a pokud máme dosáhnout Robotour Marathon 5km/h, tak je stále co dělat.

p.s. koukám, že tam mám i ty nárazníky, jen jsem to za ty roky zapomněl …

0:00:00.173364 Bumpers 0
0:17:37.512479 Bumpers 2

… tj. ano, bylo to po přepnutí na manuál v čase 17:20. Příště to bude čitelnější (PR #1081).

p.s.2 přidávám ještě nové 3-grafy, které mi přišly celkem zajímavé. První je v čase startu a druhý je v čase, kdy vyjel z cesty.

Profil na startu

Profil v okamžiku selhání

p.s.3 … a ještě alespoň jedno foto od PavlaS, jako důkaz, že tam na nás na hradě opravdu čekal kužel …

Kužel na hradě

p.s.4 … dnešní zkoumání mne lehce překvapilo — přidával jsem logování změny stavů Pata (PR #1081) a dále možnost nahrazení indexu streamu jménem (PR #1082) a toto je nový náhled na záznam krátce před nehodou:

0:16:41.464624 platform.brakes False
0:16:46.752133 platform.manual False
0:17:19.371121 platform.gear 3                # 0=disable, 1=P, 2=R, 3=N, 4=D
0:17:19.413129 platform.brakes True    !!!
0:17:20.230240 platform.manual True
0:17:20.462803 platform.brakes False
0:17:20.513865 platform.brakes True
0:17:20.571198 platform.gear 4
0:17:20.711501 platform.brakes False
0:17:21.062479 platform.brakes True
0:17:21.212663 platform.brakes False
0:17:21.463465 platform.brakes True
0:17:21.713200 platform.brakes False
0:17:22.464070 platform.brakes True
0:17:22.562732 platform.brakes False
0:17:23.063555 platform.brakes True
0:17:23.464687 platform.brakes False
0:17:37.474156 platform.gear 3
0:17:37.480376 platform.gear 1
0:17:37.512479 platform.brakes True
0:17:37.512479 platform.bumpers_front True

tj. od 16:46 byl robot v autonomním režimu a v 17:19 sám (!) začal brzdit. Navíc tady vidím, že i přepnutí řazení (gear) na dálkovém ovladači je vidět i v autonomním módu a nejspíše jsem o páčku zavadil, protože ještě před bržděním byl v N (neutrál/volnoběh)! V 17:20.23 sice přebírám řízení, ale rozjetého robota mám 0.57-0.23s v neutrálu, ale brzdy se nejprve uvolňují a pak je v panice znovu spínám. Na nárazníky došlo „až když už bylo po všem”.

Pat jede přes 2m/s!

A pro „pobavení” ještě obrázek výše — ne náhodou se mi zdálo, že Pat jede nějak rychle … enkodery reportují rychlost 2.3 m/s pro pravé a 2.0 m/s pro levé kolo zhruba v čase 1040.5, což odpovídá 17:20.5 … tj. fakt rychle vyjížděl vlevo ze silnice!!

A ještě jedna teorie, co se mi i honila hlavou když se Pat utrhl — vzpomněl jsem si na Jirku/Cogito, jak jel z kopce na jednom ze svých robotů, ODrive regulátory se přehřály a tak se „bezpečně” odpojily! Pat má výhodu pneumatické (?) brzdy, takže zřejmě byl ve stavu, kdy už se nedalo brzdit motorem a tak zabrzdil sám natvrdo. Žádné sluníčko a falešné detekce!

p.s.5 (2026-08-07) Elena implementovala skript na tvorbu titulků … ale přizám se, že offset 35s jsem odhadl od oka. Pro správné určení času je třeba vzít rozdíl absolutních časů začátků logu pro Pata a Mattyho, rozdíl času jejich hodin a čas prvního validního I-frame H.265 videa. Příště. Ale to video s titulky teď dává vetší smysl. … ještě, když jsem si to pouštěl lokálně, tak to tak šíleně černé nebylo, takže je tam asi nějaký (skrytý?) AI vylepšení kvality videa :-(

5. srpna 2026 — Helhest

(autor textu Martin Pecka, foto PavelS)

Tým Helhest z FEL ČVUT dorazil na místo poslední kvůli jednomu přílišnému spavci. Nicméně přijel plný energie, a to jak té soutěžní, tak i elektrické (tu jsme i rozdávali ). Helhest je v poslední době jako slečna před zrcadlem, co si neustále stěžuje, že nemá co na sebe, takže neuplyne týden, aby na něm nebylo něco nového. Tentokrát to byly dva (pro nás) zbrusu nové senzory: Fixposition Vision-RTK 2 a Manifold Tech Odin 1.

Roboti

Fixposition je švýcarská kombinace IMU, kamery a dvouhlavé GNSS, která interně dělá fúzi všech třech senzorů a poskytuje globální lokalizaci a odhad její přesnosti (kovarianci). Bohužel opravdu umí jen globální lokalizaci, tj. bez kvalitního GNSS fixu se ani nerozjede. Takže první hodinu na startu jsme strávili lovením fixu, což neusnadňovala ani vzdálenost k nejbližší free RTK stanici (Tábor, 62 km). Nakonec se zadařilo a v UI senzoru jsme viděli samé zelené obdélníčky. Od té chvíle vypadal celkem hezky funkční, kovarianci mění tak, jak by člověk očekával, s nedostupností jednotlivých senzorů se taky umí vypořádat obstojně. ROS 2 driver fungoval bez větších úprav out of the box, jen člověk musí pochopit, že něco se musí nakonfigurovat ručně v UI a až pak to ROS driver vidí. V záznamech jsme lokalizaci zběžně kontrolovali a vypadala ok. Akorát asi dvakrát to vypadalo, že se senzor za jízdy resetnul a pak nějakou dobu trvalo, než se zase chytil…

Odin je taková čínská černá skříňka s kamerou, solid-state lidarem a IMU. Uvnitř je nějaký nadupaný SOC a běží tam moc pěkně vyladěná fúzovaná odometrie, případně SLAM. I tenhle senzor se umí parádně vypořádat s nedostupností senzorů, akorát kovariance z něj lezou konstantní. Vypadá to skoro až magicky, když i bez loop closures to udrží pozici s přesností na centimetry po kilometrovém testu. Na školním dvoře se nám ho jednou podařilo rozhodit asi o 2 metry, ale nevíme, jak. Při dobývání hradu fungoval skvěle… až na chvíle, kdy nefungoval. V jednu chvíli IMU zahlásila 200 m/s^2 peak a senzor začal neustále zvyšovat odhadovanou rychlost, z níž pak integroval polohu. Takže jsme mu museli sebrat napájení a pak se zase umoudřil. Jinak ROS 2 driver téhle věci je takový… čínský… Funguje, ale člověk si ho musí ohackovat…

Tyhle senzory jsme na robota namontovali v pátek, takže integrace byla taková dost narychlo. Nakonec jsme zvolili celkem rychle zprovoznitelnou kombinaci: lokální odometrie pro sledování cesty z Odina, a do ní čas od času přepočítané GNSS waypointy přes Fixposition. Plánovač jsme trochu přiohnuli, původně byl zaměřený na exploraci, což tady nebylo úplně žádoucí, ale po pár pokusech se ho povedlo celkem nastavit. Žádná segmentace cesty neprobíhala, doufali jsme, že si plánovač vybere nejpříjemnější cestu po silnici

Na trasu jsme se vydali poslední, a až do ztracení Odina to celkem fungovalo. Pak (po necelých 300 metrech) se tedy Odin ztratil a tím náš pokus skončil (mapa). Pokračovali jsme ještě dál a většinou jsme ujeli pár set metrů, než nastal nějaký problém. Celkově nebylo úplně jednoduché pracovat s pointcloudy z Odina, protože mají dost jiné vlastnosti než ty, na které jsme byli zvyklí (lidar nevidí body pod úhlem cca 70° a víc). Sjezd z kopce byl celkem ok, byť motory už začaly limitovat kvůli teplu. A dole pod kopcem jsme se otočili, neb byly názory, že cestou do kopce spálíme hodně energie a aby nám vystačila na cestu zpátky… Chtěli jsme se odhlásit Martinovi, ale na jeho vybitý mobil to moc nešlo, a bohužel nás znavené horkem a hladem nikoho nenapadlo na hrad zaběhnout a rozloučit se osobně…

Návrat Helhesta

Tím byl náš odjezd trochu nezvyklý, ale všechno jsme si vysvětlili a rozhodně jsme neodjížděli nijak rozladění - spíš jen hladoví a vyprahlí… Na jídlo jsme zkusili nedaleké Bistro Libra, a nebylo to špatné, ale k dokonalosti taky ještě dost chybělo… Nicméně studené limonády měli a to bylo hlavní

6. srpna 2026 — Matty-maticians

(autor textu a fotografií Georgi Georgiev)

Hvězdné datum 4. srpna 2026
Deník Georgiho, kapitána robota Matty 02 z týmu Matty-maticians

Píše se pátek 31. července 2026. Byl to náročný den, ale nevěděl jsem, co mě ještě čeká. V 17:40 jsem skončil v práci a měl jsem jasný plán, co ještě stihnout – doladit detekci překážek podle depth

Matty M02

mapy, zprovoznit čtečku QR kódů, integrovat modul na zaznamenávání GPS souřadnic a zprovoznit hotspot. Všechno šlo dobře: nejdřív jsem trochu víc stabilizoval detekci překážek, dokonce jsem stihl test venku před budovou, kde bydlím. Matty dokázal úspěšně vyšplhat rampu na kočárky vedoucí ke vchodu do budovy, což Mattymu předtím nešlo. Už se ale začalo stmívat a navíc bylo oblačno, takže jsem si řekl, že dál budu testovat spíš v bytě. S pomocí Clauda jsem rychle a snadno zprovoznil čtečku QR a stáhl jsem si na mobilu aplikaci na vytváření QR kódů. Matty dokázal vyčíst z QR kódu na mém mobilu slavnou hlášku Obi-Wana Kenobiho: „Hello there!" Pak jsem zapojil opět Clauda do akce a s jeho pomocí jsem zaintegroval určení lokace podle GPS, což jsem už naneštěstí nemohl otestovat. Venku byla tma a v mém bytě GPS nefungovala. Ani se tomu nedivím, spíš bych se divil, pokud by GPS fungovala dobře. Takže jsem si řekl, že budu testovat až na soutěži – je to feature, kterou chci zprovoznit až na letošní Robotour, takže teď to zatím byl pouze vítaný bonus a nová funkce na vyzkoušení. Už bylo 23:00 a všechno šlo podle plánu, zbývalo zprovoznit hotspot z mého mobilu – nejjednodušší věc. Byl jsem příliš naivní, i když už s tím mám nějaké zkušenosti. Můžu potvrdit, že networking nadále není sranda. Můj mobil s Androidem 17 dokázal úspěšně vytvořit hotspot a připojil jsem k němu svůj notebook a taky Mattyho. Mobil mi ukazoval, že vidí 2 připojená zařízení, ale neukazoval jejich IP ani MAC adresy. Vesele jsem z počítače pingnul Mattyho a všechny pakety se ztratily. Po hodině debugování jsem došel k hypotéze (bez důkazu), že Android 17 je příliš bezpečný… a nedovoluje defaultně komunikaci mezi připojenými zařízeními. Navíc mobily od Google nemají pokročilá nastavení hotspotu, pokud nejsou ve vývojářském módu. A mobil je poměrně nový a nechtěl jsem s ním experimentovat.

K mému zklamání mě napadlo až na začátku psaní tohoto deníku, že mám záložní mobil, který je starší a přepnutý do vývojářského módu, protože jsem pro něj psal Android aplikaci jako součást své bakalářské práce. Záložní mobil jsem otestoval a jeho hotspot funguje bezchybně. Navíc jsem zázračně dokázal zprovoznit i hotspot svého hlavního mobilu. Zvětšil jsem bandwidth sítě a najednou všechno začalo fungovat. Ano, jako obvykle, došel jsem k závěru, že dostatek spánku dokáže zázraky. Potíže s hotspotem mě přesvědčily, že si musím koupit krátký Ethernet kabel na nouzová připojení k Mattymu. Přemýšlím, že bych si koupil i cestovní router, ale stále nejsem úplně přesvědčen, že ho potřebuji. Možná spíš nepotřebuji, teď když mám dva mobily, které dokážou fungovat jako Access Point pomocí hotspotu.

Už se píše sobota 1. srpna. Během debugování připojení k hotspotu jsem ztratil pojem o čase, a než jsem se vzpamatoval, byly už 2 hodiny ráno, a nejpozději v 5 jsem musel vstávat. Hotspot jsem vzdal a začal doufat, že Martin bude mít zázračné řešení problému, což taky víceméně měl. Nebylo to přímo zázračné řešení, spíš dobré staré klasické řešení – využít jeho mobil jako hotspot. V 5 jsem se vzbudil a začal jsem se rychle, ale opatrně připravovat na cestu. Naštěstí jsem už všechno potřebné vybavení měl v tašce. Ještě jsem si řekl, že dobiju baterku Odroida z večerního debugování hotspotu, což se mi povedlo. Ale když jsem vyrazil z domova, měl jsem už 10–15minutové zpoždění, což nebylo optimální. Cestu k Martinovi neznám dobře, spoléhal jsem se na Waze. Takže jsem během cesty ještě nabral dalších 5–10 minut zpoždění. Setkal jsem se s Martinem, nevypadal naštvaně na moje zpoždění, rychle jsme naložili Mattyho a moje dvě tašky do Martinova VW, a vyrazili jsme v 6:50. Cesta byla dobrá až na hodně větví na cestě po vichřici, která byla předchozí večer. Ještě si můj nevyspalý mozek vzpomněl, že divoká zvěř existuje.

V 8:50 jsme byli na místě a v 9:00 jsme už mohli odstartovat soutěž. Martin mi pomohl s hotspotem, takže moje největší obava se přesunula spíš k baterce mého notebooku. Je zbrusu nová, ale pořád malá, jako dřív. Dřív dokázala pod zátěží vydržet maximálně 2 a půl hodiny – herní notebook, který dokáže trénovat neuronové sítě a který jsem (málem) v minulosti rozbil tím, že jsem na něm neustále trénoval neuronové sítě po dobu 2 let na magistru. Skončilo to tím, že poslední 2–3 týdny magistra se často začala zobrazovat modrá obrazovka smrti. Ale tohle je jiný příběh.

Zpět k Dobývání hradu. Začal jsem první pokus. Start byl u stromu, který Martin zmiňuje ve svém blogu. A hned na začátku situace nevypadala dobře. Matty nejdřív udělal kolečko kolem startovní čáry a pak se rozhodl odbočit doleva kolem stromu a jezdit zcela mimo cestu k nějakému keři. Začal jsem debugovat a hned první změna byla, že jsem změnil velikost okna nad depth mapou, podle kterých určuji, kde jsou překážky (viz video).

Možná se nejdřív ptáte, jak by měl algoritmus na řízení Mattyho teoreticky fungovat. Největší prioritu má algoritmus na detekci překážek, která se řídí čtyřmi okny. Pro připomenutí, na vidění Matty používá stereo kameru Luxonis Oak-D Pro, a na Mattym momentálně běží knihovna kamery DepthAI v3.6.1. Dřív jsem pracoval s verzi knihovny 2 a hned jsem si všiml, že ve verzi 3 jsou lepší algoritmy na zpracování hloubkové mapy. Naneštěstí jsem nemohl zapnout všechny filtry mapy, protože začala docházet operační paměť kamery. Běží tam 5×5 median filter, brightness filter a navíc zabudovaný algoritmus na odhad vzdálených bodů (stereo_subpixel). Průměr hloubky přes levé a pravé okno určuje, jestli může Matty odbočit doleva nebo doprava. Střední okno určuje, zda Matty může pokračovat směrem rovně. Ještě navíc jsem přidal spodní okno, které určuje, zda náhodou není prudký pád (ladil jsem to hlavně pro schody). K mému zklamání stereo subpixel není magický algoritmus, který vyřeší problém určení hloubky vzdálených bodů (jako bonus filtruji pryč body s malou jistotou predikce). Takže příliš vzdálené body mají hloubku 0, což je nedefinovaný stav (na videu jsou v černé barvě), a Matty bere takové body jako blízkou překážku. Algoritmus se tedy nemůže dívat příliš vysoko, protože naráží na nedefinované body nad horizontem. Řešil jsem to tím, že mám nahoru-dolů posuvná okna a samotný posun se řídí IMU Luxonis kamery. Bohužel IMU není přesné, a jako bonus se z videa zdá, že se okna posouvají v opačném směru, než se mají doopravdy posouvat. Ano, znaménko vrací úder. Ve výsledku Matty čas od času detekuje zem jako blízkou překážku a odbočí na stranu, která vypadá vzdálenější. Je to vidět přímo na videu a až mě překvapilo, jak moc deterministické toto chování je – ve všech bězích Matty odbočoval doleva do trávy na stejná místa. Během soutěže jsem se pokoušel vyřešit problém změnami konstant, ale nechtěl jsem zasahovat příliš do kódu, abych nerozbil všechno, což se nakonec i stalo. Navíc mě tlačila baterka laptopu, která se rychle vybíjela, a v okolí jsme neměli kde nabíjet.

Druhá kritická část algoritmu je detekce cesty. Zatím tam používám stejnou neuronovou síť, kterou Martin použil na soutěži Tulák po krasu 2026. Jak můžete z videa vidět, model nefunguje bezchybně, ale je stabilní, když je cesta jasně definovaná. Naneštěstí nestabilita detekce překážek nepomáhala. Několikrát se stalo, že falešně pozitivní (FP) překážka způsobila prudkou zatáčku doleva nebo doprava. A jak je ve videu vidět, často se stávalo, že vlevo jsou pouze tráva a pole. Matty tak najednou vidí pole a hledání cesty detekuje oblast jako průchodnou. Výstup algoritmu je pak – jeď rovně do pole. Nastal ale scénář, kdy tráva byla ve skutečnosti vysoká, ale nižší než silnice, po které jel Matty. Matty spadl do příkopu s vysokou trávou a depth mapa najednou nemohla být úplná kvůli příliš blízkému objektu. Takže se najednou vším směrem stala překážka – ať se Matty otočil kamkoli, viděl překážku. Dostal se tak do koncového stavu. Několikrát se díky náhodě dokázal odtamtud dostat, ale jednalo se spíš o štěstí.

Během soutěže jsem ještě neměl takový hezký skript na debugování, díky kterému jsem vytvořil tohle video, takže na většinu pozorování výše jsem přišel až včera, 3. srpna. Během soutěže jsem si správně myslel, že je něco špatně s okny na detekci překážek z depth mapy, tak jsem se pokusil párkrát trefit dobré nastavení v konfiguračním souboru. Některá nastavení byla doopravdy lepší než jiná, ale žádné z nich nevyřešilo problém vjezdu do trávy. Kdybych jen mohl přijít na to, že se okna posouvají ve špatném směru a že Matty naviguje tak, že se dívá čistě do země… Každopádně baterka notebooku se mi už téměř vybila. Zbývalo posledních 15% a dostal jsem nápad pokusit se nastavit nedefinované hloubkové pixely na hodně velkou hodnotu, která se blížila maximální vzdálenosti. Proto si můžete všimnout, že ve videu horní část depth mapy má masku. Ovšem trochu předbíhám. Dokončil jsem verzi 0 masky, nahrál jsem kód do Mattyho a spustil mód čekání na uvolnění stop tlačítka. Baterka notebooku už byla na 7%. Rozběhl jsem se k Mattymu, odjistil stop tlačítko a najednou nic. Matty se ani nepokusil rozjet. Rychle jsem se vrátil k notebooku a už jsem ho nedokázal vzbudit. Takže to byl pro mě konec. Na takové situace mají Bulhaři hovorový výraz „отиде коня у реката". Překládá se to jako „Kůň vešel do řeky" a znamená to, že se všechno pokazilo. Naštěstí jsem v tu chvíli vedl podle ujeté vzdálenosti. Můj náskok vydržel ještě dlouho, ale nevydržel dostatečně dlouho.

Bylo už po 11:00 a najednou se objevil tým Helhest z ČVUT, tedy aspoň hardwarová část týmu. Jejich návrh tříkolového robota je dost dobrý, robustní a dokáže jet i vzhůru nohama. Navíc je mohutný, těžký, hodně silný, a jeho konstrukce pevná. Pokaždé, když udělá prudký pohyb, jeho kovová konstrukce vydá výrazné skřípavé zvuky a jeho velká motocyklová kola vydají zvuk protáčejících se pneumatik na asfaltu. Vzbuzuje respekt a přitahoval nejvíc pozornosti kolemjdoucích. Zanedlouho přijela i softwarová část týmu a s sebou přinesli skládací stůl, skládací židle a velký přenosný akumulátor. Půjčili nám ho taky, abychom mohli dobíjet baterky, a byla to naše záchrana. Jsem jim nesmírně vděčný. Popravdě v tu chvíli jsem už taky potřeboval dobít svoje vlastní baterky, tak jsem si dal syrové tyčinky. Ale i tak si 3 hodiny spánku už začaly vybírat svou daň. Neustále jsem přemýšlel o tom, jak stabilizovat Mattyho, a o Helhest robotovi a asi jsem se nesocializoval tak moc, jak jsem později chtěl.

Než jsem se stihl vzpamatovat, měl už můj notebook 16% baterky a dokonce se probudil ze spánku. Smůla byla, že jsem se nemohl připojit k Mattymu a začal jsem panikařit. Martin přitom nebyl v okolí, vyrazil testovat Pata, takže mi zbývalo vyčkat a přemýšlet, co se mohlo pokazit na mojí masce horních vzdálených bodů tak, že by to vyhodilo výjimku. Přišel jsem na to, že jsem možná příliš spěchal a měl bych začít tím, že přepíšu stejný kód od začátku. Martin se mezitím vrátil a dokázal nahodit spojení s Mattym, takže to pro mě znamenalo, že jsem zpátky v soutěži. Přepsal jsem maskování bodů a najednou… voilà, Matty fungoval. Byl tedy čas na další testovací běh… Ano, byl to přímo běh z nasdíleného videa. Maskování nepomohlo vůbec. Maska vyřešila problém detekce oblohy jako překážky, ale měl jsem zmatek v indexech z logu a neuvědomil jsem si, že se Matty celou dobu díval na zem, a ne na oblohu. Takže můj finální běh dopadl naprosto stejně jako můj rekordní běh. Aspoň jsem byl schopný replikovat svůj výsledek, čímž jsem zatvrdil svůj rekord. Ale tím, že jsem problém nevyřešil, jsem taky ztratil inspiraci pokoušet se debugovat ještě víc přímo na místě. Řekl jsem si, že budu o hodně efektivnější doma poté, co se pořádně vyspím. Řekl jsem si taky, že možná hlavní chyba je v neuronové síti na detekci cesty. Včera 3. srpna jsem z logu zjistil, že ano, síť není stabilní, ale nebyla hlavní příčinou odbočky do trávy.

Matty mimo cestu

Z logů videa navíc můžete vidět, že čtečka QR kódů funguje a GPS dokáže dávat směr jízdy Mattymu, ale stále si nejsem jistý, jak moc stabilní GPS je. Z práce vím, že často není nejlepší nápad věřit pouze GPS. Jarda z týmu Unidroids bojoval s GPS na svém hoverboard robotovi, ale víc napíše on sám o svých zkušenostech. Musím ještě jednou dodat, že algoritmus běžící na Mattym není zdaleka hotový a budu pokračovat ve vývoji. Deadline je Robotour v září. Každopádně jsem otestoval verzi 0 algoritmu, Matty jel autonomně dostatečně dlouho, nasbíral tak cenná logovací data, narazil na zajímavý corner case s trávou, a jako bonus jsem zjistil, že čtení QR kódu z mobilu není vždy ideální, když svítí přímé sluníčko – takže bych řekl, že jsem svoje cíle splnil. Dokonce jsem splnil pár cílů, které jsem tehdy ještě neměl. Jako bonus Matty 02 neměl žádné havárie a během testování nebylo zraněno žádné zvíře, ani jeden z největších mravenců v Evropě.

Hrad

Poté co běh z videa skončil, díval jsem se spíš, jak si vedou ostatní dva týmy – Unidroids a Helhest. Helhest nakonec dokázali stabilizovat svůj algoritmus natolik, že porazili rekord Mattyho 02. Během vítězného běhu jsem celou dobu šel vedle Helhesta a mluvili jsme o jejich algoritmu, který je dost zajímavý (nebudu prozrazovat detaily bez jejich souhlasu a doufám, že napíšou do fóra). Navíc se po dokončení běhu nevzdali a řekli si, že se budou dál pokoušet dobýt hrad. Zbytek skupiny jsme se rozhodli jít na hrad pěšky a počkat na ně tam. Martin nenechal Pata a rozhodl se dál sbírat data a zkoušet autonomní režim. Pat nám jako vedlejší efekt sloužil jako přeprava na osobní věci. Postupně jsme se dobrali k hradu a museli jsme ho nakonec dobýt sami, bez robotů. Což jsme dokázali. Jediná obrana hradu byla cenovka 100 Kč na vstup. Hrad je pěkný a tajemný, doporučuji ho. Přitom jsem měl jeden cíl – ochranu a vrácení kuželu. Ale než jsme se stihli podívat do všech koutů hradu, kužel zmizel. Pak se magicky objevil u Martina. A už jsem ho nespustil z očí, dokonce jsem ho nesl celou dobu. „My precious!" Pak následovala hospoda, plánování dalších soutěží a co s roboty, zmrzlina a cesta domů.

Cesta byla v pohodě, protože jsem neřídil. Ještě jednou děkuji Martinovi za organizaci soutěže a za odvoz. V 22:30 jsem už byl ve svém autě i s Mattym v kufru a odjížděl jsem zpět do Prahy. Matty sice ten den nevyboural nic, ale moje cesta domů byla vlastní soutěž – dobývání Prahy. Hned v lese kousek od Martinovy obce jsem se musel vyhýbat neosvětlenému cyklistovi mezi zatáčkami. Pak jsem se na poslední chvíli vyhnul úseku s dálniční známkou (kterou jsem pochopitelně neměl). A velkolepé finále proběhlo v tunelu Blanka, kde mi prudce zvedlo tep sedm motorkářů, kteří se rozhodně nesnažili být nenápadní. Mise splněna, kapitán a Matty 02 jdou spát.

Hrad

Západ slunce

Most a řeka

7. srpna 2026 — Unidroids

(autor textu Jaroslav Krch) — převzato z webu - divka_2026_II_analyza.md

Dívka 2026 II (1.8.2026) - Analýza dat

GPS poloha: Unicore UM980 + L1/L2/L5 anténa, RTK + PPP korekce
Dual Anténa Heading: Unicore UM982 + L1/L2 antény
10-Axis IMU: Hiwonder IM10A

Shrnutí

Řešení řízení robota bylo postaveno na záznamu GPS polohy. Záznam byl pořízen večer před startem (cca 1 km trasy).

Všechny pokusy při závodu vedly k tomu, že robot postupně sjížděl z cesty a systematicky uhýbal na pravou stranu.

Analýza dat po závodu ukázala, že fúze headingu a IMU obsahovala systematickou chybu 90 stupňů. Robot si myslel, že jede správným směrem, ale ve skutečnosti byl natočený do příkopu.

Analýza logu

Z logu je patrné, že robot při ztrátě heading z duální antény přepnul na heading z IMU. Úhel se skokově změnil.

Vlevo: Záznam logu při manuálním vedení robota. Vpravo: Otočení robota o 2x360 stupňů.

Další zkoumání dat z IMU ukázalo zásadní problém pro integraci. Když jsem robota otočil na místě dvakrát dokola, magnetické pole (MAG) se neotočilo, a výsledný reportovaný úhel (ANGLE) tak není správný. Nicméně Gyroskop (GYRO) na první pohled poskytuje správné informace. (Tato zjištění budou předmětem změny kódu a vylepšení integračního řešení; dalším krokem bude už jen ze zvědavosti snížení množství železa v okolí kompasu zda je příčinou chybného reportování).

Kvalita headingu

Robot se pro orientaci primárně spoléhá na GNSS heading (duální anténu a Unicore UM982) a v případě potřeby se záložně přepíná na heading (úhel) z IMU.

Vlevo: GNSS Heading a jeho chyba. Vpravo: Fúze směru orientace.

Mapa jasně ukazuje chybu orientace v částech, kde byl GNSS heading nepřesný, což je důsledek chyby v kalibraci IMU vůči robotovi.

Kvalita GPS dat

Robot byl osazen novou GNSS jednotkou Unicore UM980 s novou anténou pro příjem všech satelitních systémů a frekvencí L1/L2/L5 a s PPP korekcí. Jedná se o náhradu za původní L1/L2 anténu a u-blox F9R GNSS modul.

Vlevo: GPS záznam ze soutěže Tulák. Vpravo: GPS záznam z Dívky.

Modul Unicore UM980 společně s RTK korekcemi a L1/L2/L5 anténou byl schopen udržet RTK fix i pod stromy, zatímco u předchozího řešení (u-blox F9R s L1/L2 anténou) RTK pod stromy vypadávalo.

Závěr

Je třeba opravit fúzi headingu a IMU, aby robot lépe zvládal situace, kdy je GNSS heading nepřesný.

Modul UM982 je principiálně na primární anténě shodný s UM980 a na sekundární anténě pro určení směru používá L1/L2. Vyvstává otázka, zda pro sekundární přijímač nevyužít původní anténu od F9R, která by mohla mít lepší zisk. Což je předmětem dalšího zkoumání.

Interaktivní mapa

Interaktivní mapa (online náhled): divka_2026_mapa_kompletni.html

9. srpna 2026 — ?? Dobývání hradu II. ??

Kapitolu prvního Dobývání hradu bych asi pomalu uzavřel. Díky moc aktivním účastníkům, divákům a partnerům organizace soutěže.

A co druhá kapitola, bude? Máte o ní zájem? Má posoutěžní eufórie brzy vyprchá, tak je třeba k dalšímu kroku rychle položit základy!

Čtvrtletní Dobývání

Asi první, co mi přišlo na mysl, bylo, že pořádat soutěž až za rok, je hrozně daleko a s rozvojem AI je otázka, zda ještě budeme mít šanci něco zajímavého zkoušet. A to horké léto — není nějaka alternativa? Podzim je Robotour, na jaře zase Robotem Rovně nebo začátkem léta Tulák. Co pozdni podzim a co zima? A co to dělat každé roční období?!

GPS cílová lokace

Druhé téma, co se mi honilo hlavou, bylo, že GPS pozice cílového kužele „je pouze orientační” (něco jako text na reklamě, že obrázek je pouze ilustrační). Prostě já ani nevím, kam přesně ten Jakub kužel položil a hlavně to nechci řešit — stížnosti, že je o 2m jinde, než říka XY-super-GPS předem zamítám. S Cimrmanem bych řekl „plus-mínus 200 let” … tak poloměr podle mistra 200 metrů? … myšlenka v kostce je, že „kužel je někde na hradě” a „hledej šmudlo” (abych použil Cimrmana ještě jednou).

Ano, to nám nijak nebrání dát dopravní kužel na avízovanou GPS souřadnici, ale stejně tak máme možnost ho „schovat za roh”.

Lokace 2

Preference Helhesta byla, ať to není tak daleko od Prahy, což je celkem fér, když všechny 3 týmy byly z Prahy. V průvodci jsem narazil na zříceninu Zvířetice u Mladé Boleslavi, což je aktuální kandidát na pozdní podzim (poslední týden v říjnu 2026).

Hrad Zvířetice

MartinL pak doporučoval hrad Litice, kde by bylo i blízké ubytování v chatičkách pod hradem a pod. Byla by tam možná asi i zimní jízda, ale ta myslím skončí „tragédií”, takže jí můžeme realizovat i přímo v Praze.

Hrad Litice

Obě lokace jsou rozjednané, tak už jenom zbývá KDO a KDY?

Zdroj:

Teaser

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 nebo na mail webmaster-at-robotika.cz

Pat (a Mat)

2023-09-08T00:00:00Z

Podvozek pro donáškového robota jsem poptával již léta. Začalo to s Eurobotem a robotem Daisy (vlastně už s Bertou). Jedna z vizí byl pizzabot, který by rozvážel ještě horkou pizzu na pokoje na internátě v Praze Troji. No na realizaci nikdy nedošlo.

Další „donáškovou ligou” je soutěž Robotour. Zde je náklad pouze 5 litrový soudek, ale i pro běžné RC modely je to už moc.

Nějakou větší platformu jsem plánoval poskládat ze stavebnice Infento, ale zatím jsem tam nerozchodil ani ovládání motoru a o nějakých enkodérech ani nemluvě.

Na SubT Challenge se mi líbil Kloubák K2 a K3, ale přestože má dobrou prostupnost terénu, chybí nějaké vhodné místo, kam by se připevnil náklad. Navíc je tam problém výroby — netuším, zda někdy studenti poskládají K4, ale „letos to nebude”.

Co se komerčně dostupných platforem týče, tak si pamatuji noční šestikolovou můru z Francie, kterou Jirka testoval na Field Robot 2010. Pak jsem si nějaký čas hrál s Husky od Clearpath Robotics. Nebyla to úplně levná sranda a když si vzpomenu na stopy jak na trávníku tak na podlaze v obyváku, tak bych raději podvozek s možností zatáčení.

A konečně by bylo dobré pořídit již nějakou existující platformu a ne experimentální prototyp.

A když jsme nedávno znovu hledali platformu, co by byla schopna unést 100kg nákladu, tak jsme narazili na firmu Yuhesen: Founded in 2013, Yuhesen Technology is an industrial leading modular intelligent mobile robot provider building the easy-to-operate and high control precision robot platforms to support robotics research in the field of manufacturing, agriculture, educational, logistics, military and aerospace. YUHESEN has established a robotics product system covering all-terrain UGV and ROS based autonomous robotics solutions.

Robotických platforem nabízí hned několik s tím, že na současnou úlohu nejlépe pasoval FR-07 Pro:

FR-07 Pro (foto převzato z webu výrobce)

Rozměry: 132 x 76 x 49cm
Váha: 125kg
Náklad: 100kg
Rychlost: 8km/h
Max stoupání: 10 stupňů

Obsah

Blog / Pat (a Mat)

8. září 2023 — Nalodění

Dnes rano jsem dostal tyto fotky, které mne celkem potěšily, tak jsem se rozhodl odstartovat Pat-ovský blog.

Obsah balení

Pat ve futrále

Přepravní box

27. září 2023 — Prověření transakce, beneficiary name a EVER GLOBE

Tak jo, drobný posun. Omlouvám se, že jsem článek na chvili „schoval” (on ho stejně Google snadno našel i když byl hidden), protože situace nebyla úplně příznivá. Začalo to bankou, která chtěla „prověřit transakci”: ... banky dle zákona č. 253/2008 Sb., § 9 odst. 1 mají mimo jiné povinnost provádět kontrolu transakcí na účtu a mají právo klienta požádat o vysvětlení případně doložení transakcí, které probíhají na jeho účtech vedených u dané finanční instituce...

Pak to trvalo skoro 10 dní než se peníze dostaly z evropské banky do te čínské … přečetl jsem si dotaz na platbu do Číny, 14 dní žádná doba a nehrotil to (jméno Pavel Strašák mi také přišlo tématické ). Zabalený robůtek mezitím čekal ve skladu …

Pak to pokračovalo z čínské strany: The bank notified us they just received the payment. However it's incorrect beneficiary name so they can't released the remittance to us. It should be SHENZHEN YUHESEN TECHNOLOGY CO., LTD.

Kupodivu i toto se dá vzdáleně opravit, něco to stojí (prý až dalších 80 USD), ale … Good news. The bank just notified us they received the modify request and confirmed the payment is transfer to us.

A dnes přišlo info, že robot už je na cestě na EVER GLOBE (obrázek EVERGREEN je snad jen ilustrativní). ETA could be the middle of November. Uvidíme, co robota na cestě ještě potká.

3. listopadu 2023 — Čínský agent v Praze

Jestli myslíte, že se za titulkem skrývá informace, že už je PatAMat (jak mu říká Jirka) v Praze, tak vás zklamu. Toto navazuje na mailovou konverzaci ze začátku října, která se ke mne náhodou dostala. Tam jsem se dozvěděl, že já jsem ten agent!!! ... their company has a product agent in Prague, ...

The contact persion in PRAGUE for Yuhesen product:
Name: Martin DLOUHY
E-mail: Robotika.czmdXXX
Tel: +420 XXX

… nejprve mne to vytočilo do běla, pak mi to přišlo k smíchu … a po měsící už skoro i ke zveřejnění

Sledoval jsem, jak lodička (chápejte kontejnerová loď) pluje a kde asi robot touto dobou je a když nám posledně přišlo, že už jede loď zpět do Číny, tak jsem se raději zeptal. Odpověď byla šita na míru čínského agenta:

zboží na cestě

tak ještě že máme ty imperiální translátory … no tak tentokrát se moc nevytáhly :-(. Tak jen indicie, že Pat asi přestoupil na jinou loď a 5-7 asi odpovídá větě v mailu: The cargo has transfer to Germany warehouse now and will be delivered to your address in 5-7 days. Nechci být hnidopich, ale 27 + 7 je dnes. Jako jsem rád, že dnes dorazily ty lidary, ale to bude jiný blog …

p.s. jenom doufám, že jak překladač přeložil pravou část jako destination Republic of China, tak se pletl … „Matka vyhodnotila signál jako varování” (z filmu Vetřelec).

p.s.2 beru zpět tu poznámku o imperiálních překladačích … ona tam byla autodetekce jazyka a nějak přišel na Češtinu … když jsem mu vybral vhodnější, tak:

Dotaz na nákladní list
Číslo nákladního listu
Číslo převodního příkazu
čas schůzky
destinace
ilustrovat
fungovat
HX80054767
2023-10-27 0
Česká republika
Odhadovaný počet položek převedených do německého skladu je 5-
Znovu zkontrolujte stopu
1:06:41
Rozbalte podrobnosti
Zadejte prosím číslo objednávky (až 10), oddělené
klávesou Enter
HX80054767
【HX80054767】Podrobnosti
čas schůzky
plocha
podrobnosti
27. 10. 2023 01:06:41
Bire
Byl převezen do německého skladu a očekává se, že dorazí za 5-7 dní.
24. 10. 2023 16:40:58
Bire
Dorazil do přístavu
Zeptejte se
22. 10. 2023 00:00:00
Bire
|Předpokládaný čas příjezdu
2023-10-03 00:00:00
Shenzhen
|Odhadovaný čas plavby
27.09.2023 22:53:45
Shenzhen
| Jméno a číslo lodi: EVER GIFTED 0675-020w
27.09.2023 18:53:45
Shenzhen
|Protože inspekce nedodržela plán plaveb této lodi, je třeba ji odložit na další loď
26.09.2023 10:10:43
Shenzhen
|Odhadovaný čas plavby
22.09.2023 10:09:00
Shenzhen
Skříň nainstalovaná
22.09.2023 10:09:00
Shenzhen
| Název lodi a plavba: EVER GLOBE 0674-017W
25.09.2023 10:08:44
Opusťte distribuční centrum
2023-09-09 09:31:27
|Vstupte do distribučního centra

10. listopadu 2023 — První dojmy

A je to tady! Už dlouho jsem se na něco tak netěšil a zároveň z toho měl tak velké obavy. A oboje bylo naplněno. Balíčk dorazil. Bylo třeba tomu jít naproti, sehnat si dvakrát delší evropské trackovací číslo, provolat se k člověku co to má na starosti a možná jako v tomto případě řekne: „Jo, jo, včera to dorazilo, ale nebyl tam žádný telefón, takže je to zatím u nás ve skladu.” Den na to to ale expedovali, takže OK.

Pro začátek je třeba dodávka/nákladák s paletovou plošinou. Ta hračka, podle papírů, váží 125kg ale s krabicí a paletou už to hodí 180kg. Prostě ve dvou to neodnesete. Ale on je i problém s tím kousek popojet. Co si budeme povídat, Pat s domečkem skončil uprostřed zahrady. Dál to s paletovým vozíkem nešlo.

První dojem byl … že je Pat obrovský. Žena to později komentovala, že je to velké jak kráva! Ale ono je to asi ve srovnání s robůtky, co si člověk sám zvedne a odnese do auta, rozhodně pravda. Minimálně tak velká kola snad nemá ani Spider3 Rider. Ale neměřil jsem to, zatím. Co jsem ale změřil jsou rozměry krabičky: 145cm x 90cm x 60cm (s paletou 72cm).

Vedle toho, že Pat už je doma, mne potěšilo příslušenství — je tam i PCAN-USB převodník. Případnému hraní tedy nic nebrání.

A teď ty špatné zprávy — brání. Nejde to zapnout. Tipoval bych, že je tam někde schovaná pojistka, ale … robota jsem hned v poledne dal na nabíječku a psal Lambertovi, že platforma dorazila. Rovnou mne znova varoval (skleróza je hrozná věc), že vzhledem k tomu jak dlouho pojede robot lodí, je baterka úmyslně odpojena. Je třeba rozebrat levý kryt a baterii tlačítkem zapojit. Nepomohlo to.

Status? Pat spí uprostřed zahrady — snad divoká prasata nebudou zkoumat, co je to za nový přírustek.

Krabice na zahradě

První nabíjení

Pohled z boku

Otevřený levý bok

Baterka s čínským popisem

Remore Control

p.s. zapomněl jsem zmínit, že robot je defaultně zabrzděný, tj. je třeba ho napájet, aby se odbrzdil

13. listopadu 2023 — Baterka a brzda

Neveselo, truchlivo … hned se pozná první den dovolené. Dnes bylo nevlídno celý den. Ráno jsem byl domluvený s Lambertem (řekl bych, že obrázek na Alibabě je čistě ilustrativní , ale je tam více o Yuhesenu, je zvláštní, že cena je skoro dvojnásobná … že by už vánoce?!) na videohovoru ještě s technikem. Chtěli vidět robota „naživo”, což samozřejmě dává smysl, ale s tím deštěm uprostřed zahrady nic moc. Hodil jsem přes otevřenou krabici velkou plachtu a streamoval jak zapínám baterku a nabíječka nereaguje. Pak říkali ať platformu zapnu i když je na nabíječce (v manuálu to myslím doporučené není) a začalo to svítit a blikat jak vánoční stromeček. Tak už vím na co se mám tešit, až „baterka naběhne”, naběhne-li.

Teorie je taková, že venku je příliš chladno a tak se ochranný systém brání nabíjení. Lambert říkal 10 stupňů C a venku dnes přes den bylo 5.5C. A v noci nejspíše i mrzlo — rozhodně to není ideální pro baterku po X dnech cestování lodí.

Druhou novinkou je brzda. Defaultně se „zamkne”, když je robot bez napájení, ale páčkou lze odblokovat:

brzda

Milé překvapení bylo, že po odblokování brzdy bylo s robotem možné relativně snadno manipulovat (i když má těch 125kg). Tak jsem ho přesunul pod střechu a na vozíku přesunul i „ulitu”:

domeček na kolečkách

Další dobrá zpráva byla, že se Pat vejde do auta … dost mi to připomnělo výlet na Býčí skálu s K2. Sedačky je třeba sklopit a i jedno místo vzadu zůstane.

nakládka (1/3)

nakládka (2/3)

nakládka (3/3)

Zapnul jsem naftová kamínka, vytopil auto na 23C a … nic, nepomohlo to.

Další pokus bylo vytažení baterie. Lambert psal: It's better to label the cables before you remove the battery. The red and black are not interchangeable.

teplota v autě

označení kabelů

Řekl bych, že to byl jeho první zásek … no to je tak, když programátor hrabe do HW. Až po chvíli mi došlo, že to jsou jenom průchodky! … ty jen tak neodpojím. Když se ale povolí 4 šrouby (2 vlevo a 2 vpravo), tak lze s baterií snadno posouvat a …

napájecí konektory

… tak to bych možná ani já nepopletl.

Ještě drobná lekce čínštiny … jako opravdu díky za ty přkladače.

Čínské varování

CS překlad

Štítek baterky

Modelka

15. listopadu 2023 — ZERO battery voltage

Zatím žádné dobré zprávy. Původně jsem včerejší titulek chtěl nazvat No pasarán s touto fotkou:

No pasarán

Aneb poučení, že pokud máte někde schovaná „zadní vrátka”, tak někdy zkuste, zda jimi opravdu projdete. Matfyzácké řešení by bylo, že když měla krabice s robotem na výšku 60cm, tak při změně souřadného systému by robot měl projít, není-liž pravda? Asi lepší řešení navrhla žena a to vysadit branku a pak se tam Pat vešel.

Jak to pak vypadalo v chatě raději komentovat nebudu — prostě co měl Harry Potter pod schody byl luxus! Pat to dal jen do předsíně — vyndavat kvůli němu kamna v obýváku jsem fakt nechtěl. No nic, je v teple.

Druhý titulek co mne napadl byl „židovský vtip” o malém bytě, kdy rabín doporučí tazateli si pořídit kozu … ale nemůžu ho najít :-( Tak s FR-07 Pro je to podobobné. Pokud máte moc malý byt, poříďte si velkého robota …

Yennie hlídá Pata

A dnes jsem si koupil nový voltmetr, abych mohl proměřit tu zatracenou baterku:

ZERO voltage

Prostě je to nula ať propojíte cokoliv nebo vypnete/zapnete, napříč konektory … prostě nic. Je na čase otevřít zaplombovanou „černou skříňku”? Čekám na autorizaci z Číny.

16. listopadu 2023 — PCAN

(osgar) md@md-ThinkPad-P50:~/git/osgar$ python -m osgar.record  -duration 10 config/test-pcan.json 
                                               -note "Ubuntu Yuhesen PCAN2/USB, 10s"
2023-11-16 00:13:36,761 root             WARNING  Environment variable OSGAR_LOGS is not set 
                                                  - using working directory
2023-11-16 00:13:36,761 __main__         INFO     /home/md/git/osgar/test-pcan-231115_231336.log
2023-11-16 00:13:36,896 can              DEBUG    can config: {'bitrate': 500000, 'interface': 
                                                               'pcan', 'channel': 'PCAN_USBBUS1'}
2023-11-16 00:13:36,898 can.pcan         WARNING  uptime library not available, timestamps are relative
                                                  to boot time and not to Epoch UTC
2023-11-16 00:13:37,460 __main__         INFO     SIGINT handler installed
2023-11-16 00:13:47,471 can.bus          WARNING  PcanBus was not properly shut down

(osgar) md@md-ThinkPad-P50:~/git/osgar$ python -m osgar.logger /home/md/git/osgar/test-pcan-231115_231336.log 
 k    name  bytes | count | freq Hz
-------
 0     sys    269 |    3 |   0.3Hz
 1 can.can 109072 | 6416 | 599.1Hz

Total time 0:00:10.709735


(osgar) md@md-ThinkPad-P50:~/git/osgar$ python -m osgar.logger /home/md/git/osgar/test-pcan-231115_231336.log 
                                               -stream can.can -format '{hex(data[0])}' | sort | uniq -c

   1002 0x18c4d2ef - Chassis control feedback command
   1003 0x18c4d7ef - Left rear wheel information feedback
   1003 0x18c4d8ef - Right rear wheel information feedback
    200 0x18c4daef - Chassis I/O status feedback
   1002 0x18c4dcef
   1003 0x18c4deef - Chassis speedometer feedback
    100 0x18c4e1ef - Battery BMS information feedback
    100 0x18c4e2ef - Battery BMS mark status feedback 
   1003 0x18c4eaef - Vehicle fault status feedback

… tj. jedna nezdokumentovaná zpráva?

0x18c4e1ef 0000000000007070
0x18c4e1ef 0000000000008080
0x18c4e1ef 0000000000009090
0x18c4e1ef 000000000000a0a0
0x18c4e1ef 000000000000b0b0
0x18c4e1ef 000000000000c0c0

… tj. až na poslední counter je vše nula.

0x18c4e2ef 0000000000007070
0x18c4e2ef 0000000000008080
0x18c4e2ef 0000000000009090
0x18c4e2ef 000000000000a0a0
0x18c4e2ef 000000000000b0b0

… 0% zbývající baterie, min/max teplota 0C = nesmysl.

18. listopadu 2023 — Remote Control

Uznávám, ze poslední záznam o PCANu jsem „lehce ošidil” o nějakou omáčku. Bylo to až po půlnoci, kdy mne ostatní vyhecovali rozchodit si převodník a pak bylo tedy možné už rovnou v OSGARu nahrát si nějaká CAN bus data. A další den jsem začal psát OSGAR driver pro Yuhesen FR07 platform.

Pár pozorování:

CAN zprávy z BMS (Battery Management System) jsou vždy samé nuly ať už je baterka zapnutá, vypnutá nebo je kabel úplně vypojený! Z toho bych soudil, že pětipinový konektor není CAN
Většina zpráv jede na 100Hz
CAN zprávy pro řízení maji i echo, které vrací podle jakých příkazu se jede (hodí se v kombinaci s Remote Control)

Zapnout dálkové ovládání, když je Pat puštěný na nabíječce vypsal toto:

Úvodní obrazovka

překlad

(fakt nevěřím, že by někdo někdy mohl navázat komunikaci s mimozemskou civilizaci)

Včera jsem to zkoušel znova, přepnul druhou levou do max polohy a dostal další obrázek:

Pracovní obrazovka

překlad

(omlouvám se za mizerné foto, ale překladač to stejně nějak dal — zajímavé bylo, že když jsem špatně vybral zdrojový jazyk, tak pouze texty zvýraznil … další potenciálně užitečná vlastnost)

Pak jsem zkoušel zatáčet, houkat, couvat … no fungovalo jenom to zatáčení. Z logu jsem pak vyčetl, že robot byl celou dobu v parked režimu tak možná ta brzda je opravdu ruční? A houkačka nic i když byl požadovaný bit nastavený.

A když jsem to chtěl celé vypnout, tak to nešlo:

Závěrečná obrazovka

překlad

… ale po vypnutí robota se vypnul i dálkový ovladač.

p.s. zkusil jsem to znova a „hele, ten display je dotykovy!”

Display1

Display2

Display3

heslo?!

S tou číňštinou je spousta zábavy. Heslo?! What?! No o tom se manual nezmiňuje. Asi je na čase si ho znova přečíst.

p.s.2 tentokrát jsem se koukal i zepředu a opravdu při zatáčení dává blinkry,

p.s.3 tuto obrazovku vám nechám jako „domácí úkol”:

Display4

Display5

19. listopadu 2023 — První ujeté centimetry a User manual V2.2.0

Pat má za sebou první ujetý půlmetr! Konkretně 562mm … já vím, bída, ani celý metr … ale ono v té předsíni je cca 20cm prostoru, než nabourá. A ano, ten půlmetr je akumulovaný (CAN message 0x18C4DEEF Accumulated mileage). Vtipné mi přišlo, že v příkladu uvádějí jak nastavit rychlost 5 m/s … kdybych to udělal, tak asi místo předsíně máme verandu. No nic, pohnul se a to je hlavní, tj. i když se mi nepodařilo s ním pohnout přes dálkový ovladač, tak po CANu jede.

Asi bych vypíchnul, že ta CAN zpráva na řízení je fakt ošklivá, aneb proč probůh?! Jsou tam první 4 bity na řazení (P, R, N, D), pak 16 bitů na požadovanou rychlost v milimetrech za sekundu a dále 16 bitů na úhel zatočení v setinách stupně. Jednotky se mi líbí, ale … oni to vše narvali za sebe, takže v prvním bajtu je zkombinovaná rychlost s typem řazení a ve třetím bajtu je mix rychlosti a zatáčení. A aby to bylo zábavnější, tak je to Intel tj. pozpátku. Vůbec se nedivím, že jsem v tom udělal chybu. Pak snadno pošlete místo příkazu jeď pomalu dopředu něco jako „pedál až na podlahu”. Jako plus hodnotím pár vzorových příkazů v manuálu, ale … proč? Odpověd znám … prostě to tam ty nástroje nahází za sebe, ale pěkné to není.

Příklad, jak jet 5m/s

Druhé téma je User manual. RTFM, tak jsem si ho už také pročetl … a dnes jsem koukal na ten vytištěný, co dorazil s platformou a on byl jiný!!! Tiskovinu jsem lehce ignoroval, protože k tomu už potřebuji brýle a tak jsem byl spokojenější s PDFkem. Ale chyba lávky! PDFko, co mi posílali někdy koncem května, je verze 1.0 a ta tištěná varianta je V2.2.0. A ten dálkový ovladač má stejné páčky jako na obrázku i je tam zmínka o touch screen. Tak už vím, že houkačka je tlačítko zespodu vlevo … ale stejně nehouká, tak nic.

23. listopadu 2023 — Nabíječka a dálkový ovladač

Asi bych začal upřesněním, jak je to s tím ježděním a baterkou? Dva lidé to nezávisle z mého textu nepochopili, takže jsem to asi (jako obyčejně) zmátl:

baterka je stále mrtvá
robot je schopen popojet pár centimetrů, ale pouze na připojenou nabíječku!

Dnes bych si sem přihodil odkazy na datasheety:

Díky tomu PDFku k dálkovému ovladači nejen s předním ale i zadním pohledem je teď už jasné, že VRB není „pravé spodní tlačítko”, ale trimovací kolečko v rohu. A když s tím otočíte doprava a nezapomenete zamáčknuté Emergency STOP tlačítko, tak najednou robot jede (stále je zdrojem nabíječka). Tak alespoň nějaký posun.

Popis tlačítek

p.s. jo ještě jeden detail s houkačkou: The horn is optional part not including in standard platform. We reserve the key and interface for it, they won't work if the platform don't equip with horn hardware.

27. listopadu 2023 — Zbyňkovy hračky a Anderson konektory

V sobotu se stavil Zbyněk a vzal s sebou i svoje „hračky”: bezkontaktní měřák proudu, regulovaný zdroj do 60V s nastavitelným proudovým omezením, krimpovací kleště a pod. První měření bylo trojpinový konektor z nabíječky vs. obří Anderson konektory. Nabíječka tedy používá červené konektory a šedivé jsou pak pro napájení celé platformy. Jeden z pinu (no měl jsem si udělat foto počmáraného Pata) pak není zapojen vůbec, ani na kostru.

Druhé pozorování bylo, že při zapojené nabíječce a zapnuté platformě teklo kabelama cca 400mA (zase jsem si to měl zdokumentovat) protože to vypadalo, že se nějakých 100mA „ztrácí” v černé krabíčce baterky. Proudy se ale nijak nelišily ať už tlačítko baterky bylo zapnuté nebo vypnuté.

Další test byl se zdrojem a postupném zvyšování napětí … ani ťuk, nic si to nechtělo vzít. Při té příležitosti si Zbyněk všiml, že ty červené a šedé Anderson konektory jsou různé typy! Šedivý měl přepážku mezi + a - a červený nikoliv, takže i kdybych se to snažil pospojovat poslepu (nekoukal na barvy) tak by se mi to nepodařílo … za to mají u mne autoři FR07 plus (chtěl jsem řící malé bezvýznamné plus, ale to by asi neurazilo jen mé spolužáky z gymplu, protože to bylo oblíbené rčení naší třídní).

Do rozdělání krabice s černě označenými šroubky (buď plomby nebo prý že to bylo utahováno klíčem s měřeným momentem) jsme se zatím nepustili.

Zavěr — baterie je stále mrtvá.

Anderson konektory

Rozdílné přepážky

Kabel nabíječky

21. prosince 2023 — Stará baterka

Koukám, že jsem skoro měsíc nic nezveřejnil na téma Pat a Mat. Nějaké zprávy by byly, ale moc veřejné nikoliv. Ale čas utíká, takže doplním archlív.

Asi to vezmu od konce, tedy dnešního mailu, že náhradní nová baterka by už měla být na nějakém evropském letišti a čeká na proclení. Mám i DPD číslo zásilky, ale dnes se mi dokonce podařilo při dotazu dostat 502 (Bad Gateway) … zkrátka chybu na serveru … prostě vánoce. A minulých X dní tam nebylo nic zajímavého, jen potvrzení, že to číslo je pro mne. Trošku marnost.

Na druhou stranu mne včera potěšil TomášR, který došel k závěru, že není nač čekat a pustil se do nabíjecích experimentů „autorizované otevřené baterky” (aneb výrobce o tom ví a souhlasí a zajímá ho, na co přijdeme).

Nejprve již pár týdnů staré fotky:

Otevřený box baterky

BMS

1.8V = nenaformátované články

BMS

Asi nejdrsnější je ta vlevo dole - všech 75 článků dohromady mělo 1.8V!

Tento týden Tomáš poslal update: Před nabíjením měla baterka 1,819 V a na jednotlivých článcích bylo: 0,1725; 0,1277; 0,1342; 0,1176; 0,1006; 0,1203; 0,0953; 0,1289; 0,0856; 0,1371; 0,1526; 0,0895; 0,0854; 0,1474; 0,1246 V. Po pár hodinách nabíjení jsem ji dostal až na 20V, ale po odpojení zdroje to začlo hodně rychle padat. Buď je špatná BMS, nebo to číňan odfláknul. Naměřil jsem spotřebu přes 10 mA, což je úlet. Ráno měla baterka jen 4,37 V. Vypínač na spotřebu nemá vliv.

A včerejší zprává byla ještě nadějnější: ... tak už se mi povedlo probrat BMS :-) Při cca 38V na baterii BMS obživla a začla nabíjet (pulzy 1:1) a jede i CAN. Na CANu (500kb/s) chodí 3 zprávy:

0x200 0E CA 00 00 09 34 0A 8B
0x201 00 00 0A 64 00 03 00 00
0x202 C0 0A 00 01 0B B9 0B AF

p.s. ok, poslední report v tomto roce. V příloze máš tabulku s naměřenými napětími na jednotlivých člancích. Dnes už jsem se dostal, po dalších cca 7h nabíjení, prakticky na nominální napětí. Baterka už šla zapnout, ale kde je ta hranice přesně nevím. BMS povolila nabíjení někde mezi 38-39V, vybíjení myslím až tak kolem 42V. Články se už trošku srovnaly, ale zda tomu nějak pomohla BMS, nebo to je jen tím, že už se to dostalo do ploché části charakteristiky, nevím. To se uvidí až ke konci nabíjení.

Tabulka napětí jednotlivých článků

Jinak jsem koukal ještě na CAN zprávy a v 0x200 jsou první 2 byty napětí baterie a pak tam jsou asi 2 hodnoty (4 byty), ktere by mohly odpovídat stavu nabití. Nějak systematicky jsem to ale nezkoumal. U 0x201 jsem žádné změny nepozoroval. V 0x202 je asi nějaký status, jeden bit odpovídá stavu vypínače, a pak tam jsou asi zas 2 hodnoty, ale ty se moc nemění.

2. ledna 2024 — Odložené uspokojení

Potřebuji se uklidnit, tak to hodím „na papír” resp. na web.

Žena si přála pod stromeček knížku Cyrila Höschla Tak o co jde? a tak jsem v ní také listoval. Jedno téma bylo odložené uspokojení, což je asi teď už něco, co pomalu nedávám. Nová baterka byla odeslána 11. prosince 2023, letecky. Ano v nejnevhodnější čas. Mezi svátky mi to přišlo už pomalu divné, tak jsem volal na DPD. Zase zajímavá zkušenost s telefoními automaty … jediná cesta k operátorovi vede přes ignorování všech nabízených voleb. Tehdy (27/12) jsem se konečně provolal a dozvěděl se, že to je někde v Německu na letišti a dosud to není v systému. O dovolene (29/12) mi přišla SMS, že 2/1/2024 mi doručí balíček a že ho můžu přesměrovat (což by se fakt hodilo protože v cílovém místě 2. ledna nikdo nebude). Pár kliku, přesměrováno do Alza boxu za rohem a datum doručení se dokonce změnilo na Nový Rok! Mimochodem všem vám přeji vše nejlepší v novém roce. Už jsem viděl ten titulek Happy New Year/Pat's Battery 2024, ale chyba lávky. Včera nic … to jsem tak trošku očekával, bylo to podezřelé. Ale dnes také nic?! Navíc to převezli z Říčan do Uhnoště (na druhou, vzdálenější, část Prahy). A co mne už uplně vyřadilo byla hláška Your parcel was returned as you refused to take delivery. F* … to už se opravdu neovládám. Zítra bych Prahu opustil a přesunul se na místo, kam měli dodat balíček původně … no hlavně klid, je třeba trénovat odložené uspokojení. Tak alespoň vzpomínka na poslední západ slunce nad jezerem v roce 2023 — fakt to stoji za to se zbytečně rozčilovat?

poslední západ slunce v roce 2023

3. ledna 2024 — Konec srandy - baterka je zpátky v Německu!

No dnes bych to nazval spíše jako deprivací. Ráno jsem volal na DPD a paní mi v klidu řekla, že balíček poslali zpět odesílateli?! Dokonce se musela zeptat, jestli tam ještě jsem, protože jsem fakt nevěřil tomu co jsem slyšel. F*, musel jsem do práce a pak tam volal znova a dozvěděl se, že je tam poznámka, že se to má prošetřit. Chudáka bráchu jsem poprosil, ať se staví v Unhošti, protože bych to tam do 18h nestihl … a balíčk byl fakt pryč. V českém trackovacím systému už je jen info, že se vrací, ale alternativní německé mi ukázalo tento obrázek:

Zpátky v Německu

Nějaké dotazy? Mimochodem Alzabox je v tom nevinně — nějaký nováček prý místo přesměrování na Prahu 10 kliknul na vrátit odesílateli … také by vás zajímalo, proč to tedy neřeší?! Možná je čas vypsat kurzy jestli ti borci to pošlou až zpátky do Číny … jó, pěkně ten 2024 začíná.

p.s. 04.01.2024 10:22 Your parcel has been delivered successfully Kelsterbach, DE

11. ledna 2024 — Vzkříšení

Nevím proč, ale první asociace se vzkříšením je zase Vetřelec. Dnes to bude „pro změnu” kryptické, aneb viz github. Nechci mluvit o nové baterce (ta je ztracená někde v Německu a když jsem dnes znova volal DPD, tak řekli ať zavolám za týden, že to začnou prošetřovat jako ztrátu), ale o staré baterce, kterou TomášR několik týdnů křisil. A ano, dnes jsem poprvé po dvou měsícíh, co Pat dorazil, popojel na baterku! Musel jsem si zase otevřít čínský manuál (ano anglický, ale asi automaticky překádaný), protože robot popojet nechtěl (zatočit to ano). Brzda, vypnout automatiku, zařadit D, odblokovat STOP tlačítko … a pak jel. Po pravdě mne přepínání jízdy dopředu D a dozadu R trošku rozčilovalo, ale to bude tím prostorem (na diagonále jsem v předsíni získal cca 0.5m).

Na konektorech nic nenaměříte, pokud není baterka puštěná, tj. stiské tlačítko. Po zapnutí na obou vyskočilo 49V. A ukazuje to jak dálkový ovladač tak CAN (mimochodem zprávy, co posílal CAN baterky/BMS na robotovi dostupné nejsou). Nechal jsem to běžet cca 15 minut (v přesíni byla kosa a v kuchyni zamrzala voda, pokud jste jí tam chvíli nechali ležet, tj. úplně ideální podmínky to na testování nejsou).

Voltage 49.63 0.0 26.3
Temperature 15.0 16.0
…
Voltage 49.41 0.0 26.3
Temperature 13.0 15.0

To napětí kleslo cca o 200mV a baterka si myslela, že teplota je nějakých 14 stupňů (reportuje min a max, ale nevím, zda to mezi jednotlivými reporty resetuje). Ano, zase bych šťoural do toho kódování teploty s rozlišením 0.1 stupně Celsia/bit uložených v 12ti bitech. V realitě to je zase s rozlišením ve stupních, takže kdyby to hodili do bajtu, tak +/- 120 stupňů C by snad stačit mohlo … no nic, aspoň trošku rébus. Když je v jednom měření nybble A a zbytek nuly a v jiném 9 a 6, jak to může jít po sobě? Moc skočit to nemůže a maximum 1 stupeň je nějak málo a tak 0xA0 = 160 a 0x96 = 150. Vyřešeno.

p.s. Tomáši, díky moc!

19. ledna 2024 — Nová baterka!

Dnes v 15 hodin CET dorazila nová baterka! Byl jsem z toho trošku na nervy, když zmizela v Německu a po pravdě nevím, jestli jí nakonec odchytli tam, nebo to šla až do té Číny. Skoro si říkám nemusím vědět všechno (aneb snad to ani nechci vědět).

První pozorování — při vypnuté baterce naměřím 11.3V?! Stará baterka (po renovaci) tam má 0V, ale asi to za chvíli znova prověřím. Dobrá zpráva ale je, že při zapnuté baterce (ono je to snad pouze informativní tlačítko pro BMS) naměřím 49.3V.

Jinak je ještě několik zpráv, ale ty asi nechám až po víkendu. Minulý víkend jsem si rozchodil popojíždění přes CAN od X metrů (v mém případě centimetrů) tam a zpět, ale nevyhecoval jsem se k vyklizení cesty z předsíně, sezení na verandě a v kombinaci s nájezdy abych v lehkém mrazu vyjel tuto feature demonstrovat na zahrádku. Ona priorita byla trošku jinde (aby neuletěla střecha na přístřešku, časem snad i pro Pata) a … lenost.

Dále jsem se snažil zprovoznit prastarého ALIXe. Ano, je to "vykopávka", ale stejně jsem přesvědčený, že sběr dat a jednoduché follow me by to dát mohlo/mělo. No byl tam ještě Python 2.6 a ani se to nechtělo bavit s GitHubem, kvůli starému ssh (jestli jsem to pochopil dobře). Od Jakuba mám půjčenou novou "hračku", ale o tom asi více až uřídí popojetí 1 metr.

Komentáře (1)

1/19/24, 18:38 Ahoj. Když to ale je vypnuté, tak tam naměřím 11.3V? To bude jen svod MOSFETu. Pokud jsi to měřil digitálním multimetrem, tak ten má velký vstupní odpor, takže i malý svod vyvolá měřitelné napětí. Většinou mají multimetry vstupní odpor 10 MOhm, což by odpovídalo proudu 1,1uA a to je akceptovatelná / očekávatelná hodnota. T.

20. ledna 2024 — Pat nemá rád sníh

Dnes vystoupila teplota až na 0 stupňů Celsia, svítilo sluníčko a tak jsem se vehecoval (odsunout záchod, přestěhovat betonovou lavičku, přerovnat dřevo u baráku, vybalit nájezdy) a vyzkoušel Pata venku. A rovnou mne udeřila mezi oči stará hláška: Test First! Aneb nemá velký smysl připravovat něco komplikovaného, když i „ujetí jednoho metru” může selhat. Ano, tento výsledek jsem úplně nečekal, takže test byl úspěšný, míněno užitečný, a možná jsem se k tomu měl opravdu rozhoupat už před týdnem.

Nájezdy a výjezd z chaty

Poprvé na sněhu

Pohled zezadu

Pat neujel ani ten metr, ani na dálkové ovládání. Pociťoval jsem marnost, jako když jsem cca před měsícem zapadl na louce se Sharanem a nemohl vyjet. Holt 4x4 to není a to samé platí i pro Pata. Pokud jedno kolo bylo ve vzduchu, tak to bylo to co se točilo. A pokud podkluzovalo, tak to samé. Zvláštní bylo, že při couvání podkluzovalo zase to druhé kolo. A chvílema jsem měl pocit, že změnou zatáčení se roztočilo druhé kolo?! Jako by tam byly dva motory … ale nejsou. Nevím, jak přesně funguje ten diferenciál, ale tady nepomáhá. A ano, jak na začátku mi říkal HonzaR, ty hladká kola kloužou fakt hodně.

Další (vtipné) pozorování bylo, že jsem špatně pochopil manuál:

SWC for S4 rocker high school low-speed control mode, to forward gear, for example: SWC is at the top of the S4 rocker control the vehicle's highest speed for the low-speed mode driving; SWC is in the middle of the position when the S4 rocker control the vehicle for the medium-speed mode driving; SWC is in the bottom of the position of the S4 rocker control the vehicle for the high-speed mode driving.

Asi jediná zřejmá poloha je in the middle. Ale co je nahoře a co dole? Jako tak jak se to chová mi to dává smysl. Řekl bych, že mne zmátla věta: If the SWA/SWB/SWC/SWD toggle switches are not in the default position when powering on, an alarm interface will appear, prompting you to toggle all switches to up, and enter the main interface normally when all switches are in the default position. Tj. up je … mají to dobře, jen se naučit číst! Tak jak jsem popojížděl v předsíni s 20cm místa vpřed a vzad, tak jsem to měl samozřejmě na high-speed driving. Hmm, tak ta maximálka je (pro autonomního robota) celkem rozumná a na startu musí být páčky s nejmenší povolenou rychlostí.

10. února 2024 — Odyssey a 3x USB

Uznávám, že tu dokumentaci nějak flákam. Jsou to sice převážně drobnosti, ale z čeho jiného se skládá život (robota)? Dnes jsem s Patem chvíli jezdil venku „autonomně”. Bylo to jednoduché osgar.go s opakováním 10x na jízdu 1m tam a zpět. Nejprve jsem jezdil rychlostí 0.1m/s (jako v předsíni) a pak to zvedl na 0.5m/s (při pomalé jízdě měl na chodníku občas problém a zastavil se). Snažil jsem se to i nahrávat, ale úplně chápu Jirku, že natáčet na mobil, mít v ruce notebook a bezpečnostní dálkové ovládání nějak dohromady nejde. Ale jako důkaz viz video. Pokud si pustíte i zvuk, tak poznáte, že náš pes moc robota rád nemá.

A teď tedy k názvu dnešního příspěvku. Odyssey je malý počítač, který mám zapůjčený od Jakuba. Jedná se o ODYSSEY-X86J4125800. Studenti tam předinstalovali Ubuntu 22.04 a výkonově je na tom asi 10x lépe, než starý Alix, kterého jsem chtěl použít na logování dat. Od TomášeR mám napájecí kabel, takže jede na 12V z robota (k dispozici je ještě 24V, což plánuji pro VanJee lidar, a 48V).

Odyssey má 3 USB porty, které jsem velmi rychle zaplnil — pro řízení robota potřebuji USB-CAN převodník (PeakCAN), na detekci překážek jsem tam dal OAK-D kameru a do zbylého portu zapojil starou USB GPS. Hodilo by se mít ještě couvací kameru, 2x Pozyx majáčky a možná i SSD disk na ukládání dat … prostě brzy dojde na USB hub.

S ovladačem na PeakCAN jsem trošku zápasil a když už to fungovalo, tak jsem přidal OAK-D kameru a „rozbilo se to”. Ale nebylo to kamerou, ale (za tento hint díky moc týmu Robotika ) kvůli automatickému upgrade kernelu na pozadí! No kdybych mohl, tak bych ten vychytralý SW nejraději do toho pozadí nakopal. Jakub to komentoval: xubuntu by nemělo být tak arogantní jako ubuntu … tj. na Odyssey je asi to xubuntu, ale stejně. Prostě je to připojené na wifinu a dále na internet, tak co by si to nestáhlo nejnovější aktualizace?

Z náhodných kopii textů z terminálu je změna vidět:

2024-01-27
Leaving directory '/usr/src/linux-headers-6.5.0-14-generic'
vs.
2024-02-02
- manually installing pcan under /lib/modules/6.5.0-15-generic/misc…

… ono vlastně přeinstalování pomohlo — znova se ten samý driver nakopíroval, ale do jiného adresáře.

2. března 2024 — Pat follows Path

Je to bída! Dnes jsem si raději prohodil priority, abych se ke hraní s robotem vůbec dostal. :-( Ostatní přistávají na Měsící a já ještě ani pořádně nepopojel. Ale postupně — dnes už robot „sledoval cestu” (čistě z odometrie) a sbíral data. Stále jsem nepřimontoval ten VanJee lidar takže získaná data nejsou úplná. Také mám už cukání „slanit” ze svahu a pohybovat se dole na louce na řádově větším prostoru. Snad brzy.

Nahrávky byly pouze z robota, takže co mám je např. unlisted video, kdy robot projíždí mezi kuželama. No styděl jsem se to dát public, tak snad na to nemusíte ani klikat. … ale reálná data na detekci kužele to jsou.

p.s. přidal bych i nějaké pohledy z lidarview (alespoň trajektorii), ale zase se mi tu něco updateovalo a pygame nejede bez restartu … někdy přístě …

24. března 2024 — Navigace na kužel

MartinL se nechce veřejně pochlubit, jak s Rocker robotem jezdil před 14ti dny U-čko a během 15minut jízdy ujel cca 200m, a já tady mám vytahovat, jak se Pat horko těžko 20 sekund navigoval ke kuželu?! Ale nechť, za mne nějaký postup je:

Detekce kuželu a integrace VanJee lidaru

Obrázek je z lidarview.py, který jsem hackoval, aby zobrazoval i nové detekce z OAK kamery. Zobrazen je i VanJee lidar pro úhly 0 a -10 stupňů a je například vidět, že vodorovně (světle zelené body) kužel detekován vůbec není!

Mezi nové poznatky patří:

nutnost odolnosti vůči dešti (když jsem měl konečně chvíli na testování, tak každych 10 minut pršelo a to jsem pořádně ani nestihl vyjet z předsíně)
externí WiFi anténa — ona tam nějaká je, ale když je robot už 10m od chaty, tak se spojení ztrácí (jedu přes společné AP s přístupem na internet). Asi nejzábavnější bylo, že robot klidně vyjel (má se rozjet až když detekuje kužely), ale na obrazovku žádné detekce nevypisoval … protože výstup na konzoli byl výrazně opožděn
chtělo by to něco jako rozvodovou skříň, tj. když zapnu robota, abych s ním kousek na dálkové ovládání popojel, tak nepotřebuji rovnou pouštět lidar a počítač

Pak ještě jeden „staronový” aneb, že ta OAK-D Pro varianta hrozně žere místo (došlo mi i místo na notebooku, takže půlku logů jsem si ještě nestáhl):

(osgar) md@md-ThinkPad-P50:~/git/osgar-apps$ python -m osgar.logger
                   /data/pat/2024_03_24/cones-challenge-240324_161328.log
 k                    name     bytes | count | freq Hz
----------—-
 0                     sys    762653 |  9159 | 159.4Hz
 1    app.desired_steering      6220 |  1428 |  24.8Hz
 2            platform.can    116909 |  6877 | 119.7Hz
 3 platform.emergency_stop         1 |     1 |   0.0Hz
 4         platform.pose2d     12561 |  1428 |  24.8Hz
 5                 can.can    622914 | 36642 | 637.6Hz
 6               oak.depth 274503824 |   536 |   9.3Hz
 7               oak.color 514189468 |   536 |   9.3Hz
 8    oak.orientation_list    294234 |   534 |   9.3Hz
 9          oak.detections     28147 |   535 |   9.3Hz
10           oak.depth_seq      4440 |   536 |   9.3Hz
11           oak.color_seq      4440 |   536 |   9.3Hz
12      oak.detections_seq      4431 |   535 |   9.3Hz
13            gps.position       638 |    58 |   1.0Hz
14          gps_serial.raw     19687 |  2894 |  50.4Hz
15              vanjee.raw        36 |     1 |   0.0Hz
16              vanjee.xyz         0 |     0 |   0.0Hz
17             vanjee.scan   2339649 |   573 |  10.0Hz
18           vanjee.scan10   2601617 |   573 |  10.0Hz
19           vanjee.scanup   2316595 |   573 |  10.0Hz
20          vanjee_udp.raw  12716052 |  9169 | 159.6Hz
21      obstdet3d.obstacle      4815 |   535 |   9.3Hz

Total time 0:00:57.466885

… 774M za necelou minutu, a to je ta kamera uměle omezovaná na 10Hz.

Teď koukám, že i ten sys je nějaký velký …

…
0:00:57.430776 0 b"{'name': 'vanjee_udp', 'delay': 57.111811, 'channel': 'raw', 'caller': 'run_input'}"
0:00:57.430979 0 b"{'name': 'vanjee_udp', 'delay': 57.113248, 'channel': 'raw', 'caller': 'run_input'}"
0:00:57.431503 0 b"{'name': 'vanjee_udp', 'delay': 57.113418, 'channel': 'raw', 'caller': 'run_input'}"

… no je to report zpoždění, ale VanJee se jenom v úvodu zapne a pak už mu není třeba nic dalšího posílat. TODO fix report

A divnosti, resp. „nedodělky”? Když už kužel nevidí, tak stejně jede vesele dál. Zastaví ho pouze překážka do 1 metru. Už to vidím:

speed, steering_angle = self.max_speed, 0
if self.last_detections is not None and len(self.last_detections) == 1:
    x1, y1, x2, y2 = self.last_detections[0][2]
    steering_angle = (self.field_of_view/2) * (0.5 - (x1 + x2)/2)  # steering left is positive

… no evidentně jsem se s tím moc nepáral a i je teď jasné, proč na dva kužely moc nereagoval. Do další verze jsem chtěl před kuželem zatáčet vlevo dokud kužel nezmizí a pak dokud se zase neobjeví. Pak už by mohl vesele jezdit mezi dvěma kužely tam a zpět. Ale to už asi do velikonoc nestihnu. :-(

7. dubna 2024 — Killer Application

Když jsem před léty poprvé slyšel pojem Killer Application, tak jsem si říkal, že je podivné, že firmy píšou zabijácký software a ještě se tím chlubí! Dnešní AI si o tom myslí toto. Zajimavé je, že je to relativně starý koncept:

The concept of a killer app has been around for decades, with examples such as the VisiCalc spreadsheet for the Apple II in the late 1970s, Lotus 1-2-3 and Excel for the IBM PC in the 1980s, and the Mosaic Web browser for the Internet in the early 1990s. These applications were so good that they provided reason enough to purchase the hardware, becoming the defining feature of their respective platforms.

Dnes ale chci mluvit o jiné interpretaci a to jak se z Pata s nevinným (14 let starým) programmem followme.py stal „zabiják”. Ale pěkně popořádku …

O víkendu jsme měli návštěvu a robot z předsíně (fakt se kolem něj nedalo skoro protáhnout) musel pryč. Ze svahu jsem se ho pustit neodvážil a došlo tedy na již „osvědčenou technologii”: vysazení zadních vrátek (v kombinaci s hárající fenou a okolo číhajících nápadníku celkem zábava, ale naštěstí si dali chvíli pauzu), vyvezení Pata na kopeček, přistavit Sharana, první test nájezdu (úspěšný) a převoz autem cca 1km dolu na spodní zahradu. Tam je o řád více prostoru, tak jsem nasbíral pár logů (cca 1GB/min). Mimo jiné i záběry mostíku, kam bych rád jednou Pata pustil samotného:

mostík pohledem z hloubkové kamery

Jako slabina „nového ubytování” se ukázala, že se tam Pat se senzory na výšku nevejde. :-( … tak jsem odšrouboval lidar, OAK-D a krabici s Odyssey deskou, vypojil hlavní, vlastně jediný, propojovací konektor s robotem (trošku mi to připomíná způsob napojení Matrixu na mozek) a bylo. Jako vedlejší (pozitivní) efekt jsem pak řídící počítač mohl zapojit rovnou do zásuvky a data si během chvíle přetáhnout.

Nicméně, byl tam i negativní vedlejší efekt na který jsem narazil až dnes. Doslova jsem si „ukradl” hodinku na hraní, sešroubuji robota, pustím pokusně follow me se zamáčknutým STOP tlačítkem a … nefunguje CAN! To už není novinka, viz pozn-240210. Prostě tím, že jsem připojil počítač z robota na internet tak neměl lepší nápad, než si zase upgradeovat jádro. :-( … jen tentokrat make install nefungovalo: /home/robot/peak-linux-driver-8.16.0/driver/src/pcan_main.c:3506:22: error: initialization of ‘ssize_t (*)(const struct class *, const struct class_attribute *, char *)’ {aka ‘long int (*)(const struct class *, const struct class_attribute *, char *)’} from incompatible pointer type ‘ssize_t (*)(struct class *, struct class_attribute *, char *)’ {aka ‘long int (*)(struct class *, struct class_attribute *, char *)’} [-Werror=incompatible-pointer-types] To jsem úplně nerozdejchal — pochopte jste s robotem mimo net, resp. pár znaků tam a zpět prošlo, ale k nějakému komfortu to mělo hodně daleko, … a wono to neumí ujet ani 1 metr?! Šel jsem místo toho oživovat po zimě traktůrek, dofukovat kola a tak …

Nový kernel 6.5.0-26 ale jde použít s nejnovější verzi PCAN driveru peak-linux-driver-8.17.0 z ledna 2024. A stejný problém je popsaný i na Peak system fóru. Cvičně jsem se pokusil změnit update kernelu na manuální, ale jestli se to povedlo, se nejspíše dozvím až na Robotem Rovně 2024 a tam to bude už bez netu.

Jelikož času až tak moc nebylo, tak jsem původně chtěl vyzkoušet něco jednoduchého a Eduro followme s VanJee lidarem už jezdilo. Po pravdě to byla jedna z motivací to nejprve na Eduru „oprášit” a rozšířit na 360 stupňový lidar — se starým SICKem to jezdilo např. před 12ti lety na Floriade 2012. A to už se pomalu dostáváme k tomu zabijákovi. Pustil jsem to, stál jsem před robotem, a ten na mne vyrazil „na plný koule”, ještě trošku upravil zatočení, aby mne opravdu trefil. F* Do konfigurace jsem dal "max_speed": 0.2 a stejně do příkazové řádky … ale to co jsem viděl bylo daleko agresivnější. Také se potvrdilo, že STOP tlačítko vzadu na robotovi je úplně k ničemu, protože to už bych měl přeražené nohy … jako u 360deg pokrytí si vás robot snadno najde. Konečně ani Ctrl+C přes problémovou síť, kdy to někdy dojde, není ta správná volba. Oni Číňani věděli, proč dálkové ovldádání nejde vypnout pokud je robot zapnutý (zatím to řeším jen vytažením baterek, protože mi přijde, že se to pere s wifinou). No nic, druhý pokus, tentokrát se zapnutým dálkovým ovladačem a Pat se zase na mne vrhl a stěží jsem stihl zareagovat … hmm.

Vysvětlení je poměrně prosté, viz followme.py:L111: speed = 0.2 + 2 * (near - desiredDistance). Na žádnou max_speed si tento stařičký kód nehraje. Jako u Edura to nevadilo, protože maximálku mělo poměrně nízko, ale pro Pata jsem pak v logu našel:

(osgar) md@md-ThinkPad-P50:~/git/osgar-apps$ python -m osgar.logger pat-followme-240407_155741.log
     -stream app.desired_speed
0:00:00.254637 1 [1334, 1650]
0:00:00.353701 1 [1340, 1680]
0:00:00.453620 1 [1346, 1740]
0:00:00.553774 1 [1348, 1800]
0:00:00.653843 1 [1332, 1920]
0:00:00.753903 1 [1274, 1920]
0:00:00.853871 1 [1202, 1830]
…

F* … 16.5 stupně vlevo, rychlost 1.3m/s … to moc nevypadá na omezení 0.2m/s … no prostě si na hračky dávejte bacha, a revolver (nebo dálkové ovládání) mějte vždy po ruce. A zapnuté. A prst na spoušti.

14. dubna 2024 — Cones Challenge v1.0 (10 minut)

Dneska to vlastně byla nuda (když to porovnávám s minulou neděli ). Pat se mne nesnažil přelámat končetiny, skoro to hned fungovalo … nějak jsem si vybavil jednak Sebastianova "nudného robota" (Sebastian Thrun) a dále komentář na RoboRace (autonomní elektrické formule), že to bude zábava jako sledovat otáčející se buben elektrické pračky. To byly moje dnešní pocity. Na druhou stranu jsem měl celou hodinu zapnuté dálkové ovládání, prst na „spoušti” (přepínání autonomní/manuální režim) a jen občas zkusil natočit něco na telefon.

Už první jízda max_speed=0.2m/s a timeout 120s dělala co měla:

pokud vidíš právě jeden kužel, naviguj jeho směrem
pokud je kužel ve vzdálenosti menší než 2 metry, zatáčej doleva (limit zatáčení)
pokud je překážka z hloubkové kamery do jednoho metru zastav

Jako bylo to tak brutálně pomalé, že stačil dojet jenom tam a zpátky.

Pro další jízdu jsem zdvojnásobil rychlost na 0.4m/s a trošku posunul kužely ať robot jezdi „skoro po cestě”. A přestalo to fungovat. Na videu je vidět, jak jezdí dokolečka místo aby jel zpátky na první kužel.

Moje první teorie byla, že nestíhá detekovat kužely a že vlastně jede podle starého záznamu videa. Proto jsem ho občas pozastavil na dálkovém ovladači „aby se chytnul”. Někdy to fungovalo, někdy ne. A kde byl zakopaný pes? Mimichodem ten štěkající pes v tomto videu není náš, ale souseda naproti … asi robot Pat opravdu u psů není oblíben. V tom algoritmu výše chyběl detail, že když začně točit, tak na nějaký čas kužely ignoruje (aby náhodou nenavigoval znova na ten samý) a jakmile pak kužel detekuje, tak se k němu vydá. Jen ten ignorační čas byl trošku dlouhý = 20 sekund (viz 28eb0af). Pro rychlost 0.2m/s asi nutnost, ale pro vyšší nepoužitelné!

Aby to bylo více akční, tak jsem postupně zvyšoval rychlost (pomocí -param app.max_speed=0.7). Ale tím jsem se sám chytnul do vlastní pasti, kdy po minulém zážitku jsem dal SW speed limit přímo pro samotnou platformu (viz PR #987). Pokud si chce programátor nově zahrávat s „nebezpečnou rychlostí”, tak je třeba změnit i limit platformy, tj. -param app.max_speed=0.7 platform.max_speed=0.7. Skončil jsem u 1m/s, ale stále to vypadalo jako ta automatická pračka … viz poslední video.

Timeout jsem dal jen 10 minut — on by si rozhodčí stejně stěžoval, že ty kužely nejsou dostatečně daleko a možná by měl i jiné námitky. A také chci dát šanci ML, protože příští víkend se k tomu nedostanu. A po pravdě, když jsem se pak u té 10 minutové jízdy nudil, tak jsem kužely začal posouvat až na konec cestičky … a nefungovalo to. Proč bych měl zjistit z logu, ale zda se, že přes WiFi to dnes ani všechno nestáhnu (6.3MB/s a např cones-challenge-240414_145616.log má 9.1GB, zhruba 1GB/min, s tím budu muset také něco udělat). Co bylo v logu tedy až „někdy příště” …

OAK-D zvednut na 10 stupňů pro lepší výhled

Pat zatáčí při detekci kuželu na dvou metrech

p.s.

Odometrie 10min - cones challenge v1

2. května 2024 — 4 kužely CCW

Včerejší prvomájové testování byla dost tragédie. Nejprve nefungoval CAN driver (jádro se posunulo na 6.5.0-28, takže bych možná tady v textu našel, že bývalo starší). Tj. blokace automatického upgrade evidentně nefungovala a možná jsem to navíc trošku rozbil, když jsem se snažil nainstalovat ros2, ale o tom až někdy jindy. V plánu mam „přetrhat všechna spojení na internet”, wifi změnit na Access Point (to byl druhý problém, že jak se vše zazelenalo tak už jsem nebyl schopen se za potokem připojit) a vyhrazený statické IP na zbyly Ethernet port. Zůstal mi krátky červeny Ethernet kabel, takže už barva naznačuje jen v krizových situacích.

čtyři kužely

A co to tedy mělo dělat? Místo dvou kuželů jsem na zahradu dal čtyři a změnil v kódu podmínku, aby místo akceptace pouze jednoho jediného detekovaného kuželu to pracovalo i vícero ve výhledu. Navigovat se měl jenom na ten co vidí vpravo, takže v kombinaci se zatáčením vlevo měl jezdit do obdélníku proti směru hodinových ručiček. Když to byl právě jeden kužel, tak to byla skoro jistota, že je to ten pravý — teď do hry vstupují i různí „duchové”, ale po pravdě jejich vliv jsem moc nezaregistroval. Co se zase rozbilo bylo to 3s otáčení naslepo. Proč? Začínal jsem rovnou na rychlosti 1m/s, ale teď se už neměl otáčet 180 stupňů, ale pouze 90, takže by stačil i poloviční čas, kdy detekci kuželů ignoruje. A bylo to často přesně na hranici o zlomek sekundy, takže řešení to snížit na například 2s by to „řešilo”, ale asi už bylo dost tohoto hacku. A hlavně pak nedetekuje nic a také nic nedělá, což mne asi trápí více.

vybírej "ten pravý"

Co jsme se bavili s Jirkou před týdnem, tak je na čase začít kužely mapovat a vylepšit odometrii (viz minulý příspěvek, že ta odometrie z enkoderů na zadních hnaných kolech není úplně ideálni). Včera jsem jezdil i na „sousedním políčku”, které nám rozvrtali divočáci, a tam je krasně vidět, jak to v jednom místě pravidelně „ustřelí”, když je jedno z kol ve vzduchu (ano, Pat stále jezdí bez nákladu).

Jumping odometry

p.s. tak alespoň jedno unlisted video

p.s.2 PS píše: ... nicméně, jak jsem to tak četl, napadl mě námět na velkofilm "Pán robotů: Čtyři kužely"

6. září 2024 — Push me!

Vypadá to, že se tady nic 4 měsíce (!) nedělo, ale on v mezičase byl Pat na Robotem Rovně a později s Cogito na ELROBu …

A s ELROBem a kategorií Mula to vlastně i souvisí. Tam je úkolem nejprve robota provést z A do B, a pak už robot mezi těmito dvěma místy jezdí sám. A pravě ta úvodní follow me fáze je „taková divná” — opravdu se chcete „procházet” před několikatunovým transportérem? A stále se otáčet, jestli jede za vámi jak má? Případně zda nemáte popoběhnout?! Nebylo by lepši se v klidu procházet ZA ROBOTEM a jen ho lehce navádět, kam má jet? Jednak robotu nebudete překážet ve výhledu, aby si mohl v klidu trasu mapovat pro cestu zpět, a dále ho budete mít „stále na očích”. Tolik teorie.

Ano, lehce jsme se hecovali, že to nebude fungovat, ale … viz video. Trošku mi to připadá jako „nahánění dobytka” … honák je vidět jenom na lidarovém scanu.

Push Me log v lidarview

Jak to nejsnáze implemntovat? Jelikož má Pat 360 stupňový lidar, tak stačí ho virtuálně otočit o 180 stuňů. Pak si začne myslet, že osoba vlevo za robotem je vlastně vpravo před robotem. A zbytek už je staré dobré follow me. Ano, bude to chtít ještě „doladit detaily” jako rozumná vzdálenost od robota, zda místo kruhu spíše nevzít v úvahu obdélníkový tvar robota a počítat vzdálenost od okrajů robota a pod. Je to jen malý krůček, ale možná správným směrem.

20. řijna 2024 — Cones Challenge v1.1 (1h)

No myslím, že by mi to porota neuznala, ale aspoň jsem si trošku zajezdil. Koukám, že před půl rokem (!?), to je fakt hrůza jak ten čas utíká, jsem první pokusy nazval v1.0, tak nechť toto je drobný „upgrade”, i když na rovinu je to spíše „downgrade”.

První změna, co jsem včera hacknul, bylo vypnutí detekce překážek … to jako není 2x dobrý nápad a udělat to pořádně je už staré TODO. Další změna byla, že do zatáčky jede robot pomaleji, aby měl šanci detekovat druhý kužel. Měl jsem tam 1/4 rychlosti pro jízdu rovně, ale to se otáčel tak pomalu, že na místě rozrytém divokými prasaty to nedal. Změnil jsem to na 1/2 rychlosti jízdy rovně, tj. rovně jel 1m/s a do zatáčky 0.5m/s.

chybná detekce kuželu

Třetí úprava byla k částečnému odstranění falešných detekcí — když jsi při zatáčení viděl kužel a zmizel, tak pokud se do 2s neobjeví, tak pokračuj v zatáčení. Něco v křoví mu stále ten kužel připomíná, tak je to taková obezlička bez přetrénování. No a konečně jsem, letos asi naposledy, posekal trávu a kužel na cestě dal na přepravku, aby byl lépe vidět … no podvodník, co vám budu vykládat.

A výsledek?

$ python -m osgar.logger /data/pat/2024_10_19/cones-challenge-241019_144119.log
 k                    name      bytes |   count | freq Hz
#########################################################
 0                     sys   52096485 |  615709 | 160.0Hz
 1    app.desired_steering     570208 |   96194 |  25.0Hz
 2            platform.can    7850481 |  461793 | 120.0Hz
 3 platform.emergency_stop          2 |       2 |   0.0Hz
 4         platform.pose2d    1150680 |   96194 |  25.0Hz
 5                 can.can   41867447 | 2462791 | 639.9Hz
 6               oak.depth 3361803388 |   38442 |  10.0Hz
 7               oak.color 1362172191 |   38442 |  10.0Hz
 8    oak.orientation_list   21182093 |   38443 |  10.0Hz
 9          oak.detections    1241670 |   38442 |  10.0Hz
10             oak.left_im          0 |       0 |   0.0Hz
11            oak.right_im          0 |       0 |   0.0Hz
12           oak.depth_seq     410302 |   38442 |  10.0Hz
13           oak.color_seq     410302 |   38442 |  10.0Hz
14      oak.detections_seq     410302 |   38442 |  10.0Hz
15         oak.left_im_seq          0 |       0 |   0.0Hz
16        oak.right_im_seq          0 |       0 |   0.0Hz
17            gps.position      41221 |    3847 |   1.0Hz
18        gps.rel_position          0 |       0 |   0.0Hz
19           gps.nmea_data     704286 |    3847 |   1.0Hz
20          gps_serial.raw    1289847 |  199932 |  51.9Hz
21              vanjee.raw         36 |       1 |   0.0Hz
22              vanjee.xyz          0 |       0 |   0.0Hz
23             vanjee.scan  171430988 |   38481 |  10.0Hz
24           vanjee.scan10  200877685 |   38481 |  10.0Hz
25           vanjee.scanup  172092665 |   38481 |  10.0Hz
26          vanjee_udp.raw  853982871 |  615706 | 160.0Hz
27      obstdet3d.obstacle     345969 |   38441 |  10.0Hz

Total time 1:04:08.792693

… prostě hodinu jezdil dokolečka. Ty poslední čtyři minuty (cca) jsem ho přepnul na manuál a přejel ručně k „domečku”, ale jinak jsem do toho nezasahoval.

stav po hodině ježdění

vyjeté koleje

Zajimavé mi přišlo „rozpoložení testera” — cca prvních 15 minut jsem seděl a koukal, jak to jezdí. Pak jsem robota nechal jezdit samotného a vozil vedle dřevo. Pak jsem si říkal, že to není úplně dobrý nápad ho nechávat bez dozoru, a že bych měl oprášit tu bezpečnostní kameru. Netriviální čas jsem se jí snažil přidělat a vzpomenout si, jak se ovládá (možná vhodný okamžik zamergeovat do OSGARa. Konečně jsem si notebook vzal s sebou a koukal na video blíže k wifině (ale kdyby se něco stalo, tak stejně robota nezastavím). Pokud nic, tak pro změnu narostl seznam co by bylo dobré vylepšit/posunout:

automatické sledování robota
automatické vypnutí robota v okamžiku divného chování
alarm, pokud robot zmizí

Za včerejšek tedy alespoň dvě mizerné videa z bezpečnostní kamery, kdy jsem nahrával VLC Media Playerem a jak kamera, tak můj notebook neměly ideální wifi signál (stahování nahrávek z tapo kamery jsem také ještě nerozchodil):

https://youtu.be/qqk2YCMZr4w — Pat Cones Challenge 2024-10-19
https://youtu.be/jC8XLQK5u6M

A co dál? Chtěl bych zkusit noční jízdu, ale u prvního pokusu OAK kamera neviděla vůbec nic! Doporučení bylo používat levou a pravou černobílou kameru, ale to se mi zatím nějak popralo s detekcí na barevné kameře.

A plán B je natrénovat nějaký zajímavější okruh — jj, už jsem si ho vyhledl, jen zatím nevím jak to naprogramovat. … a možná by byl dobré ho také trošku prosekat.

p.s. pro úspěšnou misi jsem Pata naložil — myslím, že je to 70 litrů (?) kompostu, který pak žena hledala

p.s.2 je divné, že ta videa jsou bez zvuku

p.s.3 důvod ukončení předešlého pokusu cones-challenge-241019_143752.log:

překážka v cestě ...

... nerozumná!

30. července 2026 — Update systému, LIDAR road

Dnes probíhala příprava na soutěž Dobývání hradu 2026, ale po pravdě nevím, kam si těch pár interních poznámek napsat … tak sem (po dvou letech).

Přešel jsem na uv, stejně jako u většiny dalších projektů. Nejprve se to zaseklo na DNS (skoro, jako bych byl v práci) — Pat je defaultně Access Point a jeden Ethernet je natvrdo nakonfigurovaný pro VanJee lidar a druhý byl se statickou IP adresou 192.168.1.44 (až to budu někdy hledat). Změnil jsem to tedy na automatickou a připojil do domácí sítě.

Druhá kolize bylo klasicky audio — Failed to build `pyaudio==0.2.14`. Slepě jsem následoval cestičku vyšlapanou Mattýskama a nakonec to nainstalovat šlo, kde to myslím uv prostředí pro Mattyho. Chyběl ještě python-can, který jsem měl dříve ve verzi 4.2.2 a nyní je aktuální 4.6.1. Jj, následky si později ponesu sám.

Večer jsme potřebovali zajet nakoupit (39.5C ve stínu na parkovišti) a asi se mi nějak „zavařila hlava”, že po návratu jsem neodolal nutkání posunout dál LIDAR Road experiment. Koukám stále na data z Tuláka 2026 a ta asfaltka mi přišla krásně hladká (i na datech z LIDARu). Brute force myšlenka byla použít obyčejný np.diff, tj. rozdíl po sobě jdoucích měření ve scanu a nastavit si masku na True pokud ten rozdíl je v nějaké toleranci (používal jsem 10 = 1cm). Mám nějakou představu o šířce cesty (fakticky nevím, ale teď už bych to měl být schopen spočítat) a tomu odpovídá „okno” dané velikosti. No a když s tím oknem projedu celý ten diff, tak maximum je cesta, nebo ne?

kompletní scan diff

… ale pokud zoomujete na střed (ty dva „hroty” je válec na Matty M03, který jel jako Patův předvoj) …

zoom detail diff

… a po nasazení hrubé síly a zobrazení detekce cesty pro 100s z toho vypadne:

detekce hladké cesty

Až na jeden „úlet” pěkně, nebo ne?

Podle hodin bych už měl jít spát, ale to bych pak nezapsal noční pozorování:

byla skoro tma, takže když jsem vytahoval GPS modul s anténou, tak se mi podařilo utrhnout WiFi anténu na robotovi
záložní Eth port jsem měl přepnutý na auto a DHCP, takže mini router od Franty z DTC2 jsem u sebe neměl (a teď jsem ho našel)
fungoval WiFi extender, který má i vývod pro Ethernet … spojení navázáno
robot po CANu nějak komunikoval, ale nepopojel ani kousek … podle dat měl zatáčet, ale to jsem ve tmě neviděl
přehrání dat z CANu je podivné:

python -m osgar.replay -module platform /data/pat/pat-follow-matty-260730_193542.log -v
original args: b"['/home/robot/git/osgar/osgar/record.py',
                  '/home/robot/git/osgar/config/pat-follow-matty.json',
                  '-duration', '20', '-note', 'can 4.6.1, na robotu']"
0:00:00.633822 Emergency STOP False
0:00:00.633822 Error status: 3100000000
0:00:00.633964 Vehicle mode: 2
0:00:00.635015 Bumpers 0
0:00:00.660346 Error status: 2100000000
0:00:00.660529 Vehicle mode: 0
Voltage 49.68 654.86 19.39
Temperature 30.0 30.0
0:00:00.690230 Error status: 2000000000
0:00:00.700621 Error status: 0000000000
Voltage 49.68 654.86 19.39
0:00:00.783830 !!! LOST PACKET !!! 0x18c4e2ef 112 113
Temperature 30.0 30.0
Voltage 49.68 654.86 19.39
0:00:00.884276 !!! LOST PACKET !!! 0x18c4e2ef 128 129
Temperature 30.0 30.0
Voltage 49.67 654.86 19.39
0:00:00.984037 !!! LOST PACKET !!! 0x18c4e2ef 144 145
Temperature 30.0 30.0
Voltage 49.67 654.86 19.39
0:00:01.084781 !!! LOST PACKET !!! 0x18c4e2ef 160 161
Temperature 30.0 30.0
Voltage 49.67 654.86 19.39
0:00:01.183172 !!! LOST PACKET !!! 0x18c4e2ef 176 177

… každý 16tý packet se ztratí … že by ta nová verze python-can?!

Hmm, ještě koukám na data z Tuláka (pat-follow-matty-260614_125805.log) a tam je teď výpadků řádově méně. Ještě jeden rozdíl je, že si nově ukládám i scan5 (cestu plánuji detekovat primárně z scan10, tj. ten co kouká dolů pod úhlem 10 stupňů), tak jestli zase nedrhne zápis? Čas na :null expriment? Zítra.

kontaktní formulář

OSGAR

2018-10-21T00:00:00Z

Content

21st October, 2018 — OSGAR v0.0.1 released!

The OSGAR package was released today for the first time — see https://pypi.org/project/osgar/. It contains the basic functionality for logging of various data sources together with replay feature. This initial release supports John Deere and Spider3 (both quite uncommon, I am afraid), but more will come soon, I hope. If you would like to try it on your robot, please let us know. The step 1 is to describe your inputs and outputs (both the devices configuration as well as the communication protocol used).

You can give it a try:

python3 -m pip install osgar

26th March, 2023 — Web refactoring

Note, that there was a "minor" web refactoring as OSGAR was further developed (mainly for DARPA Subterranean Challenge). The original page was split into 3 and we will track them separately:

April 14, 2026 — OSGAR release 1.0.0 (powered by AI)

The worst thing about this website is that you can clearly see what you haven't touched for "years"! Or now I'm surprised that the last OSGAR update was almost exactly a year ago, when students at CZU were preparing Matty M02 for the Field Robot Event 2025 competition in Italy … it was not. But what I smiled at last year among the students, "a year later", I myself am fully using — yes, we are talking about programming with "AI flashlights". I confirm that the turning point has already occurred and it is not a waste of time to involve AI in programming.

So what does it look like? First of all, a new OSGAR release 1.0.0 was created! I wouldn't exactly call it a CD (Continuous Deployment), because there was a 5-year gap. And little motivation, because nowadays it's common to install Python ..packages'' directly from github. Of course, it wasn't without hiccups like, what on earth was my PYPI password?! Yes, I found in my email that I had reset it just five years ago, but it doesn't work anymore. PYPI requires two-factor authentication and verified email. It took about a month (hit tagged March 16, 2026), but it's there. And on top of that, there are nice pictures of robots, which somehow didn't work before??

I'm using the same name for the AI as I did in the competition a year ago, i.e. Elena.

News? So far, probably primarily documentation:

Kapathy (v2026Q1) said that today it is necessary to write documentation primarily for AI agents, that humans will no longer read it, but maybe even the machines will appreciate it?

p.s. auto-translated via https://translate.google.com/

July 21, 2026 — OSGAR release 1.1

Yesterday I put pypi OSGAR 1.1.0 on. The primary motivation was the "trauma from the past" when I didn't update OSGAR for 5 years and it was very difficult for me to log in again and release a new package. However, it's been 3 months and some little things have accumulated during that time. It's worth noting that I've already removed powered by AI from the title or what isn't it today? And yes, Elena Ai assisted with almost everything.

What's new? I'll take it partly from the automatically generated changelog on GitHub combined with changelog from Elena … however, this is my own.

osgar.logger --config … this is such a small thing that now even osgar.logger works with configuration. For osgar.record it is a necessity (specification of what should be recorded), for osgar.replay it is sometimes a useful option to recalculate data and now osgar.logger returns JSON configuration stored in logfile to the config parameter
osgar.replay --params … for osgar.record it is quite convenient to enter changes directly on the command line without changing the configuration, where the applied changes are also saved to the logfile, e.g. app.max_speed=0.2 for safer slow driving during the first testing. For playback, this makes sense, for example, when generating module outputs for variously set limits
osgar.replay --draw XXX … this function in the commercial version of OSGAR (RIGIDS) was long ago for quick visualization of various data that are part of the module calculation, e.g. speed, heading, encoders for a given robotic platform
modifiers :gz :null … now you can change the default setting in the code in the JSON configuration whether the given data stream should be automatically gzipped or discarded (:null). In OSGAR, the default is to save everything and there are a few exceptions (e.g. data from the depth camera), which are packed by default (depth:gz).
LogReaderEx … it annoyed me how we keep converting the indexes of individual outputs and then deserializing them, when it is always needed except for complete exceptions?! So LogReaderEx solves this and is named differently for backward compatibility.

Cleanup and documentation

Don't take this to heart, but Elena spent some time on it. Deep Dive for OSGAR Developers was created (it was after the release of OSGAR 1.0.0, but I can see the link there already), I deleted the subt folder, developed more than five years ago for the DARPA Suberranean Challenge (yeah, that hurt a lot, but I actually just moved it to _deprecated, but I'll really delete it someday).

Drivers and platforms

Probably the biggest improvement is with DepthAI v3 support (tested with 3.6.1) — in addition to newer models, it is the ability to run multiple models simultaneously (e.g. path detection and YOLO object detection), superblob (precompiled network for different number of cores/shaves) and also support for models for path segmentation.

A small thing is the driver for the small drone Tello — a few years old, just slightly dusted and merged into master.

Also newly added is the Ouster LiDAR SDK driver and a modification of the VanJee driver to return all 4 scans.

And that's about it in a nutshell, for details see the mentioned changelog.

p.s. auto-translated via https://translate.google.com/

Bird's Eye View (BEV)

2026-07-12T00:00:00Z

Obávám se, že tento „příspěvek” bude běh na dlouhou trať, ale přijde mi škoda „nevyrazit”

Bude to tedy kusé vyprávění co mi kdy přišlo zajímavé a jednoho dne možná AI poprosím, ať z těch dílků poskládá nějaký smlysluplný článek … jestli to vůbec bude možné!

Obsah

260712 - BEV ver0

BEV ver 0

Po soutěži Tulák po krasu 2026 jsem si hrál s daty z kamer Matty robotů a přišlo mi, že ta krásná cesta by měla jít poskládat do mozaiky. Následující obrázky jsou převzaty z článku „o tulákovi”, ale rád bych v tom pokračoval a proto tento nový článek.

Mozaika 30-50m

Mozaika 50-100m

Mozaika 100-200m

Data nasdílená nemám, ale minimálně jsem dal na review AI generovaný kód. Není dokonalý, ale jako první krok za mne dobrý. V současné verzi 0 si nejprve pomocí view_bev.py naklikáte čtyři body cesty určující projekci, pak s log2imdir.py (toto asi časem přejmenuji a přesunu) vytvoříte z nahrávky adresář obrázků s krokem 0.5 metrů a přehledem pozic robota (mělo by být kamery, ale to bude až do ver1) a konečně s mosaic.py vše zkombinujete do jednoho obrázku — mozaiky.

Volba projekce v view_bev.py

Jak je mým zvykem, vzal jsem to „zkratkou” tj. když se Elena Ai ptala na popisy rozlišení, velikost cesty, umístění kamery a způsob kombinace obrázků, tak jsem vždy volil to nejjednodušší variantu. Šířku cesty jsem odhadl na 2m, i když to asi bylo více, rozlišení pixelu nechal na doporučených 2cm, pozice kamery = pozice robota (to určítě není pravda, obzvláště když se robot kroutí) a konečně pro skládání novější obrázek přepisuje starý.

A co jde z „mozaikových obrázků” vykoukat? No na první pohled se zdá, že Jirka/Cogito team měl pravdu, že robot jede s bílou čárou po pravé straně, protože v trénovacích datech byla nějaká silnice s krajnicí … … ale chtělo by to projít celou nahrávku (1.5km/50min).

kontaktní formulář.

Tulák po krasu 2026

2026-06-07T00:00:00Z

Oficiální stránky soutěže včetně pravidel

Obsah

Blog

7. června 2026 - Oprašování HW a SW (7 dní)

Dnes jsem po dlouhé době popojel s Patem. Žádný „trhák” — 1m tam a 1m zpět. A pak ještě pat-go-314.json konfigurace z předlonškého Písku.

Last login: Sat May 10 21:19:14 2025 from 192.168.1.42

… moc si nevybavuji, proč jsem ho loni pouštěl, resp. možná jsem se pouze přihlásil a něco z něj kopíroval??

Ale asi by bylo lepší začít od začátku! Letos jsem si vymyslel takovou ptákovinu a to, že se podívám na Tuláka po krasu a vezmu s sebou všechny svoje roboty, konkrétně už zmiňovaného velkého čínského Pata a čtyři malé Matty a vedle „společenské události” by to mohla být sranda je nějak zkoordinovat. Přihlášku jsem poslal před časem a dokonce našel oběť (Georgi) ochotnou se mnou do Sloupu v Moravském krasu vyrazit (Soutěžní tým: Je minimálně dvou a maximálně čtyřčlenný). A předevčírem jsem si přečetl znova pravidla a je tam podmínka na Robota: všechny jeho části musí být fyzicky spojené. Hmm, to možná bude komplikace, resp. komplikace navíc. Psal jsem organizátorům, jak je to tedy pro vícero robotů s vyjetím z cesty? V zásadě mám dvě možnosti:

všech 5 robotů bude fyzicky spojených (např. provázkem) a pak teprve když vyjedou uplně všichni pokus končí
rozšířili by pravidla o pozemní multi-roboty a pak vyjetí libovolného znamená konec

… zatím nevím, co je pro mne lepší volba. Asi to dopadne nastejno — katastrofou.

O Patovi jsem se už ventiloval tak také trošku o Mattym. Před více než půl rokem jsme se rozhodli s OAK kamerama od Luxonisu přejít z DepthAI verze 2 na verzi 3. A dře to. Hodně. A není nad soutěž se dokopat k dalšímu krůčku (minulé neúspěchy viz např. Vytloukání AI AI). Problémy jsem měl především s YOLO modely, k této soutěži tématicky např. detekce kuželu. A teď to konečně vypadá, že by to mohlo opravdu fungovat a je to tedy třeba vše zamergeovat (Matty env depthai 3.6.1, OSGAR podpora pro NN archiv, OSGAR apps - novější model pro kužely).

Co se „strategie” týče, tak neplánuji jet po čáře, ale po cestě (ano, vtipná bude otočka, ale racionálně uvažující člověk by jí měl zatím ignorovat … s pěti roboty? ha ha ha). Neuronku jsem převzal od Jirky/Cogito a nechť bezchybně funguje. Pokud bude kameře zabýrat výhled jiný robot, tak asi méně. A ještě jeden detail, že pro Pata už kameru nemám. Mohl bych použít nějaké ty bezpečnostní a třeba by to ani tolik nedrncalo, že by to přežily, ale … teď jsou na konci seznamu. Na Patovi je VanJee lidar, ale ten z Mattyho neuvidí nic. Lidar je ve výšce 68cm, spodní vrstva kouka 10 stupňů dolů a Matty je cca 25cm vysoký … no jestli dobře počítám, tak by ho mohl detekovat ve vzdálenosti 2.5m?? To by možná šlo?

Formaci robotů jsem si nejprve představoval Pat uprostřed a v každém rohu jeden Matty. Nebo šňůra robotů a Pat asi na konci.

Ještě bych mohl znova zkusit UWB majáčky, ale ty moc nefungovaly (tedy abych mohl spolehlivě triangulovat).

Ještě je tam detail synchronizovaného startu — je prima, když program začne na uvolnění STOP tlačítka, ale pokud kamera naběhne různě v jednotlivých robotech (v praxi ověřeno), tak na to nelze spoléhat. Audio? Týden je dlouhá doba, když nepočítám, že většina jsou pracovní dny … sigh.

p.s. jeden ze záložních plánu je dat Mattyho na Pata:

Matty M04 na Patovi

8. června 2026 - matty-follow-robot.json (6 dní)

Někdy mne opravdu fascinuje, jak člověk (já) rychle zapomene ty špatné věci, resp. tu „odvrácenou stranu”. Jako chápu, že to tak příroda zařídila, jinak by nikdo ani nevstal z postele, ale stejně … Skočím tedy zase do posledního dojmu a pak to vezmu od začátku. Primární cíl Verze 0 je, aby robot (zde pěti-robot) získal alespoň jeden bod. Asi limitní sestava je, že pouze první robot pojede po cestě a ostatní ho budou následovat = varianta vláček. Co kupodivu chybí je kód na „následuj robota před tebou”.

Úlohu jsem zadal Eleně Ai. Použil jsem Zbyňkovo doporučení nejprve jí nechat vše naplánovat a zapsat do dokumentu, hard-reset a druhou instanci s čistým kontextem zaúkolovat „implementuj tento plán”. Klasicky prošla kde co leží a přišla se třemi variantami sledování (platforma Matty, senzor OAK-D Pro kamera):

sledování nejbližšího objektu z hloubkových dat
detekce objektů v barevném obrázku a kombinace s hloubkovými daty
navigace na LED výstup předešlého robota

(založil jsem pull request pokud by někoho zajímaly detaily)

Ty LEDky by mne fakt nenapadly, ale inspirovala se DTC, kde byl denní a noční mód (vlastně i sledování osob je tam ve dne i v noci pomocí YOLO modelu). Vysvětlil jsem jí, že spěcháme a není čas na trénování detekce druhého robota a že varianta A vypadá nejlépe a nasbíráme tak i reálná data pro pokročilejší varianty. Hotovo — kód vyplivnut, je čas na test, resp. správně by měl být čas na human review, ale za chvíli bude tma a první co jsem škrtnul byla podpora nočního režimu.

Nový kód jsem nahrál do M05 (oranžový), trošku se lekl oranžových disco-světel, ale na Emergency STOP reagoval ukončením programu, tak ještě test venku (nějaký člověk si tam hrál na robota) — nebylo to uplně skvělé, ale něco to dělalo. Kdybych si ale Eleně stěžoval, tak by mi to mohla hodit na hlavu s hláškou: ,, Ale tohle přeci není Robot!!!''. Vytáhl jsem tedy M03 (červený — bloody Matty) ať dělá návnadu a naviguje se na kužel a oranžový robot ho může v klidu sledovat. A nic. M03 prostě na kužely dnes večer navigovat nebude a basta! Vytáhl jsem tedy z krabice M04 (růžová Fifinka) a ta poslouchala a chvíli pendlovala mezi kužely … jen M05 moc nezaujala a následovat jí nechtěl.

Vypadalo to asi takto: https://youtu.be/7kHqVhwrC5I

Kde že je ta „odvrácená strana”? V pokoji se už nehnu — pro roboty není kam šlápnout. Pak ta otrava, že se to chová každý trošku jinak?! M03 (starší) má i starší kameru, takže by tam byl nějaký problém s DepthAI verze 3?

Dále když jsem updateoval všechny tři roboty (3 repositáře a prostředí), tak jsem viděl (3x):

Uninstalled 2 packages in 4ms
Installed 1 package in 10ms
 - depthai3.1.0
 ~ depthai3.6.1

Cože?! Takže ta oslavovaná 3.6.1 nebyla na žádném z robotů?! … jj, už je to zamergeované, ale můžu si případně git checkout předešlý commit.

Také tato hláška mne dostala: [2026-06-08 19:43:40.123] [depthai] [error] Device with id 1844301091A3BD0800 has crashed. Crash dump logs are stored in: /home/robot/git/osgar-apps/followme/.cache/depthai/crashdumps/40ef12617b276baa7fccf85677e29dcfaaa9bb09/crash_dump_2026-06-08_19_43_40.tar.gz - please report to developers. [2026-06-08 19:43:40.129] [depthai] [warning] Failed to send crash dump logs to the server. … jako chtějí mi říci, že si pády mého soukromého offline robota někdo posílá na svůj server?! Milé (ironie).

Asi už jsem se dost vypovídal, tak možná upload toho videa (jen důkaz, že roboti většinou nefungují) a abych nezapomněl, tak jsem na web hodil i kopii článku od Martina Lockera o tom, jak byl Matty M01 na loňském ročníku — viz Tulák po krasu 2025.

9. června 2026 - Bez robota bos (5 dní)

No nevím, zda jsem dnešní večer dobře investoval, resp. nerad si přiznám, že ani náhodou! Nechal jsem Elenu, ať udělá analýzu včerejšího selhaní, přestože důvod byl na první pohled jasný:

Na začátku sledování

Selhání sledování

Ono je to vlastně vidět i na tom videu, kdy oranžový najede na trávu a přední část kouká nahoru. Ale Elena mne stejně překvapila a to následující analýzou. Jj, je „trošku” upovídaná. Ve zkratce došla k závěru, že udělala chybu ve znaménku a korekci horizontu z IMU (pitch) naopak pokazila. Hmm, to mám mínus body, že jsem si nevšiml, že tam to IMU z kamery rovnou zapojila — rozmluvil bych jí to.

A tak jsem instruoval další kopii AI, ať připraví PLÁN B, kdyby ta IMU vracela úplné nesmysly. Musím uznat, že rozdělení do fází: nejprve se nad dokumentem dohadovat, co bude implementovat a následně (nejlépe čerstvá instance) to vše „bez otázek” implementovat, je funkční scénář. Skoro. Já totiž vždy na něco zapomenu a jsem líny se do fáze plánování vracet, ale to je můj problém.

Plán B má sledovat 2D objekty přímo v hloubkovém obrazu, ale to jsem jí neřekl, že i ten obraz je fakt mizerný. Ale přidal jsem do plánu i postup následné analýzy, takže i na té jediné nahrávce je vidět, že přímo to fungovat rozhodně nebude:

m05_183003_001233_lost.jpg

… no je to debug image spíše pro stroj než pro člověka, prože mi přijde, že sleduje blýskavku než-li robota. Ten clustering na zašuměných datech … TODO.

No a sám bych se měl alespoň podívat, co ta nebohá M03?

Hloubková data M03

Krása …

10. června 2026 - Team Lead Matty M01? (4 dny)

Dnes to bude hodně stručné: je 21:30, ještě jsem nic neudělal a asi neudělám. Ale vymyslel jsem novou strategii — není 5 robotů málo? Co přidat ještě „konkurenční tým” MartinaL s Matty M01, který bude odladěný tu čáru letos vyhrát, a vézt se jenom v závěsu, tj. všichni Robotika roboti by jeli follow robot.

Také se chystám Bloody Matty M03 obětovat před Pata. Má totiž za kamerou ještě starou díru, kam by se dal přidělat plastový válec co mu zvedne výšku o 20cm, ostatně viz

Freyja SubT Tunnels

Místo na reklamu nebo na odrazivou plochu, ale kde ty majáčky z Eurobota 2004 skončily?

Majáčky Eurobot 2004

11. června 2026 - Robotika v podzemí 2026, Japonci a verze 0?! (3 dny)

Dnes jsem měl dovolenou, resp. jsem se byl podívat na akci Robotika v podzemí 2026. Dozvěděl jsem se o ní (krátce před půnocí) zhruba před 14ti dny, kdy do ukončení registrace zbývalo 20 minut. Tak jsem registrační formulář vyplnil dříve, než jsem podrobně nastudoval program, ale nelituji. Akce se konala ve Štole Josef na kterou nostalgicky vzpomínám z přípravy na DARPA Subterranean Challenge 2019.

Co mne asi nejvíce zaujalo byla česká firma First Green a jejich „hračky”:

Rockear 700

FollowMe konkurence

MiniZ 400 nakladač

I studenstká konference nebyla špatná — alespoň jsem získal představu, jaká jsou témata pro diplomové práce v dnešní době.

Odpoledne se mi ale už zastesklo po vlastních robotech a tak alespoň večer jsem chvíli testoval …

Japonci? To je téma japonské vesmírné agentury a rozdělení cílů — měl jsem to udělat už při prvním zápisu, ale stalé se to počítá aneb je před Akcí. Definice tří úrovní cílů pro naši Pražskou pětku nebo Srostlici:

Minimální

ujet 10 metrů (celá skupina pěti robotů)

Ku spokojenosti

překonat Matty M01/R-team nejlepší pokus z roku 2025 (754 metrů)

Vynikající

dosáhnout místa obrátky (1400 metrů)

OK a kde dnes v noci jsme, necelé 3 dny do soutěže? Sigh. Verze 0!? Asi bych měl zmínit Jirkův komentář ze včerejšího callu: „proč proboha hledaš robota v hloubkových datech a nepoužijes na identifikaci” AprilTag?! … no jó no … možná zítra (když to prý pošlu mailem, tak mi to do 17h v sousední vesnici vytisknou).

A co jsem tedy dnes dělal? Sbíral data a zkušenosti. Rychlost sledování cesty jsem snížil na 0.2m/s (spěcháte?) a testoval na jedné z mála cestiček, co máme na zahradě. Poučka 1 (ano samozřejmá) — sekvence pouštění robotů začíná od posledního! Jestli se Jirka ptá, zda jsem konečně sklopil kameru, tak nesklopil, tj. pokud je přední robot hodně blízko, tak přesahuje spodní část obrazu a se vzdáleností se posouvá nahoru. Také jsem (zbaběle) přidal na Mattyho pikslu na tablety do bazénu — primární motivace je, aby měl Pat šanci posledního Mattyho vidět, ale ono se to hodí i pro Matty-Matty z hloubkových dat.

Matty následován Patem

Video se mi z osgar.tools.lidarview nepodařilo udělat, tak alespoň jeden screenshot:

Matty na VanJee -10deg scanu

a data:

python -m osgar.logger pat-go-314-260611_173216.log -stream vanjee.scan10 
                                                    -format "{timestamp} {data[900-15:900+15:2]}"
0:00:32.676170 [3470, 3470, 3472, 3477, 3486, 3493, 3499, 3503, 3506, 3511, 3515, 3518, 3515, 3509, 3439]
0:00:32.775786 [3466, 3468, 3471, 3477, 3483, 3489, 3494, 3500, 3506, 3512, 3517, 3522, 3525, 3515, 3422]
0:00:32.877479 [0, 0, 0, 0, 0, 3491, 3494, 3500, 3506, 3512, 3517, 3521, 3523, 3510, 3438]
0:00:32.977487 [1211, 1213, 1214, 1213, 1212, 0, 3499, 3502, 3506, 3509, 3513, 3518, 3519, 3508, 3437]
0:00:33.078093 [1224, 1225, 1224, 1224, 1225, 0, 3499, 3502, 3506, 3511, 3518, 3522, 3524, 3511, 3439]
0:00:33.178936 [1232, 1230, 1225, 1221, 1220, 1223, 0, 3501, 3507, 3514, 3520, 3525, 3526, 3513, 3435]
…
0:00:39.477243 [2377, 2377, 2377, 2378, 2379, 2381, 2382, 2382, 0, 3512, 3518, 3524, 3527, 3515, 3439]
0:00:39.574522 [2395, 2396, 2397, 2399, 2399, 2398, 2398, 2398, 0, 3517, 3521, 3525, 3525, 3512, 3441]
0:00:39.674839 [2410, 2411, 2413, 2415, 2417, 2420, 2423, 2425, 0, 3512, 3517, 3522, 3525, 3511, 3434]

… tj. je šance ten váleček vidět ve vzdálenosti 1.2m - 2.3m … už to jen udělat. Dávám si BAN/zákaz na AI, jinak ani ta triviální funkční verze zítra večer nebude.

12. června 2026 - Prší, prší … a April Tags (2 dny)

Venku stále prší a tak zkouším ty AprilTag. Nevím, kdy jsem ten dotaz can you give me a quick intro into AprilTags? položil a zákaz AI tedy rovnou porušil, ale těch pár odstavečků dávalo smysl a link na generování April Tagů do PDFka jsem použil a trošku „naslepo” nechal vytisknout pár vzorů tag25h9 a tag16h5. Příklad kódu ale používal pupil-apriltags a tím se zase spustila lavina. Domácí odkaz je na github pupil-labs, kde je info, ze je to fork z duckietown/apriltags3-py a THIS REPOSITORY IS NO LONGER SUPPORTED a alternativa je duckietown/lib-dt-apriltags. A ještě originál všeho apriltag 0.0.16 byl Released: Dec 7, 2018. Někdy tou dobou mi začalo docházet, že tímto „peklem” už jsme si jednou prošli a hle poznámky na robotice.

Vlastně jsem ještě přeskočil krok 0, kdy jsme se na callu bavili, že OAK April Tag přímo podporuje! Ale při detailnějším čtení člověk zjisti, že RVC2 On the RVC2 devices, the AprilTag node runs on the host computer, so the performance will be limited by the host CPU.. Takže nic, resp. je jistější to udělat na PC „po staru”.

Zpět k poznámkám — pro OpenCV 4.1.1 tam funcionalita přímo byla, tak snad jí neodstranili! (mimochodem v té době jsem si psal datumy bez roku, jak naivní!) Teď mám OpenCV 4-7.0 a API se trošku změnilo (ale kvalita dokumentace nikoliv). Nebudu tu AI pouštět, aby mne vrhla zase do úplně jiného bazénu …

A hle trosky stackoverflow stále obsahují přesně to co pozoruji: API changed for 4.7.x, Now you need to instantiate ArucoDetector object. Po drobných úpravách toto funguje:

import cv2
im = cv2.imread("april-tags.jpg", 0)
dictionary = cv2.aruco.getPredefinedDictionary(cv2.aruco.DICT_APRILTAG_25h9)
parameters =  cv2.aruco.DetectorParameters()
detector = cv2.aruco.ArucoDetector(dictionary, parameters)
markerCorners, markerIds, rejectedCandidates = detector.detectMarkers(im)
print(markerCorners, markerIds)

s výsledkem 4x rohy a IDs (bohužel náš markdown dump výstupu „pársuje”, takže ho zase odmazávám a později možná přidám obrázky.

testovací obrázek

a ještě pro mne apriltags-3pages.pdf

13. června 2026 - Temný les (1 den)

Tento zápis je zpětně (a krátký), protože čekám, než se dobijí baterky …

V sobotu jsme dorazili po desáté hodině, ale vedle organizátorů tu moc týmů na testování nebylo. Střídavě pršelo, svítilo sluníčko, teplo, studeno, ale v zásadě OK počasí (no na déšť připravený nejsme). Tentokrát ani nemůžu odkazovat na github, protože vše mám stále lokálně bez internetu.

Dopoledne jsem rozchozoval AprilTags — nakonec používáme ty 25h9. Vzdálenost jenom odhaduji z velikosti diagonály a vypadalo to OK. 1 metr mezi roboty mi přišlo moc, takže jsem nastavil 0.5m. Rychlosti maximální (0.5m/s) a u prvního robota snížena na 0.4m/s, aby ho následníci měli šanci dohnat.

U Pata jsem nakonec použil klasické prastaré followme, jenom viděl v zadu sám sebe, a tak jsem celý kód zkopiroval a upravoval v osgar-apps. Mám to vše na jedné hromadě (git branch), a akceptuji pouze data +/- 45 stupňů. Kousek to popojelo za M03, ale na další testy už nedošlo.

K večeru jsme vypustili všechny čtyři Matty roboty na trasu a s pěknou simulací „zácpy na dálnici” (video snad najdu později) dojeli až k lesu … a tam se „vláček” rozpadl. :-( Detekce cesty fungovala na M02 krásně — pořadí M02, M04, M05, M03 … (někdy Pat, tato jízda byla bez Pata), ale přišel Temný les a začala selhávat detekce AprilTagů! No jo no.

A kouzelné řešení, jehož autor je GG, bude mít pokračování až „zítra”.

15. června 2026 - Soutěž a výsledky

Neděle začala poměrně brzy, konkrétně v 6h ráno, když nastoupili borci lesáci a pokračovali v kácení bukového lesa za barákem. Já stejně raději programuji po ránu, takže ideál.

Úkol byl jasný — implementace Georgiho poměrné prosté myšlenky: „Pokud nevidíš žádný AprilTag naviguj po cestě, jinak se drž AprilTagu v dané vzdálenosti”. Vytvořil jsem teď novou větev feature/tulak-po-krasu-2026, kam jsem dal pouze commity ze soboty a neděle. Trošku Cimrmanovsky bych řekl: „A nebyla to právě AI/Elena, která nám ukázala "tudy ne přátelé"”?! … prostě jsem rád, že jsem měl klid a žádný internet …

No nic, když půjdu zpětně po commitech (ten rebase to všechno rozbil, takže datumy dávají smysl pouze v opuštěné větvi). Založil jsem (jj, copy and paste) novou konfiguraci matty-tulak.json, což byla kopie matty-follow-apriltag.json a matty-redroad.json — to bylo celkem triviální.

Pak jsem vytvořil tulak.py (jj, zase kopie, až se stydím) a nahradil jednu řádku zastavení pomocí přepnutí na navigaci po cestě (viz mixovací commit). A hotovo, resp. připraveno na test.

Nefungovalo to. Asi očekávané, jen ten důvod jsem nečekal. On totiž Matty na požadované rozestupové vzdálenosti ten AprilTag už téměř nevídí! Už zase slyším MartinaL: „proč máš tu kameru nahoru, když to má jet po cestě!” … no prostě mi ty záběry přijdou zajímavější, ale ano uznávám, že to má i svě slabiny:

Matty rozestup

No minimálně to trošku vysvětlovalo to cukání ze soboty, protože při dosažení tagu, nebo jeho ztrátě, zastavi. A ano regulace max_speed, stop, max_speed, stop, … není úplně to pravé. To, co v sobotu zastavovalo, ale v neděli přeplo na „naviguj po cestě” a jelikož na větev feature/safe-redroad jsem trošku pozapomněl, tak Matty překážky moc neřešil a opakovaně do robota před sebou narážel …

Fix byl jednoduchý — zvednout požadovanou vzdálenost mezi roboty na 0.8m.

No a co s Patem? V sobotu jsem zvedl rychlost na 0.6m/s a rozmezí vzdáleností na 1.5m až 3m, ale neotestoval jsem to. Commity pomalu dochází, takže s tímto stavem jsme „soutěžili”.

První start byl dost katastrofální — ono když člověk pouští 5 robotů a do toho se je snaží natáčet mobilem a vzadu ten velký dělá neplechu a je třeba přes vysílačku ho zastavit … málo rukou nebo používat DARPA e-stop. Takže poučení — místo startování robotů od posledního je teď třeba startovat od prvního!

Co se mi na nové variantě líbilo nejvíce je fakt, že všichni roboti, tedy až na jednoho, měli stejný kód a vlastně bylo jedno v jakém pořadí je poskládáme na cestu. Skoro. Patologický Pat by je všechny rozdrtil na plastové šlupky (fakticky to udělal 2x), takže červený Matty M03 s válcem mu jediný mohl odolat … takže úplně náhodné pořadí to nebylo.

V prvním kole nám dali organizátoři 7.7m — jako už nevím, jak se to počítalo, ale asi jsme ztratili Pata a čtyři Mattýskové se vesele vydali na výlet …

oficiální výsledky

… a dojeli až na otočku a pokračovali by dál, kdybychom je nezastavili. Jako ta asfaltová cesta je na detekci fakt luxusní! A Red Road model už jí loni viděl skrz Matty M01 kameru. Pokus se nepočítal (nejelo všech 5 robotů), ale mne během procházky došlo, kde je zakopaný pes. Pat se chvíli celkem držel, ale postupně ztrácel až mu Matty M03 s válcem ujel ze zorného pole spodního lidaru. Proč? Nuže viz poslední commit. Pokud si vzpomenete na Killer Application před dvěma lety, tak od té doby je defaultni SW limit na Patovi nastaven na 0.5m/s. To je ale zároveň maximální rychlost Mattyho … a pokud někdy Pat zpomalí, tak už je nedožene. Oprava je tedy lehce posunout tento limit výše — dal jsem 0.7m, ale platilo to co je v aplikaci, tedy limit zůstal na 0.6m … hmm, když o tom přemýšlím možná toto byla také chyba.

A novou opravou jsme se vraceli od otočky, ale … proti nám jeli soutěžící roboti a uhnout z cesty 5x není až tak triviální. Pat jednou sejmul Mattyho trojku, ale sepnul bezpečnostní nárazník na Patovi a ten už odmítal jakýkoliv další pohyb (ať už z počítače nebo z dálkového ovladače). Reboot.

Další problém byla výdrž baterek — přeci jenom malí roboti jeli cca hodinu tam, chvíli postávali před startem, o něco delší chvíli čekali s Georgim na točně, než „si skočím pro notebook” (2x 1.4km) a pak ještě cesta zpět. Bloody Matty to nedal — hlídání baterky začalo pípat v „temném lese” (tj. skoro doma) a z mírného kopečka dokonce přestalo. Teď už vím, že je to poslední stadium před smrtí! Měl jsem za to, že Odroid (řídící počítač) skončí na 15V (v manuálu je 15V-20V, myslím), ale MartinL mne ujistil, že to poběží i na 12V! Tak jsem se dozvěděl/naučil něco nového. A pak byla baterka už tak vybitá, že ani pípák nechtěl pípat. A následně, co ho Pat odvezl na základnu, už baterka nešla slušně nabít. Ale nešlušné triky (trošku jako elektrický šok) zafungovaly.

Tolik první výlet. Pak dvě hodiny nabíjeni všech PC baterek a druhý, pro nás závěrečný, pokus. Chtěl jsem si ho natočit = chyba, sorry Jirko, možná to video z odhozeného mobilu někam dám skrytě. V každém případě tady už Patův nárazník nesepnul a už jednou otlučeného a vybitého Mattýska Pat přejel. Viditelné je to na ulomeném nárazníku — na rengenu ještě nebyl. Přiznám se, že jsem se trošku přestal ovládat a start asi 3x zopakoval. Prostě největši slabina byla, aby se Pat spravně chytil/detekoval M03 a pak už to jelo OK. Nakonec to OK vydrželo 460m, po průjezdu „temným lesem”, kdy LIDAR asi zmátlo slunce nebo nějaké odrazy od konkurence (TODO analyze later).

Podle japonského hodnocení byl minimální cíl dosažen (všech 5 robotů ujelo 10 metrů). Oficiálně sice Ku spokojenosti chybělo ještě 754-460=294 metrů, ale tím že 4 roboti dali Vynikající (1400 metrů), tak celkově úspěch.

p.s. alespoň jedno video ze soboty (4x Matty testování)

p.s.2 … a ještě přeběžně celý playlist

16. června 2026 - Závěr (Robotika, Pat + 4x Matty)

Včera v noci už jsem neměl sil to nějak uzavřít a teprve ráno jsem uploadoval různá videa, tak ještě shrnující „odstaveček”.

Za mne to bylo super! Takže nejprve velké díky organizátorům — Tomášům:

Organizátoři T+T

Přiznám se, že mé cíle byly trochu jiné, než většiny soutěžících, aneb by to mohla být odpověď na otázku: „proč to proboha řešíte takto složitě?!”.

Částečně jsem si soutěžil sám se sebou, ale („Milanův”) Robotický cirkus snad pobavil a nikdo se na nás nezlobil. Win-Win Hybridní skupina pěti nezávislých autonomních robotů byl asi můj další milník — ano, klasicky to skončilo na ořezané Verzi 0, která nefungovala ani před odjezdem na soutěž! Ale nakonec to jelo, skupina se chovala relativně rozumně a vytáhli jsme i osamoceného Pata, aby mu po letech nebylo tak smutno.

Kam dál? Ta formace může být daleko zajímavější, roboti mohou spolu komunikovat, střídat se ve vedení „pelotonu”, kroužit kolem Pata, jezdit pozpátku, vyhýbat se překážkám, používat „čáru jako zeď”, najíždet na Pata a nechat se vozit, zvednout rychlost Pata na 2.5m/s, nechat Pata řídit vícero Mattýskama na palubě …

Další úroveň je modrá značka vedoucí lesem:

Alternativní lesní cesta - modrá značka

… je možné jezdit okruh, pouze terén … Letos tam bylo dost bahno a třeba Matty by asi i klidně celý skončil po kameru v bahně, tak jsem ho tam zbaběle nepustil. I organizátoři to mají jako potenciální další variantu soutěže, tak uvidíme v roce 2027.

Pak je tu stále Robotour Marathon 5km, který by se dal na robotickém polygonu realizovat. Během soutěžního dne na daný úsek cyklistické stezky byl zákaz vjezdu aut, takže VRU (vulnerables) jsou pouze cyklisti, chodci a bruslaři. Pro vyšší rychlosti by bylo na místě rozchodit detekci a vyhybání se překážkám (nebo alespoň kolizím).

Což mi připomíná ještě starého Istrobota, kde úlohu Stopár každoročně zesložiťovali. Místo tunelu je na trase „temný les”, tak možná někdy budou překážky, které neuhnou …

Ještě jenou díky a přídávám ještě odkaz na oficiální reportáž JedoBotů.

8. července 2026 - Slepý Pat a není Matty jako Matty

Původně jsem myslel, že zde ještě přibudou další příspěvky konkurenčních týmů, ale v danou chvíli to zní nepravděpodobně. Tak ještě jednou připomenu Unidroids vítěznou jízdu!

Za sebe jsem trošku zkoumal logy a uklízel pull request. Jedna z otázek například byla, zda roboti někdy viděli více jak jeden AprilTag? A ano odpověď byla, že chvílema viděli i 3 tagy!

3x AprilTag

Další byl hack, že pokud vidím alespoň jeden AprilTag, tak naviguji na první detekovaný, jestli to někdy bylo špatné rozhodnutí? (ano, lenost to pořešit) … a bylo:

0:17:26.797315 [1.2738802853424471, 0.009094801649064201], [3.8269467486030613, 0.06303638384351394]
0:17:26.896863 [1.2612156249080342, 0.006585890849322352]
0:17:26.997080 [1.2673802962951644, 0.009094801649064201], [3.785101005175049, 0.0655452946432558]
0:17:27.099002 [3.7258743526102713, 0.0650748738683042], [1.2677473241080792, 0.006899504699290083]

tj. chvilku to navigovalo na ten 3.7m vzdáleny tag. A také musím uznat, že oprava od Eleny Ai je celkem elegantní:

dist, angle = min(data, key=lambda x: x[0])

Tak to bylo jenom zahřívací kolo …

Slepý Pat

Na co jsem byl samozřejmě nejvíce zvědavý byl důvod, proč se nám vláček po cca 300 metrech rozpadl. Chtělo by to video z osgar.tools.lidarview … ale ono to nefunguje. :-( Hmm, tak oprava … ono to funguje, ale ... je třeba nastavit rozměry okna, které odpovídají rozlišení výstupního videa!!!

AssertionError: ((1080, 1920), (1016, 1848, 3))

… ten assert si tam nechám! Tak jo, už umím udělat video, ale vzhledem k pokročilé hodině psaní odložím na zítra.

O den později — je to opravené (resp. ve fázi opravy, hmm testy selhaly) … a mám 8 minut do callu, tak to zase nedám. V každém případě zde je slibované video.

Je tam pár detailů hodných pozornosti:

hladká cesta je dobře rozeznatelná od okolí
na začátku je pěkně vidět zábradlí mostu, kde se oba skeny (vodorovný i ten 10 stupňů dolu) potkávají
před lesem je pěkně vidět rozšíření silnice o místo na vyhýbání se
v lese pak jednak svah nahoru vlevo, mizející sken vpravo (svah dolu) a rozpoznatelné stromy
v závěru robot v protisměru, kdy VanJee asi přenastavil citlivost a ztratil tak Mattyho z hledáčku

Není Matty jako Matty

No teď už jsou pryč další dva dny(!) a rád bych to ukončil, takže klasické poučení i ty „slavné” příspěvky si rozděl …

… ale na druhou stranu tento byl zrovna důvod, proč jsem se to rozhodl sepisovat. Hrál jsem si chvíli s BEV — v práci to ostatní dělají pořád tak proč bych si to nezkusil i já?

Je to zkratka za Bird's Eye View a to znamená pohled shora. No a jelikož na Tulákovi byla úplně luxusní asfaltová cesta, tak by měla jít poskládat z mozaiky na základě pohledu z přední kamery robota. Nebo se pletu?

Už klasicky jsem poprosil Elenu (ať se pořád nenudí), ať udělá malý interaktivní nástroj — to ona ráda. Vstup je obrázek na disku a výstup je pak pohled shora. A to by nebyla Elena, aby k tomu nepřidala spousta šoupátek, load/save konfigurace a pod. Ale to jádro, které bych musel jinak hledat a dostudovat jsou 2 řádky:

# Calculate homography matrix and warp
M = cv2.getPerspectiveTransform(pts_src, pts_dst)
bev_img = cv2.warpPerspective(img, M, (bev_w, bev_h))

Prostě ze čtyř (x,y) bodů v prvním obrázku a čtyř (x,y) bodů v cílovém obrázku spočítá transformační matici a pak ji prostě aplikuje.

Detaily jsou případně na GitHubu. Ale ke druhému kroku jsem se už nedostal, protože i ten první mi přišel totálně nepoužitelný. Důvodem je, že s vyjímkou M02 (GG pokud to čteš, tak mne data z robota zajímají ) všichni ostatní vidí jednoho a více robotů před sebou a to případnou pěknou mozaiku hodně rozbije. Musel jsem se i AI ptát proč to vypadá tak šíleně a důvod byla třeba kamera robota přede mnou roztažená na 3/4 „ptačího pohledu”. Ale když jsem si vybral skulinu, kde skoro viděl jenom cestu, tak to bylo OK. Skoro OK.

No asi mne to tak šokovalo, že jsem si neudělal žádnou dokumentaci … tak teď nějaké nové screenshoty …

BEV pro M03 vzadu

BEV pro M04 vpředu

Pokud to není z obrázků jasné, tak doplním info, že M03 měl kameru více dolu a M04 nahoru. A to mi tam MartinL udělal zoubky, abych mohl všechny roboty nastavit stejně! Ale asi když jsem si hrál s M03 a detekcí cesty, tak mi přišlo, že kouká moc nahoru (původní nastavení z DTC2 Systems, aby viděl lidi) a trošku to sklopil dolu a zapomenul …

Je to prý vidět i z té matice

cat bev.json
{
    "top_y": 857,
    "bottom_y": 885,
    "top_width": 400,
    "bottom_width": 707,
    "offset_x": 986,
    "show_grid": 1,
    "bev_width": 400,
    "bev_height": 600,
    "matrix_M": [
        [
            -0.04450251352363365,
            -0.24317444889699785,
            243.3794783343032
        ],
        [
            0.0,
            -1.6845547756949022,
            1443.6634427705312
        ],
        [
            -4.640868235845023e-19,
            -0.0012189195433433444,
            1.0
        ]
    ]
}

vs.

m03
"matrix_M": [
        [
            -0.06679355486718928,
            -0.28794196341906053,
            263.6218126725021
        ],
        [
            -6.579099405186112e-17,
            -1.2942934071591932,
            973.3086421837133
        ],
        [
            -8.07320644968878e-20,
            -0.0014433181123762412,
            1.0
        ]
    ]

… přesněji -0.0012189 vs. -0.0014433. Pokud to zkombinujete s FOV (field of view) kamery, tak dostanete náklon. Ale ty AI řeči už jsem asi zavřel.

p.s. Mozaika

… aneb s jídlem roste chuť. Když už umí udělat jeden obrázek, tak proč jich z logu nevysekat více (třeba po 0.5m) a proč to podle odhadu z odometrie neposkládat?

Mozaika 30-50m

Mozaika 50-100m

Mozaika 100-200m

Pokud máte nějaké doplňující informace či komentáře napište nám.

OAK-D Pro

2022-03-22T00:00:00Z

OAK-D Pro (převzato z webu Luxonis)

Obsah

Blog

22. březen 2022 — Měsíc čekání

Jak začít? O OAK-D jsem poprvé slyšel od týmu Sĺňava (Robotour 2021). Pak jsem se cca před měsícem dozvěděl o existenci firmy Luxonis a rozhodl si udělat představu „z první ruky”. Doporučení jsem dostal na novou kameru OAK-D Pro, která je zatím zařazena v beta programu. Byl jsem i varován, že doručení bude nějaký čas trvat (expeduje se z Hong Kongu).

Vlastně mne velmi potešilo, když objednávka byla ještě ten den potvrzena a druhý den expedována … tak to třeba nebude tak dlouho trvat? Ale trvalo. Přes týden to viselo v Belgii na celnici (to je ta „výhoda” online sledování — člověk se může permanentně nervovat, místo aby počítal s dlouhou dobou a pak byl překvapen) a vrchol byl pak v Čechách. Z adresy vypadly všechny znaky s diakritikou (na rovinu bych jí nepoužíval, ale mám pocit, že tam byla nějaká nápověda pro dohledání adresy, ale už je to dlouho, takže ani tím si nejsem jist). V každém případě „tracking number” není to samé v ČR a pokud ho nemáte, tak se dohledává podle adresy. Zkrátím to, skončilo to v koši „nedoručitelné”, ale po dvou dnech telefonování a „intervencí” se balíček na depu v Praze našel. Doporučení: odmažte diakritiku.

A když už jsem měl krabičku doma, tak jsem se zase nemohl rozhoupat jí vůbec otevřít. Začal jsem totiž pořádně „listovat” dokumentací a narazil jsem na: Due to the large power consumption of dot projector/illumination LED, a Y-adapter is required when using these functions! F-slovo. Znamená to, že teď budu muset objednávat nějaky Y-adaptér, abych si mohl kameru vůbec pustit?! To mi asi vzalo trošku vítr z plachet. Pak jsem alespoň otevřel krabičku a našel jsem tam toto:

Obsah krabičky

Vlastně tedy dobrá a špatná zpráva:

Y-adaptér je součástí balení
trošku to vypadá, že tam něco chybí, třeba kabel?

Kabel tam byl — pod krabičkou. Ale jestli tam má být takto poloprázdná krabička úplně nevím. Na druhou stranu i druhý kus vypadal stejně.

A teď dobré zprávy — First steps with DepthAI … prostě návod co udělat od zapojení nové kamery do USB konektoru. A fungovalo to bezchybně!

DepthAI selfie

Myšák

p.s. a ano, na extra přísvit a extra zdroj dojde někdy později … tj. na první pokusy nebyl nutný.

25. březen 2022 — Druhý krok

První krok byl snadný, ale co bude druhý krok? Napsal bych si nějaky mini-prográmek, ale jaký? Konečně jsem začal více koukat do dokumentace API a užitečný mi přijde tento obrázek:

Host je váš počítač a OAK Device je „chytrá kamera” … stále nevím, co OAK (v překladu dub) znamená? Node, connection a pipeline připomíná klasický robotický systém, jenom to vše běží přímo na „kameře” a nejspíše se to musí připravit předem. XLink pak zajišťuje komunikaci tam a zpět.

Kameru mám zatím zapojenou přímo do notebooku a tak její chytrost úplně nevyužiji. Co by mi ale přišlo zajímavé vyzkoušet je, co když se XLink přeruší? Jede pipeline vesele dál? Pak by paradoxně Y-adaptér, na který jsem ještě nedávno „nadával”, byl přesně ten kousek HW, který by mi průběžné odpojování od počítače umožnil. Možná.

Koukal jsem tedy na standalone mode a chyba lávky: Standalone mode is only possible on OAKs that have on-board flash memory, which are currently OAK IOT and OAK POE camera models. Je tady asi na místě zdůraznit, že Luxonis nabízí několik řad zařízení a tak bych doporučil si to předem nastudovat a volit podle plánované aplikace.

A co by to „offline” resp. „nezávisle” dělalo? Může si kamera po začátek pamatovat několik obrázků nebo dokonce video? Podle příkladu RAM usage: All OAK devices have 512 MiB (4 Gbit) on-board RAM, which is used for firmware (about 15MB), assets (a few KB up to 100MB+, eg. NN models), and other resources, such as message pools where messages are stored. … teď jsem si říkal, co je ten 4 Gbit? Rychlost? Jiný model? Well … 8x 512MB = 4G bitu … asi.

Vypadá to, že můžu rovnou použít demo system_information.py:

Ddr used / total - 0.13 / 339.99 MiB
Cmx used / total - 2.06 / 2.50 MiB
LeonCss heap used / total - 7.54 / 78.28 MiB
LeonMss heap used / total - 2.95 / 41.54 MiB
Chip temperature - average: 24.12, css: 25.67, mss: 23.69, upa: 23.44, dss: 23.69
Cpu usage - Leon CSS: 10.64%, Leon MSS: 1.98 %

Kód je kratký, jen si teď neumím představit, jak otevřít dai.Device bez pipeline, která pro nastartování obsahuje dva uzly: dai.node.SystemLogger a dai.node.XLinkOut. I to prolinkování sysLog.out.link(linkOut.input) vypadá přímočaře.

p.s. tak schválně, jestli mi někdo poradí: Reconnection to running OAK device?

28. březen 2022 — Standalone mode

Na odpověď jsem nemusel dlouho čekat — Hussain psal: What I understood is that you want to run the OAK in standalone mode. If that was the case, check this documentation.

A pak se ještě ozval Erik: ... that's not possible, after you terminate the connection with the device, the device will remove the pipeline/assets to be ready for the next connection. As Hussain mentioned, if you would like to run pipeline in standalone mode, check the docs page he linked. This still wouldn't allow you to do exactly what you want, but you could eg. stream results via WiFi (OAK IoT) or ethernet (OAK PoE) to the server.

Nešlo by to nějak obejít, když OAK IoT ani PoE nemám? Mimochodem „test komunity” bych považoval za úspěšný. Mám v plánu někdy revidovat úvodní odstavec a doplnit tam, např. že Luxonis má za sebou úspěšnou Kickstarterovou kampaň opencv-ai-kit-lite ($1,136,926 USD by 8,640 backers) [je tam takové množství projektů, až na mne zase padá depka a jestli se mám vůbec o něco snažit ] Také přemýšlím, jestli O=OpenCV, A=Ai, K=Kit??

No nic, zpět k Standalone mode … you first need to remove all XLinkOut and XLinkIn nodes. No jo, ale co dál? SPIOut nepoužiji, protože nemám SPI, a script node jede přes ten Ethernet.

Koukám, že OAK-D Pro má přímo dedikované issue … hledal jsem, jak se vypíná/zapíná podsvícení. Asi vyjímečně nemá cenu hledat přes Google, a je rychlejší proklikat dokumentaci, tj. v Device jsou funkce setIrFloodLightBrightness() a setIrLaserDotProjectorBrightness().

Ale to jsem se „trošku” odchýlil od tématu, ke kterému vlastně nemám více jak „tudy ne”.

29. březen 2022 — IMU a SLAM

Teď je ráno, na rozdíl od včerejšího zápisu, tak je naděje, že budu mít více optimismu než po práci. Navíc téma je snad přímočaré a měly by k tomu být rovnou funkční příklady. Motivace je náhrada Realsense T264 tracking kamery (Limited Lifetime Product) za OAK-D.

Ještě co jsem o víkendu (?) tak narychlo procházel, tak IMU do SLAMu zatím integrovaná není, tak to může být takový self-test, jak jsou oba výstupy konzistentní. No asi jsem zase naivní, ale uvidíme.

Nejprve tedy IMU (Inertial Measurement Unit). K dispozici jsou hned dva příklady:

IMU Accelerometer & Gyroscope — GitHub imu_gyroscope_accelerometer.py
IMU Rotation Vector — GitHub imu_rotation_vector.py

První bych viděl na raw data a druhý jako integraci. Píšou tam nějaké „nezdravé” Herzy (500Hz a 400Hz), ale to se může časem hodit.

Tak jo, první příklad fungoval bez problémů:

Accelerometer timestamp: 5613.242 ms
Accelerometer [m/s^2]: x: 5.200206 y: 0.019154 z: -8.820239
Gyroscope timestamp: 5613.925 ms
Gyroscope [rad/s]: x: 0.014914 y: 0.003196 z: -0.008522
Accelerometer timestamp: 5615.379 ms
Accelerometer [m/s^2]: x: 5.190629 y: 0.000000 z: -8.820239
Gyroscope timestamp: 5616.424 ms
Gyroscope [rad/s]: x: 0.009587 y: 0.001065 z: -0.005326

a druhý stejně tak:

Rotation vector timestamp: 2707.787 ms
Quaternion: i: 0.000305 j: -0.964600 k: -0.001465 real: 0.263672
Accuracy (rad): 3.141602
Rotation vector timestamp: 2709.946 ms
Quaternion: i: 0.000305 j: -0.964600 k: -0.001465 real: 0.263672
Accuracy (rad): 3.141602

SLAM (Simultaneous Localization And Mapping) jsem na stejné stránce mezi příklady nenašel, ale byl „hned vedle” na stránce věnované Spatial AI:

SLAM with OAK … tak to asi nebude jen „copy and paste”: We plan on creating our own visual-inertial SLAM project that would use on-device feature tracking (using FeatureTracker node) and intertial data (using IMU node), if the device has an IMU sensor onboard.

Jsou tam ale odkazy na community projects: OAK-D ORB_SLAM3 Experiment a deptha-slam … (ještě tam byl ArduCam SLAM). Hmm, tak asi zatím nic. Nevýhoda „ranního hraní” spočívá v tom, že v tom nejlepším toho člověk musí nechat a „jít do práce”. V tomto experimentu alespoň vidím jistou naději. To be continued

7. září 2022 — FollowMe a USB kabel (Jirka)

Tentokrát blog posunul Jirka …

Jirka si koupil OAK-D W (Wide), tedy verzi s širokým záběrem a jako demo aplikaci si vymyslel starý dobrý FollowMe co před 10+ lety vylepšil (resp. udělal použitelný) na Eduru (viz staré video z Floriade … takže tady to bylo 10 let). Je sranda jak ty děti dokážou poměrně rychle dostat robota do neřešitelné situace.

Jinak v tomto demo je OAK-D kamera použita pouze jako zdroj hloubkových dat (podobně jako dřive byl RealSense) a veškerý processing probíhá na hlavním počítači. Bude-li ver2, tak možná zkombinuje i detekci osob a alternativní výběr objektu pro sledování, uvidíme … Jirka si určítě něco vymyslí.

Další info od Jirky bylo o GPS (možná dodá i extra článk o stereo-GPS pro získání absolutního směru robota). Vše prý fungovalo krásně až do okamžiku, kdy k robotovi připojil kameru. A ano, problém byl „klasicky” USB 3, tentokrát ale řešitelný kabelem:

Zdar, kdybyste potřebovali k OAK-D kabel, kolem kterého může fungovat GPS, mám teď dobrou zkušenost s: https://www.delock.com/produkt/84007/merkmale.html Koukám, že má i další sourozence: 83718, 84017, 84019]. Ty ale vyzkoušené nemám. Myšlenkový pochod byl: Vysoká přenosová rychlost nejspíš potřebuje lepší stínění, šrouby lépe utáhnou kontakt, s kratším kabelem bude méně potíží. Pořád bych pak nedával GPS přímo ke kameře, ale v mém případě, kdy je anténa necelý metr od kamery, výměna kabelu, se kterou kamera přišla, za tenhle, převedla GPS ze stavu "při puštěné kameře vůbec nefunguje" do "funguje perfektně, bez výpadků".

… třeba se to bude někomu hodit např. na Robotour.

8. října 2022 — SLAM na 6 řádek

Na posledním robotickém callu Jirka zmínil, že jen tak mimochodem se mu podařilo pustit SLAM na OAK-D kameře bez velkých problémů … cože?!

Tak nejprve oprava, že „obrázek je pouze ilustrativní” a „reklama je zavádějící” … není to úplně SLAM (Simultaneous Localization and Mapping, tj. současná lokalizace a mapování), ale visual odometry, tj. odometrie z kamery. Jirka to asi říkal, ale já si zapamatoval SLAM, pardón. A těch řádků je o něco více, ale to by se dalo okecat:

import depthai
import spectacularAI
import time

pipeline = depthai.Pipeline()

vio_pipeline = spectacularAI.depthai.Pipeline(pipeline)
# optional config args: vio_pipeline = spectacularAI.depthai.Pipeline(pipeline, config, useStereo=False)

with depthai.Device(pipeline) as device, \
    vio_pipeline.startSession(device) as vio_session:

    while True:
        out = vio_session.waitForOutput()
        print(out.asJson())

Zdroj: https://github.com/SpectacularAI/sdk-examples/blob/main/python/oak/vio_jsonl.py

Rozchození bylo přímočaré, ještě než mi vystydlo kafe:

mkvirtualenv slam
workon slam
pip install depthai
pip install spectacularAI

a pak už puštění skriptu výše:

(slam) md@md-ThinkPad-P50:~/git/slam$ python vio_slam.py
Traceback (most recent call last):
  File "vio_slam.py", line 10, in 
    with depthai.Device(pipeline) as device, \
RuntimeError: No available devices

Já vlastně nevím, proč to dělám … prostě zvyk, aneb co se stane, když tam žádná kamera není? BTW kam jsem jí sakra dal?! Ano, už je lehce „zaprášená”…

Na druhý pokus (s připojenou OAK-D PRO kamerou přes USB) už to vypadalo lépe:

(slam) md@md-ThinkPad-P50:~/git/slam$ python vio_slam.py
Spectacular AI SDK: WARN: unrecoginzed OAK board name 'OAK-D-PRO'
you may need to manually set IMU-to-camera extrinsics (configuration.imuToCameraLeft)
{
  "acceleration":{"x":3.1929334554640985e-06,"y":-1.8542926966551022e-06,"z":-4.7221780476648234e-07},
  "angularVelocity":{"x":0.0015828333562240005,"y":0.012700891122221947,"z":0.00035301301977597177},
  "orientation":{"w":0.20955791688410802,"x":0.6385671367191919,"y":-0.7166392482573564,"z":-0.18640114051633144},
  "position":{"x":0.006880179754191055,"y":-0.02585324999779014,"z":-0.0037064156909441524},
  "status":"TRACKING","time":343134.285796941,
  "velocity":{"x":-0.1518426175218836,"y":0.050841540677380274,"z":0.0363924090447811}
}
…

Pak jsem si nechal vypisovat jen pozice a trošku mával kamerou nad stolem:

{'x': -9.319226940036552, 'y': 1.5651737606558058, 'z': -5.689111896116633}
{'x': -9.724962378082667, 'y': 1.683750553335214, 'z': -5.987711949231651}
{'x': -10.173431395097694, 'y': 1.8181065640771044, 'z': -6.323567343157043}
{'x': -10.596265664774739, 'y': 1.947684970617886, 'z': -6.645771182786724}
{'x': -11.028292374467366, 'y': 2.0827255306275148, 'z': -6.980379856466121}
{'x': -11.50425102807769, 'y': 2.2345457195224334, 'z': -7.355377866839724}
{'x': -11.956292577500529, 'y': 2.3815888137119883, 'z': -7.717576736330567}

hmm, to moc nevypadá jako v metrech?! No asi je třeba udělat ten první krok pořádně a nastudovat si readme. Jak znám Jirku, tak u tohoto povrchního pokusu rozhodně nezůstal a více to prozkoumal. Konkrétně ještě posílal link na vio_gnss.py, což by měla být kombinace GPS s vizuální odometrii a to má to blízko k jeho článku o Ardusimple RTK3B.

22. ledna 2024 — OSGAR driver

V rámci vytahování „kostlivců ze skříně”, aneb co vše by se hodilo na nového robota, došlo znova na OAK-D kamery. Chěl jsem si napsat driver pro OSGARa, ale Jakub mne minulý týden dostal, že už přece dávno existuje!

Ano, je tam nějaký config/test-oak-camera.json, ale uvnitř jsem viděl IP adresu, tak jsem předpokládal, že bude fungovat pouze na PoE kamery, co Jakub na ČZU používá. A není tomu tak.

(osgar) md@md-ThinkPad-P50:~/git/osgar$ cat config/test-oak-camera.json
{
  "version": 2,
  "robot": {
    "modules": {
      "app": {
          "driver": "osgar.drivers.oak_camera:OakCamera",
          "init": {
            "fps": 10,
            "is_color": true,
            "is_depth": true,
            "laser_projector_current": 1200,
            "is_imu_enabled": true,
            "number_imu_records": 10,
            "disable_magnetometer_fusion": false,
            "cam_ip": "169.254.1.222",

            "mono_resolution": "THE_400_P",
            "color_resolution": "THE_1080_P",
            "color_manual_focus": 130,

            "stereo_median_filter": "KERNEL_3x3",
            "stereo_mode": "HIGH_ACCURACY",
            "stereo_extended_disparity": false,
            "stereo_subpixel": false,
            "stereo_left_right_check": true
          }
      }
    },
    "links": []
  }
}

po spuštění:

(osgar) md@md-ThinkPad-P50:~/git/osgar$ python -m osgar.record –duration 10 config/test-oak-camera.json
2024-01-17 23:10:13,192 __main__   INFO     /home/md/git/osgar/test-oak-camera-240117_221013.log
2024-01-17 23:10:13,230 __main__   INFO     SIGINT handler installed
2024-01-17 23:10:13,752 osgar.drivers.oak_camera WARNING  IP 169.254.1.222 was not found!
2024-01-17 23:10:13,752 osgar.drivers.oak_camera INFO     Found devices: 1.6
2024-01-17 23:10:13,752 osgar.drivers.oak_camera INFO     Used the first available device.

a následně:

(osgar) md@md-ThinkPad-P50:~/git/osgar$ python -m osgar.logger test-oak-camera-240117_221013.log
 k                 name    bytes | count | freq Hz
----------
 0                  sys      803 |  5 |   0.5Hz
 1            app.depth 36361514 | 71 |   6.7Hz
 2            app.color 25732424 | 71 |   6.7Hz
 3 app.orientation_list    38570 | 70 |   6.6Hz

Total time 0:00:10.574191

Na první pohled to vypadá, že je tam vše … tak asi není co dělat.

RGB obrázek přes OSGAR driver

hloubková data

p.s. přidám si sem ještě poznámku, že na druhém počítači to tak snadné nebylo:

[2024-01-26 16:19:36.660] [depthai] [warning] Insufficient permissions to communicate with X_LINK_UNBOOTED
                                              device having name "1.3". Make sure udev rules are set

RuntimeError: No available devices

a hodí se použít instalační skript, který obsahuje:

# Allow all users to read and write to Myriad X devices
    echo "Installing udev rules…"
    echo 'SUBSYSTEM"usb", ATTRS{idVendor}"03e7", MODE="0666"' |
                 sudo tee /etc/udev/rules.d/80-movidius.rules > /dev/null
    sudo udevadm control –reload-rules && sudo udevadm trigger

… případně viz instalační návod

p.s.2 ještě úplně výhra to není, protože na Patovi to teď funguje, jen když nejprve připojím kameru a pak PCAN

10. února 2024 — Two Towers

Dnes jsem si konečně chvíli hrál s Patem, jenom jízda 1 metr tam a zpět. Vpředu má teď namontovanou OAK-D kameru s úhlem 20 stupňů dolů (viz Multi Angle Joint). Další úloha je vcelku triviální: jezdi tam a zpět, ale pokud bude v cestě překážka, tak zastav. A to, že je cesta blokovaná překážkou má program zjistit z hloubkových OAK-D dat.

A teď se už pomalu dostáváme k zápletce o „Dvou věžích”. Do cesty jsem si dal dopravní kužel (to je zase jiná hra, který z robotů Pat nebo Rocker první dokáže 30 minut jezdit od kuželu ke kuželu, přímá viditelnost). A když se koukám na nasbíraná data, tak vidím toto:

RGB obrázek

hloubkový obrázek

RGB obrázek

hloubkový obrázek

Hmm, je to očekávané?? Možná ano, ale mne to minimálně překvapilo.

26. února 2024 — Staronoví manažeři a přehrávání videa

Bude to už pomalu 14 dní, co jsem zkoušel následující kód z luxonis webu:

from depthai_sdk import OakCamera
with OakCamera(replay='https://www.youtube.com/watch?v=Y1jTEyb3wiI') as oak:
    oak.replay.set_loop(True)  # <— Enable looping of the video, so it will never end
    color = oak.create_camera('color')
    nn = oak.create_nn('vehicle-detection-0202', color)
    oak.visualize(nn, fps=True)
    oak.start(blocking=True)

Realtime anotování YouTube videa

Tenkrát mi to padalo na oak.replay.set_loop(True), ale když jsem tento řádek zakomentoval, tak to na připojené OAK-D kameře v reálném čase detekovalo autíčka z YouTube videa.

A dnes jsem řešil detekci kuželu (na PC fungovala, na OAK-D zatím stále nikoliv) a narazil v dokumentaci na výměnu manažerů:

https://docs.luxonis.com/projects/sdk/en/old_sdk_managers/getting-started/ (BlobManager, NNetManager, atd.)

vs.

https://docs.luxonis.com/projects/sdk/en/latest/oak-camera/ (OakCamera vládne všem)

Stará detekce kuželů dále odkazovala na Yolov7 Luxonis Detection (asi fork) a tam v main.py půlka importů nefungovala. Vysvětlení je částečně na diskusním fóru cca před rokem.

A co bylo tedy špatně na mém kódu? Verze depthai-sdk. Používal jsem github DepthAI, ale fakticky jsem měl i balíček nainstalovaný (verze 1.9.4). Po upgrade na nejnovější (verze 1.13.1) už set_loop() funguje a stejně tak třeba nastavení konfigurace kamery … ale to snad příště.

4. března 2024 — Detekce kuželu pomocí YoloV7

Trošku se děsím, že se dostávám do vývojové fáze mých studentů před dvaceti lety, kteří, když dostali úkol, tak místo aby se nad ním zamysleli, rovnou hledali řešení na webu. S tou „moji” detekcí kuželů je to stejné! Vycházel jsem z modelu Coneslayer, který mi fungoval na PC, ale odkazovaná OAK-D varianta už ne (viz Staronoví manažeři ...).

Možná bych ještě udělal jednu odbočku pro ty, kdo jsou na tom jako já — nazval bych to Slon zahradníkem, aneb kříženec Slona v porcelanu s Kozlem zahradníkem. NNeurotickému světu dominuje několik firmem a z toho vyplývají nejrůznější důsledky. Vycházím s „vtipného” popisu, kterak snadno a rychle konvertovat pytorch model na Movidius/OAK-D. To je skoro na tabulku:

Firma	Nástroj	Fromát souborů
Facebook	Pytorch	.pt a .pth
Microsoft	ONNX	*.onnx
Intel	OpenVino	.bin, .xml, *.blob
Google	Tensorflow	.tf, .tflite, …
NVidia	TensorRT	??

Jako ve správném kapitalistickém světě se ty firmy nemají rády a tak přechod od jednoho k druhému je dost kostrbatý, pokud vůbec jde (jsou tam i technické rozdíly, ale o nich zatím nejsem schopen nic říci). Typicky to vyžaduje nějakou obskurní verzi, nejlépe v dockeru, která ale zase funguje pouze pro některé verze modelů (?).

Co jsem to chtěl? Jo pointa této předehry je v tom, že YOLO je postaveno na Pytorchi.

Přemmýšlím, jestli Cimrmanovsky neprozradit konec celé detektivky? Asi jo, oni nám jinak diváci zůstavají sedět …

git clone https://github.com/luxonis/depthai-experiments.git
cd depthai-experiments/gen2-yolo/device-decoding
python main.py -config ~/git/Coneslayer/coneslayer.json -recording ~/git/osgar/follow-path.mp4

(zase pozor u configu mají být dvě pomlčky! staré TODO web parser, aby to nebylo interpretováno jako škrtnutý text)

Přiběh začíná tak, že PavelJ řešil rychlost neuronky na Robotour. A právě kvůli zmiňovaným konverzním problémům to dal na github, jestli není problém jen u něj. Já jsem pro model coneslayer_openvino_2021.4_6shave.blob nemohl přímo pustit původní skript, tak jsme to na pravidelném callu zkoušeli v Pavlově prostředí. Nekreslilo to žádné detekce (ano, má rozpoznávací schopnost zda něco funguje je dost chabá) a tak došlo na ladění a tím jsem call zcela zabil a všem účastníkům se ještě jednou omlouvám.

Na výstupu sítě bylo 48672 floatů — co to je? Resp. na výstupu nebylo nic, ale když člověk zavolal in_nn.getAllLayerNames(), tak získal nápovědu, že výstup není output, ale jedna z variant ['output1_yolov7', 'output2_yolov7', 'output3_yolov7']. Dobře, takže to neni jen 48672 floatů, ale 18*52*52 floatů. Lepší? Když je to celé na hromadě, tak není jasné, zda 18 je ta první dimenze nebo poslední (ano, mohla by být i prostřední, ale to by nám snad neudělali). Yolo jede na „mřízce detekcí”, tj. těch 52x52 bude ta mřížka a 18 budou detekce. Jsou to bounding boxy, tj. pozice x, y, velikost w, h a pak důvěryhodnost detekce, ale že by tam měli 14 typů kuželů??

Další den Jirka doporučil si udělat vlastní blob konverzi: Vezmi ten onnx model a zkonvertuj si ho pomocí Luxonis blobconverteru sám https://blobconverter.luxonis.com/. Nastav -mean_values=[0,0,0] -scale_values=[255,255,255]. Tak vznikl nový blob. Jirka lehce naznačil „co se všechno může pokazit”, resp. co vše může být jinak. Barvy nejsou 0 až 255, ale třeba 0 až 1 nebo -0.5 až +0.5. Uspořádané jsou buď RGB nebo BRG. Obrázek může vyžadovat jistou velikost např. 416x416. Data obrázku jsou buď 3x416x416 nebo 416x416x3. Ještě jsem na něco zapomněl? Jirku nic nezastaví, takže odpověď byla

img = cv2.imread(str(args.input_image), cv2.IMREAD_COLOR)  # BGR, HWC
img = cv2.resize(img, (args.width, args.height))
img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB)  # RGB, HWC
img = img.transpose(2, 0, 1)  # RGB, CHW
img = numpy.expand_dims(img, 0)  # NCHW, i.e. including a "batch" dimension.
img = (img / 255.).astype(numpy.float32)  # [0..1] range

… no mne to tenkrát přišlo skoro vtipné, že tam byly úplně „všechny věci co se pokazit můžou” — Murphy by byl spokojený.

Ještě psal, že ta síť, resp. ONNX varianta dává nahlédnout pod … jak se to dnes korektně říká? … kapotu:

Zajimave je, ze kdyz si zobrazim ONNX variantu modelu v http://netron.app, vypadaji vystupy jinak, nez co jsme videli v tom xml.

1. Jsou ctyri. Tri nepojmenovane, ktere vypadaji (skoro, ne uplne!) jako ty v tom xml. A jeden "agregovany", ktery z tech tri vznike preskalovanim a slepenim a ktery se jmenuje "output".

2. Ty tri nepojmenovane jsou vicerozmerne a maji tvary jako 1x3x56x56x6. Tj, ta divna osmnactka je asi ve zkutecnosti 3x6. Ta 3 mi unika, ale 6 je neco, co bych cekal, kdyz mam x, y, w, h plus dva typy kuzelu.

3. Ten agregovany "output" ma rozmer 1x1064x6. Tj. 6 zustane, ostatni dimenze se splacnou.

Zkusil jsem pustit ten ONNX model na CPU, ale zatim uplne nechapu skalu hodnot v tom "output". Jsou mimo 0..1, ale moc male na to, aby to byly pixely ve 416x416 obrazku.

Jirka se asi bude zlobit, že to nebylo ke zveřejnění, ale … snad mi to odpustí. Výsledek vypadal takto:

Detekce kuželu přes ONNX

Spousta malých obdělníčků. Znova jsem koukal na yolo popisek a zmiňují tam jednak tu mřížku:

YOLO divides an input image into an S × S grid. If the center of an object falls into a grid cell, that grid cell is responsible for detecting that object. Each grid cell predicts B bounding boxes and confidence scores for those boxes. These confidence scores reflect how confident the model is that the box contains an object and how accurate it thinks the predicted box is.

a dále NMS:

One key technique used in the YOLO models is non-maximum suppression (NMS). NMS is a post-processing step that is used to improve the accuracy and efficiency of object detection. In object detection, it is common for multiple bounding boxes to be generated for a single object in an image. These bounding boxes may overlap or be located at different positions, but they all represent the same object. NMS is used to identify and remove redundant or incorrect bounding boxes and to output a single bounding box for each object in the image.

To Jirka zmiňoval a já moc nechápal o co jde … ale je to způsob, jak z těch mnoha detekci (confidence level 0.999!) získat jednu velkou. Teď už přeskočím na konec (za chvíli budu muset do práce) … s tvrzením „Vrah je slon” (jj, pondělky bývají náročnější) … a zkonvertuji alespoň data nahraná Patem.

Hmm, tak asi později — nemám teď u sebe OAK-D a mezi desítkami parametrů nevidím ukládání výstupu:

(depthai) md@md-ThinkPad-P50:~/git/depthai-experiments/gen2-yolo/device-decoding$ python main.py -h
usage: main.py [-h] [-conf CONFIG] [-recording RECORDING] [-rgbr RGBRESOLUTION]
               [-rgbf RGBFPS] [-monor MONORESOLUTION] [-monof MONOFPS] [-fps FPS]
               [-defaultRes {None,min,max}] [-isp ISPSCALE] [-sharpness SHARPNESS]
               [-lumaDenoise LUMADENOISE] [-chromaDenoise CHROMADENOISE]
               [-manualFocus MANUALFOCUS] [-afMode AFMODE] [-awbMode AWBMODE]
               [-sceneMode SCENEMODE] [-abMode ANTIBANDINGMODE]
               [-effectMode EFFECTMODE] [-dct DISPARITYCONFIDENCETHRESHOLD]
               [-lrct LRCTHRESHOLD] [-sig SIGMA] [-med {0,3,5,7}]
               [-lrc STEREOLRCHECK] [-ext EXTENDEDDISPARITY] [-sub SUBPIXEL]
               [-maxd MAXDEPTH] [-mind MINDEPTH] [-sbbsf SBBSCALEFACTOR]
               [-openvinoVersion {2020_3,2020_4,2021_1,2021_2,2021_3,2021_4,2022_1,UNIVERSAL}]
               [-xls XLINKCHUNKSIZE] [-tun CAMERATUNING] [-dev DEVICEID]
               [-usbs {usb2,usb3}] [-irDotBrightness IRDOTBRIGHTNESS]
               [–irFloodBrightness IRFLOODBRIGHTNESS]
…

16. března 2024 — Software syncing

Dnes jsem se zase něco naučil — od Jirky, jak jinak.

OAK-D kamera nějak běží, detekuje a reportuje kužely (a loguje v OSGARovi), ale když pak chci detekce visualizovat s původními obrázky, tak mám problém:

python -m osgar.logger oak-cone-detection-240315_203533.log -stream oak.detections  oak.color \
                                                            -format "{timestamp} {len(data)}"

0:00:03.442914 219488
0:00:03.487640 4
0:00:03.489948 214840   <====
0:00:03.517288 309346
0:00:03.540213 301433
0:00:03.566320 4
0:00:03.566519 290162
0:00:03.589637 4
0:00:03.599398 299662
0:00:03.615203 304556
0:00:03.638670 4
0:00:03.664591 4
0:00:03.664854 283100
0:00:03.681872 222737
0:00:03.713446 4
0:00:03.724757 4
0:00:03.743658 733428
0:00:03.747007 375482
0:00:03.776240 4
0:00:03.787632 4
0:00:03.790691 386878
0:00:03.812691 408704

… prostě mi přišly tři obrázky za sebou a k čemu se váže ta detekce z času 3.566320?! Jirka to komentoval: Dataframy z OAKu obsahují i timestamp a sequence id. Podle sequence id by to mělo jít párovat se vstupním obrázkem. … a je to přesně tak … viz Software syncing. Přidal jsem sekvenční číslo do OSGAR driveru pro OAK-D kameru (rovnou i pro depth) a výsledky detekce z neuronky je teď možné relativně snadno napárovat v použitým vstupním obrázkem. Ale … sekvenční čísla pro depth jedou v „jiném rytmu” a tak jsem raději rovnou doplnil i ten timestamp_us:

seq_num = packets[-1].getSequenceNum()  # for sync of various outputs
dt = packets[-1].getTimestamp()  # datetime.timedelta
timestamp_us = ((dt.days * 24 * 3600 + dt.seconds) * 1000000 + dt.microseconds)

OSGAR používá msgpack a ten nemá Pythonovský datetime.timedelta v základní sadě. A je škoda ukládat floaty, když vím, že zdroj je v mikrosekundách. Výsledek?

5        oak.depth_seq     1864 | 166 |   8.3Hz
6        oak.color_seq      341 |  31 |   1.5Hz
7   oak.detections_seq      341 |  31 |   1.5Hz

OSGAR time, OSGAR stream, [seq_num, timestamp_us]
0:00:03.472923 6 [0, 163893263641]
0:00:03.516000 7 [0, 163893263641]
0:00:03.518708 6 [2, 163893313635]
0:00:03.547843 6 [3, 163893338631]  <==
0:00:03.567436 5 [0, 163893348213]
0:00:03.569827 6 [4, 163893363629]
0:00:03.596117 7 [2, 163893313635]
0:00:03.596373 6 [5, 163893388627]
0:00:03.619423 7 [3, 163893338631]  <==
0:00:03.619587 6 [6, 163893413624]
0:00:03.646627 6 [7, 163893438618]
0:00:03.650795 5 [1, 163893448204]
0:00:03.666352 7 [4, 163893363629]

18. března 2024 — Debugging DepthAI pipeline

Přiznám se bez mučení — synchronizace obrázku se seznamem detekcí nebylo vše, co mne v sobotu trápilo. I když jsem nahrávání pouštěl několikrát dokola, tak typicky u 31. obrázku se mi to „kouslo” (ale hloubková data se nahrávala dál). Když jsem vypnul nahrávání hloubkových dat, stále stejný problém. Když jsem snížil FPS (počet snímků za sekundu) na 1, tak stejně po 30 sekundách konec.

Jako tonoucí jsem hledal „stéblo” na stránkách Luxonisu a našel Debugging DepthAI pipeline. Úvodní věta, currently, tools for debugging the DepthAI pipeline are limited, mne příliš nepovzbudila (fakticky lze zapnout debug výstup na konzoli a to je asi vše), ale byla tam i zmínka ... which would allow users to debug a “frozen” pipeline much easier, which is usually caused by a filled up blocking queue. Prostě že probém je typicky plná blokovaná fronta.

V mém případě to byl xoutRgb, který jsem vůbec v upravené verzi OSGAR driveru nečetl. Sice měla být jako „neblokovaná”, ale 32 už je možná moc? V každém případě po vyčítání i této fronty, případně úplné odstranění xoutRgb, to najednou jede jak má!

A zároveň jsem pochopil, proč v tom jejich demu jsou dvě výstupní okna. V popisu ColorCamera modulu je zmíněno, že preview - ImgFrame - RGB (or BGR planar/interleaved if configured), mostly suited for small size previews and to feed the image into NeuralNetwork. Prostě zmenšený obrázek se používá jak pro „normální náhled” tak jako vstup do neuronek! A toto preview zobrazovalo to druhé okno. Proč? Protože pokud chcete na vstupu mít 416x416 pixelový obrázek se zachováním poměrů stran, musíte řezat. A to pěkně ukazuje obrázek isp.jpg:

výřez pro preview - převzato z Luxonis webu

A když bboxy pronásobíte pouze výškou a posunete o polovičku rozdílu výšky a šířky dostanete konečně to co chcete:

Detekce kuželů přes OSGAR HIL (hardware-in-the-loop)

p.s. už jenom drobné pozorování, že pokud byl původný záběr kamery úzký, tak po tom ořezu pro detekci bude ještě užší … ale jak to vylepšit si nechám do nějaké ver2.

11.května 2025 — 13 šlupek (SHAVE) - Custom model v OAK-D

Blíží se Robotem Rovně 2025 (ukončení registrace je zítra! (2025-05-12)) a tak jsem se pokusil na Patovi rozchodit detekci cesty pomocí neuronky od PavlaJ, která běžela přímo na kameře. Přestože jsem to měl naservírované na zlatém podnose: tady je model.blob a k tomu skriptík oak_sil.py, pomocí kterého je možné na kameře zpracovat už nahrané JPEGy. Co více si přát, obzvlaště když příklad rovnou fungoval?

Konverze do OSGARa ale už tak hladká nebyla a o tom tedy dnešní „příspěvek”, než to zase zapomenu. Problém byl v:

Blob compiled for 13 shaves, but only 12 are available in current configuration.

Cože?! Tak nejprve odtajnění, co je SHAVE? Do dnes jsem o WikiChip nevěděl, ale odkaz shave_v2.0 vypadá zajímavě: Streaming Hybrid Architecture Vector Engine v2.0 (SHAVE v2.0) is an accelerator microarchitecture designed by Movidius for their vision processors. SHAVE-based products are branded as the Myriad family of vision processors. Jsou tam i detailnější diagramy a popisy, pokud by někoho zajímala architektura.

Druhý vstup je Robotics Vision Core 2 (RVC2), kde jsou detaily o OAK-D Pro konfiguraci (případně viz dotaz na fóru How many shaves available in OAK-D pipeline?). Zkrátím to: OAK-D Pro má 16 SHAVE jader.

Co s tím? Poradil mi Jirka: ,,Máš tam hloubku? Zruš ji."" A ano, používal jsem na robotovi hloubková data a když jsem na ně rezignoval, tak to jelo.

Závěr? Když jsem dnes sepisoval tento odstaveček a chtěl copy and paste hlášek z poznámek, tak jsem si to pořádně přečetl:

Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.8/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/home/md/git/osgar/osgar/drivers/oak_camera.py", line 315, in run_input
    with dai.Device(pipeline, device_info) as device:
RuntimeError: NeuralNetwork: Blob compiled for 13 shaves,
                    but only 12 are available in current configuration.
NeuralNetwork allocated resources: shaves: [0-11] cmx slices: [0-11]
ColorCamera allocated resources: no shaves; cmx slices: [13-15]
StereoDepth allocated resources: shaves: [13-13] cmx slices: [12-12]
ImageManip allocated resources: shaves: [15-15] no cmx slices.

… takže to i vypisovalo kdo co chce. Jako vedlejší efekt jsem získal zářez do Marathonu - 1.1km, takže dobrý.

Detekce cesty pomocí 13 SHAVE jader

p.s. volný „překlad” SHAVE na šlupku … no je to hlavně holení, ale také odřiznout tenký plátek, tj. slupku a šlupka zní lépe — seznam slovnik

7. května 2026 — Vytloukání AI AI (dříve klínu klínem)

Loni na podzim Luxonis vydal novou DepthAI v3. Upgradeovat krátce před DARPA Triage Challenge by byl holý nesmysl (stačilo už to, že jsem se tam přihlásil) a tak na upgrade došlo až po návratu. Nová verze slibovala nová kouzla (SLAM, … vlastně už nevím), ale půl roku uteklo a když došlo „na lámání chleba” (tedy robotů, viz Dobývání hradu), tak příprava byla nedostatečná a pro YOLO modely jsem musel přeskakovat zpět na verzi 2.

Dnes jsem ještě nabuzen předešlým neúspěchem, tak jsem chtěl rozchodit nějaký triviální příklad s vlastní neuronkou (ona tedy není tak vlastní, ale to teď pominu). A drhne to. Fest. Tak jsem pustil druhý počítač a „nechť se trápí AI”, proč já?! Možná jsem to měl spíše nazvat vytloukání DepthAI AI? V každém případě je zajímavé to sledovat. Ještě bych možná na svoji obhajobu použil fakt, že verzi 3.0 jsem přeskočil, 3.1 jsem rozchodil základ z příkladu (asi hlavně nové features), 3.3 padala, 3.5 vypadala rozumně, ale to YOLO jsem nedotáhl a teď zkouším 3.6.1 … resp. vedle Elena. Takže první pozorování je, že dokumentace je nedostatečná (dříve bývala lepší). A tak místo hledání na Google hledá uvnitř zdrojáků. Na každý krůček si napíše jednořádkový prográmek a rovnou ho zkouší s připojenou kamerou. A jelikož je to detekce v obrázku (přihodila si tam sama opencv-python), ale pouštět to z CMD line se špatně ověřuje, tak alespoň python -m py_compile main.py (pro mne novinka).

No a já v mezičase nemám moc co dělat, než mačkat Enter a sledovat její myšlenkové pochody, tak vedle sepisuji tento … hmm blábol? výlev? pamflet? Trošku škodolibě mne těší, že už se dostala do fáze, kde jsem byl já a padalo to (v OSGARu):

[2026-05-07 16:28:20.553] [depthai] [error] Communication exception
 - possible device error/misconfiguration.
 Original message 'Couldn't read data from stream: '__x_6_depth' (X_LINK_ERROR)'
[2026-05-07 16:28:20.553] [depthai] [error] Communication exception
 - possible device error/misconfiguration.
 Original message 'Couldn't read data from stream: '__x_1__out' (X_LINK_ERROR)'
[2026-05-07 16:28:20.552] [depthai] [error] Communication exception
 - possible device error/misconfiguration.
 Original message 'Couldn't read data from stream: '__x_9_out' (X_LINK_ERROR)'
[1844301091A3BD0800] [1.6] [1778164102.050] [host] [warning] Closed connection

[1844301091A3BD0800] [1.6] [1778164102.050] [host] [warning] Attempting to reconnect. Timeout is 10000ms

No teď zkouší ImageManipConfig, aby neuronku nakrmila obrázkem o správném rozměru … nevím, zda se mi jí podařilo přesvědčit, ať si to pouští sama, že to můžu zavřít sám … vypadá to, že ANO.

22:17 — už mne přestalo bavit mačkat Enter a stejně tak poslouchat notifikace odpojení/připojení kamery po restartu

22:20 — přitvrdila taskkill /F /IM python.exe … o co, že mi odstřelí i jiné puštěné konzole … jj

22:22 — zapomíná pouštět uv run main.py

22:24 — už zase zabíjí všechny Pythony (jako chápu RuntimeError: No available devices)

22:27 — zabíjení všech Pythonů už je běžná věc, tak to chce volat před každým puštěním …

This version is optimized for stability on Windows with DepthAI 3.6.1 and serves as foundational "Hello World" for your specific model and hardware setup. … skoro se jí bojím říci, že to nefunguje a stále to crashuje … ještě je možné, že ta kamera už je také úplně poblázněná?

Hmm, vypnul jsem a zapnul kameru … a chovalo se to jinak! Možná to je ten primární zakopaný pes a proto se to tak blbě ladí! Aneb pokud jedno puštění ovlivní všechny následující, tak je třeba VŽDY vytahovat USB a začít od nuly …

Asi to pro dnešek uzavřu hláškou, od stejné AI: „Vytloukání klínu klínem“ je přísloví označující řešení problému (jednoho klínu) jiným, novým problémem (druhým klínem). Situace se často zhorší, místo aby se vyřešila. Typicky se tento obrat používá pro nebezpečnou dluhovou spirálu, kdy si lidé berou další půjčky na splacení těch předchozích.

p.s. ještě jsem použil silnější AI (větší klín) a ta to během pár sekund opravila, aby to nepadalo … jen ty kužely to stále nedetekuje. Ale to určitě bude nějaká ptákovina … je čas jít spát.

kontaktní formulář

Matty (dvojčata)

2024-12-08T00:00:00Z

Mattyho domovské stránky

Matty M-01

Obsah

Blog / Matty (dvojčata)

8. prosince 2024 — Představení robota

Pokud jste včera byli na vánočním RoboDoupěti, tak jste mohli nového robota vidět naživo. V opačném případě doporučuji Mattyho domovské stránky nebo přímo link na video testovací jízdy.

O čem bude tento blog? Bude o Mattyho dvojčatech, resp. jeho klonech. Jestli se ptáte, jak je rozlišíte, tak podle barvy. Ve frontě je žlutá, oranžová, červená, světle modrá, zelená tmavá, zelená světlá, růžová … zatím to vidím „růžově”. Pro dnešek tedy jen převzaté foto součastek Mattyho M1:

Matty v součastkách

10. prosince 2024 — General Driver for Robots

Nemůžu si pomoci, ale když vidím General, tak mne znovu a znovu pobaví vzpomínka na registraci na SubT. Bylo tam na výběr:

Team lead
General member

… no generál nejsem, tak jsem dal team lead … a tak jsme měli dva registrované vedoucí.

No nic, zpátky k Mattymu a jeho řízení. Martin Locker použil Waveshare driver.

Waveshare General Driver for Robots (převzato z waveshare.com)

Až tedy budu mít všechny díly pohromadě (zatím mám serva, kola a tyto řídící desky), tak bude třeba do robota nahrát firmware, připadně ho někdy updateovat. Není nad to si to vyzkoušet „dokud to ještě nehoří”. Ono to asi také úplně triviální nebude, protože hlavní podpora je pro Windows a na roboty mám primárně Linux/Ubuntu (staré).

Poradil jsem se s AI, protože jinak mi vyhledávání dávalo spíše odkazy na obchody, kde desku koupit, a klíčové slovo Ubuntu to téměř ignorovalo. Perplexity navrhovalo buď Arduiono IDE nebo PlatformIO. Beginner-friendly vs. advanced development … no s Arduinem jsem kdysi něco na Windows dělal, ale nechť se tváříme, že děláme pokročilý vývoj. Po pravdě si nepamatuji, co MartinL má, ale skoro bych tipoval právě PlatformIO …

Překvapilo mne, že PlatformIO je postanevo nad Microsoftím Visual Code (ano, daleko od Windows jsem neutekl), ale opravdu podporuje i Linux.

sudo apt install ~/Downloads/code_1.95.3-1731513102_amd64.deb

Instalace PlatformIO extension se zasekla na tom, že to nemohlo najít Python 3.6+ … systémový mám prastarý Python 3.8, ale faktický problem byl v python3-venv. Naštěstí to varování je už na úvodní stránce: Linux Users: To ensure a smooth experience with PlatformIO, it is essential to have the python3-venv package installed on your system. … tak pak už to bylo smooth.

Ještě dvě drobnosti:

USB kabel je Download interface Type-C … tj. takový ten symetrický, placatý
u výběru HW při vytváření projektu je třeba vybrat ESP32 Dev Module (to říká návod, fakticky je tam ještě něco navíc)

20. prosince 2024 — Předvánoční upoutávka

Je to již týden, co mi MartinL poslal foto, jak přibývají dílky na Matty-M02:

Díly na Matty-M02

A včera psal: ... tak jsem si dnes hrál na Popelku a počítal šroubky (189 ks na jednoho Mattyho). "Stavebnice" M2 je tedy hotová (chybí jen jeden konektor - snad Dan přiveze). Pokud bys chtěl dárek pod stromeček, tak si pro něj můžeš přijet.

Kdyby auto fungovalo a nebylo to „trošku z ruky” tak bych asi hned vyrazil a vánoce by byly v plném dětském nadšení. Hmm … ještě to asi zvážím.

p.s. možná bych měl doplnit, že MartinL sestavil i kompletní seznam použitých součastek a ty už jsem minulý týden v pěti baličcích vyzvedl. Byly to tyto internetové obchody:

https://www.laskakit.cz/ — WaveShare serva a řídící deska
https://www.krabicky-pro-elektroniku.cz/ — plastové krabičky
https://www.rcobchod.cz/ — kola
https://www.bighobby.cz/ — baterky
https://www.hadex.cz/ — emergency STOP tlačítka

5. ledna 2025 — Vánoční nadílka

Včera jsem si vyzvednul a dnes rozbalil balíček:

Matty M02 v krabici

… a ano, byl to „dárek”, který jsem si opravdu přál

jednotlivé díly

Fascinovalo mne to provedení — ano, toto není (zatím?) seriově vyráběná stavebnice, ale neumím vyjádřit to potěšní nad promyšlenou konstrukcí, dokonale pasujícími díly atd. Podle návodu jsem si zatím poskládal kloub a jedno kolo:

kloub

servo

zapouzdření serva

"noha" s kolem

Kabel k servu mne lehce zaskočil, ale hned na druhý pohled to dává smysl — jsou to serva na společné sběrnici, takže je možné je zřetězit (MartinL to teď potvrzuje: U serva jsou oba konektory zcela totožné. Takže to můžeš dát do libovolného.).

Pokračování asi zítra …

p.s. mimochodem, MartinL vzal M01 přes svátky na projižďku venku

kolo s pneumatikou

všechna čtyři kola

první rám

M02 podvozek s krabicemi

11. ledna 2025 — Nastevení serv a kalibrace kloubu

Toto dokumentační foto asi MartinaL moc nepotěší, ale … takto vypadá aktuální stav:

Matty M02 se zapojenými servy

První pozorování, že žena má pravdu, a že je na čase si konečně stůl trošku uklidit. Druhé pozorování je, že na Mattym nejsou plastové krabice, přestože 4mm díry jsem již provrtal (vzadu je vidět spodek vrtačky ), ale … na nastavení serv se musím stejně dostat ke každému zvlášť. Defaultně mají totiž všechna ID=1.

Návod od MartinaL (kopírují si ho sem pro sebe, až mail zapadne v nenávratnu):

1. do desky s ESP nahraješ ten kód (přeposílání ze sériáku na sériák)
2. připojíš kabel od serva do desky - jsou tam dva identické konektory, tedy do libovolného z nich
3. připojíš napájení - kabel se stop tlačítkem (musíš mít připájený ten konektor k baterce), zapneš napájení
4. připojíš usb kabel k PC (jako v 1.)
5. pustíš sw od feetechu: https://www.theremino.com/wp-content/uploads/files/SmartMotors/Feetech_Motors_Programming_Kit_V1.1.zip FD_1_9_8_1.exe viz. /articles/digitalservo/
6. vybereš COM port a Open
7. tlačítko Search a mělo by to najít jedno servo s ID 1
8. na záložce programming zvolíš registr 5 ID, vpravo dole do editačního pole napíšeš nové ID a dáš save
9. mám serva číslovaná: 1 - levé přední, 2 - pravé přední, 3 - levé zadní, 4 - pravé zadní
10. dále upravíš registry:
33 Work mode na 1 (režim řízení rychlosti)
37 Velocity P Gain na 50
39 Velocity I Gain na 25

DONE.

Ten Freetech program je celkem fajn (byl tedy třeba pustit na Windows), ale s každým servem jsem si trošku zatočil — pravá se pro hodnotu 100 točí pomalu dopředu, levá pak dozadu. Snad je to očekávané.

Druhá úloha byla kalibrace kloubu, viz PR Test joint encoder #4. I toto fungovalo hned.

Zbývá toho ještě hodně, ale …

po mechanické stránce vyvrtat 20mm a 22mm díry do krabice (moje děrovací pilky začínají na 32mm)
napsat OSGAR driver pro Mattyho

… pak bych chtěl ujet 1 metr po kabelu z notebooku. A následně počítač na robotovi a OAK-D kamera.

14. ledna 2025 — První ujeté centimetry

Asi je zase pomalu na čase si udělat pár poznámek a odreportovat aktuální stav. Asi skočím rovnou na konec na video se STOP tlačítkem. Já vím, žádný trhák a asi ani organizátoři DTC z toho nebudou extra odvázaný. Ale je to milestone, jede to samo s „pseudo-připájenou” baterkou. A krabice jsou také přidělané …

první pohyb

Jako cesta k tomuto stavu nebyla úplně přímočará a co vidíte je deep fake nebo soft fake?

Připomněl bych si také „mučící nástroje”, které byly použity k vytvoření děr (pro STOP tlačítko a dole pro kabeláž):

nástroje na děrování krabice

… jako nejsem si jist, že to byly ty správné nástroje (asi jsou na dřevo), ale chvíli odpadávaly umělé špony a pak se objevila doslova vysekaná díra.

Chtěl jsem popisovat Mattyho protokol, ale asi na to teď už nemám sil, tak to z názvu smažu (jako jsem před půl hodinou odmazal Odroid H4+). Co ale můžu přiznat je, že M02 na tom videu nakonec ještě nejede s OSGAR driverem, dokonce to ani neřídí žádný počítač! Na Win7 jsem nastavil rychlost serv na 500 tiků vpravo a -500 tiků vlevo, vytrhnul USB kabel, zavřel krabici a dal na zem. ESP32 mi totiž po USB píše: Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Zaprvé mne to uráží a zadruhé nevím, co to je.

19. ledna 2025 — M02-OSGAR Go 1m

Matty M02 už jede z OSGARu. Rozlousknul to MartinL (viz Simple servo reading test #6), aneb „nic není zadarmo” a externí knihovna na obsluhu serv je dost mizerná. Zajímavé bylo, že když to zkompiloval MartinL ve starém prostředí, tak to fungovalo, ale když jsem to zkompiloval já v novém (později i MartinL doinstaloval druhé prostředí), tak se objevil Guru (chápej „Guru Meditation Error”).

Matty odometrie

… no s tím kreslením budu muset něco udělat. :-( O co se autor pokoušel, byla demonstrace jak je úhel v kloubu provázán s poloměrem kružnice, po které se kloubový robot pohybuje. Ve zkratce záleží na vzdálenosti k kloubu, směr robota odpovídá tečně a tak dostaneme tan, snad. (jako moc se nesměju, protože když jsem viděl jak počítám odometrii u Pata, tak to vůbec nechápu a nejspiše je to špatně!)

Enkodery pro jízdu 1m rovně

Enkodery při couvání 1m

Hmm, zajímavé! Asi by to chtělo ještě X-krát zopakovat, ale vypadá to, že když jede robot dopředu, tak se neztrácí žádná data, ale při cování je to celkem divoké?! Ještě jestli jsem neměl omylem zmáčknuté STOP tlačítko? Příště.

p.s. video Matty M02-OSGAR Go 1m and Yennie

Matty M02 and Yennie

28. ledna 2025 — Matty M03 a DTC-WS2

Začnu obrázky:

Krabice s díly M03

Nohy, resp. serva

Kloub

… asi jsem mohl udělat menší náhledy, ale dnes toho textu moc nebude, tak ať tam visí alespoň ty obrázky.

Tentokrát jsem začal s kolama a „malou seriovku”, tj. místo skládání jednoho kola po druhém jsem 4x opakoval daný úkon. A šlo to rychleji. Následoval kloub a potvrzuji, že je to rozhodně ta nejsložitější část Mattyho. A teď už to „jenom dodělat”, tj. šroubovat a nevykecávat se tady.

Ten druhý kód DTC-WS2 je zkratka za zprávu: Hello Team Robotika, Thank you for your submission. We are pleased to inform you that you have qualified for WS2. We look forward to your participation in the coming weeks. DARPA Triage Challenge Team

A pro dnešek bych to uzavřel řádkem v Pythonu:

>>> datetime.date(2025, 3, 7) - datetime.date.today()
datetime.timedelta(days=38)

30. ledna 2025 — Odroid na palubě

Dnes bude asi zápis ještě kratší než posledně. Nejprve Matty M03 je v zásadě zkompletovaný:

Zkompletovaný rám M03

Ano, zase se mi podařilo přidělat kola vzhůru nohama — pozná se to podle senzoru kloubu, který by měl být nahoru … a nebyl, ehm. Opraveno.

Další zádrhel je pozice magnetu, jestli jsem ještě něco dalšího neprohodil:

Width:   188 Angle: -356.74
Width:   184 Angle: -357.10
Width:   175 Angle: -357.89
Width:   165 Angle: -358.77
Width:   154 Angle: -359.64
Width:   135 Angle: -361.40
Width:  4280 Angle:  -0.17
Width:  4263 Angle:  -1.31
Width:  4258 Angle:  -2.11
Width:  4244 Angle:  -3.34
Width:  4232 Angle:  -4.39
Width:  4220 Angle:  -5.36

… měření pro skoro přímý směr … což ale bude potřebovat SW fix na singularitu (MartinL psal, že je magnet přilepený, takže HW řešení bych zatím ignoroval).

Dále jsem „tuneloval” USB kabel z jedné krabice do druhé — i tady je mi nyní úplně jasné doporučení, ať to udělám hned na začátku při sestavování kloubu. U Ruďocha/Červenáčka jsem to už udělal, ale v době sestavování Zelenáče jsem ještě krátké USB kabely neměl pořízené.

Pak to bylo krátké „kvantové cvičení” s Odroidem (řídící počítač) — kupodivu po startu WiFi hned fungovala a připojila se sama na domácí síť (to mi posledně nešlo, ale třeba to bylo tím rebootem?). Ale když jsem připojil kameru, tak jsem ztratil spojení! Hmm, mám pocit, že to stíní anténu WiFi USB dongle, ale jistotu nemám. Dobrá zpráva ale je, že když jsem dal USB kabel kamery do vedlejší skupiny, tak jsem měl jak kameru, tak WiFi.

A ted rychle finále — jízda s OSGARem, kamerou a palubním počítačem: https://youtu.be/fIONpq9k2Ak

2. únor 2025 — Neviditelný pes

Pro dnešek by to bylo jen pár drobností s tím, že většina je ještě „rozpracovaná”:

funguje rsync pro synchronizaci logů z Matty 02 do notebooku (aktuální base station)
přidání ssh klíčů pro snazší připojování a kopírování z robota nebo updateování gitu
nahrání pár vzorků pro detekci překážek
jednoduchá vizualizace pomocí Open3D (AI nápověda).

… no a pak už jen ten neviditelný pes … aneb naše Yennie opravdu nemá roboty ráda:

Yennie z M02

Uznávám, že v tom statickém obrázku níže skoro nic vidět není … ale ten bílý flek (chybějící body) jsou proběhnuvší pes. Ve zkratce pokud nejsou hloubková data, tak je to asi překážka, není úplně špatné rozhodnutí.

Neviditelný pes

No z kratičkého videa mám pocit, že ten problém bude někde jinde. Ono to bílé místo bude spíše hloubkový stín, co probíhající pes zakrývá…

p.s. zapomněl jsem ještě na zprávu, že Matty M03 už jezdí jak má … kompletace čeká na Odroida a provrtání děr do plastové krabice.

24. únor 2025 — Od zdi ke zdi

V sobotu mi MartinL zapojil nové nárazníky (viz foto na domovské stránce). U sebe jsem měl jenom M03 (M02 zůstal ve škole v rámci příprav na Field Robot Event 2025), takže mne ještě čeká copy and paste výzva na zeleném M02.

V rámci „výměny” jsem do M03 získal integrovanou GPS — data sbírá ESP a kompletní NMEA zprávu přeposílá do řídícího počítače. Zatím jsem udělal jen statický test na chatě a tam se GPS chytla bez problémů.

A teď k tématu „od zdi ke zdi”. Přišlo mi, že je to nejjednodušší test, zda nárazníky fungují. Dokud nedostaneš info o kolizi (z předních nárazníků), jeď maximální rychlosti vpřed. Následně couvej maximální rychlostí, dokud nenarazíš zadními nárazniky. Možná trošku příliš hrubá síla, ale … ano, zbaběle jsem nechal původních 20cm/s … ale člověk úplně nemusí být matematik, aby si spočítal, že při update 10Hz to od okamžiku kontaktu bude ještě 2cm rvát do zdi!? No asi nejsnazší řešení je zvednout frekvenci komunikace — tu si definuje řídící počítač, takže je to změna jednoho čísla. Varianta podmiňovat to rovnou na ESP se mi zatím moc nelíbí, ale možna na to také dojde.

Hmm, asi by to chtělo „bourací video”, aby byla nějaká akce (v lidarview to takový odvaz není) … tak příště.

7. března 2025 — Kompletace nárazníku a Otloukánek2

Dnes měl být Den D odletu s M02 a M03 do států na DTC Workshop Systems 2. Ale padlo to. A asi bych měl rovnou připsat naštěstí.

Asi bych sem mohl sepsat seznam „klacků”, které se mi ležely na cestě, od 19ti školení (ty jsem nakonec minulý týden dodělal), přes problémy s ubytováním a perličku bych si nechal kreditní kartu — taková ptákovina, co je potřeba, aby se člověk dostal z Atlanty do 100 mil vzdálené Perry, sigh. Objednal jsem ji v lednu. Včera jsem bance napsal, jak to vypadá a odpověď mne překvapila: Omlouvám se pokud se k Vám tato informace nedostala, Vaši žádost nebylo možné dostatečně posoudit a z tohoto důvodu byla odvolána. Důvodem odvolání je to, že účet není využíván na běžné denní placení (jídlo v obchodech, výdaje domácnosti, léky, drogerie apod.). — toto roboti potřebují?! No nic, asi půjdu v září pěšky, nebo zkusím najít nějakou půjčovnu, co by akceptovala debetní karty. F*ck them. Tušil bych za tím AI, co rozhoduje o udělení úvěru (ano, kreditní karty nehledejte pod záložkou platební karty ale úvěry).

No nic, to chce klid a téma by mělo být jiné. Nicméně jsem ve fotkách za poslední měsíc našel i několik pokusů „jak zabalit 2 roboty”, aby splňovali limity letecké společnosti a kupodivu nejlepší varianta (když nepočítám rozebrání na součastky) je jejich stackování:

štosování robotů

Pak jsem tam objevil ještě toto starší foto:

montážní díly k servu

… ono by to bylo i srandovní, kdyby to nebylo k pláči. No prostě jsem na M03 přídělal kola a přišlo mi zbytečné rozbalovat všechny pytlíčky, co se dodávají k servům. Pak mi ale dvě kola sotva držela a to řízení rychlosti nic moc. No odpověď je na obrázku — jsou to různé typy uchycení a na hnané kolo samozřejmě potřebuji to ozubené … jen už to člověk, resp. já, nevidí.

Odloukánek2 — zase jsem jezdil od zdi ke zdi, ale už ne na kabelu, ale z Odroida v přední krabici. Také už jsem namontoval posledně chybějící díl — průhledný nárazník.

průhledný nárazník

Tentokrát jsem pokusy i dokumentoval … a je to divné! Ale asi je třeba uploadovat i nezajímavá videa, jinak by člověk měl pocit, že je vše zajímavé … tak nechť:

Něco je rozhodně špatně. Kontakty cvakají, ale nedostatečně? Jako kolečka podkluzují o sto šest, ale …

p.s. první pozorování je, že 50Hz je fakticky stále 10Hz, protože jsem změnil frekvencí posílání příkazů, ale nikoliv frekvenci posílání informačních zpráv

Druhé pozorování je, že to není nutně v detekci změny stavu nárazníku, ale v době reakce na změnu:

python -m osgarlogger matty-wall2wall-250307_122952.log –stream platform.bumpers_front
                                               platform.bumpers_rear app.desired_steering
0:00:00.072924 5 False
0:00:00.073010 6 False
0:00:00.073809 1 [200, 0]
0:00:00.073921 1 [200, 0]
0:00:35.598887 5 True
0:00:35.599225 1 [-200, 0]
0:00:38.605356 5 False
0:00:38.605618 1 [-200, 0]
0:00:40.234255 6 True
0:00:40.234612 1 [200, 0]
0:00:43.531562 6 False
0:00:43.531821 1 [200, 0]
…

pomalá reakce na náraz v čase 35.5s

p.s.2 včera jsme si na toto téma vyměnili pár mailů a pravděpodobný vinník je plynulá regulace a rampy. Tj. když dostane ESP32 a následně servo příkaz jeď opačnou rychlostí, tak díky postupnému snižování interní požadované rychlosti ještě do příkážky chvíli více tlačí. Navíc narazí trošku bokem, takže se ještě zapojí regulace korekce natočení kloubu, jak je celkem pěkně vidět z následujícího obrázku (rozdíl po sobě jdoucích enkoderů):

enkodérové rychlosti jednotlivých serv

14. března 2025 — STOP módy a záhada hlavolamu (nevyřešená)

STOP módy trošku zní, jako „dost bylo těch hadrů!” No myslel jsem tím novou funkci rozšiřující S-příkaz o parametr, jakým způsobem má robot zastavit (viz PR 12). Nové možnosti jsou:

mode = 0 … STOP
mode = 1 … BREAK
mode = 2 … POWER OFF

MartinL jednotlivé módy dokumentoval i pomocí videa. … možná bych ještě doplnil info, že na podlaze je čára a v okamžiku, kdy jí robot přejel tak Martin mačkal vzdálené STOP tlačítko s vybraným konkrétním módem. V základním módu STOP robot v klidu zastaví, postupně snižuje rychlost a udržuje úhel kloubu. Pro BREAK dupne na brzdy až je z toho převodovka neštastná. A konečne POWER OFF by mělo imitovat vypnutí napájení serv.

A teď ten problém/záhada: MartinoviL to funguje bez problémů, jak dokumentuje to 11s video. Posílá pouze příkaz jeď a následně STOP a watchdog má nastaven na 3s (aby nemusel posílat příkazy stále dokola) … případně viz commit, kde jsem teď vrátil watchdog z 3.15s zpět na 150ms.

Jak se to chová? Když dám jízdu 1 metr a cestou narazím, tak to vypadá úplně stejně jako na MartinověL videu. Dokonce jsem to zkusil rychlosti 0.5m/s.

náraz při 0.5m/s

Svislé čáry jsou změna stavu nárazníků s tím, že omylem jsem zadním nárazníkem byl natlačen do zdi. Je vidět okamžitá reakce všech serv a zastavení během 300ms.

Když ale jezdím „od zdi ke zdi”, tak graf vypadá takto (i s použitím STOP=2 a okamžité reakce na nově příchozí packet):

od zdi ke zdi

Zde skoro 2 sekundy vůbec nic nedělá!

MartinL teď píše: tak jsem si zkusil přesně to, co zkoušíš ty a nakonec mám stejný problém. Tedy pokud mám nastaveno posílání dat 10 Hz a povely posílám taky 10 Hz, tak celkem v pohodě. Ale když to zvednu na 50 Hz a jen přijímám, tak ok. Ale když i stejnou frekvencí začnu posílat příkazy, tak to začne výrazně váznout (zpoždění až cca 2 s jako u tebe). Vypadá to, že je problém v tom převodníku usb - uart, resp. ovladači. Matně se mi vybavuje, že jsem to už někde řešil, že je nějak problém v tom, že to posílá po usb po paketech a je nějak nutné vyvolat to odeslání (jinak čeká na větší počet znaků, resp, timeout). Zkusím zapátrat, co s tím.

Stále se dohadujeme k čemu je OSGAR dobrý, tak teď mi možná MartinL narhál: To je ten problém, že ty to nevidíš realtime (ale z logu). Když se "zpožďuje" komunikace, tak sice okamžitě zareaguješ na nárazník, ale ta zpráva, že je nárazník aktivní přišla třeba sekundu po realitě. (moje poznámka byla, že jsem od ESP dostal potvrzeno, že STOP přijal — 0x80 bit je nově nulový)

0:00:01.624386 4 [99, 0, 20]
0:00:01.713402 11 1.7111320300027728
0:00:01.713704 2 b'U\x06\x17G\xc8\x00\x00\x00\xd4'
0:00:01.715929 12 b'U\x14ZI\x84\x02\xd8-\x14\x05\xb4\x00X\x00a\x07O\x06\x0e\x08\x83\x08;'
0:00:01.726237 12 b'U\x02\x17A\xa6'
0:00:01.726642 5 True
0:00:01.726772 2 b'U\x03\x18S\x02\x90'
0:00:01.726856 4 [115, 0, 20]
0:00:01.727066 1 [-200, 0]
0:00:01.727488 2 b'U\x03\x19S\x02\x8f'
0:00:01.736495 12 b'U\x02\x18A\xa5U\x02\x19A\xa4'
0:00:01.813773 11 1.8115024130092934
0:00:01.814137 2 b'U\x03\x1aS\x02\x8e'
0:00:01.818223 12 b'U\x14[I\x04\x02\xfc/\x00\x008\x00O\x00i\x07V\xaa\x06\x12\x08\x88\x08\x1bU\x02\x1aA\xa3'
0:00:01.818572 4 [127, 0, 21]
0:00:01.914088 11 1.9118210389860906
0:00:01.914474 2 b'U\x03\x1bS\x02\x8d'
0:00:01.920407 12 b'U\x14\\I\x04\x02\xfc/\x00\x00\xf9\xff,\x00i\x07S\x06\x10\x08\x88\x08\x81U\x02\x1bA\xa2'

… no možná se mi nepodaří vás přesvědčit, že je OSGAR úžasný, ale … zkusím to.

Ještě pro „dekódování” dumpu výše potřebuji jména jednotlivých kanálů:

python -m osgar.logger matty-wall2wall-250313_192818.log 
 k                    name bytes | count | freq Hz
----------
 0                     sys  3097 |  17 |   0.6Hz
 1    app.desired_steering    54 |  12 |   0.4Hz
 2       platform.esp_data  3303 | 330 |  10.8Hz
 3 platform.emergency_stop     0 |   0 |   0.0Hz
 4         platform.pose2d  1924 | 280 |   9.2Hz
 5  platform.bumpers_front     7 |   7 |   0.2Hz
 6   platform.bumpers_rear     5 |   5 |   0.2Hz
 7     platform.gps_serial  4116 |  56 |   1.8Hz
 8            gps.position   308 |  28 |   0.9Hz
 9        gps.rel_position     0 |   0 |   0.0Hz
10           gps.nmea_data  5012 |  28 |   0.9Hz
11              timer.tick  2745 | 305 |  10.0Hz
12              serial.raw 14619 | 638 |  20.9Hz

Total time 0:00:30.513614

tj.

0:00:01.624386 4 [99, 0, 20]
0:00:01.713402 11 1.7111320300027728
0:00:01.713704 2 b'U\x06\x17G\xc8\x00\x00\x00\xd4'
0:00:01.715929 12 b'U\x14ZI\x84\x02\xd8-\x14\x05\xb4\x00X\x00a\x07O\x06\x0e\x08\x83\x08;'
                                            … stavová informace (I) a mód 0x84, tj. RUNNING a narazil
0:00:01.726237 12 b'U\x02\x17A\xa6'
0:00:01.726642 5 True                       … narazil přední nárazník
0:00:01.726772 2 b'U\x03\x18S\x02\x90'      … okamžitě odešli S-příkaz power off(2)
0:00:01.726856 4 [115, 0, 20]
0:00:01.727066 1 [-200, 0]           … vyšší vrstva říká, že máme couvat, ale to se 2s po nárazu ignoruje
0:00:01.727488 2 b'U\x03\x19S\x02\x8f'
0:00:01.736495 12 b'U\x02\x18A\xa5U\x02\x19A\xa4' … potvrzení přijetí S-zprávy
0:00:01.813773 11 1.8115024130092934              … 10Hz časovač
0:00:01.814137 2 b'U\x03\x1aS\x02\x8e'            … následné odeslání S-příkazu
0:00:01.818223 12 b'U\x14[I\x04\x02\xfc/\x00\x008\x00O\x00i\x07V\xaa\x06\x12\x08\x88\x08\x1bU\x02\x1aA\xa3'
                                       … přijatá stavová informace (I) a 0x04 znamená, že už není RUNNING
0:00:01.818572 4 [127, 0, 21]
0:00:01.914088 11 1.9118210389860906
0:00:01.914474 2 b'U\x03\x1bS\x02\x8d'
0:00:01.920407 12 b'U\x14\\I\x04\x02\xfc/\x00\x00\xf9\xff,\x00i\x07S\x06\x10\x08\x88\x08\x81U\x02\x1bA\xa2'

… ten první sloupec je časová známka uložení do souboru (čas PC, bohužel nemáme interní čas ESP — TODO).

16. března 2025 — Megabota

Fakt jsem nepoučitelný. :-( Tuto chybu už jsem udělal už tolikrát, až je to opravdu smutné. O co jde? Viz záhada s nárazníky … koukal jsem dnes znova do logu, protože co jsem popisoval byl přechod z 0x84 na 0x04, tj. když robot zareagoval na nárazník. Ale co jsem zjistil byla v logu tato zpráva:

0:00:00.815948 12 b'U\x14OI\x80\x02\xf8.\x0e\x01\xad\x00\x00
                    \x00\xc4\x06\xb7\x05\x83\x07\xf1\x07\xe8U\x02\x0eA\xaf'
0:00:00.918261 12 b'U\x14PI\x84\x02\xcc-z\x03\x9e\x00\x00\x00
                    \xd4\x06\xc7\x05\x93\x07\x01\x08pU\x02\x0fA\xae'

prostě už v čase 0.918s příšla zpráva o nárazu a nic, žádná reakce?! A co hůř, když jsem si nechal vypisovat pořadí jednotlivých zpráv, tak v čase 0.918 jsem dostal:

0:00:00.918261 I 73 0x80 b'II\x80\x02(/\xe6\x00\x86\x00\x1a\x00\x84\x06w\x05D\x07\xb0\x07'

Cože?! Zase neumím dekódovat ty ESP znaky??!

Ne, problém je jinde. Dat z Mattyho chodí více a shlukují se do větších bloků. A jeden blok může tedy obsahovat více než jednu zprávu! V reakci na přijaté bajty ale vždy pouze rozšířím buffer již došlých zpráv a pokud obsahuje alespoň jednu kompletní, tak jí zpracují a končím. Matty ale teď posílá zpráv více. Jednak to jsou potvrzení došlých příkazů a dále třeba GPS data. Prostě velmi rychle začne „operovat v prehistorii”. Řešení je prosté — zpracuj všechny zprávy v bufferu, jen pak zase ale může systém trošku zadřít. Oprava ale až zítra …

17. března 2025 — Bugfix PR #1006

Tak jo, přestanu naříkat nad kombinaci ESC znaků s délkou zpráv a rezignuji na nejnovější zprávu — prostě jí zpracuji až přijde další a interní buffer budu udržovat včetně ESC a SYNC znaků. Pokud nevíte o čem mluvím, tak snad během dneška (resp. určitě než tento odstaveček zveřejním) vytvořím pull request na githubu.

https://github.com/robotika/osgar/pull/1006

Je už pozdní odpoledne, mám ještě cca 15min na vše, takže se alespoň pokusim o upload dokumentačních videí, že Matty už je „boring robot”. Jinými slovy, že děla co má.

https://youtu.be/HM0RxSb_Vcc — od zdi ke zdi
https://youtu.be/FEe-a--oZPg — od zdi ke zdi šikmo
https://youtu.be/sGIGQWTw9Vc — random walk po kuchyni

4. září 2025 — Zapojení LEDek

Zapojení konektorů

jednokabelový LED modul vlevo a dvoukabelový vpravo

12. září 2025 — Matty M04 a M05

Matty M04 a M05

Je to už týden, co na „základnu” dorazili nově Matty M04 a Matty M05. Tentorkát je MartinL už i rovnou sestavil, za co jsem mu moc vděčný — ta stavebnice v zimě byla fajn, ale teď už to vše „pomalu drne” a DTC je za 14 dní.

V robotech chyběly pouze řídící počítače, baterky a OAK kamery. Během kompletace jsem narazil na dvě drobnosti — plastový výstupek z krabičky překážel Odroidu (myslím, že má v tom místě ze spodu paměť), a nové baterky byly cca o 2mm širší, takže se vedle Odroida do přední krabice nevejdou! První problém šel poměrně snadno a rychle vyřešit pomocí vybrační brusky Renovátor. Když jsem jí před lety dostal od ženy „pod stromeček”, tak jsem prskal, co je to za nesmyslný nástroj … ještě s nálepkou Znáte z TV reklamy! Ale po letech jsem názor změnil a na danou úlohu to bylo jak dělané.

Renovátor v akci

Odroid baterka na placato

Falešná kamera

Dárečky pro M02 a M03

Kvarteto

STIX1 - společné testování

A baterku? No tu jsem dal zatím naplacato …

Čtveřice má za sebou první společné testování a zítra je (M04+M05) snad beru na Robotour …

5. května 2026 — Matty Dobyvatel

Minulý pátek (1. května 2026) jsme si to s M03 (Bloody Matty, neplést s Bloody Mary) a M04 (Fifinka) celkem užili. V rámci testování na Dobývání hradu jsme vyrazili na Dívčí Kámen a bylo to celkem maso. Dva roboty jsem vzal především proto, že na zříceninách není elektřina (ve skutečnosti je to ještě lepší, dokonce není ani mobilní signál!) a tak jsem chtěl mít prostor pro více pokusů. Ono vlastně byla výzva už se jenom dostat z parkoviště cca 2km vzdáleného — ideální pro Marathon … ostatně viz nejdelší autonomní jízdu. Pak už následovaly staré kamené schody a marnost nad marnost.

Musím uznat, že mne stále překvapuje průchodnost terénem pro takto malého robota. Používal jsem Jirkovu RedRoad detekci cesty, co běžela na OAK-D Pro kameře. Hloubková data jsem (zase) ignoroval a tak velký kámen vypadá někdy jako super dlážděná cesta … TODO later. Na hradě jsem chtěl pak pouštět kód na RoboOrienteering, ale málo jsem ho oprášil z loňských Mariánských Lázní. Sigh. Navíc upgrade na depthai3 pro OSGARa ještě není plně funkční a to se ukázalo jako fatální u YOLO neuronek, ano např. natrénované detekce kuželu. Také IMU data z kamery jsem nesbíral … a vůbec seznam věcí, co je třeba udělat, po testování rychle přibýval.

Kde se Matty moc nechytal byly situace, kdy mu podklouzlo jedno (nebo více) kol a při rychlosti 0.5m/s už nedokázal udžet požadované natočení pasivního kloubu. Jakub navrhoval, že by mohlo pomoci snížit rychlost, pokud jsem schopen prokluz detekovat — uvidíme. Čekám, že minimálně úhel kloubu „uskočí” a to by mohl být ten potřebný signál.

Další, doslova „do očí bijící”, nedodělek je stabilita videa, resp. hrubé poskakování (po kamenech). Vím, že Jirkovi se dělá špatně z té uzávěrky kamery (progressive scan (?) … no prostě není to global shutter), takže i chudák neuronka. Uvidíme, zda s tím AI programátorka něco vykouzlí, ale pokud ne, tak raw data zatím vypadají takto:

kontaktní formulář

DTC Phase 3

2025-12-19T00:00:00Z

https://triagechallenge.darpa.mil/ — oficiální stránky soutěže

DARPA Triage Challenge má podobný časový rozvrh jako již ukončená SubT Challenge. Soutěž bude trvat 3 roky, jsou tři základní kategorie (Primary System, Primary Virtual a Secondary Data) a účastníci jsou jak DARPA sponzorované týmy, tak self-funded týmy.

Obsah

Blog

19. prosince 2025 — Summary of Potential Major Rules Changes

Chvíli jsem přemýšlel, zda začínat tento 3. DTC Blog, když se do USA v roce 2026 na 95% nechystáme, ale … pokud budu ignorovat těch 5%, tak minimálně můžu dát šanci potenciálnímu týmu, který by mohl přehlednout …

„Ale ty plány byly vyvěšeny…“
„Vyvěšeny? Musel jsem je nakonec jít hledat do sklepa.“
„Tam je oddělení, kde je vyvěšují.“
„S baterkou.“
„Asi byl zrovna výpadek proudu.“
„A schody zřejmě taky vypadly.“
„Podívejte se, našel jste to oznámení nebo ne?“
„Ale jo, našel. Na dně zamčené registračky, a tu vecpali na zrušený záchod
a na dveře dali ceduli Pozor, leopard!.“

zdroj … abych citoval oblíbenou knižku.

První informace, která je veřejná a mohli jste jí přehlédnout je, že registrace končí až 2. února 2026 (dřive byla do 2. ledna 2026). To znamená, že ještě máte cca měsíc čas — ono na registraci je třeba, vedle extra formulářů, doplnit ještě několik video nahrávek demonstrující funkčnost vašeho řešení, takže na poslední den bych to určitě nenechával!

Druhá informace přišla včera (12/18/25, 14:09) mailem z DTC fóra (jen pro zvané, resp. potřebujete přístup = zamčená registračka) a téma bylo zmiňované Summary of Potential Major Rules Changes. Po loňsku bych asi zdůraznil slovo Potential! … tenkrát jsem si naivně přestavoval, že když v pravidlech je, že systémy musí být autonomní, tak musí být autonomní a ne že Version 2g danou sekci zase vypustí! Ale tím vás nechci demotivovat … jako je zvláštní se registrovat na soutěž u které neznáte pravidla, ale už mne to tak nepřekvapuje. Zatím na fóru není ani „hrubý nastin pravidel” s výjimkou zmíněného Ph3 - Systems - summary of major changes-for DISTAR.pdf Proč to zmiňuji je, že vedle úplně jiného formátu se mění i původní plán (toto je ze starých pravidel verze 2g):

Původně plánované ceny

Za Data je nově jenom jedna cena za 1. místo (ušetříme 500,000 USD) … to není ta vzrušující motivační zpráva.

V kategorii Systems jsou nově 4 Gates (v překladu to nebudou brány, spíše u chodících robotů to byly nějaké módy/schopnosti chůze?) v rámci Lane 1. A Lane 2 je pak spolupráce strojů s mediky. Do Lane 2 postupují pouze 4 nejlepší týmy. Ptáte se, kde jsou ty „dobré zprávy”? No jsou tam extra ceny pro self-funded teams, podobně jako v prvních dvou letech soutěže. Jen aby ta klička nebyla v tom, že tyto nesponzorované týmy se nejprve musí dostat do semi-finále a pak mají nárok na cenu (dříve 2. a 3. cena) … (pravděpodobně ušetříme 950,000 USD). Suma sumárum to asi nebyla dobrá zpráva a nebo jsem jenom škarohlíd a ceny pro self-funded teams platí i když se nedostanou do Lane 2? V prezentaci je: 1st and 2nd prize are for best self-funded teams on Lane 1 and 2. … ta Booleovská algebra!

Závěr — pokud uvažujete o účasti, tak to moc dlouho neodkádejte a zaregistrujte se na fórum, ať máte přístup k zamčeným registračkám!

p.s. Fórum (22/12/2025):

Is the best self-funded team eligible for a prize if it finishes on 5th place, i.e. it will not be among 4 best teams and will not score in Lane 2?

Think about it as 3 separate prize pools. The cavate with the below is that a team must beat the minimum to be eligible for prizes

Gate prizes: anyone is eligible to win in gates 1-4, the prize goes to the best on that particular gate
Lane 1 prizes: the top two self-funded teams (based on weighted sum of score for gates 1-4) are eligible for prizes.
Grandprize: anyone is eligible to win, based on performance in all lanes.

So it is possible if the top 4 teams in lane 1 were all funded, there would still be Lane 1 prizes for the top 2 self-funded teams (place 5 and 6).

15. leden 2026 — DTC3 Systems - Pravidla verze 3a

Včera večer mi přišel mail od DTC Team, jestli se chystáme na Challenge Event 3. Chvili jsme si dělali srandu, jestli tedy už jsou k dispozici alespoň pravidla (na uzavřeném fóru byla "alfa verze" od 6. ledna 2026) a … jsou už oficiální. Trošku mne to překvapilo, že bych čekal nějakou revizi po komentářích na fóru (za mne alespoň to datum na první stránce — ano, nestěžoval jsem si, tak bych měl teď mlčet), ale můžete se případně podívat na změny v bodování a úpravy finančních cen co jsem zmiňoval minule.

Jinak má odpověď byla: Robotika team se na DTC3-Systems momentalně nechystá.

p.s. také jsme dostali nahrávky ze všech (?) DARPA kamer z našich dvou soutěžních jízd loni v říjnu … ale bohužel z toho nemůžeme nic zveřejnit :-( … ne že by to bylo tak úžasné, ale je to trošku škoda a po sestříhání by alespoň byla vidět nějaká Matty akce. No nic.

5. únor 2026 — DTC3 Systems - Konec registrace týmů

Včera mi došlo, že už se nemusím trápit variantou výjezdu do USA na DTC3, protože registrace týmů skončila.

Někde na fóru jsem zahledl novější verzi pravidel, ale nemůžu to teď najít a oficiální jsou stale verze 3a. Ale vidím v mailech, že dnes je další deadline: Reminder to all teams - the qualification deadline for WS3 ends at midnight Feb 5th., kde WS3 je workshop systems 3 v Texasu.

14. dubna 2026 — DTC3 Systems - Opětné otevření registrace týmů

Nedá mi to a vlastně třeba by to někoho zaujalo? Před pár dny mi příšel mail:

Greetings, Thank you for your interest in the DARPA Triage Challenge (DTC). As we approach the Finals this November, we are extending the qualification deadline for new teams to June 28, 2026 . This extension applies to both the Systems and Data Competitions. A limited number of new teams will be accepted on a rolling basis. Acceptance will be at DARPA's discretion and based on the official qualification guide. If you would like to demonstrate your technology in standoff sensing or autonomy, please visit the Team Portal for detailed qualification requirements. Please note that a separate event qualification step will be required closer to the Finals.

Sincerely, The DTC Team DARPA Triage Challenge Website

A jinak? Před měsícem skončil Workshop System 3 a nikde nevidím nějaké výsledky, videa nebo fotografie (ty 3? v záložce media bych nepočítal). Podle odsunutí termínu registrací skoro o půl roku soudím, že se to až tak úplně nepovedlo, ale „čert ví”.

hele já to snad přivolal! Tak jim pískalo v uších, že poslali další mail:

[DTC Forum] [1 - General] May 6 2026 - DTC Workshop 3 Lessons Learned Meeting

Please mark your calendars for May 6th, 2026 from 9:30-3:00pm EST. This will be a virtual meeting to discuss experiences at Workshop 3, mainly focused on the Systems Competition. We will have a small segment for the Data Competition at this meeting. There will be a longer ‘lessons learned’ just for the Data Competition in early July. Registration information and agenda will be posted in this thread. … míněno na fóru pro registrované uživatele.

kontaktní formulář

MDEK1001

2022-03-09T00:00:00Z

MDEK1001 (zdroj Mouser.com)

Toto je vlastně druhý článek věnovaný UWB technologii. První část najdete v blogu o Pozyxu.

Obsah

Blog

9. březen 2022 — Balíček dorazil

MDEK1001 jsme si koupili s Jirkou přes Mouser (ještě tam mají 184 sad, tj. za týden zhruba podobné číslo prodali). Není to úplně levné (s posláním z USA, daněma a clem to stálo 6 576,55Kč (na webu 5 480,46 Kč), ale stále je to řádově levnější než Pozyx (1,050.00 EUR+doprava). V čem se tady obě sady liší? Častečnou odpověď jsme dostali před časem od Pozyx podpory, kde k jednotlivým bodům se budeme postupně vracet.

První pozorování je, že Pozyx krabiček je 10 (oprava 9) 5x kotva/anchor a 4x tag (ty jsem po pravdě ještě moc nepoužíval). MDEK1001 obsahuje 12 krabiček bez rolišení role. Pozyx tagy mají na sobě ještě IMU (9-axis inertial measurement unit), kotvy nemají nic. MDEK1001 by měl mít všude akcelerometry, pro detekci pohybu, a Bluetooth pro konfiguraci. Pozyx má krabičky pouze pro tagy, MDEK1001 je má pro všech 12 zařízení.

MDEK1001 Quick Start Guide doporučuje zapojit 4 kotvy v jedné rovině do obdélníka na zdroje, tag na baterku nebo USB powerbanku, stáhnout si Android aplikaci a můžete začít konfigurovat přes Bluetooth. Zatímco Pozyx s kabely fakt nešetří (5 zdrojů s kabely, 3 malé powerbanky, extra komunikační USB kabel), tak MDEK1001 obsahuje jediný USB kabel, 4x L-kové propojky a to je vše. S Pozyxem si tedy můžete začít hrát hned, ale pro MDEK1001 potřebujete ještě „zajít do obchodu” nebo „znárodnit” Pozyx.

Co se stane, když nebudu postupovat podle návodu a prostě tím jediným kabelem na flashování firmware DMW1001C modul zapnu? Vidim disco čtyř LEDek a dmesg říká:

[131295.467222] usb 1-6: new full-speed USB device number 13 using xhci_hcd
[131295.619237] usb 1-6: New USB device found, idVendor=1366, idProduct=0105, bcdDevice= 1.00
[131295.619243] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[131295.619246] usb 1-6: Product: J-Link
[131295.619249] usb 1-6: Manufacturer: SEGGER
[131295.619251] usb 1-6: SerialNumber: 000760154093
[131295.626959] cdc_acm 1-6:1.0: ttyACM0: USB ACM device

A teď kde je (sakra) ten příklad s terminálem pro komunikaci přes USB? Toto vypadá užitečně i když je to článek z roku 2018: minicom -D /dev/ttyACM0

DWM console

… i když se to se mnou začalo rozumně bavit až když jsem dal Hangup … a nebo to nějakou dobu nabíhá, nevím … ale na druhé straně je chatbot se kterým se dá pokecat.

dwm> si
[001155.990 INF] sys: fw2 fw_ver=x01030001 cfg_ver=x00010700
[001155.990 INF] uwb0: panid=x0000 addr=xDECAB827E225DC19
[001156.000 INF] mode: tn (pasv,twr,np,le)
[001156.000 INF] uwbmac: disconnected
[001156.000 INF] uwbmac: bh disconnected
[001156.010 INF] cfg: sync=0 fwup=0 ble=1 leds=1 le=1 lp=0 stat_det=1 (sens=1) mode=0
  upd_rate_norm=1 upd_rate_stat=100 label=DWDC19
[001156.020 INF] enc: off
[001156.020 INF] ble: addr=EF:24:D0:2E:0F:B3

dwm> ut
[001294.240 INF] uptime: 00:21:34.240 0 days (1294240 ms)

dwm> av
acc: x = -1776, y = 4160, z = 6608

dwm> utpg
utpg: pg_delay=xB5 tx_power=x456585A5 (pg_delay=xB8 tx_power=x446484A4)

dwm> nmg
mode: tn (pasv,twr,np,le)

Možná vhodný okamžik první iteraci přerušit.

p.s. jo jo, je tam příkaz help nebo jen ?, který vypíše asi 20+ příkazů „na hraní”

11. březen 2022 — Android a Bluetooth

Potvrzuji, že začátky s MDEK1001 úplně hladké nejsou. Rozhodl jsem se tedy postupovat podle návodu, věřte nevěřte. Stáhl jsem si tedy DRTLS_Manager_R2.apk (z Google Play byla odstraněna) a pokusil se to nainstalovat na starší Android telefon: There was a problem parsing the package. Hmm. Povolil jsem instalaci z jiných zdrojů, ale výsledek stejný.

Pak jsem si včera hrál s Bluetooth (jak z konzole přes USB nastavit tag/kotvu jsem úplně nepochopil a přes BT by to jít mělo). Existuje několik wrapperů jako decawave-ble, ale tam instalace skončila ERROR: Failed building wheel for bluepy.

Tak jsem přešel na nápovědu od Jirky: K tématu Bluetooth & Python: https://github.com/hbldh/bleak a https://github.com/pybluez/pybluez Jiné možnosti dost možná ani nejsou. Rozhodující nejspíš bude, co ti bude fungovat na Windows. Teoreticky obojí, prakticky možná ani jedno. Když jsem to zkoumal kolem Vánoc, vyšlo mi, tuším, "radši Bleak." Argumenty si úplně nepamatuji. Něco kolem API a něco kolem pybluez "not being maintained" a se souvistlostí se zastaralými tooly (hcitool).

Bleak opravdu vypadal „živější”, příklad fungoval, jen jsem pro UUID používal kódy z decawave_ble init tabulky.

import asyncio
from bleak import BleakScanner

async def main():
    devices = await BleakScanner.discover()
    for d in devices:
        print(d)

asyncio.run(main())

při zapnutém jednom zařízení ukázal:

5C:FB:7C:C6:B2:13: JBL Flip 4
24:FC:E5:6F:B2:C7: 24-FC-E5-6F-B2-C7
D6:DC:77:A5:C8:61: DW4D37
8C:79:F5:10:A5:E5: [TV] Samsung 7 Series (43)
53:62:1A:F4:32:35: 53-62-1A-F4-32-35
05:84:BC:18:E2:FB: 05-84-BC-18-E2-FB
F0:27:F0:09:B0:B8: F0-27-F0-09-B0-B8
6B:76:00:1B:A4:E6: 6B-76-00-1B-A4-E6
78:BD:BC:40:5B:BD: 78-BD-BC-40-5B-BD

jj, skoro to vypadá, že bych mohl sousedům vypnout televizi. A ano, to co hledáme, je DW4D37. Zatím asi nejzajímavější zpráva byla Device Info: bytearray(b'7M3\xfb\x08\xf3\xca\xde*\x00\xca\xde\x00\x00\x03\x01\x01\x00\x03\x01>\x97pQ\t\x1e\xaf\xce\x00') což v HEX vypadá lepší a prvních 8 bajtů je Node ID = 374d 33fb 08f3 cade. Nějaké indicie? Vypadá to na malé „indiány” a spodní/první bajty odpovídají identifikaci zařízení. Ale o moc dále jsem se nedostal.

A teď „Androidí rozuzlení” — oni to vlastně je v tom MDEK1001 Quick Start Guide:

podporovaná Android APK MDEK1001 verze

No můj starší telefon je Android 4.4, žena měla 5.0 a poslední na testování UWB má verzi 12. Tak úplně není divu, že s nabízenou verzi 6 a 7 to nemá žádný průnik …

Update 11-03-2022 9:53pm (Jirka)

Na mém když-to-funguje-tak-to-neupdatuj tabletu ta aplikace pustit jde.

První poznatek je, že Auto Positioning kotev při dvou kotvách nefunguje. Ta aplikace to ale neví, takže jí několik minut trvá, než vytimeoutuje. Naštěstí je tam i Cancel.

Druhý poznatek je, že při třech kotvách to trvá více než půl minuty.

Třetí poznatek je, že při třech kotvách v trojúhelníku se stranou lehce nad dva metry jsou vzdálenosti z Auto Positioning o deset až patnáct centimetrů špatně. To je na výstavní systém přímo od zdroje, s kalibrovanými zpožděními na anténách, podle mě docela slabota. Na druhou stranu, bylo to o několik týdnů rychlejší, než moje hrátky s BU01.

Na ovládání z tabletu přes Bluetooth, bez natahování propojovacích kablíků z konvertoru USB<->sériák, bych si taky zvykl docela rychle. Vlastně asi úplně nejvíc by se mi líbilo, kdyby ten DW1000 byl přímo v noteboku a měl bych k němu nízkoúrovňový přístup. Pak bych nemusel řešit ani kabely, ani dvě souběžné bezdrátové sítě vysávající baterky.

13. březen 2022 — uwg, uwt, uwi a les

Včera mne Jirka motivoval to zase zkusit, když jemu to vše hned fungovalo. Ty tajemné zkratky z názvu jsou skoro všechny příkazy ze skupiny UWBMAC a pokud je použijete, tak konzole začne vypisovat vzdálenost dvou krabiček.

Ale postupně. Nejprve přehled nápovědy z konzolové aplikace (nevím, zda už jsem zmiňoval, že je třeba pro přepnutí 2x po sobě stisknout Enter, viz dokumentace), sekce UWBMAC:

** Command group: UWBMAC **
nmg: Get node mode
nmp: Set UWB mode to passive
nmo: Set UWB mode to off
nma: Set mode to AN
nmi: Set mode to ANI
nmt: Set mode to TN
nmtl: Set mode to TN-LP
nmb: Set mode to BN
la: Show AN list
lb: Show BN list
nis: Set Network ID
nls: Set node label
udi: Show incoming IoT data
uui: Send IoT data
stg: Get stats
stc: Clear stats

nmg už jsem zmiňoval v prvním příspěvku, kde všechny krabičky vracely mode: tn (pasv,twr,np,le). Ne že bych tomu rozumněl, ale pasv zní dost pasivně, twr by mohlo být Two Way Ranging, zbytek netuším. Také to tn něco znamená a na tn.cz to asi nenajdete.

Teorie byla taková, že když doporučený postup přes Android a Bluetooth nakonfiguruje nejprve kotvy (AN bude nejspíše Anchor Node, takže to TN bude Tag Node, konec „záhady”), tak pak je možné lokalizovat tag vůči kotvám. To I my přišlo jako inicializační, jako kdo diriguje všechny kotvy v dané podsíti … ale to si budu muset znova nastudovat ať vás nematu. V každém případě po nmt se změnil stav na tn (act,twr,np,le) (aktivní tag?) a u druhé krabičky nmi byla odpověď ani (act,real). Pokud jsem tag znova zapojil do USB a napsal les (les: Show meas. and pos.) tak jsem získal tento výpis:

dwm> les
dwm> 4D37[0.00,0.00,0.00]=0.54
4D37[0.00,0.00,0.00]=0.49
4D37[0.00,0.00,0.00]=0.44
4D37[0.00,0.00,0.00]=0.56
4D37[0.00,0.00,0.00]=0.48
4D37[0.00,0.00,0.00]=0.49
4D37[0.00,0.00,0.00]=0.52
4D37[0.00,0.00,0.00]=0.42

Také la (výpis kotev) už něco začal dělat:

dwm> la
[000034.780 INF] AN: cnt=1 seq=x01
[000034.780 INF]    0) id=0000000000004D37 seat=0 seens=98 map=0000 pos=0.00:0.00:0.00
[000034.790 INF]

A ano, potvrzuji Jirkovu „předtuchu”, že se Pozyx s MDEK1001 nebude chtít vůbec bavit, minimálně zapnutou Pozyx kotvu to nevypisuje (i když si myslím, že po startu oba systémy používaji kanál 5 a preambuli velikosti 64) … ale to možná někdy později.

Mohl bych sem alespoň doplnit první fotky z rozbalování Qorvo (fakt se to čte kurvo?)

Qorvo krabice

tucet lokalizátorů

p.s. ještě jsem měl říci, že to nastavení tag/kotva/init zůstává platné i po vypnutí napájení

p.s.2 potvrzuji, že v tom návodu (quick start) vidím:

All RTLS units will initially appear as tags in "passive" UWB mode
Set "UWB" to "Active"
For any one of the anchors, check the "Initiator" box (there must always be one initiator in the network)

17. březen 2022 — Bridge node, panid a IoT data

V rámci včerejšího robotického callu jsme se trošku posunuli, resp. mne zase Jirka kousek poposunul. Sice výsledek je částečně z kategorie „Cimrmanovského foukání tabákového dýmu do vody”, ve smyslu „tudy ne přátelé”, ale uvidíme.

Pro mne první objev byl, co je to: B-node z nápovědy:

nmb: Set mode to BN
lb: Show BN list

Je k tomu totiž potřeba novější dokumentace (DWM1001_Gateway_Quick_Deployment_Guide.pdf), kde zmiňují nový typ nodu/uzlu a to bridge node. Je to krabička, která by měla umožnit napojení UWB sítě na klasický internet.

Příklad vícero gateway napojení

Bohužel se to nedá úplně snadno vyzkoušet, protože je k tomu třeba RaspberryPi3 a DWM1001 modul je třeba připojit přes piny. Nakonfigurovat ale node jako bridge node pomocí nmb jde a pak se objeví i při výpisu pomocí lb. Divné ale je, že tento výpis funguje pouze pro kotvy ale už ne pro tagy a přitom převzatý obrázek zmiňuje UWB link s tagem …

Možná jsem měl začít motivací, jak jsem se k tomu vůbec dostal? No chtěl jsem poslat pár bajtů z jedné krabičky do druhé a příkazy:

udi: Show incoming IoT data
uui: Send IoT data

vypadaly zprvu nadějně. Nikde o nich nebyla zmínka, tak znova Google a ta novější dokumentace:

Adding a gateway to a PANS network enables the possibility to exchange data other than location between gateways and nodes within the systems. This non-location data is called "IoT Data". From the web-manager, it is possible to send IoT data to a node under the node properties window, in the "messages" tab. The data sent to the tag can be observed on the UART shell after using the "udi" command. Data is sent as hexadecimal.

Tady si Jirka všiml klíčového slova tag (prostě pro anchors to nejspíše fungovat ani nemá). Bohužel z různých diskuzí (Receiving Tag position using a bridge, Bridge node and web manager) to vypadá, že bez HW úpravy bridge node nic poslat nepůjde.

Jirka našel ještě PANS R2: Some questions on the Gateway application of DWM1001 a How to communicate with listener (without using raspberry), tj. možná cesta existuje, ale bude poměrně trnitá …

A na závěr bych ještě zmínil tu panid (Personal Area Network ID), které lze nastavit pomocí příkazu nis a je součástí si (system info):

dwm> si
[000116.510 INF] sys: fw2 fw_ver=x01030001 cfg_ver=x00010700
[000116.510 INF] uwb0: panid=x0000 addr=xDECA2B75F6248207
[000116.520 INF] mode: tn (pasv,twr,np,le)
[000116.520 INF] uwbmac: disconnected
[000116.520 INF] uwbmac: bh disconnected
[000116.530 INF] cfg: sync=0 fwup=0 ble=1 leds=1 le=1 lp=0 stat_det=1
                 (sens=1) mode=0 upd_rate_norm=1 upd_rate_stat=100 label=DW8207
[000116.540 INF] enc: off
[000116.540 INF] ble: addr=E2:47:07:28:12:6E

… tj. zatím se držím defaultu=0.

17. leden 2023 — OSGAR driver a rychlost měření

Dnes to bude opravdu stručné — mám 10 minut, než to tady budeme muset opustit. Testoval jsem skoro po roce Qorvo UWB krabičky. Důvod? Pozyx mám doma a tam jsem se nestavoval, ale Qorvo balíček jsem měl při ruce. První pozorování: nic si nepamatuji! … tj. opět se potvrdilo, že není nad to si to někam (třeba sem) napsat.

Test přes minicom fungoval a relativně rychle jsem zjistil, co znamená modrá nálepka (tag) a co červená (kotva). Na vzdálenost je třeba se ptát tagů a to příkazem les. To také fungovalo, ale občas mi došla trpělivost a možná jsem výpisy zastavil. Ono se tím příkazem to jak zapíná tak vypíná a extra Enter zopakuje minulý příkaz.

Myslím, že stav dobře vystihla Jakubova hláška: „ono je to live?!” … když jsem se chtěl pochlubit, jak to pěkně funguje. Jak moc je to tedy "živé" lze nejlépe poznat z timestamp a k tomu máme OSGARa přeci …

0:00:06.547920 4 b'4D37[0.00,0.00,0.00]=0.37 \r\n'
0:00:16.545517 4 b'4D37[0.00,0.'
0:00:16.555737 4 b'00,0.00]=0.34 \r\n'
0:00:26.552047 4 b'4D37[0.00,0.00,0.00]=0.37 \r\n'
0:00:36.547780 4 b'4D37[0.00,0.00,0.00]=0.43 \r\n'
0:00:46.553412 4 b'4D37[0.00,0.00,0.00]=0.40 \r\n'
0:00:56.550504 4 b'4D37[0.00,0.00,0.00]=0.34 \r\n'

Myslím si, že tento výpis mluví za vše. … na jedno měření potřebuji 10 sekund! To moc na follow me, kde by se hodilo spíše 10Hz (jen dva řády rozdíl) úplně není …

Tak rychle, git commit, git push a opustit budovu …

24. listopad 2025 — Rehabilitace Qorvo krabiček (AI-powered)

Tento víkend jsem se dostal do podobné situace jako před skoro třemi lety výše — Pozyx krabičky jsem zapomněl doma v Praze a po ruce jsem měl pouze Quarvo, které už jsem jednou opustil. Moc se mi do toho nechtělo, protože update rate jednou za 10s je pro follow me fakt nepoužitelné. Možná bych měl zmínit motivační kontext, jenž je pro sledováni osoby pomocí OAK-D Pro kamery s YOLO modelem (viz video) bych i rád lépe odhadl vzdálenost, případně nějakou „organizaci tlupy robotů” … a na to by ty zaprášené UWB krabičky šly možná použít?

V práci nás navádějí používat AI, tak co bych se nezeptal? Jako plus bych zmínil, že mi AI vyhrabala Python wrapper pydwm1001. Tak jsem hned vytáhl starou bolest a zeptal se update rate. AI začala lehce halucinovat, že odpovídající C-funkce dwm_upd_rate_set nejspíše bude v Pythonu tracker.set_update_rate(). Hmm. Když se podíváte na github projekt, tak tam nic takového není. Chtěl jsem to zase vzdát, ale zmínila i možnost nastavení přes pyserial a UART:

Nastavení rychlosti posílání pozice pomocí AI

Hmm2. Takový příkaz existuje! Jak jsem ho mohl přehlédnout?! Respektive ignorovat celou sekci!!

** Command group: API **
tlv: Send TLV frame
aurs: Set upd rate
aurg: Get upd rate
apg: Get pos
aps: Set pos
acas: Set anchor config
acts: Set tag config
aks: Set encryption key
akc: Clear encryption key
ans: Set NVM usr data
anc: Clear NVM usr data
ang: Get NVM usr data

A opravdu aurg vrací aurg: nom=1 stat=100 — pokud je tag stacionární, tak se použije druhé číslo a to odpovídá 100 * 100ms = 10s! A když jsem to měl připojené k počítači tak holt byl „stacionární” (to vyhodnotil akcelerometr) a snažil se šetřit baterku. Stačí tedy zavolat aurs 1 1 a jede to na max 10Hz v každém případě. Tímto se Qorvo krabičkám veřejně omlouvám …

kontaktní formulář

Ichikaze

2025-06-26T00:00:00Z

Ichikaze（いちかぜ / 一風）

Význam: „Jedinečný vítr“ nebo i „podivínský způsob“ (v idiomu 一風変わった)
Skvělé spojení! Zní poeticky, ale v japonštině „ippū kawatta“ znamená „trochu bláznivý“ – čili Ichikaze může naznačovat „ta, co má vlastní vítr / styl“.

A AI mi navrhla i motto, které myslím, že bude sedět

"Jsem vítr, co se nikdy neptá na směr." ("I am the wind that never asks for direction.")
"Nezastavuj mě. Ani já nevím, kam běžím." ("Don't stop me. Even I don't know where I'm going.")

Model ver0

Oficiálně (obhajoba rodinných výdajů) je to autonomní sekačka na zahradu, ikdyž to mi doma stejně nikdo nevěří… Primárně to mám pro sebe na hraní - hlubší myšlenka je opravdu sekačka popř "mula" na převážení věcí. V práci máme velký areál a jít kvůli drobnosti přes celý areál - mnohdy i několikrát denně mě nebaví - kéž bych tak někomu mohl říct - zaběhni do budovy A a řekni ať ti dají to a to a pak se vrať…

Konstrukce pro v0 je komplet z 3D tiskárny. Je to jednodušší a rychlejší než jakákoliv ocelovka a pokud něco nevydrží můžu to vždy vytisknout znovu a lépe nebo nahradit pevnějším materiálem. Ichikaze má všechna 4 koho hnaná inwheel motory Waveshare DDSM210 a zároveň jsou natáčecí pomocí serv Waveshare ST3020. Přední náprava je navíc kyvná (obdobně jako na Kloubákovi), takže by měl umět zdolávat i nějaké ty překážky. Od tohoto řešení si slibuji silné menévrovací schopnosti, navíc ho plánuji udělat co nejvíc symetricky a všechny strany osadit stejnými senzory - pak bude "téměř" (natáčení kol není 360 - ukroutil bych kabely) jedno kterým směrem jedu. Což mě připomíná, že na řízení používám Raspberry Pi 4B, hodně si pohrávám s myšlenkou výhledově ho nahradit průmyslovým pc od B&R automation (které používám v práci) - jsou modulární, takže bych nemusel řešit omezené vstupy, sběrnice apod…a také cenově někde jinde…tak uvidíme…

Aktuálně má Ichikaze základní rám a popojel svých prvních pár cm pomocí všech 4 kol, nicméně to je jen první test. Verze 0 by k tomu měla umět natáčet všechny 4 kola a taky by měl přestřihnout "pupeční šňůru" = jen pouze na baterii. Pak začnu řešit úložný prostor na elektroniku a senzoriku atd.

14. října 2025 — Lodní fáze

MartinS: Nicméně drobný update by asi si zasloužil, obzvláště když jsem se podíval co jsme o něm psali posledně a úplně tam chybí tzv. lodní fáze

Samotný spojený rám se (překvapivě) ukázal jako nedostatečný pro umístění, alespoň nějakých komponent. Navíc jsem našel ultrazvukové snímače na I2C za kouzelných 38,- Kč a zrovna mi chybělo asi 400,- Kč do poštovného zdarma - tak jsem jich vzal rovnou 10ks. Bohužel jsem ho přes I2C nerozchodil - ikdyž teď jsem našel ještě jiný návod, takže to ještě zkusím - nicméně přes TTL to jede…

Další velký a nezbytný upgrade byla baterka - z původní 3,2Ah jsem přešel na 30Ah — to by mělo na chvilku stačit. Navíc dodala Ichimu patřičnou váhu (doslova). S ultrazvuky bylo potřeba i udělat držák pro ultrazvuky - nicméně nějakým záhadným způsobem pak Ichikaze vypadal spíš jako loď. Argumenty, že to je prostor, kterým pak potáhnu kabely nikoho neobměkčili - prý je to loď. Takže v další palubě…tedy nadstavbě jsem se rozhodl pro maximálně nelodní tvar - což se povedlo. Nicméně dle slov HonzyK je to "dobrá přepravka" - tak už jen přemýšlím jaký tvar zvolit na další patro a kolik těch pater vlastně bude než to bude vypadat ok Nicméně hlavní úspěch mého snažení je konečně vidět - se zapojenými 2 ultrazvuky dokážu projet chodbou aniž bych odřel čerstvě vymalovanou stěnu

A kam dál? Hlavní cíl je teď doupravit kabeláž a zapojit všechny ultrazvuky. A pak začít zkoumat OSGAR/ROS cestu + zajet se podívat ven

PS: můj standalone SW pro Ichiho už nedává smysl — resp udělal a otestoval jsem to co jsem chtěl, ale výhledově bude určitě výhodnější přejít na OSGAR/ROS - tj. kdybys měl čas chuť a náladu tak bych se nechal (znovu) zasvětit

kontaktní formulář

Robotour 2025

2025-01-17T00:00:00Z

Automatic translation by Google translate

Rules

The rules are the same as last year and can be found on GitHub with the tag ROBOTOUR2023RC1: czech and english.

Location

The competition will take place in the castle park Buchlovice.

https://zamek-buchlovice.cz/en/photogalleries/1469-the-chateau-garden

Registration

As in the last years, please send by the end of July 2025 an email to the address webmaster-at-robotika.cz with the subject Robotour 2025 - team name. If the robot is new, add a more detailed HW/SW description. Part of the registration is a link to this year's YouTube video with the title ROBOTOUR 2025 REGISTRATION - team name, proving that your robot (still) works. Ride 10m after path, obstacle detection, Emergency STOP button functionality.

Teams 2025

Pre-registered teams from 2024

ARBot (CR)
BeMaTo (CR) — renamed to Helhest
Istrobotics (SR)
Sĺňava (SR)
Smelý Zajko (SR)
SynthCat Robotics (CR)

Marathon

ND Team (CR) — registered via Robotour Marathonu (2025-06-07)

New teams

Artemis (CR)
description
HW: Chassis: Hunter SE by Agilex PC: Asus NUC I5 Cameras: 2x RealSense D435 from Intel Display: 10" WaveShare GPS: Septentrio mosaic-go Wifi: Mikrotik mAP lite Software: OS: Ubuntu 24.04 LTS ROS2 Jazzy NAV2
Ultimo Minuto (CR+SR)

description
Own construction assembled from the ground up, material mostly iron, skid steering Drive: DC motor, 2×24 V Driver: PWM of an older design, replacement with a more powerful driver is planned Power supply: 2×12 V in series, gel-lead battery Control: PC - laptop with Windows 11, control software in Python Currently only works with a camera, but a small LiDAR will also be connected. The video shows today's first ride outside, so there is still a lot to work on. We hope to have everything done by the competition deadline.
Unidroids (CR)

description
Hardware: Computing unit: NVIDIA Jetson Orin Nano (8GB, JetPack 6.2) Cameras: 2× IMX219 (CSI, 200° FOV) – stereo view down LiDAR: Unitree L2 (Ethernet) GNSS + Dead Reckoning: C102-F9R (USB) Base: Hoverboard with modified firmware, controlled via USB serial line Control: Mobile phone (Android Infinix Smart 8) Data storage: SSD Lexar NM620 2TB (separated for system, logs and projects) Software: Linux (Ubuntu, JetPack 6), services written in Python We use our own architecture with separate socket and HTTP services (FastAPI) Videos, segmentation, obstacle detection and control are implemented as separate processes Development is done remotely from VSCode via USB-C (gadget mode, headless) https://github.com/unidroids/robotour2025

Invitation

The competition will take place on Saturday afternoon (13/9/2025 2-4pm) and Sunday morning (14/9/2025 10-12am), but some teams will probably test in the castle park on Friday.

The official invitation (PDF) is available for download.

https://live.robotour.cz/ with exact start times and QR codes for robots will also be available.

Partners

Blog (md)

Saturday, September 13, 2025

10:00 — the journey along the D1 was surprisingly smooth (yes, I got up at 4:10, so body forced me to get up, and yet I won't go back to bed when the alarm was set for 4:40), so Tomáš (SynthCat Robotics) and I arrived in Buchlovice around 9 am. That was also the beginning of the park's opening hours, or there couldn't have been a better timing. The weather is worse — it's pouring like a bucket, which reminds me too much of last year's floods. :-(

Yesterday, 4 teams were supposed to arrive, but apparently none of them showed up at the park — either they didn't arrive, or they have enough problems to solve without the park, or the message got lost somewhere. But even now (10am) there's no one here except Tomáš. We have a luxurious castle setting … I could imagine a wedding here. And if the weather doesn't improve (the forecast isn't very positive), we'll be really grateful for a roof over our heads!

Base

I had a quick look around the park and … the competitors often complain that I'm planning all sorts of tricks for them — there's no need, the reality is really "cruel". I have a feeling that Matty would do it, but Eduro probably wouldn't. Various bridges, drainage channels (they are really needed here), puddles (where there are no channels), roots … just a proper English park … the fact that there is no GPS under the wet trees is just a detail. I know they will stone me anyway, but … I didn't have to complicate anything.

11:00 — ARBot and Istrobotics arrived. Aleš (ARBot) is said to be returning to Prague today, but Istrobotics managed to do one quick ride last night and it is said to be challenging. They mentioned the newly established flowerbed, which is black and the neuron evaluates it as an asphalt road. Otherwise, the rain stopped and I briefly saw the sun. There is still hope.

added 15/09/2025

12:00 — it was almost time to go for lunch, but at the same time other teams started to appear. Or this would be solved "a little" from an organizational point of view (most likely by returning to the original competition only on Saturday, but from morning to evening). Ultimo Minuto arrived with their obviously quite heavy machine (two people struggled with it in total). Michal said that he was returning to Robotour after 15 years and if you remember tank from Robotour 2010, Tatran team, then that's the connection. Helhest and Artemis also appeared — bigger robots. And slowly, things started to get better. So at least a quick lunch …

Artemis

Helhest

Ultimo Minuto and SynthCat Robotics

13:00 — test pre-round. I accompanied Istrobotics to the loading point and on the way to the unloading … only at one point the robot angrily threw the beer away. It was a big step at the approach to the bridge and the keg fell out:

Automatic unloading - Istrobotics

I think several teams would have deserved at least a point, but I wasn't at the start and it doesn't count towards the overall results anyway.

14:00 – 1st round

The loading and unloading task was the same as in the test pre-round (motivation why to participate in the optional pre-round). This time I accompanied a large tricycle Helhest, which zigzagged to the first bridge and reached the loading. After entering the next goal (unloading), but while turning 180 degrees the robot went off the road. But a very nice (and dramatic) ride.

Helhest heads to the first bridge

Istrobotics repeated the ride from the pre-round without any problems, but they also did not get to the unloading. I think they filmed all the rides, so I will add a documentary video if necessary.

ARBot had problems with USB cameras — they would fail at various times, so the robot would sometimes only drive to one camera instead of two. Another problem was with the position on the map and although the robot later navigated nicely along the paths, its routing did not necessarily lead to the goal and therefore only 1 point for leaving the semi-autonomous zone. Tomáš alias "SynthCat Robotics"" and the guys with "Artemis" were in a similar situation. "Unidroids"" struggled the most at the start, where the robot swerved a lot, simply not going straight, and "Ultimo Minuto"" also always only moved a little. Both teams therefore lost points.

15:30 – 2nd round

By the second round, several teams had started editing the map, or rather prohibiting automatic routing over some bridges. There were 4 bridges in the castle garden and each one had some kind of betrayal. To be honest, I was a little scared when "Istrobotics"" threw themselves down a narrow path down the hill onto a smaller bridge, but they were not alone, so it was probably the poorest route. In the second round, Helhest failed to repeat the successful loading, nor did any other team. On the other hand, Ultimo Minuto scored points and "something went wrong" "SynthCat Robotics"".

Ultimo Minuto scores a point in the last minute of round 2

Sunday, September 14, 2025 added 15/09/2025

9:00 — it rained in the morning. More precisely, it poured and thundered all night, so much so that it reminded me of last year's floods. Nevertheless, PavelS/ND Team arrived with Saya and after a while Andy/Sĺňava with a toy car. The bad news was that when PavelS drove the robot from the car to the joystick, one of the motors stopped turning and that ended the competition for ND Team.

ND Team - Saya with a cart

10:00 — 3rd round

Loading at the statue, unloading at the Chocolate Factory … but it didn't work out. Actually, no team arrived for loading. To boost my optimism, I took Matty and went for a walk with him in the park — see video (trailer: ends with a collision with Helhest).

Matty 2x and team Sĺňava

11:30 — 4th round

Helhest drove around the bend to the second bridge, Istrobotics successfully loaded, but did not deliver the cargo, Artemis drove out of the semi-autonomous zone and continued to the park (video). Sĺňava also drove to the park and received an unofficial point for leaving the start. Only Unidroids danced in front of the entrance and did not want to go any further.

dancer Unidroids

12:30 — end of the competition and announcement. I'm actually glad that it turned out so clearly and we didn't have to argue whether both days count or just the better one as I promised. The competition was very demanding and once again I would like to thank all the teams for their active participation and commitment and the management of Buchlovice Castle for the great facilities and support.

21:00 — I'm happily back home, completely exhausted … but it was really nice, the weather finally cleared up in the critical slots (it was horrible at night — many hours of rain and thunderstorms), so good. But now for some reason the results for the 4th round haven't been updated, so maybe you can tell from the photo who won. I would like to add the two days of "blog", but I'd rather not promise anything anymore …

p.s. when the results are downloaded and re-uploaded, they are visible …

Online Robotour Workshop (recording)

Robotour Workshop
Wednesday, 1st October 2025, 20:00 – 21:00

RoboOrienteering 2025

2015-04-28T00:00:00Z

Zámek Kynžvart

zdroj: https://www.zamek-kynzvart.cz/cs/fotogalerie/69553-kynzvartsky-zamecky-areal-z-nebes

Obsah

Změna lokace!

Z důvodu revitalizace (?) zámeckého parku se soutěž přesouvá na jíné místo — na dopravní hříště Základní školy Úšovice v Mariánských Lázních!

nová lokace

Doplňující info od organizátora soutěže:

V příloze naleznete mapu s vyznačenými značkami a jejich přesné souřadnice. Vzhledem k menšímu prostoru bude pouze 8 kontrolních bodů. Pokud pojede robot v pořadí číslování kuželů 1 – 8, délka trati je cca 350m. Pořadí a počet navštívených kontrolních bodů si můžete zvolit sami.

Start prvního kola je v 10:30 hod, vzhledem k velkému počtu přihlášených robotů se bude startovat v tří minutových intervalech. Během max. tří minut musí robot opustit startovací pozici.

Pokládání golfových míčků je dobrovolné, ale pokud to robot zvládne, získá body navíc. Body získá i za průjezd, nebo přiblížení se k cíli. Cíl bude umístěn jinde než start, aby nedocházelo ke kolizím se startujícími roboty.

Pokud by mělo během jízdy dojít ke střetu dvou či více robotů, je povoleno robota zastavit ( měl by se sice umět jinému robotovi vyhnout), a opětovně zase zapnout. To platí hlavně u střetu více robotů u kontrolního bodu - kuželu. Tady můžete robota v dostatečné vzdálenosti zastavit a až bude prostor kolem kuželu volný, pokračovat v jízdě.

Kontrolní body

Start 49°954046 12°709531
Cíl 49°953423 12°709187
1 49°9539450 12°708882
2 49°9537240 12°709185
3 49°9539130 12°709649
4 49°9541606 12°709484
5 49°9543109 12°709360
6 49°9542960 12°708717
7 49°9546010 12°708368
8 49°9536645 12°708831

… celková vzdálenost trasy při průjezdu všemi kontrolními body v pořadí 1 – 8 je cca 350m

Výsledky

výsledky

Matty M03 - Robotika

Včerejší soutěž byla fajn — vlastně předčila všechna moje očekávání. Na rovinu se přiznám, že jsem se těšil na Kynžvartský zámecký park a že to byla jedna z motivací, proč do toho po delší době jít. Pak Jirka/Cogito zmínil, že je to jedna z mála soutěží letos, kam by mohl dorazit sám ze Švýcar. No a korunu tomu nasadil MartinL, když prohlásil, že se ho žena ptala, zda nebude nějaka soutěž, že by si udělali rodinný výlet. A s robotem (a ženou) do toho šel i PavelS, tak … řekněte v této konstelaci NE! a že máte už robotů po FRE plné zuby?!

Z čeho jsem však nakonec ustoupil byl počet robotů. Původně jsem chtěl „vyvětrat” velkého Pata, který by na rozsáhlý zámecký park pěkně pasoval. A přihlásil jsem i Mattyho M02, hlavího učastníka FRE, kdyby si to studenti náhodou rozmysleli — nerozmysleli. Nakonec jsem zůstal u jednoho robota Matty M03, kterému jsem se ale tady v Mariánkách mohl plně věnovat.

Přiznám se bez mučení, že přípravě jsem věnoval opravdu málo času … a na rovinu nebylo z čeho brát. Schválně otevřu pull request, tam to v těch commitech bude vidět (mimochodem mne tady dostal TomíkK, že vlastně sleduje i změny na GitHubu, což je asi první člověk, kterého znám ) No myslel jsem, že tam bude vidět i časová osa, ale není — ta je lépe vidět zde.

Je tam nějaký commit z 23. května 2025, kdy jsme se asi rozhodli, že do toho jdeme. Naházel jsem tam na hromadu kód z 2018 (???), hrátky s Patem a Cones Challenge. Další příhoz byl 18. června (3 dny do soutěže), kdy jsem tam pro vyhybání se překážkám přidal kus kódu z FREčka. I když to možná ještě byla jen jízda rovně … no raději toho nechám, je to ostuda a takto se přece člověk na soutěž nepřípravuje. Ale opravdu nám šlo o soutěž? Plán byl to pojmout jako společenskou událost a přizvat k tomu i naše roboty.

Testování na hřišti

Asi největší radost jsem měl z toho, že Matty M03 detekoval (resp. jeho neuronka běžící na OAK-D Pro) oranžový kužel bez pruhů! Model jsem převzal na zmiňovanou Cones Challenge (jen interní hecování) někde z internetu a nedotrénovával jsem to. (pozn. teď na ten odkaz koukám a je tam ukázka detekce přímo na oranžových kuželech) To bych tady na místě opravdu nedal. A co více, nejen že kamera kužely detekovala, ona je detekovala velmi dobře i na vzdálenost několika desítek metrů!

Ale klasicky to mělo i vedlejší efekt — při prvních testovacích jízdách vždy hned po startu vyjel a zahnul vlevo?! On tam totiž byl kužel (číslo 2) a tak se na něj vrhnul. Jen to bylo do kopce a ten před sebou krásně po rovince (číslo 1) ignoroval. Svůj starý kód si teď interpretuji tak, že pokud vidíš vícero kuželů, tak si vyber ten největší, tj. nejblíž (z barevného obrazu).

vzdálený kužel

1. kolo

Startoval jsem poměrně na začátku, tak už nebyl čas na další úpravy a „problém” z testování jsem chtěl pořešit vhodným nasměrováním robota na startu. Úplně se to nepovedlo, ale myslím, že na druhý pokus vyjel skoro rozumně. Detaily si teď už přesně nevybavím, ale při náhodné jízdě s algoritmem:

když vidíš kužel, tak vyraž tím směrem
pokud je před tebou překážka, tak uhni volným směrem, který je blíže středu (levá vs. pravá)
jinak jeď rovně
a pokud i přesto narazíš (přední nárazník), tak si 1m couvni mírně do zatáčky
pokud je kužel méně než 1m před tebou zastav a čekej 3 sekundy

A tak Matty M03 vesele jezdil (rychlost jsem mu zvedl na maximálku 0.5m/s) a když to šlo, tak ze soutěžního prostoru „zdrhnul”. Nechal jsem ho přejet hřiště, silnici a až ke kontejnerům v dalším bloku, ale pak podle GPS (kterou jsem jenom sbíral a nepoužíval) byl více jak 100m od nejbližšího waypointu. Tam jsme robota se sudím o 180 stupňů otočili (to bylo v prvním kole povolené). Body získal někde na začátku (kužel 4?) tak zbytek už byl test, co vše přežije … a bylo to drsné.

První kolo skončilo bouráním do plotu, kdy se navíc připletl do plané růže a ta mu vytrhla kabel od kamery. Zpětně si uvědomuji, že za tu problémovou detekci drátěného plotu si možná můžu sám — místo nejblížší překážky jsem bral np.percentile(data, 5), tj. 5% nejbližších se ignoruje (typicky vyšší stonky trávy a šum) … a možná i ten plot.

1. kolo - Matty M03 - dokumentační video

2. kolo

Cílem druhého kola bylo se udržet v soutěžní aréně. Jelikož nedošlo k integraci kompasu (ani indicie typu míříš na sever nebo na jih), tak hrubou informaci měl robot pouze z GPS. Musel mezi tím ujet alespoň metr … a ano, byl to důvod tanečků. Algoritmus se změnil na

jinak jeď rovně, pokud GPS pozice od nejbližšího waypointu je menší než 20m
v opačném případě se otoč na waypoint

A jak to dopadlo? Jel krasně rovně na kužel číslo 1 a po dvaceti metrech se otočil o 180 stupňů zpět na start. A když v té divoké otočce neviděl žádný kužel, který by ho srovnal a nutil do jízdy na kužel tak se na té hranici 20m rád rozhlížel po okolí — viz obrázek odometrie z poslední části (i když to možná byl už test navíc po soutěžní jízdě). Za startovní kužel mi nikdo body dát nechtěl, ale přesto se robotu podařílo zase jeden (?) někde cestou ulovit.

tancující robot

Matty M03 leze na plot

3. kolo

Do posledního kola jsem přídal pár drobných, ale důležitých, změn:

ignoruj první waypoint (start)
pokud při reportu dosažení kužele jsi blíž jak 10m od nějakého waypointu, tak ho odstraň ze seznamu
pokud jsi více jak 20m od nejbližího ze zbývajících waypointu, tak se otáčej pomalým obloukem jeho směrem (ať orientace z GPS pozice dává alespoň trošku smysl).

Na doporučení jsem také přesunul GPS anténu alespoň na krabici — jak jsem tu GPS do té doby moc nepotřeboval, tak byla uvnitř.

A jezdilo to pěkně. Sice některé kužely si dal i 4x (v GPS waypointech je neměl, ale když je viděl, tak „nemohl odolat”), ale s časem a přirozenou randomizací (nature) za 75 minut navštívil všechny kužele. Ono třeba cíli byl cca v první třetině, ale nikde neni v pravidlech řečeno, že cíl musí být poslední. Bylo to úmorné a dalo se na to koukat jenom s tím, že níkdo nevěděl, co teď přesně udělá!

3. kolo - Matty M03 - dokumentační video

1:07 - cone4, scoring
4:04 - false detection
4:53 - cone1, not reporting, not scoring
8:39 - goal cone, scoring
10:20 - goal cone, not scoring
11:50 - goal cone, not scoring
13:42 - false detection
13:57 - false detection
14:54 - cone8, scoring
15:51 - Odroid, power reset
19:35 - cone6, scoring
21:13 - cone1, scoring
22:41 - cone2, scoring
23:57 - goal cone, not scoring
25:34 - manual intervention (?)
26:57 - false detection
27:53 - cone3, scoring
29:00 - start cone
30:24 - start cone
31:13 - found hole in the fence
31:50 - cone4, not scoring
37:55 - fence hole again
39:04 - cone4, not scoring
42:50 - cone4, not scoring
46:37 - cone5, not reporting, not scoring
50:05 - cone5, not reporting, not scoring
52:09 - start cone
52:25 - start cone
53:26 - cone4, not scoring
55:42 - cone5, scoring
57:48 - cone6, not scoring
59:05 - cone2, not scoring
1:00:07 - cone8, not scoring
1:04:15 - cone7, not reporting, not scoring
1:04:42 - camera restart
1:07:18 - cone7, scoring

GPS/NMEA trace - Matty M03, round 3

TIMEOUT … časem snad doplním nějaké foto a video … a závěr, že díky moc ogranizátorům za super outdoor robotický den!

Freyja - Tým Cogito

Jak kdysi napsal spolužák do protokolu o chemické laboratorní práci: Pokus se mi líbil.

Martin už předestřel, že jsme se letos účastnili podle motta "robotická soutěž jako společenská událost." Jelikož praotce Čecha bolely nohy, jsou Čechy zbytečně daleko od mého současného bydliště. Do Mariánských Lázní ještě jakž takž dojedu jako jeden řidič za jeden den. Tj. v pátek tam, v neděli zpátky. Cokoli dál by mi zabralo div ne týden.

Po loňském nepředstavení na Elrobu bylo mým letošním cílem, aby se Freyja alespoň rozjela. Kód byl v zásadě právě z Elrobu. Jenom fázi 1, Následuj Mě a Pamatuj si Průjezdní Body, nahradily ručně zadané souřadnice průjezdních bodů. Prostě jsem kus kódu smazal.

Týden před soutěží zpochybňovala žena má - bez jejíž podpory by to nešlo! - moji snahu někam jet soutěžit, když robot nejezdí.

V pátek jsem totiž odpálil pojistku, pořád nevím jak. V sobotu nenabíhalo PC a kamery. V tom horku se na některé komponenty v robotovi ani nedalo sáhnout. Odrivům - řadičům motorů - se do akce taky spíš nechtělo. Dobrá zpráva byla, že kamery se mi podařilo "opravit." Nesmím totiž pustit všechny najednou, Jenže jsem při nějakém upgrade kódu vynechal veledůležité synchronizační sleepy. Potíž s Odrivy je podle všeho potíž s USB konektory. Robota jsem stavěl před šesti lety a nečekal jsem, že přežije svou první Subterranean Challenge. Ten věk začíná být znát.

Do předsoutěžní neděle jsem vkročil s nadějí v srdci. Kompas s IMU ji vyrval. Přešel z režimu "občas, velmi zřídka, zamrznu" do režimu "po každém startu za chvilku zamrznu." Ale já se nedám! Konečně ten problém dokážu reprodukovat! A co jde reprodukovat, jde spravit! No věřili byste tomu, že to několikasetmegahertzové dvoujádrové esp32 "arduino" se, když zaplní výstupní buffer sériové linky, totálně zasekne? Pracovní hypotéza je, že v tom horku něco zpomalilo a proto se ten buffer přeplňoval. Jednoduchým řešením je posílat data méně často. Beztak je podvzorkovávám na PC. O tom podivném kódu pro detekci překážek z lidaru, který tam byl už na Elrob 2024, se radši nebudeme bavit, ano? To do slušné společnosti nepatří.

Pondělní rychlý ranní test vypadal nadějně. Pondělní odpolední pohled na již dlouho nepoužitý nafouklý záložní lipoly akumulátor mě natolik vyděsil, že jsem ho ve svém pyrotechnickém obleku okamžitě odvezl do sběrného dvora a objednal jiný.

V úterý večer jsem připrogramoval homologační "když nemáš waypointy, jeď rovně." No jo, zapomněl jsem na homologaci. Ve středu večer jsem to otestoval a opravil, aby robot jel, ale ne na opačnou stranu. Robot se vcelku hýbal, jenom s těmi konektory toho už moc nenadělám.

V pátek jsem přejel do Čech, vybalil u hotelu robota, popojel rovně, senzory fungovaly, robota jsem vypnul a jal se moudře radit konkurenci.

Freyja s Martinem a Pavlem

V sobotu jsme se přesunuli do soutěžního prostoru. Homologace se nějak nekonala, tak jsem nastavil trasu podle Plánu A a robota cvičně pustil. Robot na první dobrou projel celou trasu, jen cílové kužely objel bokem a zastavil trochu moc daleko za nimi. Posunul jsem cílový bod v konfiguraci na sever a šel se socializovat do pitstopu na východ.

Do prvního soutěžního kola se nechtělo pustit PC. Viz Těžká Sobota. A už jste to zkusili vypnout a zapnout? Robot vyráží, krásně nachází čtyři kužely a vydává se směrem k úzkým kovovým trubkám kolem fotbalového hřiště. Při testovací jízdě jimi Freyja prokličkovala, zůstávám v klidu. To jsem neměl. Tentokrát se dala s jednou z trubek do boje. Býval jsem měl dělat překážku, to se smělo. Robota vypínám stop tlačítkem. V prvním kole ho smím posunout a pustit znovu. Nicméně odrivy už nenaběhly. V systémovám logu jsem pak našel nějaké divné errory z USB systému. Dobré zprávy jsou dvě: 1. Robot se rozjel, mám splněno. 2. Aniž bych si to uvědomil, můj nezvyklý průjezd v protisměru oproti očekávání vedl nejdříve přes vysoce bodované kužely. Nedojeli jsme jen k plebsovým kuželům. Zůstáváme ve hře.

Do druhého kola jsem posunul jeden z průjezdních bodů, aby měla Freyja více prostoru při objezdu basketbalového koše. Ach ty úzké kovové tyče. Teď už jsem z nich nervózní. S trochou pomoci aktivních překážek kolem tyčí u fotbalového hřistě Freyja objíždí celou trasu kolem všech kuželů. Jenom do cíle opět přijíždí z boku, čímž přichází o pár bodů.

Z mezivýsledků po druhém kole je zřejmé, že:

První s Freyjou nebudeme. Vedoucí robot kladoucí golfové míčky, což Freyja nedělá, už má pro nás nedosažitelné množství bodů.
Druzí taky nebudeme. To by musel průběžně druhý robot, taky kladoucí míčky, shořet, což se nejspíš nestane, a Freyja by musela předvést perfektní jízdu.
Třetí bychom být měli. Pokud neshoří Freyja, což se stát může, ale nemělo by, a neustřelí naprosto nadstandardním výkonem některý z robotů za námi.

V závěrečním kole chce organizátor vidět hodně pohybu a bodů a povoluje týmům roboty ručně zachraňovat z obtížných situací a znovu je pouštět. Tak na tomhle nemůžeme s Freyjou nic získat. Restarty nám zjevně nejdou. Můžeme jenom ztratit :-/ Musí něco předvést!

Do závěrečného kola posouvám průjezdní bod u hřistě dál od těch #@! trubek. Stejně byla ale zase potřeba živá stěna. A předělávám příjezd do cíle. Chci maxim bodů! Moje blbost. Copy paste error a robot se po návštěvě všech kuželů místo nájezdu do cíle vydává do Kazachstánu. A kdo ví, třeba tam jede dodnes.

Vrtá mi hlavou, jestli by se oprava waypointů v soutěžním prostoru považovala za ve třetím kole povolený restart, nebo za stále zakázanou úpravu kódu v poli.

Každopádně, na odražení Martinova závěrečného náporu to stačilo a ani při onom povoleném freestyle jiný robot bodově neustřelil.

Robot Freyja týmu Cogito získává třetí místo celkově a první v nevyhlášené mnou smyšlené kategorii robotů bez golfových míčků! Děkujeme organizátorům za krásné robotické setkání.

Po patřičné sobotní večerní socializaci v místních občerstvovacích zařízeních se v neděli vydávám domů, kde nacházím již připravený vítězný plán na příští ročník.

Plán 2026

Freyja / Cogito - Přesnost lokalizace

RoboOrientering nám dává mimořádnou příležitost ověřit lokalizaci robota ve venkovním prostředí. Freyja totiž jede na zadanou souřadnici a dojede-li k ní, podle svého názoru, na méně než jeden metr, nahlásí kužel. Ale je opravdu kužel tam, kde ho očekává?

První indicii vysoké přesnosti Freyjiny lokalizace nám dává průběh soutěže. Všechny kužely, které Freyja hlásila, se vešly do 2,5 metru od ní, což je hranice měřená rozhodčími.

Druhou informaci nám dávají další senzory na robotovi a uložené logy z jízdy. Když robot zastaví u kuželu, měl by kužel být viditelný některým z lidarů nebo některou z hloubkových kamer. Pro účely tohoto článku se budu soustředit na vodorovný lidar. Je nejpřesnější a nejsnáze zpracovatelný.

Lokalizace na Freyje je možná trochu složitější, než je pro Roboorienteering nutné. Fúzuji dvě GPS (Septentrio Mosaic X5 na desce SimpleRTK3B, v RoboOreinteeringu bez RTK korekce), magnetický kompas (LIS3MDL), IMU (LSM6DSL), odometrii z kol a SLAM (simultánní lokalizace a mapování) z lidaru. Kompas z dvouanténových GPS kvůli rušení ze strany USB3 kamer během analyzovaného kola nefungoval a robot se pro určení své orientace musel spoléhat především na magnetický kompas a IMU. Odometrie je na smykově řízeném robotovi poměrně nekvalitní a pokud má lokalizace jinou možnost, odometrii moc nevěří. Kvalita lidarového SLAMu závisí na prostředí, na množství překážek a jejich pohyblivosti. V každém případě IMU, odometrie i SLAM dávají informaci jen o relativním otočení a nikoli o absolutním natočení, např. vůči severu.

Začněme kuželem č. 1, kde se robot podle všeho během svého druhého kola nejvíce ztratil. Na obrázku vidíme, že se očekávaná poloha kuželu, symbolizovaná červenou tečkou, od polohy detekované lidarem, symbolizované shlukem modrých teček, liší o necelého 1.5 metru. I v nejhorším teoretickém případě, což není případ kuželu č. 1, kdyby robot tuto chybu udělal nedojetím ke kuželu přesně před sebou a zastavil by metr od domnělé polohy kuželu, nejbližší část robota by stále byla blíže než 2,5 metru od kuželu.

Kužel č. 1

U dalších kuželů vidíme rozdíl mezi očekávanou a skutečnou polohou kuželu pod půl metru, i když ne o moc.

Kužel č. 2

Kužel č. 3

Kužel č. 5

Ostatní kužely, které neukazuji, na tom byly podobně. Jen zůstaly v zákrytu za částí robota a vodorovný lidar je v okamžiku jejich nahlášení neviděl. Detekce z ostatních senzorů dávají shodný obraz, jen s větším množstvím nepřesnosti ze strany senzorů.

Když se místo na fúzovanou lokalizaci soustředím jen na jednu z GPS a magnetický kompas s IMU, vychází to skoro také tak. U kuželu č. 1 se fúzovaná poloha a poloha s GPS shodují. U kuželu č. 2 je GPS dokonce přesnější. U kuželu č. 3 je fúzovaný odhad o 20 cm přesnější a u kuželu č. 5 o 50 cm.

Závěrem tedy je, že navzdory stromům lze RoboOrienteering zvládnout jen s GPS a kompasem, bez detekce kuželů, a v naprosté většině případů dojet do 2.5 metru od kuželu. Při kombinaci více senzorů to jde i přesněji. Pochopitelně pak s využitím kamery nebo lidaru pro závěrečné přiblížení anebo přidáním RTK či SBAS GPS korekcí je možné jet na dotyk s kuželem, jak předváděl vítězný robot (SBAS korekce).

Cogito team's robot Freyja at the second round of RoboOrienteering 2025 (video)

kontaktní formulář

Field Robot 2025

2025-02-02T00:00:00Z

official FRE2025 website

Official announcement

Competition Challenges FRE2025:

🚜 Task 1: Autonomous Maize Field Navigation
🌽 Task 2: Autonomous Maize Field Navigation with Cobs Detection
🍎 Task 3: Fruit Mapping
🍄 Task 4: Bioluminescent Fungi Discovery
✨ Task 5: Freestyle

💡 Want to compete? Registration opens on March 3, 2025, and closes on April 25, 2025. The registration fee per team will be announced at the opening of registration.

🤖 Seeking sponsorship? New teams can apply for sponsorship to support their participation, with funding up to €1500 per team by CLAAS-Stiftung. More details and application link: https://www.claas-foundation.com/students/field-robot-event/application.

📢 Have questions about the rules? Join our FRE2025 Discord server now to get updates, connect with teams, and participate in the Q&A discussion: https://discord.gg/56unzZVBqn. Read the rules now!

🌐 Website Update: Further event details will soon be available on our website: https://fieldrobot.nl/event/

📍 Getting here: The event venue is 12 km from Milano Linate Airport and 17 km from Milano Central Station (Google Maps).

CULS Robotics Team Blog (CRT-B)

CULS Robotics is a new Czech student team for Field Robot 2025! Yes, it took only 10 years to find a group of excited students and „start again”! The team of 3 students was founded in Czech University of Life Science Prague. The members are all in the last year of their study, so the priorities a bit colide with with details like finishing diploma thesis or final exams … but their self-motivation is still strong so hopefully we will see them all competing in Italy in June.

CRT will compete with robot Matty M02 — the green one, red one is a backup or it will be used for the free style discipline. Robot is equipped only with OAK-D Pro camera and it is programmed in Python using OSGAR framework.

Team members:

Simona (team lead)
Ondra (software)
Franta (hardware)
Elena (ChatGPT)

Content

Week 18 (18/2) — Matty GO!

This was the very first time we met with Franta and Ondra at the university. It was great that they had already some basic experience with OSGAR and they had the development environment already prepared. The only needed detail was update of Matty driver to the latest version. Two robots for two students looked like good match.

Unfortunately Franta's Win11 did not recognize the ESP USB-serial, so only Ondra could directly connect his laptop to robot via USB. Never-the-less the goal was to use onboard ODroid, and for that putty was enough.

Odroid and battery arrangement in Matty M02

The 1st lessons learned was — try screen -dr just in case somebody is already using robot, otherwise:

screen
workon osgar
cd git/osgar
python -m osgar.record –duration 10 config/matty-go.json –params app.dist=0.5 app.steering_deg=-20

… and this will go for 0.5m with steering 20 degrees to the right.

Week 17 (25/2) — Fake it until you make it (matty-go-cam.json, github, Rules 2.0)

The 2nd robotics round was again together with Franta and Ondra. Franta welded (!) new holder for OAK-D camera:

Camera holder (front)

Camera holder (back)

… so it already had sense to collect some basic data. Ondra combined OSGAR configuration files for driving and collection of depth and image streams from OAK-D camera. At the end he also managed to push his changes to github, and thus resolved issues with keys etc. Here you can see the proof — matty-go-cam.json.

Finally Simona shared with us the latest rules FRE2025_RULES_v2_0.pdf — which is kind of funny that even now (2025-04-11) there is still old version v1.0 on the official website … (even the location is still in Germany and not Itally).

Week 16 (4/3) — NumPy and obstacle detection

This time the whole team finally met: Ondra, Franta and Simona. The goal was to get started with OSGAR programming (see corresponding Czech notes here). The plan was to stop the robot! in a case there is some obstacle in front of it. The inputs are depth data from OAK-D camera which are available as 2D array of uint16 (unsigned 16 bit integers) corresponding to distance in millimeters.

Step one — pick distance in the middle of the image (single pixel) and if it smaller than 330 (I do not remember where they picked that value) stop. It turned out that 0 is often present, but it rather means I DO NOT KNOW, i.e. the distance is not valid. What to do in such a case? If previous measurement was long distance, then it is probably OK to continue moving. If it was short distance before then it would be safer to stop. And if you are receiving zeros for a long time then you do not know anything and it would be also better to stop. Yes, such complex logic on single pixel reading!

This week Python lesson was that division with two / characters means integer division, which is needed for adressing array. So what we were interested was value of depth[400//2][640//2].

Week 15 (11/3) — Camera holder upgrade, osgar.replay, NumPy mask

The most visible part for this week is a new camera holder. It is 3D printed, allows two degrees of freedom, and camera can be tilted and/or shifted:

3d printed camera holder

back side

Note, that there are also serious changes inside — properly mounted Odrive, batteries etc.

Coding was this time on Ondra, so he learned how to use python -m osgar.replay --module app for debugging and checking that identical code was running on the robot and on his notebook. Once there is a new feature/fix you can use this replay utility for syntax checking with parameter -F (force), which will replay the logfile without checking output values.

Single pixel in the center of the depth image (data[400//2][640//2]) was replaced by rectangle. There the zeros (unknown distance) were not as frequent, but they still had to be handled. This was the introduction of numpy masks:

>>> import numpy as np
>>> a = np.array([ [0, 1, 2],[3, 4, 5] ])
>>> a
array([ [0, 1, 2],
        [3, 4, 5] ])
>>> a.shape
(2, 3)
>>> a == 0
array([ [ True, False, False],
        [False, False, False] ])
>>> a[1]
array([3, 4, 5])
>>> a[1][1:]
array([4, 5])
>>> a[1][1:3]
array([4, 5])
>>> a[1][1:2]
array([4])

Yeah, maybe time to check numpy introduction for absolute beginners.

The artificial fruits and mashrooms needed for tasks 2-5 should be soon ordered. The team size is now 6 = 3 students + [Milan, Jakub, me].

New bumpers were brought for Matty M02, and Franta shoud mount them next week. Finally Milan promissed to cut new set of corn/maize plants 40-50cm ("nice to have").

p.s. we also started to use git branches for new development, so feature/task1 was created.

Week 14 (18/3) — Row navigation

Robot Matty M02 for the first time autonomously navigated in curved row! Do not expect super-smart algorithm, but … it worked (video).

Algorithm:

if obstacle to the left and to the right are at roughtly the same distance then go straight
otherwise if left obstacle is closer then turn right
otherwise (i.e. right obstacle is closer) turn left

There was an update to used numpy mask as min/max from empty array is not defined:

>>> max([1, 2, 3])
3
>>> max([])
Traceback (most recent call last):
  File "", line 1, in 
ValueError: max() arg is an empty sequence

… and the same situation can happen with the non-zero mask (i.e. only valid depth data)

>>> import numpy as np
>>> arr = np.array([0, 0, 0])
>>> mask = arr != 0
>>> mask
array([False, False, False])
>>> arr[mask].max()
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\SDK\WinPython-64bit-3.6.2.0Qt5\python-3.6.2.amd64\lib\site-packages\numpy\core\_methods.py",
    line 26, in _amax
      return umr_maximum(a, axis, None, out, keepdims)
ValueError: zero-size array to reduction operation maximum which has no identity

Another update was that instead of a line in the depth image we now take into account bigger rectangle — one for the left obstacle, one for the right obstacle and one just in front of the robot to STOP and avoid collision. Also note, that to address an rectangle you need to specify limits with comma: data[row_begin:row_end, column_begin:column_end].

There was also an issue with numpy.dtype. In particular the depth is unsigned 16 bit integer, so evaluation „left and right obstacle are almost equal” in a half of the cases overflow. The easiest solution was to cast result to normal Python integer (fix).

The newly mounted bumpers were tested with a new firmware and they worked fine. We will see if new black extenders will not colide with plants, but let's leave it for now.

Accidentally we also tested battery alarm. The Odroid battery reached 14.5V, and yes, the sound was well hearable even for closed box. The good news is that PC worked without any problem although the minimal limit is officially 15V.

Week 13 (25/3) — Priority override

Number 13 is not lucky number, so we skipped it. … no, just kidding, but … yes, we skipped this week because all three students had to finish their diploma thesis. Priority override. Robots next week.

p.s. team registered for FRE2025 in Italy as CULS Robotics

p.s.2 order of artifical fruits is still pending

Week 12 (1/4) — Refactoring Task1

OK, robot Matty now navigates in the row, but at the end it needs to turn 180 degrees and enter the next row. This taks is no longer easy to do (or nice to do) with callbacks and instead a sequence would help with readability (see /guide/osgar#250407).

The code for Task1 looks like this now:

def run(self):
    try:
        for num in range(10):
            self.navigate_row()
            self.go_straight(1.0)
            self.turn_deg_left(180)
            self.navigate_row()
            self.go_straight(1.0)
            self.turn_deg_right(180)
    except BusShutdownException:
        pass

… actually the code above looked like this later … on week 12 it was stop at the end of row.

p.s. we have the artifical fruit now and mashrooms … only stawberries are missing …

Week 11 (8/4) — PR Task1

OK, the robot finally started to move back-and-forth. You can see it in the video, which was also a data collection for the fruit detection. I would consider this task1 (version 0) as completed, so lets create pull request and merge it into master. This is actually also the first excercise with GitHub and "standard development routine". Note, that the robot moved 0.2m/s, so in 3 minutes it would drive approximately 30 meters. And if the rows are 20m long then we will just do 1.5 row. 30 points? That would be OK for ver0.

Task1 with collection of images with oranges

Once feature/task1 branch is merged, let's switch to new branch feature/task2 and create task2.py and config/task2.json. It should be basically Task1 + detections. The goal is to use Yolo models.

Week 10 (15/4) — Yolo fruit detection

Fruit detection by Yolo

OK, this time it was not that exciting, but at least we got new strawberries and we collected some pictures for further annotations. On the picture above you can see output directly from available Yolo model — banana works great, orange sometimes, lemon never. Also notice detected plant and persons.

The attempt to lower the camera resolution and reduce the log file size failed. Actually the OAK-D Pro supports 4K, 2K and 1K resolution, so we should be happy with the lowest 1K. Sigh.

This time we (I mean students) refreshed their knowledge of trigonometry and calculated properly the steering angle needed to match the 75cm radius. Franta also suggested to use single turn even for skipping the row, which could work. But we have not test it.

It was a bit hard to get the detector running directly on the camera (OpenCV and Qt without display), but what worked was depthai/examples/tiny_yolo. And the problem with OpenCV was discussed here with solution:

pip uninstall opencv-python
pip install opencv-python-headless

Note, that the tiny model is really quite small:

(depthai) robot@m02-odroid:~/git/fre2025$ ls -lh models/
total 6,1M
-rw-rw-r– 1 robot robot 6,1M dub 15 21:30 yolov8n_coco_640x352.blob

Week 7 (22/4) — Outdoor testing

There was a bug in the Matrix. Yes, my bug: 24 - 8 is not 18, right? So now we lost 2 weeks due to this mistake. So not 9 weeks to the competition but only 7!

This time we were testing outside (near the Round Hall) and it was great. I mean the weather. The strawberries were planted and it looked almost like a real run. Lessons learned (where they really learned?!) is that the setup is very sensitive to camera tilt. If it is pointing up then you do not see the row for navigation. If it is pointing down you see ground which looks like an obstacle. BTW we had to disable obstacle detections because of the grass.

Visualization in rerun.io

The change of light was very significant if you „looked into the sun” or the other way around. 10fps was not sufficient for auto-exposition, so we experimentally increased to 20fps.

Banana detector (YoloV8) was integrated into task2.py — I know that there will be no bananas on the ground, but this one already worked.

Integrated YoloV8 into task2

Franta brought an Apple watch, which could be fun to use to control the robot (as a remote start/stop), but … none of us ever created an application for Apple and the watch is not able to display webpages.

Homework:

train new detector with collected images of artificial strawberries from outdoor run
calculate (X, Y) position of detections in the image
group multiple detections, close positions, into single representative cluster

Week 6 (29/4) — Homeworks

Almost the whole homework was done. Simona annotated strawberries via roboflow, which was free of charge, but once she wanted to download a pre-trained model it asked for 13000Kč! Yeah, so this is the business plan.

Jakub took the annotations later during our Tuesday session and we got a new model (torch pt-file) in less than an hour …

The task to compute fruit 2D position was correct (from bounding box in image and distance taken from depth image estimate relative position to the robot). The only issue was the angle sign — and that is always an issue, so let's stick to the OSGAR mathematical notion, where angle grows to the left (positive X is forward, positive Y is left).

The grouping or proper name clustering is currently TODO.

The original Yolo detector worked best for bananas, so we continue developing with that. One of the problems is that OAK-D Pro camera has different color and depth cameras (color has 69 degrees, depth 80 degrees). If we use the overlapping part we lose field of view (FOV) of depth needed for navigation in the row, so for now we live with a compromise and the alignment is only an approximation.

Use python -m osgar.tools.lidarview --camera oak.color --camera2 oak.depth --pose2d platform.pose2d --bbox oak.detections task2-250429_192426.log to visualize the data. Note that different models use different input images (cone detection used input_size 416x416, while the tiny YoloV8 used 640x352). This is currently hacked in feature/lidarview-bbox-config, but it forces lidarview to parse the original config and it is not really nice — not merged yet, so detections are wrongly displayed!

Newly was added drawing of XY positions of detections into task2.py:

banana detection groups

New homework:

run clustering and draw circles around detected groups
save detections into CSV file CULS-Robotics-task2.csv
convert and integrate new Strawberries model from Jakub (best.pt)
get mentally ready for 3D — detection of fruit on trees will be more fun (3D geometry)

p.s. Jakub prepared experimental precise (rather offline) depth-color alignment PR

p.s.2 FRE2025 dates collide with Naše pole in Nabočany, so Milan will not go with us to Italy. :-(

Week 5 (6/5) — Banana cluster

There was some progress, although not as great as I would hope for. The new strawberry model is not integrated yet, but bananas could be used as dummy detections for testing of clustering. Also feature/task2 is merged now into master (again some issue with merging rights, but it seems that GitHub has policy that you already have to have something merged into master to gain the right to merge (???)).

Also CSV file is generated and circles are drawn on the graph.

What was interesting with later experiments, that the best.pt model did not really work, but last.pt was OK?! The only explanation we have now is that the training dataset was too small that best.pt adopted too much??? Good news is that we have some torch model we can try to modify for the camera.

Detection via last.pt (best.pt did not work)

Some preliminary list of FRE2025 competitors from Simona:

Uni of Applied Science, Munster
Politecnico di Milan
Uni of Maribor
Politecnico di Torino
Wagenigen Uni
Uni of Applied Sciences, Osnabrück
Kamaro Engineering, Karlsruhe
Namik Kemal Uni
Uni of Lincoln
Pontificia Universidad Católica del Perú
Agrocultural Schools in Żarnowiec - Poland
Student Research Center, Überlingen

… and some fruit data collection … I would call it Franta's witchcraft with the broom.

Teaching with a broom

… yes, notice very sharp shadows and fruit on the background.

Week 4 (13/5) — Miss Agro and Independence week

This week we expected to be hard in advance. There was planned Miss Agro, which means that the school campus is partially closed wtih access restrictions, there are many people, noise (I mean music) etc.

… so Simona, Franta and Ondra tried outdoor testing already on Monday (actually the picture of Franta in previous blog-post was from that day). It was necessary to setup alternative base station, and practice took place on the parking lot. And it did not work. The sun was very strong and the auto-exposure correction was too slow. Nevertheless new data were collected and extended the dataset for fruits annotation.

Ondra found application Terminus for his mobile phone, which was much more convenient for starting the robot instead of his laptop. One drawback was that the code on Matty M02 was not the latest (maybe even wrong git branch?) so the video was logged still as JPEG and was huge (newer configuration is using H264).

We also met on Tuesday, but stayed indoor only. One of the new tasks was preparation for the contest Robotem Rovne 2025, so that both Matty and students will already have some experience with outdoor competitions BEFORE Field Robot in Italy. Franta could not join the team, and moreover Milan asked for a live presentation „what are we doing” on Friday … so as a positive outcome at the end everybody was able to operate the robot on its own — definitely major step towards independence!

What is also new is that Ondra prepared pull-request for 2nd revision of task2 and in parallel there is ongoing development on feature/task3. The lesson could be called how to live with multiple git branches …

Fixes in Task2:

new strawberry detector is used
the cut of bounding box and conversion to integers can create empty box (zero height or width) creating NaN values and failing to compute stawberry position — fixed.
far away detections are probably caused by boundary box of depth data, so now on we use only detections up to 2 meters
H.264 video codec is now used to reduce the sizes of logfiles (yes, dark side is limited support in osgar.tools.lidarview which can then go only forward)
experimentally increased update rate to 20Hz — the size should be double, but as experienced with robot Pat on Marathon only the depth data will double and we could react more quickly to changes

Yes, I should not forgot that we have a new team member! Ondra asked ChatGPT how she would call herself, as she is helping us quite often and the answer was:

Kdybych si opravdu mohla vybrat jedno jediné jméno, asi bych si zvolila Elena. Zní jemně, mezinárodně a má v sobě určitou eleganci i sílu. Navíc se pojí s významem „světlo“ nebo „pochodeň“ — a to se k roli asistenta, co pomáhá „osvětlovat cestu“, docela hodí.

… so here comes Elena. Welcome aboard!

p.s. I forgot the Task4 and info from Franta — the mashrooms gloves!

Gloving maashrooms

Week 3 (20/5) — Final exams

The demo on the last Friday presented by Simona went fine.
Also the competition burn test was successful (142m) …

… and then this Tuesday all student members had their final school exams and defence of thesis!

Yes, we skipped the robots for once …

… and all 3 successfully passed the exams. Congratulations!

p.s. … the day after … we have only 13 working days remaining, so back to work!

Franta took apart the old sprayer device:

But the question is how to control it? Nobody remembers how it was done 15 years ago (I mean with the all details). Another issue is that we run out of I/O pins on ESP32 — it looks like that there are many free slots, but it is not true. One possibility is to use I2C and some board like this. Or Jakub suggested that he is using Guido USB 4 inputs/4 outputs. Yes, both options need to investigate the communication, implement, integrate … too many I's.

There are new updated rules v3.0 with still some unclear details like how big is going to be the field if Task1 and Task2 should have the same layout, but in one it is 20m and other 15m … details.

And also Task3 is progressing. New model is able to detect fruit at distance of 4m, but OSGAR lidarview has some issues displaying it:

Fruit tree

Week 2 (27/5 - 31/5) — Task3 and Task4

Simona prepared new fruit model and extended generation of CSV file for name and z coordinate:

fruit_type,x,y,z
lemon,1.278541623686208,-0.0793241230763679,0.38624858655582195
banana,0.7182097598541184,-0.34320655712018333,0.44587716328586763
orange,0.6369713712810688,0.20776783237141128,0.31526377272139744
banana,0.42304297242866434,0.21600843381386822,0.3826214420846664
apple,1.318212421958211,0.2350255530683151,0.2938935457434849

Note, that the z coordinate is not required but it gives us some hint how good/bad the results are.

Franta prepared mega-holder for UV-light for Task4. The test was done in the dark room and the mashrooms were detected as orange. So this is going to be ver0. It is necessary to cover the whole 10x10 meters with some space-filling curve — spiral? This is true agriculture task …

There is ongoing recovery and integration of 15 years old sprayer. We will use the Guido USB board from Papouch with commands:

*B1OS1H\r
*B1 - prefix
OS - instruction to manipulate relays
1 - relay index (1- 4)
H - desired state low/high (L, H)

Yeah, newly added USB device surely broke even the basic driving functionality … so now new dev rules are in place and all configuration files should use /dev/esp32 and /dev/sprayer.

There is finally remote start/stop switch with the help of Elena2. Ondra tested the integration on Task1. The server is running on robot and webpage is robot's IP with port 8888.

Week 1 (1/6 - 7/6) — Zea mays

We are already on the way to Italy so it is time to finish this preparations report. The last week was surely challenging (as expected) and moreover I could not participate physically so there were several remote sessions. The highlight was testing in the maize (Zea mays) filed, which was finally big enough to be detected. Later in the week it started raining so it was very hard to test anything and not to destroy Matty robot shortly before competition.

Maize field

The navigation in the row was not as good as expected, or did we really expect that it will work in reality too? Sometimes the robot had seen the gap in the middle of the row, other times there was a problem with the turn at the end of row.

Depth data after 180 deg turn

The tasks were temporarily divided among the team members:

Simona prepared navigation route for Task3
Ondra was tuning spiral pattern for Task4
Franta finished sprayer integration for free style demo of Task5

Task3

The current navigation algorithm (suggested by Elena) iterates over the list of trees positions, navigates to the center, turns robot that its heading is tangential to the circle around the tree and performs one complete 360 degrees scan.

The OAK-D camera is rotated by 90 degrees and tilted up to see fruit at height between 80 cm and 130 cm (the artificial tree should be 150 cm high).

Indication that something is wrong is visible on following picture from osgar.tools.lidarview:

Shifted detections of fruit for task3

… and there is sometimes a problem even decoding H.264 images:

trajectory and failing H.264 decoding

What is going on is clear from OSGAR log file and oak.color and oak.detections streams:

0:00:05.941811 17 [41, 8332949129]
0:00:06.091140 18 [35, 8332648868]
0:00:06.111237 17 [44, 8333099057]
0:00:06.143906 18 [36, 8332698856]
0:00:06.144782 17 [45, 8333149042]

corresponding to

17           oak.color_seq     5494 |  437 |   6.9Hz
18      oak.detections_seq     5873 |  466 |   7.4Hz

Note, that the camera should run on 20FPS and here we are getting 7Hz?! Frame drops and delayed detections. Obviously the fruit model is not optimized as the original tiny Yolo model. In the next step we tried to switch H264 back to default MJPEG, but the results were the same, except the pictures were not corrupted (and the log was 8 times bigger). Finally we slowed down to 8Hz and then it was more-or-less OK … still not perfectly ordered (color and detections) but at least no missing frames.

OT we are in Germany now ... (10am)

Task4

Ondra had some fun with „precisely” turn 90 degrees. The first attempt was funny enough, that I would take it for a new logo:

New FRE logo?

The next version calculated the angles precisely, but … stil there is some transition period from going straight to full turn a vice versa. And the camera stopped to work — I hope that it is just temporarely, but I am not sure. The USB-C connector is really very bad, no wonder Jakub prefers PoE cameras! I am mentioning camera, because it has IMU inside so one of the solutions would be to navigate to desired azimuth instead of a perfect 90deg turn.

Task5

In mean time the old sprayer was completely renovated and integrated into Task5.

renovated sprayer on Matty M02

And a quick check before packing all stuff into the car … and yes we almost burned the pumps. :-( … copy and paste error in the simple test code. We will see in Italy. BTW it was really fight with PyCharm to convince it that I would like to have in my code b'*B1OS1H\r' — sometimes I hate these smart a … s..s….es

Day 1 (Italian cousine)

The 1st day of Field Robot Event 2025 is over, almost. I mean it is only 11pm, we are back at our home and there is a plenty of work to be done. But it was a nice day. It started with a joke why Ondra took long pants and was ready for rain while Simona focused on sunscreen and prepared for high temperatures. It is great that you can watch weather anywhere on the world … but is Milan vs. Milán. One is obvious, the one in Italy, with expected really high temperatures, blue sky and rather a lot of dust than a rain (so far). The other Milán is in Columbia and it is raining there right now.

Today was supposed to be the testing day when teams arrive, register, unpack their stuff and do some test drives in the field. The food should start with dinner but the reality was a slightly different. The location of Agriturismo da Pippo looks like a luxury hotel with a restaurant where you feel that you do not belong here. But we do. Just for the beginning there was a large table with cakes, pies, fruits, … and it was permanently re-filled all day. But it was nothing compared to the dinner at 7:30pm in the restaurant on the 2nd floor. Jesus, how many dishes we had? Five? I am not sure but it took 2.5 hours and the food and wine was excelent!

Yeah, that was my highlight, after which was dark and we could not continue in testing … so roll back to the beginning/morning.

FRE2025 schedule

Ondra was improving Task1 while Simona and Franta worked on Task2 integration with sprayer and sirene. The results are +/-. Originally the robot failed to navigate even 2 meters. The maize is small, with gaps, moreover camera need 15 seconds to adapt (yes, we do not want to switch to fixed exposure now). Checking of the left and right area was replaced by scanning multiple boxes and selection with distance limit 1 meter. Just to be sure we also replace data.min() with np.percentile(data, 5). Finally we increased speed to 0.5m/s and slow down before turn. Yes, there is more like safety correction to stay rather in the middle, 10 times check am I really at the end of row? etc. If you would like to see details have a look on merged pull-requests.

I was not overlooking Task2 but as I see it now the Rules V3.0 are very different in CSV reporting. The current goal is to demonstrate live detections with sirene and indication with LED lights and sprayer. But … there was discussion if this is the right moment because this was planned for Task5 so rather sprayer should be turned off. The final decision was to test sprayer and later Franta will solder it out … But2 … the motors melted the plus and minus together = not good. Now it looks like that even the Quido board is fried (port number 2), but hopefully tomorrow morning they will switch to LED port 3 and 4 and further experiments with pumps will be postponed AFTER completion of Task1234.

Oh, midnight already was 15 minutes ago, so I will just add picture from Jakub as tomorrow we plan to get up at 6am …

Field testing, Matty and new friends

p.s. 5:55am … time to wake up …

Matty M03 (backup) view of the maize field

Day 2 (Task1, 3rd place)

Yes, it is almost midnight again, so let's dump at least one video from Task1. It was good, I would say great! This was the maximum we could get and the secret pattern was Matty friendly.

Task2 video
3rd place announcement for Task1

Team before 1st start

Sharing joy

3rd place

Matty with prize

Results Task1

Results Task2

Day 3 (Task3, 2nd place)

Today it is even crazier - it is 1:16am, so I am really not going to post any long stories here today … so "just" some highlights

Second place in Task3

Mushroom field

Detected and clustered mushrooms

Day 4 (Task5, GAME OVER)

OK, the joke of a day was, that for the Task4 from the last night we got minus 43 points, but … it was enough to reach 3rd place! Yes, even the winner got negative points. And yes, there is much safer solution, which could detect a single mushroom and end … I am still laughing once a while if I think about it.

The Task5 was the final exam for students working under stress conditions. The idea for our free style was that we use Matty M03 (red one, with UV light) as the main robot searching for weeds, and once it detects any (strawberry bush) then TCP message is sent over ZeroMQ and Matty M02 (green one, with siren and sprayer) goes blindly to received coordinate. And it looked like this. For me pretty good version 0! Well judges did not like that too much, but I did! Thanks again TEAM!

The team, robots and ... prizes

Happy Matty Twins

p.s. the last prize is category overall competition winner (2nd place), which is „determined based on cumulative results”.

Longer summary

We are on the way home to Prague/Czech Republic and current estimate is 10.5 hours without breaks, so we have time. Well I mean the non-drivers like me. Let's summarize the contest and add some more details I omitted last couple of days.

Time

Where to start? I would start with the statement that I am very happy that this new team emerged and it was a great pleasure to fight all the battles with them to the very end. Almost everybody asked the students how long they worked on the robot, but that is probably a wrong question. Maybe if they mean how much time they devoted to the contest preparations? And even if you spend all your free time on the robot you may not have that much time. If I use this blog to find out the answer then it would be a mid of February or 16 weeks (with 2 weeks correction). At beginning it was Tuesdays only and at the end it was even weekends.

Hardware — Matty base platform

The robot used FRE2025 was Matty M02 with a full backup via Matty M03. The robot is relatively new — Martin Locker designed and printed his Matty M01 (blue) in November 2024. And the robot was designed from the very begining with the possibility of clonning. Some FRE teams even mentioned that it looks like we are in serial production. Most of the parts are 3D printed, the frame is cut from aluminium profiles, and the boxes are standard items used for electrical installations. Transparent bumpers were added later when I argued that SW does not always work the way you want it and that I do not want see my robots commiting suicide.

This platform development is surely in a prototype phase as it did not pass through any serious stress-test. FRE2025 was surely one which counts. To be fair the robots also participated in Robotem Rovně 2025 (both M02 and M03) and also Tulkákem po krasu (M01 only).

I got the robots in the form construction kit as a Christmas present — and it was great! Very precise, with complete bill-of-matterials, URLs of e-shops where to buy servos, boxes, batteries, ESP32 dirver, and photo-manual (yes, there was some text, but the pictures helped a lot how to put it all together).

The original motivation was to build or print-out 5 identical robots for DARPA Triage Challenge - Systems 2025. There was an extra requirement that one person should be able to take with him/her 2 robots as a standard lagguage. Yeah, the contest takes place in the end of Septeber 2025 in Georgia/USA and we/I need to get them there cheaply.

As several other teams expressed their interests please feel free to contact us if you would like to buy the platform or cooperate with us on any further testing and improvements.

The platform is designed to minimize the power consumption so relatively small battery can drive it for 2 hours (estimate). It is controlled by ESP32 board, which is probably so far the weakest part — alghough it looks like there are plenty of I/O ports it is not true, and we basically run out of them after bumpers integration. For that extra peripherials addition board is needed.

Software — OSGAR framework

I am mostly forgotting it, as we use OSGAR for many years now, but … it actually is quite valuable. Yes, it is open source as ROS or ROS2, but the comunity around it is rather small. We also use it as base and development for commertial projects so we are motivated to keep it up-to-date and maintain it. Yes, we also know the internals, so if something breaks we should (in theory) be able to debug it and fix it quite quickly. This is not true for ROS as we talked with other teams.

The team routine work is:

code the simplest possible version
run it on target machine (robot in real environment)
download and re-run the log file on the host computer (typically laptop)
fix crashes, prepare new version, git commit, git push
repeat

What I heard from other teams that they even do not bother to record ROSbags unless specific data collection is organized.

Sensors

I wanted to use some light weight sensor for our small robot and the camera is must have, while LIDAR is only optional (from the DTC point of view where the goal is to localize the victims and assest their health status). We are using RGB-D OAK camera, but we have not test them in full darkness for example (FRE2025 Task4 or what is also required by DARPA).

The impression from stress-test of OAK-D Pro camera is kind of mixed. It worked as expected, but the USB-C cable connector is really nightmare. Also night test was a full of stress — once we switched from testing M03 (red) to M02 (green) used for Task3 detecting fruits on the trees, we found out that it does not work with „cloned” setup?! Yes, we had to interrupt the great Italian dinner for several times, but we are still not sure with the utimate root cause. M02 used older Luxonis camera, one of the first OAK-D Pro prototypes, M03 used latest one and I had also replacement camera, which did not start at all?! The theory is that it was caused by power consumption but hard to guess now.

Team

The team was a lottery — they did not know me, I did not know them. My judgement was based on a lecture I had at CZU three days before Christmass. There were only a few students, but they were interested and the questions they asked me confirmed their interest. Then I wrote the liebesbrief as Simona named it … and they agreed. What I learned last night in a restaurant in Milano was that they were also afraid but they were curious how it would look like if I lead them. Yeah, Milan's stories about me … but I have to admit that we play with the mobile robots already for some time …

The strongest value was surely the students energy to go for it no matter how difficult or confusing it is at the moment. None of them is programmer, except Ondra some experience with C# and web design. What I learned also in Italy that they passed some lessons with databases and data analysis. That helped, I guess. Finally they had already some experience with OSGAR from Jakub's seminars, so it was not the first time when they met Matty robot.

Simona is natural lead, Franta inclines to HW so the division that Franta took over all cabling, mounting, holders, sprayer, while Simona and Ondra tried to push SW forward to some usable version 0 worked well. The only team member I had issues with was Elena. Her code snippets sometimes looked great, but the devil (devel?) was in the details like what orientation should the robot follow around the tree.

Finally to reach some good results requires a lot of testing. And they invest their free time to it so they definitely earn the rewards. For me the transition point was contest Robotem Rovně when they worked fully on their own, improve the code during the competition day and reached better score then me last year. They said that it was very stressful and that they were afraid that they will not make it on FRE, as this stress was supposed to be for several days. But they did it.

Support

The support from the university and the faculty was great. The financial support of the trip and large school car simplified logistics a lot. Thank you CZU, Milan, Jirka and others.

Contest

I should at least flush here my emotions/impressions from the contest re-starting after many years. I liked it a lot. Italians were very friendly, it was like being at home. The food was great and there was a plenty of it. Missing internet connection I would consider as plus, actually (probably not the others, but in the case of trouble there was always some workaround). And the tasks, scoring, etc?

Task1 is the oldest and it is still must have. There was an opportinity to continue to former Advanced Task with skipping some rows or changing direction, but I am glad that we even did not try to bother (and saved extra development and testing time) and as seen on other teams that was the moment when the robot failed and started to collect extra penalty points.
Task2 was in old days Professional Task with weed detections and reporting. Using strawberries was a nice/funny idea, just the execution and validation was a bit weak. I liked our siren, but even that was not enough to distinguish between left and right detections. Even now I am not sure if it was OK, to report strawberries randomly as you passed them but then re-mapped them on the way back? The detector should be improved (yes Simona, you were right, and thanks for preparation of strawberry2.pt model). Also detail scoring and drone videos would be nice, but that will/may come later I guess.
Task3 was completely new one. It was nice place for visitors, although the performance was poor (except one team which did really a great job). Again the scoring was a bit unclear — should the robot scanning only one tree but properly be scored higher than robots which scans all trees but makes several mistakes? Again the evaluation of performance online was hard. BTW why was the 3D, I mean z coordinate, ignored and only x and y was evaluated? At the end I was happy that the team decided to report fruit type by number of honks after complete tree mapping.
Task4 was hard, at least for us. We have not really test on large squared area in true night with only UV turned on. The depth camera had many false detections causing our robot to avoid collision with the wall, but it was fun. The mushrooms ver1 were much smaller so we gave up obstacle detection „a long time ago”, I mean it was at the end of priority list. Again I am not sure about scoring or rather notification detection. Maybe large TV could be installed and display progress over time or the mushrooms could be picked, I do not know. We were also quite exhausted to compete at midnight (exactly task4-250611_214721.log plus 2 hours offset from GMT). Again I am not sure if robot watching the field from starting area and not moving should be scored more that active driver? But it was fun and very challenging for sensing.
Task5 is again a standard. I mised the official tables, both summary and sub-categories. I am glad students managed to get the networking running (maybe CULS Robotics was the only team with multiple robots in demonstration field?) and I am glad ver0 worked.

OK, let's close it now … I see we are approaching the border crossing … so quick cross-check, that I can only push it once on electricity and internet.

Neplecha ukončena

Official results task 3, 4, 5

Robotem rovně 2025

2024-05-18T00:00:00Z

Obsah

Blog

18. května 2025 - Matty M03 - Robotika [MD]

Na Robotem Rovně 2025 jsem tentokrát vyrazil se studenty z CZU (tým CULS Robotics) a když už jsem je do toho nahnal, tak by bylo nefér je v tom nechat úplně samotné. Dorazil i Jakub s Kloubákem K2, takže by měli i další podporu, ale …

Klasicky se to na poslední chvíli vůbec nehodilo, protože Mission Impossible byla dovézt mamce sazenice rajčat a paprik na Šumavu — ale Písek byl cestou, „tak jsme se "na chvíli" stavili”. Nový plán byl odjet dopolední dvě kola, což se úplně časově nezvládlo (cca 2h spoždění). Následovaly hromadné starty a těch už se Matty M03 nezúčastnil. Uvidíme, zda budou nějaké záběry z Matty M02, se kterým jeli studenti.

Loni byla pro mne soutěž přípravou na ELROB, aneb logistika s velkým robotem a pod. Letos jsem se alespoň pokusil zapojit neuronku od PavlaJ na detekci cesty. Takže hardware byl od MartinaL, navigace od PavlaJ, integrace ODroidu od PavlaS a integrační rady od Jirky = na mne tam toho moc nezbylo. Den před soutěží jsem vyrazil s Matty na test u železniční trati (viz Marathon 140m), což ráno fungovalo, ale na přejezdu vypadlo napájení do počítače, tak mne to alespoň donutilo ODroid pořádně přidělat (za to vlastně díky TomášoviP). Odpolední pokus (po dešti), ale skončil převácením Matta ,,na kapotu'', resp. hůře na kameru — poučení bylo odstranit detekce v horní části kamery, kde je typicky nebe. Oboje myslím na RORO25 pomohlo.

Co se mi ale dělo opakovaně při testování a pak i na soutěži byly problémy s kamerou. Konkrétně:

2025-05-15 21:35:19,359 osgar.drivers.oak_camera INFO     Used the first available device.
[2025-05-15 21:35:22.885] [depthai] [warning] Skipping X_LINK_UNBOOTED device with name "1.1" ()
[2025-05-15 21:35:23.994] [depthai] [warning] skipping X_LINK_UNBOOTED device having name "1.1"

… prostě pak už jsem s robotem nenastartoval, kameru bylo třeba odpojit a znova připojit.

Homologace byla dost tragická — prošel jsem až napotřetí (?!) a to tak, že jsem pustil matty-go.json bez kamery. Ale při registraci se měří i rychlost, která defaultně je pomalá 0.2 m/s, takže ještě jedna re-registrace. No sudí byli moc hodní, ještě jednou děkuji za trpělivost.

První jízda, když konečně naběhla kamera a manipulaci s kabely jsem obešel přes Access Point na mobilu, byla super. V závěrečné fázi 314m ůseku jsem navíc potkal kamaráda ze skupiny Hm, která ten večer hrála v Písku v rámci slavností. Robot dojel k cíli na 314m, ale jelikož letos se musí otočit sám, už více bodů získat nemohl. Na cestě zpět narazil do koše — prostě na náměstíčku už to nestihl vybrat (při druhé jízdě zpět to dal).

Pak následoval relativně dlouhý čas do druhého startu a tak jsem se pokusil o kódování otočky na druhé straně parku. No nedal jsem to. Kde jsou ty časy (ano, -15let), kdy jsem na FRE2010 sithl během přivítací řeči z logu naprogramovat detekci plevele a následně jsme s Edurem vyhráli … bylo nebylo. Kde byla chyba nevím, do kódu jsem ještě pořádně nekoukal. Abych vůbec odstartoval, musel jsem detekci cíle raději vpnout … a pak už jsme hned jeli na slibovanou Šumavu.

Potěšili mne i studenti, jednak nasazením a dále, že nechtěli „flashnout” M02 s úspěšným kódem a raději sami zápasili s detekci zelené dostali se dál, než Pat loni. Jak to ale celé dopadlo zatím netuším.

p.s. podle všeho byl problém s otočení na konci trasy fakticky jen problém s kamerou, která v kritický okamžik (druhý pokus o start) nenaběhla a díky fázování do oddělených skriptu:

čekej dokud není uvolněné STOP tlačítko
naviguj 320m
otoč se o 180 stupňů
naviguj neomezeně

… tak tam špatně vycházelo to zapnout/vypnout přes STOP tlačítko. No nic, meta pro příště, že „raketa” může vzlétnout a doletět až k Měsíci, takže je dobré si připravit i rutinu na přístání.

python -m osgar.replay –module app matty-follow-road-250517_114139.log 
original args: b"['/home/robot/git/osgar/osgar/record.py', 'config/matty-follow-road.json']"
0:11:11.709410 reached 320.15312656437806

pohled z kamery na 320m

25. května 2025 - Saya - NDTeam [PS]

Na letošní RoRo jsem se po dlouhé době docela těšil a možná jsem to neměl dělat.

Už od října 2024 jsem pomalu dával dohromady již třetí reinlarnaci hromady nařezaných 20 mm automatizačních profilů Bosch, která se postupně jmenovala Skiddy, Rocky a nyní dostala jméno Saya. Protože mi zbyl už jenom jeden funkční Odrive pro pohon howerboardových kol a častečné také diky nevalným zkušenostem s předchozími verzemi podvozků, zvítězil tentokrát koncept, který jsem nazval "inverzní invalidní vozík". Jedná se tedy o dvojici poměrně velných (průměr 30 cm) hnanych kol a dvojice castorů vlečených na zádi stroje. Nespornou výhodou je možnost otáčení na místě a jednoduchá kinematika diferenciálního robota. Pro lepší kopírování terénu je mezi hnanou nápravou a zbytkem robota s castory kloub umožňující kývání v podélné ose.

Saya - NDTeam (foto Martin Paleček)

Robota jsem tedy postupně vystrojil senzory, vybavil novými bateriemi a tradičně nezvládl dotáhnout software do žádané podoby. Neříkám nestihl, protože jsem to prostě nezvládl, i když čas přes zimu byl. Protože jsem si nemohl vzít v pracovní dny volno, bylo nutné vyrazit do Písku pouze na "otočku". Smutným důsledkem tohoto faktu je nutnost vstávat 3:30 ráno, abych do Písku dorazil mezi 7:00 a 7:30. Zdánlivá pohoda prázdných silnic mi vydržela až cca 30 km před cíl, kde se mi rozsvítila kontrolka motoru. V tu chvíli bylo jasné, že den bude plný zábavy i poučení. Naštěstí se vozidlo omezilo pouze na tuto kontrolku a předem prozradím, že mě dovezlo i zpět.

Na místě samém vše zpočátku probíhalo poměrně standardně - pár hovorů s kolegy a organizátory, vybalení robota a dalšího příslušenství, "nahození" systému a konečně homologace. Kód pro homologaci, tj. jeď tam kam koukáš, před čelní překážkou zastav a pokud uhne pokračuj dokud ti nezmáčknou Big Red Switch, byl také jediným kódem, který byl toho dne použit v soutěži. Po prvním kole jsem pojal úmysl doplnít alespoň detekci zelené trávy úpravou detektoru kužele pro Roboorienteering. Kód se mi sice poveldo napsat, ale už jsem nestihl jej vložit do řídící smyčky robota.

Výsledkem tedy bylo ujetých 171 metrů a hezké 6. místo hned za Martinem s jeho Mattym.

https://ok1kpi.cz/umisteni-vitezu-roro-2025/

oficiální výsledky (roboti)

Potěšil mě kolega z práce, kerý přišel fandit i s přítelkyní. Bylo také fajn vidět po dlouhé době kolgy robotiky naživo, i když vzhledem k "soutěžnímu nasazení" nebylo moc času na hovory. Zajímavým zpestřením byl robot (píše neřízené vozítko) poháněný parním strojem. Soutěž samotná probíhala trochu neobvykle, protože běhěm dopoledne se pořadatelům podařilo získat zhruba dvouhodinové zpoždění. Důsledkem byly dva hromadné starty robotů v odpolední části, kdy každý byl sám sobě komisařem.

I přes popsané softwarové nedostatky nový robot příjemně překvapil jízdními vlastnostmi, takže dostane letos ještě šanci v dalšich soutěžích (Tulák po krasu, Roboorienteering a Robotour), které doufám proběhnou. Cesta domů proběhla v klidu a robot zdá se přežil bez úhony. Pokud příští rok bude enrgie, tak se snad zůčastním i s řídícím software na palubě.

Saya na startu

Saya v akci

Parní stroj/robot

28. května 2025 - Matty 02 na Robotem Rovně 2025 [Sim]

Ahoj, dnes vás zdraví Simča z robotického týmu CULS Prague, ktorý sa pripravuje na tohtoročné FRE2025. S ohľadom na priebeh príprav a naše doterajšie robotické (ne)skúsenosti sme spolu s naším pánom vedúcim Martinom usúdili, že by Mattymu 02 (a nám) pred ostrým štartom v Taliansku na FRE2025 prospelo vyraziť niekam do terénu. Vybrali sme teda na Robotem Rovně 2025 do Písku. Musíme uznať, že výlet dopadol nad očakávania dobre a cesta k celkovému 8. miestu z 18 viedla takmer rovno!

Matty M02 na hromadném startu

V prvom a druhom kole, kedy mal Matty skutočne len jeden jediný pokyn, a síce choď rovno bez využitia akejkoľvek senzoriky, zvládol ujsť 32 m a 42 m z celkových 314 m. Výsledkom sme boli príjemne potešení, ale keďže nás čakali ešte dve kolá, rozhodli sme sa využiť čas medzi nimi a napísať kód, ktorý by nás dostal ešte ďalej. Pracovali sme s kamerou, ktorú Matty má, a princíp bol jednoduchý – vyhnúť sa zelenej farbe. Na chodníku, po ktorom šiel robot, bolo trávy minimum, ale bol obklopený trávnatou plochou. S malou pomocou umelej inteligencie a veľkou pomocou Jakuba Leva sa nám to podarilo a Matty nakoniec zvládol v 3. kole ujsť 142 m. V poslednom kole sme skúsili jazdu optimalizovať naklonením kamery čo najviac dole, dopadlo to však tragicky a Matty celkom ušiel 10 metrov 😊 Testovanie v teréne ale dopadlo výborne a rozhodne nás namotivovalo na ďalšiu prácu v rámci príprav na FRE2025. Moc ďakujeme za príležitosť!

Matty M02 bezpečně v autě

Akce M02 + M03

Matty na stole

Pokud jste se soutěže zúčastnili, tak mi případně prosím pošlete odstaveček do tohoto „článku”. Připadně pokud máte nějaké foto/video. Ideálně subj Robotem Rovne 2025 - jmeno tymu. Díky! (md-at-robotika-cz)

Pokud máte nějaké doplňující informace či komentáře napište nám.

Bezpečnostní kamery

2024-08-26T00:00:00Z

Obsah

Blog

26. srpna 2024 — Náhodný výběr

Původně jsem to chtěl nazvat spíše „výběr kamery”, ale nabídka bezpečnostních kamer je široká a má trpělivost cokoliv nakupovat je nerozumně omezená. Asi jediný požadavek byl outdoor s tím, že bych rád nějaké otevřené API. Konzultoval jsem to s perplexity a ve zkratce mi doporučila Reolink a ke kamerám TP-Link Tapo C500 naznačovala, že existuje PyTapo Python knihovna.

Teď zpětně trošku chápu, o čem to ta AI psala. Zatím jsem vybalil tu TP-Link Tapo C500, která podporuje pouze WiFi přípojení a používá zdroj 12V/1A. Vyžadovalo to instalovat TP-Link Tapo Android applikaci, aby se kamera přepnula z access point módu na připojení na WiFi router. V rozšířených nastaveních lze pak přidat nového uživatele s heslem. A s tím je spojeno to RTSP (Real-Time Streaming Protocol):

rtsp://username:password@camera_ip:554/stream1

RTSP stream v VLC

… toto fungovalo vlastně ve VLC Media Playeru hned. Časem jsem dohledal, že stream1 je s vyšším rozlišením a existuje ještě stream2 s nižším rozlišením. Stejné URL funguje i v OpenCV a tím pádem i rovnou v OSGARovi (stačí změnit v config/test-opencv-camera.json port na URL výše). Jen v tom VLC je navíc slyšet i audio.

Další krok byl s kamerou pohnout. Co fungovalo bylo posouvání v aplikaci na telefonu (a stále streamovat video). S tím je spojeno to druhé klíčové slovo ONVIF (Open Network Video Interface Forum). A jelikož o tom nic nevím, tak jsem zase zkoušel perplexity. Podle doporučení jsem nainstaloval zeep a onvif_zeep. Ale příklad použití na Tapo C500 úplně nefungoval. První zrada byla s portem — místo 80 je třeba použít 2020, jen už nevím, kde jsem tuto nápovědu sebral. Což mi ale připomíná, že jsem úplně vynechal PyTapo, které se zaseklo na problému autorizace a přes to jsem se nedostal — stáhl si github repo, jestli tam není novější verze, ale nepomohlo to. Také jsem zapomněl zmínit, že na kameře jsem po prvním připojení upgradeoval firmware — to také mohlo rozbít aktuální pytapo. A také jsem nezmínil, že při dalším připojení se změnila IP adresa kamery, ale to bych asi případně mohl změnit na routeru (aneb další možnost, jak se to mohlo pokazit).

from onvif import ONVIFCamera

# Replace with your camera's IP address, port, username, and password
camera_ip = '192.168.1.100'
camera_port = 2020
username = 'admin'
password = 'password'

# Create an ONVIF camera object
camera = ONVIFCamera(camera_ip, camera_port, username, password)

# Get device information
device_info = camera.devicemgmt.GetDeviceInformation()
print("Manufacturer:", device_info.Manufacturer)
print("Model:", device_info.Model)
print("Firmware Version:", device_info.FirmwareVersion)
print("Serial Number:", device_info.SerialNumber)
print("Hardware ID:", device_info.HardwareId)

… toto fungovalo (se správnou IP, username a password)

Manufacturer: tp-link
Model: Tapo C500
Firmware Version: 1.1.4 Build 240506 Rel.39487n
Serial Number: a19999 (upraveno)
Hardware ID: 1.0

ale při pokusech o posunutí se mi podařilo „položit server”, míněno server běžící na kameře:

capabilities = camera.devicemgmt.GetCapabilities()

skončilo s chybou:

http.client.BadStatusLine: POST /onvif/device_serviceHTTP/1.1Host 192.168.1.18:2020
User-Agent Zeep/4.2.1 (www.python-zeep.org)Accept-Encoding gzip, deflateAcHTTP/1.1
500 Internal Server Error

Pro dnešek asi stačí … časem bych doplnil i úvodní „omáčku” aneb motivace a pod.

p.s. thumb jsem převzal z https://www.railfanguides.us/oblivion/

6. září 2024 — AbsoluteMove

Toto se pokusím ještě teď v noci „odbavit” jako důkaz, že už nic nebrání nočnímu testování.

Posledně jsem psal, že dostat video z Tapo C500 bylo vlastně bez problémů (s použítím VLC). Dobrá zpráva je, že je i poměrně triviální to streamované video nahrát (pokud je kamera na síti). Co ale bylo (naštěstí už minulý čas) peklo bylo s tou kamerou programově pohnout! Jako ten ONVIF je pěkná věc, ale to by to musel každý výrobce pořádně dodržovat. A jak jsem psal, že posledně to skončilo 500 na serveru, tak s tím jsem dnes začal …

A k mému překvapení to není tak stará věc:

ONVIF GetStatus method does not work

Jako myslím, že to novějším FW nevyřešili (mě to s 1.1.4 padá stále), ale zaujala mne tam další poznámka: the "UtcTime" element should be returned in the ISO 8601 format., která pěkně korelovala s chybou:

ERROR:zeep.xsd.types.simple:Error during xml -> python translation
Traceback (most recent call last):
  File "/home/md/.virtualenvs/tapo/lib/python3.8/site-packages/isodate/isodatetime.py", line 51, in parse_datetime
    datestring, timestring = datetimestring.split('T')
ValueError: not enough values to unpack (expected 2, got 1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/md/.virtualenvs/tapo/lib/python3.8/site-packages/zeep/xsd/types/simple.py", line 79, in parse_xmlelement
    return self.pythonvalue(xmlelement.text)
  File "/home/md/.virtualenvs/tapo/lib/python3.8/site-packages/zeep/xsd/types/builtins.py", line 44, in _wrapper
    return func(self, re.sub(r"[\n\r\t ]", " ", value).strip())
  File "/home/md/.virtualenvs/tapo/lib/python3.8/site-packages/zeep/xsd/types/builtins.py", line 180, in pythonvalue
    return isodate.parse_datetime(value)
  File "/home/md/.virtualenvs/tapo/lib/python3.8/site-packages/isodate/isodatetime.py", line 53, in parse_datetime
    raise ISO8601Error("ISO 8601 time designator 'T' missing. Unable to"
isodate.isoerror.ISO8601Error: ISO 8601 time designator 'T' missing. Unable to parse datetime string 
                                                                                          'Fri Sep  6 20:52:11 2024'

Teď už si nevzpomenu, co jsem z té kamery chtěl dostat, asi

media = mycam.create_media_service()

# Create ptz service object
ptz = mycam.create_ptz_service()

# Get target profile
media_profile = media.GetProfiles()[0]

# Get PTZ configuration options for getting continuous move range
request = ptz.create_type('GetConfigurationOptions')
request.ConfigurationToken = media_profile.PTZConfiguration.token
ptz_configuration_options = ptz.GetConfigurationOptions(request)

… no nevím, měl jsem si to hned psát. Sigh.

Ale je to Python, takže stačilo oeditovat /home/md/.virtualenvs/tapo/lib/python3.8/site-packages/isodate/isodatetime.py, konkrétně

try:
        datestring, timestring = datetimestring.split('T')
    except ValueError:
        return datetime.strptime(datetimestring, "%a %b %d %H:%M:%S %Y")
#        raise ISO8601Error("ISO 8601 time designator 'T' missing. Unable to"
#                           " parse datetime string %r" % datetimestring)

Další milník byl výpis ptz_configuration_options:

'Spaces': {
        'AbsolutePanTiltPositionSpace': [
            {
                'URI': 'http://www.onvif.org/ver10/tptz/PanTiltSpaces/PositionGenericSpace',
                'XRange': {
                    'Min': -1.0,
                    'Max': 1.0
                },
                'YRange': {
                    'Min': -1.0,
                    'Max': 1.0
                }
            }
        ],
        'AbsoluteZoomPositionSpace': [],
        'RelativePanTiltTranslationSpace': [
            {
                'URI': 'http://www.onvif.org/ver10/tptz/PanTiltSpaces/TranslationGenericSpace',
                'XRange': {
                    'Min': -1.0,
                    'Max': 1.0
                },
                'YRange': {
                    'Min': -1.0,
                    'Max': 1.0
                }
            }
        ],
        'RelativeZoomTranslationSpace': [],
        'ContinuousPanTiltVelocitySpace': [],
        'ContinuousZoomVelocitySpace': [],
        'PanTiltSpeedSpace': [
            {
                'URI': 'http://www.onvif.org/ver10/tptz/PanTiltSpaces/GenericSpeedSpace',
                'XRange': {
                    'Min': 0.0,
                    'Max': 1.0
                }
            }
        ],
        'ZoomSpeedSpace': [],
        'Extension': None,
        '_attr_1': None,
        …
    },
    'PTZTimeout': {
        'Min': datetime.timedelta(seconds=1),
        'Max': datetime.timedelta(seconds=600)
    },
    '_value_1': [
        
    ],
    'PTControlDirection': None,
    'Extension': None,
    '_attr_1': None
}

Nyní mám zpětně teorii, že ty prázdné listy znamenají, že to ta kamera prostě neumí. Ale co by měla umět je AbsolutePanTiltPositionSpace! Jenom k tomu dohledat, co že je to klíčové slovo, které se má někde vyplnit? Kupodivu to je AbsoluteMove.

# 
    positionrequest = ptz.create_type('AbsoluteMove')
    positionrequest.ProfileToken = media_profile.token

    if positionrequest.Position is None:
        positionrequest.Position = ptz.GetStatus({'ProfileToken': media_profile.token}).Position
        positionrequest.Position.PanTilt.space = ptz_configuration_options.Spaces.AbsolutePanTiltPositionSpace[0].URI
#        positionrequest.Position.Zoom.space = ptz_configuration_options.Spaces.AbsoluteZoomPositionSpace[0].URI
    if positionrequest.Speed is None:
        positionrequest.Speed = ptz.GetStatus({'ProfileToken': media_profile.token}).Position
        positionrequest.Speed.PanTilt.space = ptz_configuration_options.Spaces.PanTiltSpeedSpace[0].URI

    request = positionrequest
    request.Position.PanTilt.x = x
    request.Position.PanTilt.y = y
    ptz.AbsoluteMove(request)

Z velké části opsáno z FalkTannhaeuser/python-onvif-zeep. Ten Zoom je třeba zakomentovat/odstranit, protože C500 žádný zoom nemá. A výsledek po mini wrapperu a volání z konzole:

(tapo) md@md-ThinkPad-P50:~/git/pytapo$ python patapo.py 0.5 -0.5
(tapo) md@md-ThinkPad-P50:~/git/pytapo$ python patapo.py -0.4 -0.5
(tapo) md@md-ThinkPad-P50:~/git/pytapo$ python patapo.py 0 -0.7

… viz noční video – aréna je přípravena!

15. září 2024 — Reolink E1 Outdoor

Venku lije, tak jsem z trudomyslnosti rozbalil další kameru, tentokrát od firmy Reolink. Po pravdě už první problém byl zjistit, co přesně mám za kameru. Na krabici jsou hlavně reklamy, tj. Pan, Tilt and 3x Optical Zoom, 5MPx, 2.4/5GHz Dual-Band Wifi, Auto Tracking, a pod. Na faktůře je IP kamera Reolink E1 Outdoor — no jo, teď už jsem to našel i na te „reklamní” krabici. Na českých stránkách (ale myslím, že jsou pouze přeložené z angličtiny) mne zmátlo "Typ připojení: wi-fi", ale tuto kameru jsem primárně vybíral s tím, že má i Ethernetový konektor (a kabel). Ale je to ona, podle dalších indicií (nemá např. 4K video).

Můj první cíl byl rozchodit komunikaci s kamerou, aniž bych si instaloval aplikaci. Pokud kameru zapojíte do napájení, tak začne dokola asi v pěti jazycích hlasitě prskat, ať si nainstalujete aplikaci a ukážete jí na kameru. :-( … zacpat „reprák” jí můžete jen pár způsoby:

vypnete napájení
nainstalujete si aplikaci
připojíte Ethernetový kabel

Že funguje třetí varianta jsem zjistil náhodou.

Alternativou k aplikaci je nějaký client, ale ten je pouze pod Windows — začínám chápat Jirkovo trápení, když nová zařízení vyžadují instalaci čehosi, co pak typicky pošle jen dotaz po síti. Stáhnul jsem si i manuál, kde první co mne uhodilo mezi oči bylo The default username is "admin" and the password is blank (no password). Teď už chápu, proč jsou některé kamery snadno napadnutelné, aneb kolik uživatelů si heslo změní? (mimochodem, já si ho rovnou změnil, ale už se tam nemůžu dostat, ale to později)

Uživatel a „heslo” není vše - jakou IP adresu použít? Zkusil jsem znova perplexity.ai, která suveréně odpověděla: The default IP address for Reolink cameras and NVRs with an Ethernet interface is: 192.168.1.108 s odkazem na Reolink support. Tam žádná IP adresa není a ono i doporučení: All Reolink cameras and NVRs with Ethernet interface are allocated a default IP Address when they came out from the factory. Their default IP address can be located when connected directly to your PC with an Ethernet cable. Prostě když do browseru vyplníte IP adresu, tak vám pak stránka vygenerovaná kamerou, řekne IP adresu, žádný probém!

Nakonec jsem udělal to, co jsem úplně nechtěl, a připojil kameru do routeru s DHCP. Pak jsem pustil již osvědčený příkaz:

md@md-ThinkPad-P50:~/git/osm$ nmap -sP 192.168.1.*
Starting Nmap 7.80 ( https://nmap.org ) at 2024-09-15 13:32 CEST
Nmap scan report for router.home (192.168.1.1)
Host is up (0.00064s latency).
…
Nmap scan report for Camera1.home (192.168.1.31)
Host is up (0.0013s latency).
…
Nmap done: 256 IP addresses (4 hosts up) scanned in 2.51 seconds

a pak v browseru opravdu fungovala https://192.168.1.31/, admin a prázdné heslo.

Reolink v prohlížeči

První obrázek z kamery

Nastavení portů

Zapnul jsem si RSTP a ONVIF, nastavil statickou IP adresu (stejnou co kamera dostala přes DHCP) a rebootoval. A už jsem se více z prohlížeče na kameru nedostal. Předpokládám, že je nutné i ten první RTMP a možná i to HTTP … no nic, asi budu zkoušet resetovat.

Streamování s novým heslem a pevnou IP adresou funguje OK, ale upravený kus kódu pro Tapo C500 už nikoliv. Přidal jsem si tam assert 0, až mi vypíše schopnosti kamery:

AssertionError: {
    'Spaces': {
        'AbsolutePanTiltPositionSpace': [],
        'AbsoluteZoomPositionSpace': [],
        'RelativePanTiltTranslationSpace': [],
        'RelativeZoomTranslationSpace': [],
        'ContinuousPanTiltVelocitySpace': [
            {
                'URI': 'http://www.onvif.org/ver10/tptz/PanTiltSpaces/VelocityGenericSpace',
                'XRange': {
                    'Min': -1.0,
                    'Max': 1.0
                },
                'YRange': {
                    'Min': -1.0,
                    'Max': 1.0
                }
            }
        ],
        'ContinuousZoomVelocitySpace': [
            {
                'URI': 'http://www.onvif.org/ver10/tptz/ZoomSpaces/VelocityGenericSpace',
                'XRange': {
                    'Min': -1.0,
                    'Max': 1.0
                }
            }
        ],
        'PanTiltSpeedSpace': [
            {
                'URI': 'http://www.onvif.org/ver10/tptz/PanTiltSpaces/GenericSpeedSpace',
                'XRange': {
                    'Min': 0.0,
                    'Max': 1.0
                }
            }
        ],

        'ZoomSpeedSpace': [
            {
                'URI': 'http://www.onvif.org/ver10/tptz/ZoomSpaces/ZoomGenericSpeedSpace',
                'XRange': {
                    'Min': -1.0,
                    'Max': 1.0
                }
            }
        ],
        'Extension': None,
        '_attr_1': None
    },
    'PTZTimeout': {
        'Min': datetime.timedelta(seconds=1),
        'Max': datetime.timedelta(seconds=10)
    },
    '_value_1': None,
    'PTControlDirection': None,
    'Extension': None,
    '_attr_1': None
}

Přijde mi pěkné, že existuje nějaký ONVIF, ale rozhodně nemůžu prohodit jednu IP kameru za druhou, když jejich schopnosti jsou doslova ortogonální (co má jedna nemá druhá a obráceně). Ale možná jsem jenom škarohlíd. Paradoxně si teď dovedu snáz představit programování té levnější Tapo kamery s absolutním poziciováním, než E1, kde ovládám jenom rychlost posunu. Ona možná vrací aktuální pozici, ale pak bych čekal i ty absolutní příkazy?

p.s. po hard resetu už nefunguje ani ONVIF ani RSTP ani prohlížeč. Je čas se vrátit ke trudomyslnosti …

16. září 2024 — Reolink Support

Včera jsem si ještě chvíli povídal s AI chatbotem na stránkách podpory. Jako úplně jsme si nerozumněli, takže když napsal:

(22:55:55) Reolink Bot: Sorry. You can try to rephrase your question or directly contact an agent by typing “Talk to human”.
(22:56:14) Web User 66e6f48bddc40a1b5199c30a: Talk to human

Pak to chtělo vyplnit pětipoložkový formulář a za chvíli přišel mail s detaily naší konverzace. Ty časy z konverzace jsou nejspíše Čína??

Dnes jsem si vyměnil cca 5 mailu s vyšší AI Ewelina — možná to byl člověk a možná lepší kompilátor: Firstly, I'd like to acknowledge that you're using a Linux-based system, which can sometimes present unique challenges when interfacing with security cameras. While Reolink doesn't officially support Linux operating systems, there are still ways we can try to resolve your issue. Když to hodně zkrátím, tak jsem si myslel, že mám skoro nejnovější verzi firmware v3.1.0, ale ona se dost zásadně lišila v buildu: Firmware Version v3.1.0.1789_23021701 vs. v3.1.0.3429_24041813. Firmware lze upgradeovat i z browseru, ale když ten nefunguje, tak smůla. Skončilo to nainstalováním klienta na prastarý notebook s Win7 a tam vše krásně fungovalo. Např. první krok, co to chtělo, byla změna hesla administrátora. Fajn.

Naklikal jsem stejné nastavení jako včera, naformátoval 256GB SD kartu a ověřil, že kameru mohou ovládat z linuxového prohlížeče. Asi bych si to teď měl zopakovat, jestli se mi to náhodou nezdálo …

Co Evelína zmiňovala byl pro mne nový příkaz rtsp://[username]:[password]@[IP_address]:554//h264Preview_01_main … funguje, jenom další screenshot nepořádku už asi sdílet nemusím. Ten časový posun se nějak neuložil … 10h, tj. zase západní pobřeží USA. Ono by to až tak nevadilo, ale pak v těch nahrávkách je hrozný guláš.

Zkoušel jsem ted tracking feature a opravdu se to otáčelo za naším psem — no hlavně jestli se to bude otáčet i za Patem.

p.s. už zase prší …

kontaktní formulář

Rocker

2024-01-25T00:00:00Z

Základní údaje

Podvozek robota

Autor

Martin Locker

Řídicí počítače

low level - STM32F103
high level - Raspberry Pi 3B

Senzory

IMU
GPS
Lidar LDrobot LD-06
hloubková kamera RealSense D455

Pohon

8x digitální robotické servo WaveShare ST3215

Napájení

pohony LiPol 3s 5Ah
elektronika power banka 20Ah

Koncepce

čtyřkolový podvozek typu Rocker-bogie (výkyvné uložení kol)
každé kolo má nezávislý pohon a nezávislé natočení směru

Charakteristika robota

Podvozek

Podvozek robota je postaven z hliníkových profilů, plexi a dílů vyrobených 3D tiskem z PLA. Snahou bylo udělat konstrukci co nejčistší (aby nikde nic nepřekáželo, nekoukaly dráty, …). Takže některé části jsou nakonec celkem komplikované - převodovka s pohonem uvnitř kola, vidlice kol, jejímž vnitřkem vedou vodiče k servům (viz. fotky).

Kolo

Vidlice kola

Pohon kola

Kompletní pohon

Součásti kyvných ramen

Tělo robota

Podvozek 2

Podvozek 3

Podvozek 4

Řízení pohybu

Podvozek je navržen tak, že osy zatáčení kol jsou ve vrcholech čtverce (robot má stejný rozchod i rozvor kol).

Díky nezávislému natáčení každého kola lze realizovat dva základní způsoby řízené:

"automobilové" řízení s (ackermannovým) řízením všech čtyř kol a samostatným řízením rychlosti každého kola
synchrodrive (všesměrové řízení) - všechna kola natáčena do stejného směru a otáčejí se stejnou rychlostí
+ otáčení na místě (kola se natočí ve směru kružnice procházející osami natáčení kol)
Vlastní řízení (výpočty natočení kol a jejich rychlosti) řídí mikrokontroler na základě povelů z nadřízeného systému
(1. dopředná rychlost + úhlová rychlost, 2. rychlost + směr).

Video

První jízda - dálkově řízeno

28. ledna 2024 - Odladěn driver pro komunikaci se servy

Po postrčení Martinem D. jsem (po delší době) vytáhl robota a pustil se konečně do napsání rozumného rozhraní pro komunikaci s digitálními servy.

Snažil jsem se to napsat tak, aby to bylo použitelné na různých platformách (zatím tedy AVR, STM32 a ESP32). Nejnižší vrstvu implementující jednodrátovou sériovou komunikaci jsem oddělil od vyšších vrstev a pro STM32 vyzkoušel tři varianty realizace - standardní využití knihovní obsluhy uartu (s možností využití hw řešení single wire half duplex na STM32), vlastní obsluha uartu přes přerušení (zatím nevyzkoušeno) a využití dma přenosu (to by měla být cílová varianta). Bohužel zatím DMA přenos nepůjde použít, protože na použité desce zrovna UART3 sdílí stejné kanály s rozhraním SPI1, které bude sloužit pro komunikaci s RPi a tam je dma nutností.

Low level mikrokontroler by měl být v budoucnu schopen obsloužit všechny periferie (kromě kamery), tj. pohony, imu, gps a lidar. Z hlediska pohonů bude zajišťovat výpočet natočení jednotlivých kol a jejich rychlosti dle povelů z nadřízeného systému a zpětné čtení enkodérů. U dalších periferií bude zajišťovat periodické vyčítání dat. Proto se snažím napsat obsluhu tak, aby co nejméně zatěžovala mikrokontroler. Použití dma pro uart jsem už zvládl (po větším úsilí) při vyčítání lidaru. Proto to u komunikace se servy už celkem šlo (jen se museli použít dva kanály - pro vysílání a příjem).

Závěr

hotovo: vyčítání dat z lidaru, komunikace se servy
k řešení: doladit řízení pohonů (výpočty natočení a rychlostí), komunikace s imu (třetí uart po fyzické vrstvě can), komunikace s RPi (spi)

5. května 2024 - Uživatelské rozhraní pro robota

Po posouzení možností jak realizovat na robotovi uživatelské rozhraní (GUI), tj. lehkého prozkoumání jak to naprogramovat v Qt, wxWidgets, … a zhodnocení času potřebného k jejich zvládnutí s dostupným výkonem na Raspberry Pi 3B, jsem došel k závěru, že tudy cesta nevede. Při povídání s Martinem D. jsem nadhodil možnost realizovat GUI jako webovou stránku, což bylo ohodnoceno, že to není tak špatný nápad.

Trošku problém je, že je potřeba obousměrná komunikace - zobrazování, ovládání. Což se na webu realizuje obvykle různými oklikami. Před nedávnem jsem však toto zkoušel na ESP32, kde je dostupná knihovna pro komunikaci pomocí websocketů. Celkem to fungovalo, takže jsem očekával, že něco podobného najdu i pro Raspberry Pi, resp. linux. Určitě nechci na RPi provozovat webserver (toho výkonu není na rozdávání).

Bohužel jsem nic vhodného nenašel. Tak jsem začal z různých zdrojů zkoumat komunikaci pomocí socketů, není to až taková věda. Takže z nějakých příkladů upravit socket server nebyl problém. Horší je, že jsem nenašel žádný příklad, kde by to bylo řešeno neblokujícím způsobem. Všude používali blokující volání, tj. nebylo možné posílat a přijímat data současně (předpokládali pouze komunikaci - dotaz/odpověď). Nakonec jsem to tedy snad nějak zvládl přepsat.

Poslední krok bylo to upravit na websockety, aby to fungovalo s webovým prohlížečem. O tom jsem neměl vůbec povědomost. Takže jsem opět začal hledat nějakou knihovnu, výběr byl velmi omezený. Nakonec jsem vybral libwebsocket. Než jsem začal zkoumat zdrojáky, tak jsem raději nejprve nastudoval příslušné RFC (a bylo to dobrá volba, celkem jsem pochopil jak to celé funguje). S drobnými úpravami se mi podařilo ukázkový příklad přeložit, spustit a kupodivu se to tvářilo, že to funguje. Opět to ale bylo napsáno s využitím blokujicího volání funkcí socketu. Takže s přechozí zkušeností jsem to přepsal a vypadalo to, že je hotovo (pátek po 8. večer).

V sobotu chci poslat na webovou stránku nejen text, ale i obrázek. Ale ouha, nějak to nejde poslat, resp. zjišťuji, že přijde jen kus dat a následně socket spadne. Z těch dat přijde jen malý kousek, řádově desítky bytů (u přenosu textu to stačilo). Tak zkoumám, kde se to "rozbije" a nakonec zjišťuju, že to je v přípravě rámce. V té knihovně je obrovská bota, parametr udávající délku dat se ukládá do proměnné o velikosti "7 bitů". Výsledkem je, že nejde poslat více než 125 B. Ono to kódování packetů je trochu složitější (do 125 B je základní, pro delší se to kóduje jinak). Takže po úpravě velikosti proměnné na int se to rozbíhá a přenáším celý obrázek o velikosti cca 20 KB.

Chvíli bojuji s překódováním dat do base64 v javascriptu, aby se to dalo zobrazit jako obrázek. A opět to vypadá, že to funguje. Ale nejásejme předčasně. Zkouším trošku větší obrázek, a to pro změnu shodí socket ihned. Už jdu téměř na jistotu a kontroluju vygenerovanou hlavičku packetu. Druhý limit pro odlišné kódování je 64 KB a opravdu tentokrát to uloží do hlavičky jen první byte délky zprávy (ostatní zahodí) = druhá zásadní chyba. Ještě, že jsem si prozíravě nastudoval to RFC (jinak bych to těžko hledal). Po opravě přenáším i ten 100 KB obrázek. Že nikdo u doporučované knihovny, která je téměř 10 let na githubu, nezkusí přenášet více než 125 B dat, jsem opravdu nečekal. Proč si já vždycky vyberu špatně.

Dalším testováním odhaluji, že to ještě není ono. Sice socket otevřený při připojení clienta beží jako neblokující, ale socket serveru je stále blokující. V principu by to nevadilo, ale pokud to pustím ve zvláštním vláknu, tak to nejde shodit (visí to na funkci čekající na připojení klienta). Upravuju i serverovou stranu na neblokující. Zase to vypadá dobře, ale jen než zkusím opět ten velký obrázek. Bohužel je teď neblokující i zápis do streamu, a když se to nevejde do bufferu (64 KB), resp. ještě není vyprázdněný, tak to spadne. Takže ještě upravit volání write, aby zkontrolovalo kolik dat se předalo k odeslání a postupně to odeslat po částech.

WebSocket funguje!

Už dlouho jsem se do programování takhle nezakousl. Ale po třech "dnech" to snad funguje.

Závěr

hotovo (snad, je třeba to řádně otestovat): odesílání dat na webovou stránku (text, obrázek) a příjem dat z webu (pouze text)

15. května 2024 - Jízda na kužel

Myslel jsem si, že když mám funkční jednotlivé komponenty - komunikace s řídicím mikrokontrolerem, websocket, webkameru, detekci kužele, tak to jen dám dohromady a mám funčního robota. Bohužel to opět tak přímočaré nebylo.

Snažil jsem se veškeré komponenty psát jako samostatná vlákna, aby se vzájemně nezdržovaly (hlavně detekce kužele). Jakmile jsem to všechno dal do jednoho programu, tak během startu websocket serveru to padalo do GP fault. Nakonec jsem to vyřešit tím, že vlákno nevytvářím hned v konstruktoru objektu, ale až po startu vlastního programu. To ještě musím dostudovat, co tam je za problém.

Ale první test jízdy na kužel fungoval na první dobrou, tak jak jsem to od stolu napsal. Jedinou úpravu jsem udělal, snížil jsem zesílení regulátoru řízení (mělo to snahu kmitat). Teď to jezdí dle mých představ.

Jízda na kužel - první testy

Horší bude až to pustím venku, jsem zvědav jak se s tím ta webkamerka popere.

24. července 2024 - Jízda po naprogramované dráze

Konečně jsem se dostal k tomu, že jsem vzal robota ven, abych otestoval jízdu přes waypointy. Pro navigaci se používá odometrie (tedy jen měření ujeté vzdálenosti) a směr z kompasu (AHRS). První test byl trojúhelník, k prvnímu waypointu to dojelo bez problémů, ale pak se robot měl otočit o více než 90° a ztuhnul (doma jsem testoval jen čtvetec a tam byly všechny úhly max. 90°). Tušil jsem, co je za chybu, ale nemohl jsem najít, proč není úhel zatáčení omezen na 45° (max. co dovoluje kinematika). Nakonec nalezena blbá chyba (hodnota se sice omezí, ale přesto se počítá s původní).

Zhodnocení po složitější trase (5 bodů). Vzdálenost ujetá podle odometrie je nad očekávání dobrá (chyba v jednotkách procent odpovídá jízdě po nerovnostech). S kompasem je to trošku horší, po první jízdě jsem tam přidal korekci na odchylku magnetického severu (a chyby montáže IMU), nakonec kompromisní hodnota 7°. Ještě výhledově zkusím překalibrovat kompas, vzal jsem ho tak, jak je z minulého robota. Výsledná ochylka po ujetí celé cca 100 m trasy rychlostí 0,5 m je méně než 2 m, viz. video.

Jízda po trase - 5 waypointů, cca 100 m

Korekci z gps jsem nakonec nevyzkoušel (někde tam mám chybu v přepočtu z gps na xy) a na sluníčku je na to blbě vidět (pozn. už je to opravené). Ale vzhledem k přesnosti jízdy z odometrie a kompasu by tomu ta obyčená gps (kde to lítá +- 10 m) asi moc nepomohla.

A teď to horší, použitá webkamera je venku na sluníčku úplně slepá (přepálený obraz). Po návratu domů a hledání chyby v přepočtu gps se mi dvakrát opakovaně stalo, že přestalo komunikovat STM32 s Raspberry. Pomohlo až kompletní vypnutí. Doufám, že zjistím, co se to děje, do teď s tím nebyl žádný problém.

Článek je převzat z https://robotika.vosrk.cz/

ELROB 2024

2022-12-22T00:00:00Z

https://www.elrob.org/elrob-2024

ELROB 2024 - European Land Robot Trial, 12th European Land Robot Trial, 9th Military ELROB24 - 28 June 2024, Trier, Germany

This is the first official announcement for the twelfth European Land Robot Trial 2024! The military ELROB, which takes place for the ninth time now, enables you to get a glance at the latest R&D in the area of unmanned outdoor/off-road ground systems. The scenarios have been developed in closest co-operation with the military users and reflect the up-to-date requirements of the forces. This event offers the fantastic opportunity to mingle with the international experts from the user community, the industry and the R&D sector. ELROB is a strictly non-profit activity! The event is organized and carried out only by non-profit organisations. All participation fees are completely redistributed among the participants to cover travel expenses.

jirka says: https://www.elrob.org/files/elrob2022/ELROB2022_Scenario_Mule.pdf

Google translate říká:

ELROB 2024 – European Land Robot Trial, 12. European Land Robot Trial, 9. Military ELROB24 – 28. června 2024, Trier, Německo Toto je první oficiální oznámení pro dvanáctý European Land Robot Trial 2024! Vojenský ELROB, který se koná již podeváté, vám umožní nahlédnout do nejnovějšího výzkumu a vývoje v oblasti bezpilotních venkovních/terénních pozemních systémů. Scénáře byly vypracovány v nejužší spolupráci s vojenskými uživateli a odrážejí aktuální požadavky sil. Tato událost nabízí fantastickou příležitost setkat se s mezinárodními odborníky z komunity uživatelů, průmyslu a sektoru výzkumu a vývoje. ELROB je přísně nezisková aktivita! Akci organizují a provádějí pouze neziskové organizace. Veškeré účastnické poplatky jsou zcela přerozděleny mezi účastníky na pokrytí cestovních nákladů.

Content

Blog

Automatic translation by Google translate

December 22, 2022 - What's it all about? (550 days left) [MD]

Jirka convinced me at yesterday's regular "call" that it would make sense to participate in the "competition" ELROB. I was last there in 2006 as a “journalist”, but already then I was struck by the difference between the American and European versions of the “competition”: while the American DARPA will offer you a million dollars or more to win, in the European you will (hopefully) receive a diploma and still pay a registration fee of 500 EUR … but maybe it's not like that anymore — we'll check in time.

So why even bother with it? ELROB offers many comparison categories, from which Jirkov liked mula. In short, the robot first follows you to the target position and then you switch it to "autonomous mode". The robot itself returns to the start along the same route and then commutes start-goal-start-goal-… and when it becomes too boring, so the organizers will add an obstacle for you.

A similar task can also be used in practice and it doesn't matter if the robot carries a brick (md) or rolls (zw). You simply create such a temporary "transport channel".

If we were to leave today, Jirka has Freyja, Jakub K2 and K3 hats, “in stock” and actually all Robotour robots could probably be used. Well, it's such a milestone, or yet distant deadline, so we'll see…

October 5, 2023 - Time to Begin (263 days left) [JI]

Freyja 2.0 is complete except for minor details. PatAMat floats. It's time to write software and drive!

Freyja has a bit of a head start on this because I started writing the software back in the winter when we started talking about the competition. I tested it on Deedee, which is a smaller home robot that I already used as a "technology demonstrator" at SubT. Deedee followed me around the apartment and then back to the start, going back and forth already in the spring. In the meantime, I finished rebuilding Freyja and started "porting" the software. This week Freyja went there and back for the first time. On 34 meters next to the house, she drove 830 meters in 25 minutes. There, back, there, back, there … simply a thrilling experience.

What did I learn from these experiments?

The RealSense tracking camera that Deedee uses at home is a powerful weapon. The robot always knows where it is. Freyja does not have such certainty with such precision outside. It is necessary to continue working on the localization and fusion of data from different sensors. Relative localization to the sample path may be sufficient.
"Follow human" and "avoid obstacles" are mutually exclusive tasks. Man is also an obstacle! I don't see a solution here yet. I tried deleting the tracked person from the local map, but on the one hand, the detection of the leading person is not reliable and accurate enough for this at the moment, and on the other hand, the robot will willingly hack into me. Which I don't like very much. A related problem is when he wipes not only me off the map, but also the wall next to me, and crashes into it.
When the robot detects obstacles (so far) only with the lidar and the data from the lidar stops, it is bad. Who would have said?

Freyja hits the wall

October 18, 2023 - Achilles' Heel (250 days left) [JI]

The robot is driven for as long as the wheel breaks off. Whoever wants to beat a dog can always find a stick. With these and other words, Mr. Jiří does not announce the arrival of Aunt Kateřina, but a broken robot. You've already heard some "I told you so" too.

What's going on? Freyja is a robotic construct of the "Good Programmer" type. And sometimes you can tell. Mechanical attachment at the point of transmission of power from the engine to the wheels is a challenge. On K2, cousins (or cousins?) to SubT, hold the wheels in turned iron blocks. Robík (or was it his follower?) has an iron block bored and carefully cut in the same place, with a very similar result. Freyje holding the wheels 3D printing. I can totally hear it, "What the heck?" In his defense: "I know." Someday I'll have to learn how to say "I need to turn such and such a bazmek" in the local dialect, Züritüütsch.

To be honest, after this year's stress tests where I let Freyja jump over logs, I was expecting it to hold up. It wasn't like that. When attempting a skid turn almost on the spot - another "I told you so!" - it snapped, the wheel gave way and the cable snapped. "Fortunately" always - well, even the previous experience would be - first they loosen the thin cable to the hall sensors, ODrive gets scared and stops.

The team of experts called to the site of the robot accident, ie me, then concluded that the design team, ie me, could have done a better job. The printed part is made of carbon reinforced PLA, which helps, but I left the infill low and the part was more empty than not. In addition, for version 2.0 there was a screw hole left over from version 1.0, which is no longer needed. It burst along her side.

I still don't master Züritüütsch, so Freyja received a hard copy of version 2.1. Without the extra screw hole, with a larger infill and with a piece of aluminum attached where it gave way. For sure on all four wheels. So Freyja drives again. Hopefully it will last longer now.

December 3, 2023 - Not like this? (203 days left) [JI]

Maybe it won't look like this at ELROB in June:

Freyja in the snow

Or yes?

Water in the air … it can rain.
Snow on the ground … not, but mud can pack up quite similarly.
Visually poor environment … sandy area, concrete area, mowed area, undefined path, it will probably be all.

So what did Freyja and I learn?

Snow in the air does not matter for lidar obstacle detection.
The mess on the bikes is okay to some extent, but it can be worse with mud.
Once Freyja sits on her stomach, nothing can save her.
The robot remained dry.
Bacha on the joystick falling when carrying the robot into a snowdrift. The search is bad.

January 5, 2024 - Non-Invertible Behavior (171 days left) [JI]

Q: How do I send Freyje a control signal to turn at 70 degrees per second? Answer: Freyja and turn? Are you serious?

Turning a skid-controlled robot in a controlled manner is not easy. Freyja is no exception. In 2005, we published an article on this topic at a conference about the control of the tracked robot Ester using neural networks.

The idea was pretty straightforward:

We will "randomly" ride the joystick for a while.
From the log we collect data <management, behavior>. Or "if I do X, Y will happen".
I will switch the data to <behaviour, management>. Or "in order for Y to happen, I have to do X".
I train a neural network modeling behavior -> management.
Done. When I need to turn, I ask the neural network what control signal to send.

But it's not that simple!

Let's simulate this on a simplified but realistic enough problem. Let our system be linear with inaccuracies / with noise.

First, we generate sample data:

import numpy

N = 1000000
numpy.random.seed(42)
control = numpy.random.normal(scale=6, size=(N,))
behavior = 0.1 * control + numpy.random.normal(scale=2, size=control.shape)

I.e. to the control signal ("control") our simulated robot turns ("behavior") at a speed corresponding to one tenth of the control signal. We can easily imagine that the turn is in radians per second. It happens to be, perhaps to scale, a reasonable simplified model of Freyja's turning. Freja's turning also depends on the surface, current forward and rotation speed, and a few other things. Our simplified model does not explicitly include these. They fall under noise / imprecision.

Now let's "learn" the inverse model (control_model). We have a linear system, a linear model should do. To be sure, we will also make a forward behavior model (behavior_model).

import scipy

behavior_model = scipy.stats.linregress(control, behavior)
control_model = scipy.stats.linregress(behavior, control)

print(behavior_model)
> LinregressResult(slope=0.100300724814567, intercept=-0.00048361981064025785,
 rvalue=0.28784673170627245, pvalue=0.0, stderr=0.0003337044737230931,
 intercept_stderr=0.0020026058962632327)

It looks good. The behavior model understood that the yaw rate is a tenth of the control signal and the curve passes through zero.

Who bets control_model.slope == 10, i.e. the "opposite" of the forward behavior model? I! The idea is simple: If behavior = 0.1 * control, then control = 10 * behavior, right?

print(control_model)
> LinregressResult(slope=0.8260732024336218, intercept=-0.008403739321622323,
 rvalue=0.28784673170627245, pvalue=0.0, stderr=0.00274837817757052,
 intercept_stderr=0.005747146531042411)

Huh? So according to the forward behavior model if I send a control signal of 10.0 the robot will turn 1 rad/s, but according to the behavior model for the robot to turn 1 rad/s I have to send a control signal of 0.8? But the robot will turn only 0.08 rad/s, i.e. almost not at all! What's going on?

First, it's not a lack of training data. We simulated a lot of them, and according to control_model.stderr, scipy is confident in its output.

Second, it's not that we "drive the joystick badly". The data is simulated, beautifully normally distributed. But it's getting hot here. The distribution of the data matters. And it also depends on what one of those linear models minimizes.

import matplotlib.pyplot as plt

plt.xlabel('Control')
plt.ylabel('Behavior')

plt.plot(control[:500], behavior[:500], 'bo', label='Training data')
plt.plot(control[:1000], control[:1000] * behavior_model.slope + behavior_model.intercept,
 'ro', label='Behavior model: control -> behavior')
plt.plot(behavior[:1000] * control_model.slope + control_model.intercept, behavior[:1000],
 'yo', label='Management model: behavior -> control')
plt.legend()
plt.show()

First, the sample data is denser around the zero control signal. On a real robot, this would correspond to the robot driving mostly straight.

Second, the behavior model minimizes the square of the difference between expected and observed behavior. The control model minimizes the square of the difference between the expected control and the actual control. The first of those two differences is measured in the Y-axis, the second in the X-axis! Note that the average value of the control signal that caused a rotation of 1 rad/s is indeed very close to zero. The two linear models have different tasks and there is not the slightest reason for the control model to be the inverse of the behavior model.

The two points together mean that the data is pulling the control model towards zero.

And indeed, if you "play" with the distribution of the sample data - those two numpy.random.normal calls - you can get quite a wide range of values in control_model.slope.

Even evenly distributing the control signal from a limited interval instead of a normal distribution won't do it.

On a real robot, even the inaccuracy in behavior is not symmetrically normally distributed. It is more likely that the robot will fail to turn than that it will unexpectedly begin to spin violently. This also drags the behavior model to zero. But to zero on a different axis than where the control model is drawn. The scissors will open even more.

If you're more confused now than you were at the beginning, that's okay. At least in your own experiments with machine learning, or even with simpler approximations, you will be more cautious than we are about the effect of the distribution of the data and the effect of the error function on the result.

And if this is all clear to you, congratulations. You are eighteen years faster than me. Honestly, I have a nagging feeling that I'm not getting all the implications yet.

So what about that? Maybe I'll leave that for another time. Unless the margin of this page is too small.

Comments (1)

1/6/24, 12:44 Hi Jirko and Martin, I would like to make a few comments on Non-Invertible Behavior. I apologize in advance. Neural networks don't tell me much, but common sense (and a bit of control theory I remember from school) they tell me that the road does not lead here. What you are trying to do here is the so-called forward control, i.e. if I have a model of behavior robot, so by inversion I find the required action to obtain the desired result. This works, but under the crucial assumption that the system is not influenced by others significant influences (what you call noise/disruption) - the system is predictable. Even this problem can be compensated if I am able to somehow "measure" the malfunction (which in this case in this case it probably won't work - e.g. to determine the current slippage). It is used for example in the case of the so-called equiterms of regulation. I measure the temperature outside (fault/noise) and based on the model behavior in response to a fault I control the heating to achieve the desired temperature inside. This works if the conditions resemble the state in which the model was built (if it is e.g. -10 degrees and the sun is shining, it will no longer work so nicely, but it doesn't matter much here, because the house has a huge inertia). The use of a neuron to control rotation feels like I want to drive heating according to the image from the webcam, which I will stick out of the window (= I will announce according to picture the outside temperature and based on that, I will heat). So in my opinion the only chance is to use the proven feedback control which manages based on measurements of the current state. I.e. I'm still measuring the current speed of rotation (gyroscope) and I compare it with the request, I process the difference "some" regulator. This is guaranteed to work though adjusting it of the controller will not be completely trivial, because malfunctions or their rate of change they are huge here. Martin P.S. I am quite tempted to try it.

January 9, 2024 - On, off, on, off … (167 days left) [JI]

Something to lighten up today.

Elrob rules require every robot to be equipped with an orange beacon. Available orange beacons are either for construction or for trucks. They hardly fit on a small robot.

But such hipster super-luminous bicycle flashers sure do!

Freyja with lights

March 11, 2024 - Half Hour (105 days left) [JI]

Robotics is an activity for the patient. Or for fools. When a robot snaps somewhere after fifteen years of work, it makes me sad.

But now I was lucky enough to make an interesting observation. I needed to clean up the logs and free up disk space. So I looked at which ELROB logs I wanted to keep and which I didn't. At the end of July, the robot did not start. At the end of August, he took off, but on the wrong side. Yesterday he rode for 29.5 minutes and covered 1720 meters. And then he parked under the van, well. That's progress, right?

29.5 minutes is close enough to the half-hour limit in Elrob for me to feel some satisfaction. The excuse for the van is that there is probably a solution. Such a van bothers the robot with the height of its chassis. Freyja can see below with the lidar and the only visible obstacle is the wheels, somewhere far away. The good news is that there are also four stereo cameras on the Freyje. One of them detected an obstacle. I am "just" ignoring the detection from the cameras for now, because I am not yet satisfied with the small side cameras. They give rise to frequent false alarms. I should probably start using the front and rear camera to protect the vans in the vicinity. Those are OK. They and the side ones after recalibration and with more conservative settings start to look better.

So what moved Freyja to a brighter tomorrow? I got advice from MartinL. PavelS confirmed that he does something similar. I added one feedback loop for yaw control. In the original solution, the high-level control consumed the compass and gyroscope to produce the required forward and rotational speeds. I transformed these into the required wheel speed on the left and right side, which, according to a simple mathematical model (inversion to odometry), should lead to the desired effect. The left and right motor controllers then, with the help of PI control, made sure the wheels turned at the correct speeds. Unfortunately, this leads to the correct speed and several times underestimated turning.

The new solution cancels that model and the decomposition into left and right speed. Adds mid-level PID control with feedback from gyroscope and encoders, or hello If the robot doesn't turn fast enough, it will take longer. The low level of speed control of individual wheels remains. And it is done. The robot is now much more agile.

I just didn't let MartinL convince me that I needed a microcontroller for this. The real-time priority of processes on the PC and communication via USB lead to the fact that even from the PC I can manage the new loop sufficiently regularly at 100 Hz without the computer suffocating. It's enough for me.

This solves one of the two motivations - the public one - for the recent lengthy discussion on the subject of forward and backward modeling. The second motivation will be a separate conference paper, so I will leave it for another time.

A more nimble robot has discovered a flaw in a new experimental obstacle avoidance. Somehow I can't remember why I didn't use an older, working solution. I guess I had a smart idea :-/ I have to have fun with something Anyway, I fixed the mistake and that helped a lot too.

Oh, and in high-level trajectory planning, the shoe was like a gate too. There was a reason for that, when I said before Christmas 2022 that a year and a half until ELROB 2024 would be just enough with scratched ears.

And what else? The second reason for Freyja's trip under the van was that she got lost after that half hour. To my surprise, she knew her position correctly, but she was disoriented by sixty degrees, so she was headed in the wrong direction. I understand that the two on-board GPS compasses don't always have enough signal, but the CMPS14 combined magnetometer and gyro (BNO080) shouldn't get lost like that, right? Except he does. Not just me. Greetings PavlaJ! I read on the net that it is very sensitive to its location. So I'm moving it today. Compass. Not Paul.

April 3, 2024 - Halí, belí (81 days left) [JI]

So I replaced it. Compass. Not Paul.

UM7, another attempt at "I'll just buy an off-the-shelf solution" went wrong. The sensor holds tilts (roll, pitch) well, but it drifts outrageously in rotation along the vertical axis (yaw). In two days of working with it, I couldn't figure out if it shows the turn from the north, from the starting position, from the east, or from where actually. The advice on the forums is: "Install the older firmware." That's easy to say, but harder to do. Both the "current" manufacturer and the original manufacturer have probably already gone bankrupt. Anyway, their websites are down. When I see that compass, I'm not too surprised.

So the time of total domination (total control) is coming. Or Do it yourself. Like MartinL and PavelS. Since I'm a suspicious creature and there's not much time left for Elrob, I bought the AltIMU-10 v5 - a board with an accelerometer, gyroscope, magnetometer and pressure sensor. The pressure sensor will come later. In SubT he helped a lot with localization stabilization. I added Arduino Nano ESP32 to the AltIMU. This means that the first Arduino also arrives on Freyja. You can make a dash. Not that it was necessary. Some kind of USB-I2C converter can be found in the drawer and, as I have already shown with the CMPS14, 200 Hz communication can be handled via it, and the AHRS (attitude and heading reference system) could easily be calculated on a PC. Maybe one day it will happen. Now I just wanted to play around with the ESP32 for educational reasons. Maybe there will be some Micropython. When there is so little time left

Branch: Arduino Nano ESP32 includes dual-core RISC-V processor at 240 MHz, wifi, bluetooth. It runs FreeRTOS. It's "total overkill" for my purpose. This is what the entire robot should be driving. But what amazed me is that thanks to the Arduino HAL (hardware abstraction layer), all the existing Arduino libraries for working with the accelerometer, gyro, and magnetometer work on it. Some RISC-V, two cores or FreeRTOS don't matter! Unfortunately, there is a lack of support in Arduino-Makefile and Arduino Studio, but I really don't need it. Maybe even in 2000 there was a better development environment. And she didn't freeze. Hell. End of turn.

Back to total domination. With great power comes great responsibility. Have you ever calibrated a magnetometer? "You just take it and turn it in all directions." OK, I can do it. “And you have to do it with the robot too, to decalibrate your own interference. Have you ever twirled a 30-pound object that can't be properly grasped, with fragile antennae sticking out, in all directions, right? Fortunately, these are extreme values for basic calibration. These can be reached by pointing each of the three axes north and south. Not all directions are needed. In our geographical location, the lines of force run downwards between forty and sixty degrees. You also have to take that into account. So take the robot, tilt it and, because of course I can't hit the exact north and the exact slope, swing it. A woman walked by and asked if I wanted to sing a lullaby to Freyja. Nevermind.

That was the calibration on the balcony, which I didn't really trust in the end. Who knows where there is something iron around and where some electricity flows. "You definitely have to go outside!" Until MartinL. So to the yard. And since I don't want to sing, it's time to get creative:

With a suspended robot, it's easier to move!

With the magnetometer calibrated, it's time for software. It is said that Madgwick Filter (pdf) offers an appropriate ratio between the quality of behavior and computational complexity. PavelS uses it. MartinL is happy with the Mahony filter. Madgwickpro Arduino exists, screw it! Did someone say something about great responsibility? But hey! It's acting "somewhat weird". So I reset the gain (beta parameter), the only thing that can be reset. Well, that's not possible. Not in that library. There is a beta "private" parameter. Why?? And while I'm digging into it, why does it initialize to the zero direction and not from the first measurement? This is how the first estimates are completely stupid! Big responsibility, own code fork. Like everyone else. These are exactly the things I didn't want to deal with!

Custom fork, initialization, reset gain, it's still weird. Many. The various copies of the Madgwick filter circulating around the world contain various bugs. E.g. In my [[https://github.com/Ridebeeline/madgwick-investigation/blob/a2b129964542EE4FA4D3787DA608991F25E746C6/MADFILTERS/CPP/MADGWICK_ORIGINALS/MADGWICHARKS_SQRT KAHRS_SQ_FIX.CPP#L108-L109 | missing in two places *2]. In a copy of MartinL, who uses Mahony anyway, too. It's not pretty code to read and neither is the article, but yes, the *2 really belongs there.

Add *2, readjust the magnetometer bias one more time and it starts to make sense. Except that the environment is always working against it. That "yard" is the roof of an underground garage. Reinforced concrete, some electrical lines here and there. Definitely out! Yeah. In one place, the compass points north in the direction where the sun rises. That's probably not right, is it? The new compass on the robot even points south at that point.

Interestingly, the copied filters do not seem to try to ignore the obviously invalid measurements. Oh well, it's my responsibility now. One interesting option is to monitor the strength of the magnetic field. With an external disturbance, there is a chance that it will add to or subtract from the Earth's magnetic field. When an obviously invalid value like this comes in, Madgwick can only hold heading from the gyro for a while.

When I draw a histogram of the magnetic field strength while driving around the house, I see a distinct spike of correct readings, distinct bad too strong and too weak readings, and lots of "sort of in between" readings.

There is no obvious range of correct values. But it can be done with a little hysteresis. When the power exceeds 0.46, it is definitely a biased measurement. And from that moment I don't trust the magnetometer until it drops back below 0.42. Similarly on the low end side. With this method, the IMU ignores the magnetometer while driving back and forth in the same places repeatedly. Among other things, in the place where the compass is completely off. That looks promising. I have yet to test how Madgwick behaves with just the gyro. I hope there are no more errors.

Another method of detecting an invalid measurement is by the direction of the magnetic field. It should point its forty to sixty, or however many, degrees downwards. I can tell the direction down from … the world hold on … I have an IMU! I don't do this yet, and I quietly hope I don't have to.

I'm a bit concerned that these carefully selected cut-off values and expected magnetic field gradients apply here, but not quite at the other end of Germany, where ELROB will be. Perhaps it's close enough that the magnetic field doesn't change that much.

I'm starting to think that there is no such thing as a ready solution because it can't :-/

June 9, 2024 - Freezing (14 days left) [JI]

With two weeks left in the competition, it's time to stop smashing the robot. The last month has been tough. Both humans and robots crumble under pressure. There was also a leak of magic brushes, without which the electronics no longer work. The next two weeks and the competition should not be like this. So! End of hardware redesign. A "hardware freeze" occurs. A "software freeze" also occurs. End of fundamental changes in the program - no new strategies, no new program modules, no new features. From now on "only" repairs and tuning of already existing parts.

What else got into the robot before the slightly shifted deadline?

New lidars for slope detection and corresponding software.
Sending messages via XBee on GPS modules to the base station ("base station") and from there saving the trajectory on the WebDav server of the organizers. This will need to be tested on site as it seems WebDav has different versions and flavors and their server and my client may not understand each other.
Reporting the status of the robot via the on-board http server. Together with the pre-existing startup and shutdown, this means I can start, check and shut down the program from the browser on my mobile phone. Anyone who has ever stood with a laptop in the rain will appreciate it.
Not avoiding tall grass. Who would have thought that not detecting an obstacle could be a difficult thing? In the videos from Elrob from last year, I looked out for tall grass, and finally the organizers also warned us that they deliberately leave waist-high grass there in several places. Freyja is, for this task, a small robot and she hides completely in such grass. In addition, so that the small robots do not have to follow the path ridden by the big robots, the small robots will go first. So the grass won't even be mowed. Freyja is possibly the smallest robot competing as a mule this year. Let's guess who will go first.

Which way is not an obstacle?

June 25, 2024 - ELROB Day 1 and 2 [MD, photo SP]

It goes by very quickly and after a whole day of testing at a military base near Trier (not far from Luxembourg), one is happy to take a shower and go to sleep, and the “report” falters.

To begin with, I am attaching at least a few photos from Standa from the first day:

older autonomous trucks

big toys

Mule competition

THeMIS - other competition

Pat and Freyja

the most valuable here is the shadow!

another monster

Today, Jirka tested in tall grass (crazy), but Freyja gave it until she hummed into some invisible hole. Pat didn't even flinch even though Standa weighed him down. That was clear a long time ago, Pat actually has no backup, both on the SW and HW side. The competition is tomorrow, so we'll see — hold us, or Thumbs up to Jirko/Freyje!

June 26, 2024 - C'est la vie [JI]

Before the competition, I quite publicly announced, following the example of the Japanese space agency, three levels of goals:

Minimum: Drive off the start.
To satisfaction: Lead the robot from the starting point to the destination point.
Excellent: Autonomously then return to the start.

Any further driving to the destination again and possibly back would be a bonus.

We met the minimum goal.

Yesterday's testing, which Martin commented with the word "crazy", was not only about tall grass, but also about a meadow dug up by wild pigs. We heard from the organizers that this is what awaits us at the competition area. Freyja somehow managed to dig herself out of the holes, but she wasn't very good at it. So I was faced with a difficult choice: Do something about it or let it go? The competition surface, which we did not have access to, I expected even worse.

So I shifted the maximum power of the engine. The result was … well, it was a tough choice between going and not going. With the increased power, the controllers hit the current limit every moment during the competition ride, the software reset them, which means a nice twenty seconds of inactivity with ODRive, and the robot drove a bit again.

After jumping for a while, the robot entered a narrow passage where, prepared to pass through the meter-high grass, it did not consider the grass on the sides as an obstacle. Instead of the path, Freyja took it through the grass. She made good progress for a while, but eventually the grass got wrapped around her wheels in such a way that I couldn't get it off, and the regulators gave up completely. At that moment, I was convinced that I was done with the robot. And Martin, that he has an afternoon ride and Pat.

Much to our surprise, Freyja woke up after a full reboot. We knew about Pat that he doesn't quite give off-road. So a second chance for Freyja.

Back to the previous settings of the controllers, a slightly more conservative setting of Follow Me, so that it does not meander so much to the sides when the route is almost straight, and the organizers are already looking for us, saying that we should go an hour earlier against the schedule and that we should be there in four minutes. Quickly turn off everything, replace the batteries with charged ones, quickly move to the start, turn on the robot … and nothing.

Sometime during that switching off and on, one of the two controllers decided that they really had had enough for today and were calling it quits. Finding out exactly what happened will be a job for forensic detectives.

To illustrate the weather, I'll add that my 3D-printed holder for the GPS antenna stand on the base station (PLA) melted within about fifteen minutes of the first lap. The laptop was so hot in preparation for the second ride that you couldn't touch it. If some electronics decided to quit, I'm not surprised.

Now we have to think about what I learned from it, what follows from it and what to do next. We are probably hitting the limits of our abilities, possibilities and motivation somewhere here.

Freyja in the grass

June 29, 2024 - Pat as a Mule [MD]

You look like Death! — were my wife's first words when I finally arrived at the cottage on Friday night. And probably that was/is apt. I was sick from the moment we they arrived at their destination (a village not far from Trier/Trier) until the last rest stop on the way to the house in front of Rozvadov. I don't know if it was some kind of "geofence" — how sick I am still and as a preview age it was/is definitely a warning. So a motivational photo from the Trier church

Death in Trier Church

That's one take on it that I didn't really enjoy.

The second was a bit more fun, meeting and discussing with other teams. Teams from Canada or Finland also flew in, so the Czech Republic (and Switzerland) is just around the corner. The guy next door was good:

SWX-Robotics

… or he was the first person I ever met who actively participated in RobotWars. And he said, as he was also in India, that they have a category of heavy robots there … and now that I'm arguing with perplexity.ai, so it looks like the limit was 60kg, but there doesn't his weight of 115 kg fit again? Maybe other units? Otherwise, he had the robot's wheels shot through to prove that it didn't matter. Just a different world — how did he look at us in a straw hat? (he wore a military uniform throughout the event and occasionally put on a helmet and set off with the robot "hunting" at a leisurely 5 m/s (rough estimate).

Otherwise, it was mainly Jirka who saw it as a "social event", so maybe he will throw in some more impressions in time.

And thirdly, how did Pat the robot see it? Finally a bigger trip, a lot of spectators, a lot of concrete, where you can drive to the max, :) Probably one Polish team liked it the most, that it is prettier than green competition. I did most of the tuning on the spot, so it was quite moving and people like that too. He didn't succeed so much in the task itself — I actually wrote that he needed to load, but the weight of the man was already too much. On the way to the "Scenario Mule" playground, we picked up some broken concrete, and Standa put it together into a beautifully saddled mule. Even positively was also evaluated by several higher nobles. But there was no time for the test itself, because 2 teams canceled the second attempt in the afternoon… they just somehow forgot to tell us. :-( So we were the last ones the team, the judges (typically older people) were “cooking” under the shelter, so the original promise that we could deploy both robots in the given time window fell through. I take it that we were all over them stolen and they enjoyed more when they could teleoperate various "tanks". They just didn't consider super-autonomy that much.

ELROB is

not organized as a competition but as a trial,
a strictly non-profit activity and
strictly R&D oriented. (source elrob.org)

Pat at the start (photo Jirka)

Pat in action (photo by Stand)

Turn-off into tall grass (photo by Stand)

Competition on horseback (photo by Stand)

And that's about all I can sweat out right now. I can still add a link to a video of how the whole ride looked from the robot's point of view: https://youtu.be/7JkO5qXuSZ0 (it's a "raw" recording, so long boring)

p.s. check out Standy's video from the opening section—it's a bit snappier and shorter

If you have any additional information or comments email us.

Infento

2021-12-12T00:00:00Z

Představení stavebnice

www.infento.com

Pro úvod bych zatím použil volný překlad popisu od výrobce: Vzpomínáte na hračky z Lega nebo Merkuru? Nuže, toto je o trošku větší. Infento je první na světě, které vyrábí stavebnice pro rodiny, jenž umožnují konstrukci vozítek pro děti. Potřebujete pouze stavebnice a šestihranný klič k sestavení nekonečného (to bych asi trošku rozporoval) množství typu vozítek, které můžete používat celé dětství...

Původní text: Remember the iconic toys Lego and Meccano? Well, this is bigger than that. Infento is the first in the world to develop a kit for families that lets them build real constructible rides together. You only need one kit and one hex key to create unlimited rides for their whole childhood. From toddler to teenager. From a walker, scooter, tricycle, bicycle, go-kart, skibock to a sledge and more. Infento’s modular parts allow endless possibilities.

Co jsem to vlastně objednal? No naivně si představuji, že je to Legend Kit s nějakýma extra drobnostna (nechci říci blbostma, ale nějak se mi to slovo vnucuje) — svítící kola a lyžiny zdarma, no neberte to.

Vozítka

Krabice

Obsah

Blog

12. prosinec 2021 — Balíček dorazil

Balíček z Amsterdamu dorazil v pátek 10. prosince 2021. Objednával (resp. platil) jsem to v pondělí, takže první část slibu Fast delivery: 2-5 working days opravdu splnili. Doma se to úplně s nadšením nesetkalo (krabice zabírají skoro půlku chodby), ale to se dalo čekat. Na vánoce se to odveze pryč a doma bude klid … možná.

Vánoční nadílka

Co mne zatím „trošku” mate je, že přestože ty tři krabice byly těžké jak prase (kamarádi z ČZU by jistě oponovali, že prase může být daleko těžší) … tak to bylo 55.73 Kg ve třech krabicích a uplně to nesedí k obrázku výše. Nálepky také nesedí a osobní váhu tu nemám, tak to asi holt bude překvapení!

30. prosinec 2021 — První výtvor - Ice Breaker

Včera jsme to už nevydrželi a krabice rozbalili (oficiálně jsme měli počkat až do Silvestra, na kdy se odsunuly společné Vánoce). V těch třech bednách, o celkové váze asi 50kg, je šest „malých” (cca 40x40cm) krabic a čtyři „velké” (cca 40x70cm). Vše je ve svítivé červené, což jsem si z obrázků na webu automaticky spojil s plechem — nevím proč. Jsou normálně papírové.

V legend sadě jsou 4 velká kola (průměr 33cm), které mi připomínají Kloubáka. Ty jsou pořádné, s duší a pláštěm. Pak tam jsou 4 prostřední plastové a 4+2 malé, jako na inline brusle. A ano, děti nejvíce zaujaly LEDkové kola (co jsem je komentoval „taková blbost”) … prostě děti to vidí jinak.

Poměrně rychle jsem propadl malomyslnosti — jak začít?! Možností je opravdu hodně, tak jsme koukali na různé obrázky a vypadalo to, že malá tříkolka by byl dobrý úvod. Ale přes noc napadlo 5cm nového sněhu a tak padla volba na „něco s lyžema”, což byl druhý přídavek k vanočnímu balení. Volba padla na Ice Breaker (PDF, 60 stran).

Ice Breaker PDFko

Vypadá to, že každé konstrukci je ke stažení PDFko — no došlo na varování Jirky, že sestavit cokoliv je na několik hodin a pro úplně malé děti to není. Prostě tak dlouho tu pozornost neudrží. A navíc první stavba znamená i mnoho omylů a nejasností … ale dopadlo to výborně, jsem jen trošku v šoku. Mimochodem na sestavovaní se hodí dost velký volný prostor. Po 21h byl skůtr na světě. Jen venku v mezičase začalo pršet a sníh slezl, takže možná před prvním testem ještě lyže nahradíme za kola.

p.s. asi jedinou výtku, kterou bych zatím měl, je chybějící malý šestihranný klíč na přidělání úchytu na řidítka, ale stejně tak je možné, že jsem ho zatím přehledl.

p.s.2 motivace, že až to dostavíte, tak se na tom projedete, je opravdu silná

Lyže a kolo

Elektrický motor

Pokoj s krabicema

5. únor 2022 — Sněžný test - FAIL

Po dlouhé době konečně nějaký pokus a report. Dnes jsme ověřili, ze na Ice Breaker sníh není dostačující podmínka. Pár pozorování:

konstrukce je pro děti celkem těžká (na nošení určitě)
asi jsem opravdu měl zakapávat šroubky barvou, protože přestože jsem je včera všechny sám dotáhl, tak se řidítka trošku uvolnila (ano, může to být skleróza, že jsem na nějaké šroubky zapomněl … a s „nedosažitelnými” jsem rozhodně nic nedělal)
chce to doplnit úchyt na tahání (psí vodítko OK, ale je třeba, aby přední lyže následovala „tažné zvíře”)

Jinak co jsme výtvor dorvali na kopec, tak po nasednutí se o 10cm probořil skrz vrchní zmrzlou krustu a nikam se mu jet nechtělo. Menšímu dítěti se podařil „drobný kotrmelec” přes řidítka, když předek více zapadl. No bude to chtít nějaký upgrade nebo nejprve nástroj na udusání kopce/bobové dráhy …

5. září 2022 — Elektrická tříkolka

Koukám, jak se ta „věc” jmenovala a icebreaker vypadá po sedmi měsících úplně stejně:

Icebreaker v létě

Není divu, že to na půdě pomalu „překáží” a měl bych si to odvézt pryč … ale příšlo mi to škoda, včera byl krásný slunečný den a tak jsem vytahal všechny ty krabice (ono už to je první energetická překážka, kterou člověk musí překonat) ven na trávu a "hrál si".

Nahradit zadní lyže za kola byla otázka cca jedné minuty — chtěl jsem napsat pár sekund, ale ta minuta to asi byla. Osa je kompatibilní šestihran, takže stačilo povolit dorazy, vyndat lyžiny na ložisku a zandat velká kola, také s ložisky. Až později jsem zjistil, že si nejsou všechna 4 kola rovna — jedno je napevno, míněno pravděpodobně jako pohonné.

Mutant

Co ale s předkem? Nabízely se nášlapy na rychlý test, což nevypadalo úplně špatně, ale funkční to nebylo — kam dát nohy a limit na zatáčení:

Falešný předek

Situaci trošku řešila delší osa umístěná místo přední lyžiny:

Pevný úchyt předních kol

Moc bytelně to ale nevypadalo. Navíc hned začaly vyskakovat body, jako co se bude dít v terénu, v zatáčce, každé kolo by se mělo točit jinou rychlostí (ano, toto byl okamžik, kdy jsem zjistil, že jen jedno kolo je jiné, ale zde se hlavní osa protáčela). Jako popojet se na tom dalo, ale „nic moc”.

Pak šel okolo OndraP a říká, že je to divné a jak to bude fungovat s těma náklonama? Tj. tato varianta měla hodně krátkou dobu života.

Kyvná náprava byla super, ale že by to bylo nějak extra stabilní se opravdu říci nedalo. Navíc jízda po trávě šla ztuha a „chtělo by to motor”. Ale to už jsem nebyl sám a hráli jsme si dva.

Kyvná přední náprava

Ondra předělal předek na jedno kolo, po pravdě chtěl zkusit spíše elektrokoloběžku, a já experimentoval s pohonem. Ve stavebnici jsou 3 ozubené řemeny ruzných délek, ale ani jedna moc nepasovala, tak Ondra ještě celou konstrukci o pár cm prodloužil výměnou zadních dílů.

Elektrická trojkolka

Mno, evidentně jsem přestal pravidelně dokumentovat změny, protože první fotka má „časovou známku” 11:18 a posledni 17:59 … skoro jakoby poslední „refactoring” trval 4 hodiny … hmm, no byl tam ještě oběd, káva, … nějaké testy.

EliEtri

A ještě pár „detailů”:

nejsou tam brzdy
není připojen chránič řemenu
převod je do pomala

To první mne asi trápilo nejméně - ono to celkem brutálně brzdí motorem. Pravda, že jsem měl dnes v noci sen, jak to proletí výlohou, ale to mi spíše připomínalo robota ze SubT, možná v rámci ročního výročí finále.

Kryt mi příšel na první pokusy trošku zbytečný, ale jak Eli měla dlouhé šaty, tak bych tomu skoro dal „vysokou prioritu do další iterace”.

No a převod do pomala jsem primárně dělal kvůli sobě — a ano i po té trávě to táhlo skvěle … ale děti chtějí rychlost, nebezpečí, … no comment … možná bych to řešil s tou brzdou a jestli tam Infento nemá i spojku?? Za mne ať to raději jezdí nudně pomalu.

Tak jo, čas přepnout na jinou „zábavu” — ve zkratce pro dospělé je ta stavebnice fajn. Chce ale hodně prostoru na vybalení a ještě více času … jo a ty děti bude třeba do toho nějak znova zapojit … jednou.

20. ledna 2024 — Inverzní vánoce

Asi jsem zlej strejda — letos (vlastně teď už je to loni) o vánocích jsem dětem stavebnici "zabavil", protože se na ní pomalu na půdě prášilo a já zjistil, že má nová hračka (robot Pat) má na horní straně dvě „kolejnice”, které vypadají úplně stejně jako Infento profily, a že bych nějaké pokusné nadstavby mohl zkusit právě ze stavebnice…

… se čtyřma velkýma krabicema se tu už skoro nehnu a nostalgicky vzpomínám na první pokusy, kdy vše bylo rozbalené na nově dokončeném (tehdy ještě úplně prázdném) podkroví. Skoro mi přišlo, že bude rychlejší hledat na internetu, co všechno za díly mám k dispozici (což není úplně dobré znamení), ale jako malá inventura to jde:

Po pravdě jsem hledal Infento fasteners measurement sheet, kde jsou v poměru 1:1 vyobrazeny všechny dostupné šrouby a spojky. Klasicky jsem to našel ve spodní krabici úplně na dně.

A co jsem postavil? No chtěl jsem začít nějakým uchytem pro lidar a kameru, protože z robota čouhá takový „trn” (něco jako konektor na připojení do Matrixu) a je tedy nutné se dostat výše. V praxi jsem pak ověřil, co kamarádí říkali minulý týden ve škole, ty profily vypadají podobně ale nejsou stejné! Tj. takové kouzelné spojky (profile nut short) s pružinkou do čínského profilu nepasovaly. :-( … dobrá zpráva ale byla, že alespoň šrouby jsou kompatibilní a tak jsem konstrukci namotoval místo dvou šroubů držící původní děrovanou desku.

Držák na senzory

28. ledna 2024 — Multi Angle Joint Set

Vedle snadného uchycení a rychlého polohování pomocí profilů jsem si teď o víkendu celkem užil Multi Angle Joint Set — prostě spojku s nastavitelným úhlem.

Multi angle joint (převzato z webu Infento)

Potřeboal jsem přidělat OAK-D hloubkovou kameru a už při testování na Eduru jsem vyzkoušel, že musí být mírně nakloněna dolů, aby detekovala blízké překážky. Otázka ale je, jak moc ji naklonit? Případně vyzkoušet pár experimentů pro různé úhly? Na tuto úlohu je ta spojka úplně ideální nástoj.

náklon 10 stupňů

náklon 20 stupňů

náklon 30 stupňů

Interface propojení kamery se stavebnicí je „lehce” ostudný, ale požadavky ver0 to splňuje a třeba se toho TomášP chytí a vytiskne k tomu pak nový úchyt … až to vše bude fungovat! Pro teď chápu Jirku, proč preferuje jako materiál dřevo — prostě i my programátoři to nějak uděláme.

držák na kameru

boční pohled

OAK-D kamera na Patovi

Řešení spoje pomocí 3 hlavních dílů umožňuje polohování s krokem 10 stupňů. Říkal jsem si, že kdyby u toho prostředního kolečka posunuli zuby o 5 stupňů, tak by bylo možné, podle výběru středového dílu, dostat kroky 0, 10, 20 nebo 5, 15, 25 … a co myslíte? Ano, viz přehledová stránka spojek a konkrétně díl Knurled Disc I Stripe (Knurled Disc I-stripe can make angles of 5 ° – 15 ° – 25 ° -35 ° – etc.) a Knurled Disc II Stripes (Knurled Disc II-stripes can make angles of 0 ° – 10 ° – 20 ° – 30 ° – etc.). Je tedy dost pravděpodobné, že v těch krabicích někde mám i ten první typ.

13. června 2024 — Bubnovka

Takto to dopadne, když si robotici hrají s dětskou stavebnicí

připojení robota k bubnové sekačce

Nebo video, když to ještě jezdilo na dálkové ovládání:

https://youtu.be/wAUIVAtVBRw

kontaktní formulář

Unitree Lidar L1

2024-05-22T00:00:00Z

Unitree Lidar L1 - The Hardware

Unitree, a producer of quadruped and humanoid robots, now also offers a budget-friendlier lidar.

Unitree Lidar L1 (source: shop.unitree.com)

In their own words: "360° × 90° Omnidirectional ultra-wide angle scanning; Replacing traditional LIDAR sensing solution, achieving the same effect, with less than 1/10 of the price." They offer it for $349 on their shop, which happens to be exactly what Luxonis asks for OAK-D Pro stereo camera.

The argument by Unitree is that for small and slow robots, one does not need a "full" 3D lidar.

Unitree L1 is relatively slow and sparse and its design reminds me a lot of RPLidar. There is a rotating head over a single "normal" TOF sensor and that's it. Except that L1's head rotates around two axes, unlike RPLidar's one axis.

From all that you can deduce that the capabilities of this sensor are expected to sit somewhere between RPLidar and the "industrial" 3D lidars. And indeed they do: L1 provides 21600 measurements per second, which is not that many, and measures distances between 0.05 and 20 meters, which is fine, at 11 Hz, which is OK. Resp. this is for the PM "precision" model. There is also a 30m "long range" RM version, which costs more. I did not find other differences between their specifications.

Unitree advertisers "non-repetitive static scanning" as a feature. Two consecutive scans from a static lidar will measure different parts of the environment. Well, the rotations around the two axes are simply not synchronized, as far as I can tell, so the lidar measures wherever it happens to point at the moment. Wherever it points is probably estimated from some encoders or from some rotation key(s) and time interpolation. This hardware goes as simple as it gets. Do not expect any nicely aligned lines in the produced data.

There is also an onboard IMU on the device.

It wasn't very clear to me what is in the box, so here we go:

The sensor itself.
53cm dangling UART + Power connector. It is mechanically mounted to the lidar, which I find very unfortunate, because it makes it harder to replace it with a shorter one. Space is a luxurious item on a small robot and cables tend to eat it. There is a 4-pin GH1.25mm JST connector on the dangling end. This one is described in the documentation.
The box contains a USB-to-UART converter based on CP2104. If you want to use your own, keep in mind that you are aiming for 2Mbaud. Not all converters support that. The JST connector plugs into this converter. CP2104 reports a serial number, which means it should be possible to connect multiple such lidars on a single robot and differentiate between them in the operating system.
A 100-240VAC 12V/1A power adapter is supposed to provide energy. It is an American plug. Very useless to me. But the whole thing ends up on a mobile robot anyway, so what is the adapter for?
Which brings us to an important part that is not documented or I missed it: The outer diameter of the power barrel going into the UART converter is 3.5mm. I am unfortunately uncertain about the inner diameter, because I happend to have an unlabeled connector that fits. I can put a 1.1mm nail into the connector, fwiw. On one hand, it fits in without falling out, on the other hand I can slightly wiggle it. 1.3mm inner diameter is not entirely out of question.
There is a 1m USB-A to USB-C cable for connecting the UART converter with the computer.
And there are few small screws for mounting the lidar.

Let's keep the software part and experience with it for later articles.

The Software

Unitree provides an SDK for communication with the lidar on Github. The project provides header files and static libraries. I … don't like binary libraries like this. I really don't. Have I mentioned I don't like binary libraries?

These ones are at least static, so there is less of a chance of some dependency of theirs disappearing after some time. Still, I am pretty confident that two or three years from now I would struggle making it work on some system or hardware. I already have MyntEye stereo cameras that I can use as cute bricks, because the company went bankrupt and their binary SDK stopped working over time. Even if Unitree does not go bankrupt, will they care about supporting this particular lidar three years from now?

The good news is that the SDK works for me (TM) now. Which means I can log communication to and from the lidar, cross-check with the pieces of code that are on Github and write my own communication library. I would not have bought the lidar without being confident I can do this. I was still over-confident and got lucky.

To reiterate before I get into details: The SDK works (for me). You can likely use it without getting as defensive as I am and writing an own library. If you want to make sure before buying the lidar, compile the SDK, create a linux pseudoterminal (pty) - I used `socat` to do the job for me - and let the example code in the SDK write to the pty. You will need to modify the example to not open /dev/ttyUSB0, but the pty. You should see the example writing some data into the pty and then complaining about timing out before receiving data from the lidar. Which is, given you have not bought it and plugged it in yet, a perfectly correct behavior.

The important pieces of information for defensive folks are:

Unilidar L1 uses Mavlink v2 communication protocol without message signatures.
The Github repository contains code for processing input and output messages generated by Mavgen. I could either use this code directly to parse and serialize the messages or there is enough information to understand the message structure and to peek magical parameters such as "extra checksum".
Where I got lucky, or Unitree is friendlier than I am giving them credit, is that the repository also contains code for turning distance data packet and auxiliary data packet into a point cloud with reflexivity. This is non-trivial and I am not sure if I could deduce it from the structure of the two messages. Maybe. If I am optimistic. It would certainly take a lot of time.

With all this information … yes, I can parse the incoming data myself. Distance, reflexivity, IMU. At some point I should also send commands (turning the lidar on and off - it is on by default) and, with lower priority, to control LEDs.

Some of the messages I receive do not pass a checksum test. I may not be parsing data correctly, but I don't think this is the case. There isn't that much room for mistakes. Famous last words. Maybe there are some communication hiccups? Remember the half a meter long dangling serial line cable I mentioned in the previous article?

One more detail you may find interesting or important is that one distance + auxiliary data packet pair contains measurements from one rotation of the "fast" mirror. It is almost as getting 120 measurements from a 180deg field of view 2D lidar. Except that the slower axis of rotation gives it an extra twist, so the 2D scan does not come from a plane, even when the robot is static. And then you get another packet pair with another slice, slightly rotated. And then another one. And another one.

Vertical slice of my office room with L1 on a table, facing up:

L1 scan

Two out of three

I did not mention it before, but I got two L1 lidars, not just one. After I made my software work with the first one, I finally plugged in the second one. I should have done it earlier and try it with the provided software. Because the second one did not work.

Luckily I did it just before the expiration of the "no questions asked" return window of the European re-seller I bought them from. Mind you, I am not in EU and some of the EU customer protections are complicated here or do not apply at all.

I traced the issue to the USB-TTL converter. The sensor itself was OK. It worked with the converter from the first unit. Unitree - the original producer - does not provide spare parts. At least not this one. Despite its simplicity, I did not manage to make my own USB-TTL work with the lidar. I may have just been soldering the teeny-weeny GH JST connector wrong. Or there is more to the converter, such as a some magical wake-up byte exchange. I have not explored deeper. The provided USB-TTL converter is wrapped in a transparent piece of plastic and I could check it neither visually, nor with a multimeter or other measurement tool without breaking that plastic.

Either way, with the return window very quickly closing and the event where I need the robot to work approaching, I have returned the second lidar and bought a third one instead. Poor man's "give me a replacement." The third unit works fine, which gives me two units out of three working.

VanJee Lidar

2023-11-03T00:00:00Z

VanJee Lidar WLR-719C

VanJee Lidar WLR-719C

Obsah

Blog

3. listopadu 2023 — Vánoce v listopadu

Dnes dorazil FedEx balíček. Chvíli jsem u sebe neměl telefón a málem to Santa vzdal … prý že adresa neni v Google maps, tak jako by nebyla. Teď jsem to zkoušel a už chápu … ono to neřekne, že přesnou adresu to nenalezlo, ale ukáže to úplně jinam. No nic, paní řidička byla ochotna se zase vrátit a balíček (cca 20x20x20cm) mi předala. Co je uvnitř? Dva všesměrové lidary WLR-719C.

Na první pohled dost připomínají TiM lidary od německé firmy SICK, ale tady by měly pokrýt všech 360 stupňů a hlavně detekovat překážky/díry ve čtyřech směrech:

základní parametry lidaru

Koukám, že už je to rok, co Jirka posílal takové šílené video …

krabice

obsah krabice

VanJee Lidar

4. listopadu 2023 — První data?

Mno, včera jsem to ani nezapnul. Jako mohl jsem si to nastudovat dříve a trošku se připravit … prostě ten lidar je spíše na 24V a já tady mám tak leda 12V baterku z traktůrku. Ono sice píšou operating voltage is 12-28V DC, ale ještě v té samé větě je nominal operating voltage is 24V DC, nominal operating current is 0.25A, nominal power is 6W. Asi není úplně ideální začínat na hranici povoleného rozmezí, ale … když tu baterku více nabiju, tak bude mít třeba 14V a rozjede se to?

Hmm, tak zas úplně triviální to není. Nastavil jsem pevnou IP adresu, abych si po Ethernetu mohl povídat s 192.168.0.2 (default). Dobrá zpráva je:

(osgar) md@md-ThinkPad-P50:~/git/osgar$ ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=255 time=0.384 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=255 time=0.418 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=255 time=0.408 ms

Také krabička po chvíli od připojení na baterku začala „vrnět”, tj. snad úplně cihla to není.

No není nad „přítele na telefonu”. … Posli '\xFF\xAA\x00\x1E\x00\x00\x00\x00\x00\x00\x01\x01\x19\x0C\x00\x00\x00\x00\x00 \x00\x00\x00\x05\x03\x00\x00\x00\x00\x00\x00\x00\x0D\xEE\xEE' UDP packet na port 6050 a cti, co ti prijde zpatky. O parsovani te ale preci ochudit nemuzu!

(osgar) md@md-ThinkPad-P50:~/git/osgar$ python -m osgar.record -duration 10 
                      config/test-vanjee-lidar.json -note "port 6050, trigger from Jirka, in run()"
2023-11-04 19:29:25,123 root             WARNING  Environment variable OSGAR_LOGS is not set - using working directory
2023-11-04 19:29:25,124 __main__         INFO     /home/md/git/osgar/test-vanjee-lidar-231104_182925.log
2023-11-04 19:29:25,144 __main__         INFO     SIGINT handler installed
2023-11-04 19:29:35,176 __main__         ERROR      vanjee_udp: maximum delay of 0:00:10.031742 at 0:00:10.052223

(osgar) md@md-ThinkPad-P50:~/git/osgar$ python -m osgar.logger /home/md/git/osgar/test-vanjee-lidar-231104_182925.log 
 k           name   bytes | count | freq Hz
--------—
 0            sys  130460 | 1591 | 158.3Hz
 1     vanjee.raw      36 |    1 |   0.1Hz
 2     vanjee.xyz       0 |    0 |   0.0Hz
 3    vanjee.scan       0 |    0 |   0.0Hz
 4 vanjee_udp.raw 2198431 | 1586 | 157.8Hz

Total time 0:00:10.052477

Za mne dobrý! Myslím, že můžu v klidu vypnout počítač (v sobotu mám typicky „odvykačku” ) … co ty pakety obsahují tedy až zítra.

p.s. pokud by někoho zajímaly detaily, tak viz https://github.com/robotika/osgar/compare/feature/vanjee-lidar

první test

5. listopadu 2023 — Parsování dat

Tak jo, venku je tma, tak hurá na bitíky … Upravil jsem původní callback z

def on_raw(self, data):
    pass

def on_raw(self, data):
    assert len(data) == 0, len(data)

a pak pustil přehrávání logu:

(osgar) md@md-ThinkPad-P50:~/git/osgar$ python -m osgar.replay -module vanjee 
                                                test-vanjee-lidar-231104_182925.log
original args: b"['/home/md/git/osgar/osgar/record.py', '-duration', '10', 'config/test-vanjee-lidar.json',
                  '-note', 'port 6050, trigger from Jirka, in run()']"
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/home/md/git/osgar/osgar/drivers/vanjee.py", line 24, in run
    self.update()
  File "/home/md/git/osgar/osgar/node.py", line 36, in update
    handler(data)
  File "/home/md/git/osgar/osgar/drivers/vanjee.py", line 17, in on_raw
    assert len(data) == 0, len(data)
AssertionError: 34
maximum delay: 0:00:00

… což takto malý paket jsem opravdu nečekal. Asi je to odpověď na ten magic packet?

Tak znova replay a změna očekávané hodnoty na 34:

File "/home/md/git/osgar/osgar/drivers/vanjee.py", line 17, in on_raw
    assert len(data) == 34, len(data)
AssertionError: 1384

… to už vypadá spíše jako point cloud data.

OK, tak teď už na

assert len(data) in [34, 1384], len(data)

projde celá 10s nahrávka ze včerejška. The effective length of the WLR-719C data packet is 1380 bytes … hmm, skoro.

File "/home/md/git/osgar/osgar/drivers/vanjee.py", line 20, in on_raw
    assert data[:2] == b'\xFF\xAB', data[:2].hex()
AssertionError: ffaa

tj. na začátku je SoF, Start of frame (to FFAB jsem tam dal úmyslně, aby to selhalo a vypsalo to očekávane FFAA)

length = struct.unpack_from('<H', data, 2)
        assert length == 42, length
…
  File "/home/md/git/osgar/osgar/drivers/vanjee.py", line 22, in on_raw
    assert length == 42, length
AssertionError: (25605,)

hmm, nečekané, tj. obrácený endians?

length = struct.unpack_from('>H', data, 2)
        assert length == 42, length
…
  File "/home/md/git/osgar/osgar/drivers/vanjee.py", line 22, in on_raw
    assert length == 42, length
AssertionError: (1380,)

… lepší, jen jsem zapomněl si vzít 0tý prvek a ta délka tedy snad už odpovídá tomu the effective length.

frame = struct.unpack_from('>H', data, 4)[0]

… to už pěkně jede od 1 dále.

assert data[6:10] == bytes.fromhex('00000000'), data[6:10].hex()
…
  File "/home/md/git/osgar/osgar/drivers/vanjee.py", line 24, in on_raw
    assert data[6:10] == bytes.fromhex('00000000'), data[6:10].hex()
AssertionError: 000007f9

… tak to už očekávané není. Vycházím z PDFka stažitelného v download sekci výrobce. A pro případ, že by to zmizelo, tak zde je očekávaný začátek paketu:

úvodní část paketu

… prostě rezervovaná data jsou jiná, což si nemůžeme moc stěžovat … od toho jsou rezervovaná. A mění se:

assert data[6:10] == bytes.fromhex('000007f9'), data[6:10].hex()
AssertionError: 000007fa

Další bajty …

assert data[11:14] == bytes.fromhex('02 000C'), data[11:14].hex()
AssertionError: 02190c

… jako s assertama na real-time robotovi je „trošku” problém, ale zatím mi to přijde jako nejrychlejší způsob porovnání co říká dokumentace a co leze ze zařízení. Tj. asi nějaký nový device type?

bank, motor_speed = struct.unpack_from('>BH', data, 18)
assert 1 <= bank <= 16, bank
assert 38000 <= motor_speed <= 39300, motor_speed

… banky, jak slibovali (ne že bych tušil co že to je) a rychlosti motoru jsou proměnné — časem asi budu muset zvednout, resp. assert zrušit.

Ještě tam nejsme, ale blíží se to …

druhá část paketu

Už to taková zábava není … asi chápu Jirku, že preferuje, když dokumentace je generovaná stejně tak s parsery pro všechny možné programovací jazyky. No nic, ověřil jsem ještě EEEE na konci a teď je na čase se zakousnout do té největší časti (jj, checksum by to asi také chělo ověřit). NTP bych si nechal někdy na jindy.

1350 bajtů co má nést informaci o 450 bodech = 3 bajty na bod. 10 circles/second; 7200 points/circle; Scanning data -10°, -5°, 0°, 0.3° in sequence; 24 bytes per point, 1-byte reserved + 7-byte intensity + 16-byte distance. … to zní opravdu drsně. Tak alespoň sedí, že 450 bodů krát 16 bank je těch 7200 bodu na otočku.

... every 3 bytes corresponds to a single point cloud information. It outputs point cloud data at -10°, -5°, 0° and 0.3° in cycle, where the lower 7 bits of the first byte represent the intensity value, and the last two bytes represent the distance … aha, tak oni si také pletou bity a bajty, fajn. Tj. nikoliv 24 bajtů, ale pouze 24 bitu = 3 bajty a rezervovaný je jen jeden bit u intenzity.

points = struct.unpack_from('>' + 'BH' * 450, data, 21)
assert 0, points[:20]
…
  File "/home/md/git/osgar/osgar/drivers/vanjee.py", line 35, in on_raw
    assert 0, points[:20]
AssertionError: (4, 808, 16, 980, 10, 0, 4, 111, 0, 0, 17, 976, 0, 0, 16, 0, 0, 0, 17, 971)

… jako není to obrázek v lidarview, co jsem měl původně v plánu, ale timeout 2 hodiny právě nastal a asi bych si dal večeři a pokračování zítra (??? … ono je to pracovní den a večer je DARPA DTC kick-off, takže tomu dávám jen 30%).

6. listopadu 2023 — Lidarview

Dnes jenom rychlovka. Ty banky 1 až 16 vypadají jako pouze rozdělení velkého scanu na bloky, tj. je třeba je slepit dohromady a pak pracovat s celým scanem. Trošku mne zmátlo, že to „řežou v půlce” — ty body jdou za sebou podle jednotlivých vrstev pro -10, -5, 0 a +0.3 stupně. Prostě 450 úplně není dělitelné 4 (vrstvami). Slepené je to OK.

Když teď Jakub nově oprášil OSGAR driver replay, který simuluje v běžícím systému data z původní nahrávky, tak jsem mohl i doplnit vanjee.scan, který na začátku implementován nebyl.

{
  "version": 2,
  "robot": {
    "modules": {
      "vanjee": {
          "driver": "vanjee",
          "in": ["raw"],
          "out": ["raw", "scan"],
          "init": {}
      },
      "vanjee_udp": {
          "driver": "replay",
          "in": ["raw"],
          "out": ["raw"],
          "init": {
              "filename": "/home/md/git/osgar/test-vanjee-lidar-231104_182925.log",
              "pins": {"vanjee_udp.raw":  "raw"}
          }
      }
    },
    "links": [["vanjee_udp.raw", "vanjee.raw"],
              ["vanjee.raw", "vanjee_udp.raw"]
      ]
  }
}

A když jsem restartoval celý počítač, abych si zase mohl pustit lidarview, tak jsem dostal:

Lidarview 360deg scan

p.s. to restartování mne hrozně irituje, ale vždy mi nějakou dobu trvá si vzpomenout, co že je to za problém :-(

(osgar) md@md-ThinkPad-P50:~/git/osgar$ python -m osgar.tools.lidarview
   /home/md/git/osgar/test-replay-vanjee-lidar-231106_100810.log –lidar vanjee.scan
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  91
  Current serial number in output stream:  92

10. březen 2024 — Zapojení a WAGO spojky

Číňan měl pravdu, že jsem s „VanJee blogem” moc nepostoupil. To ale neznamená, že jsem si s lidarem vůbec nehrál! Nějaký čas jsem s ním jezdil na robotu Eduro a zkoušel ICP (viz průvodce scan matching). Pak se ale ukázalo, že pro dostatečné vykrytí prostoru před robotem stejně potřebuji zapojit kameru a tak se pozornost přesunula na OAK-D Pro. Včera jsem lidar konečně přidělal na Pata a dnes se snažil narychlo nasbírat nějaká data venku:

VanJee lidar na Patovi

pohled z boku

WAGO spojky

Už jsem za tu dobu zapomněl, co je ten žlutý kabel, tak pro příště vytrhávám z dokumentace:

kabely

Negative pole of the power supply is black (wire 1)
Positive pole of the power supply is red (wire 2)
Chassis ground is yellow (wire 3)

Toto byla také moje první zkušenost s WAGO spojkami. Ostatní je používají, tak jen varování, že jsou dva druhy — WAGO 2273 - na tuhé dráty (ty nechcete) a dále WAGO 221, které jednoduše zaklapnete. Pokud si chcete dělat elektriku, tak jsem při tom narazil na celkem koukatelné video: Základní práce s Wago svorkami, kontrolní otvory bez rozebrání a tipy (Elektrika pro začátečníky)

A jak vypadají dnešní data? No nijak, protože když jsem zapojil Ethernetový kabel lidaru, tak jsem ztratil wifinu. Ano, je to mým nastavením na počítači, ale dohledávat skript na změnu IP od Jirky nebyl čas. :-( Tak snad příští týden bude už datová sada kompletní.

3. května 2024 — Neviditelný trávník

Možná to prvomájové testování nebylo úplně k ničemu, resp. bych skoro řekl, že každý test něco nového přinese. A ano, bylo to neočekávané a došlo mi to až když jsem koukal na logy a přemýšlel jak na 4-řádkovém lidaru najít 50cm (resp. 54cm i s podstavou) kužely.

Po pravdě mi „chvilku” trvalo, než mi došlo, co je na tom pravém obrázku špatně:

VanJee OK

VanJee NOK

… prostě druhý lidar, co kouká pod úhlem 10 stupňů dolu (hnědé tečky) najednou zmizel a de facto zem (posekaný trávník) neviděl?!

chybějící odrazy pro daný scan (-10deg a -5deg paprsky)

Bude to chtít více prozkoumat … je už neděle a zatím pouze potvrzuji, že to není chybou lidarview (viz graf výše).

kontaktní formulář

Servo WaveShare ST3215

2024-01-02T00:00:00Z

Technický popis

Jedním ze stěženích problémů při stavbě vlastního robota je výběr vhodného pohonu. Je jedno jestli se jedná o robota mobilního, kde využijeme pohony pro vlastní pohyb, nebo o robotické rameno, kde pohony zajišťují pohyb kloubů.
Vždy potřebujeme pohon, který má vhodnou rychlost, požadovanou sílu, možnost řízení rychlosti a polohy a v neposlední řadě i rozumnou cenu.

Parametry serva

Konstrukce serva

velikost standardního serva
napájení 6 – 12,6V
krouticí moment 3 Nm (30kg.cm)
komunikace – sériová linka TTL
magnetický snímač otáčení 360° ! (rozlišení 4096 poloh, tj. < 0,1°)
režim servo polohové / servo rychlostní - motor

Dobré vlastnosti

zpětná vazba pozice, rychlost, teplota, …
kvalitní převodovka (kovová kola, malé vůle)
super cena ~650,- Kč (za to nelze pořídit slušný motor s převodovkou, enkodér, H-můstek a procesor pro řízení)

Horší vlastnosti

není dokumentace – pouze příklady zdrojových kódů //(update: výrobce už má na wiki popis komunikačního protokolu)//
nižší rychlost (oproti standardním servům) //(update: už existuje rychlejší varianta serva ST3215 HS - cca 2,5x rychlejší)//
obousměrná TTL sériová linka

Připojení serva k mikrokontroleru

Pro komunikaci se servy je použita 1-drátová sériová sběrnice v úrovních 3V, umožňující teoreticky připojit 253 serv. Proto jen nutné u mikrokontrolerů, které tento typ sběrnice hardwarově nepodporují doplnit potřebný obvod. Obvykle se pro komunikaci využije uart mikrokontroleru a "spojí se" signály TX a RX.

Servo Driver WaveShare

Pro prvotní hraní jsem použil desku Servo Driver od výrobce serv. Je založena na mikrokontroleru ESP32 a obsahuje budič 1-drátové sběrnice s automatickým přepínámí směru.

Budič s automatický přepínáním směru (originálního zapojení)

Originální zapojení servo driveru

Budič s automatický přepínáním směru

zjednodušená varianta originálního zapojení (bylo by vhodné přidat zpoždění přepnutí směru pro rychlejší přechod linky do H)

Budič s automatickým přepínáním směru

Budiče s „ručním“ přepínáním směru

v tomto zapojení je přepínání směru - vysílání/příjem řízeno zvláštním výstupem mikrokontroleru (používá originál Dynamixel)

Budič s ručním přepínáním směru

Wired AND (drátový AND)

realizace diodou, která zajistí aktivní výstup pouze pro logickou "0", v logické "1" je výstup odpojen a požadovanou úroveň zajišťuje pull-up rezistor

"nevýhoda" - na RXD echo vysílaných dat

Wired AND

pokud využijeme v mikrokontroleru výstup TXD v režimu otevřeného kolektoru, tak můžeme ušetřit diodu

Wired AND open colector

Mechanicky je připojování serv na sběrnici realizováno pomocí konektorů SPOX (molex) 2,5 mm – 3 pin.

Konektor SPOX 3

Konfigurace serva

U digitálních serv lze nastavovat řadu parametrů - režim práce, rychlost, maximální moment, teplotu, … Stejně tak lze mnoho údajů ze serva číst - poloha, aktuální rychlost, krouticí moment, napětí, proud, …

Bohužel výrobce dokumentaci s popisem registrů serva nemá k dispozici (tedy zatím jsem neobjevil). Ale dostal jsem tip, že toto servo vypadá jako klon serv firmy FeeTech. Takže jsem zapátral na jejich stránkách a našel jejich software pro konfiguraci serv (odkaz ve zdrojích). Zkusil jsem se připojit tímto softwarem k servu a opravdu servo komunikovalo. Vypadá to, že i struktura registrů je stejná (všechny parametry, které jsem zatím zkusil nastavit fungovaly). // (update: už existuje i konfigurační software od WaveShare)//

Konfigurační software FeeTech

Pro práci s tímto sw je potřeba připojení sériovou linkou s PC. To lze snadno realizovat jednoduchým prográmkem s využitím výše uvedené desky Servo Driver. Program pouze přeposílá data ze sériové linky z PC (USB) na sériovou linku, která je převáděna na 1-drátovou sběrnice a naopak.

#include <Arduino.h>

#define S_RXD 18
#define S_TXD 19

void setup() {
  Serial.begin(115200);
  Serial1.begin(1000000, SERIAL_8N1, S_RXD, S_TXD);
  delay(1000);
}

void loop() {
  if (Serial.available()) {
    int a = Serial.read();
    Serial1.write(a);
  }
  if (Serial1.available()) {
    int a = Serial1.read();
    Serial.write(a);
  }
}

SW řešení - jak si se servy povídat

Pro použití serv ve vlastních projektech je potřeba softwarová obsluha komunikace po sběrnici (viz. popis komunikačního protokolu) a mapa registrů v paměti serva. Lze využít knihovnu, která je součástí ukázkového demo projektu.

Já osobně používám vlastní knihovnu (originální mi přijde zbytečně složitá), protože využívám jednodušší variantu zapojení 1-drátové sběrnice wired and (a tedy je potřeba řešit echo při vysílání).

Projekty se servy ST3215

Jednoduchý robot s diferenciálním řízením

Kreslicí ruka

Terénní robot Rocker

Použitá literatura a odkazy na internetu

[1] Waveshare Servo ST3215 - stránka výrobce

[2] Waveshare Servo ST3215 - wiki

[3] Waveshare Servo driver

[4] Protokol Dynamixel 1.0

[5] WaveShare Communication Protocol

[6] FeeTech - programming kit

Článek je převzat z https://robotika.vosrk.cz/

Enrich 2023

2023-09-25T00:00:00Z

I totally underestimated how complicated is to operate a robot remotely but after the first round and some additional training I got familiar with the situation. The big problem at the competition is bad WIFI. Although it is provided by the organisator, it is a really bad connection because of the thick concrete walls and the robot also switches between multiple access points. So You can completely forget about using a distributed ROS setup or something similar. I fixed the problem by creating a tmux session, where I could give the robot simple commands like drive 1m on this course and then stop. For camera transmission X-forwarding worked kind of well. The whole mapping was running on the robot and based on rtabmap.

Next year the organizer wants fully autonomous robots.

In the end many other teams had the same problems and it was a great week anyway. I would definitely go there again.

Control room

Display

Hexapod

Lois

3D Map

Power plan

Reactor

Reactor door

ENRICH - The European Robotics Hackathon

Incidents such as Fukushima, Majak or Chernobyl as well as the decommissioning and dismantling of old nuclear facilities (e.g. Sellafield, Asse or Murmansk) have taught us that the use of robotics technology has clear advantages. There are many measurement and sampling tasks too risky for humans to carry out. For these radiological and nuclear (RN) scenarios specialized robot systems have to be developed.

ENRICH takes place every two years at Zwentendorf Nuclear Power Plant in Austria. The organisers are The Austrian Armaments and Defence Technology Agency (ADTA), EVN AG, European Robotics and mainly the Cognitive Mobile Systems Department of the Fraunhofer Institute for Communication, Information Processing and Ergonomics FKIE. The event is not organised as a competition but as a trial. There are some awards for best performance in specific subject areas. The main goal of the event is to give the teams the ability to demonstrate and test their technology in a realistic enviroment. The boiling water reactor of Zwentendof NPP ist perfect for this. This power plant was completed but never put into operation, so there is no high level of radioactivity. Already the exclusive guided tour through the power plant is worth visiting ENRICH

ENRICH 2023 (10.6.23 - 16.6.23)

There were four tasks at ENRICH 2023:

Mapping: Draw a digital 3D map of the power plant and a heat map of artifically placed real radiation sources.
Manipulation: Identify pipes containing radioactive coolant and close the corresponding valves.
Search and Rescue: Move dummy humans to a safe area with Your robot.
UAV: Do the Mapping task with an UAV (in a different area).

I joined 107-Systems as one of the 13 teams going for ENRICH 2023. We participated with a hexapod called L3XZ and my differentially driven robot Lois one might know from different competitions. We decided to go for the mapping and manipulation tasks. For mapping I set up RTAB-Map using an Intel Realsense D435i and a SICK Lidar as source for odometry data. For the manipulation task a portal frame was added on the back of Lois. I 3D-printed a drum shaped tool with a camera in it's middle in order to be able to open and close the valves.

manipulatio task

manipulation tool

There are three runs. As the hexapod had some electrical problems we only participated with Lois. I totally underestimated how complicated it is to operate a robot remotely and crashed the valve manipulation tool by driving backwards into a door during round one. After the first round and some additional training I got familiar with the situation. One problem at the competition is bad WIFI. Although it is provided by the organisator, it is a really bad connection because of the thick concrete walls and the robot also switches between multiple access points. So You can completely forget about using a distributed ROS setup or something similar. I fixed the problem by creating a tmux session, where I could give the robot simple commands like drive 1m on this course and then stop. For camera transmission X-forwarding worked kind of well. The whole mapping was running on the robot itself, so it was not affected by connectivity issues.

crash

Anyway, we had 3 successul rounds where Lois came back from the area to be explored. We could also find some radioactive artifacts and create a 3D map of a small part of the area.

UAV mapping task

Many other teams had the same problems and it was a great week anyway. I would definitely go there again. Next year the organiser wants fully autonomous robots.

Freyja

2019-08-07T00:00:00Z

https://robotika.cz/robots/freyja/

https://sites.google.com/site/cogitoteam/subterranean-challenge

This "Article" is a compilation of Jirka's email reports during the preparation for SubT Challenge Tunnel Circuit.

It is necessary to consider the very limited time frame in which Freyja was created — decision was made after our return from SubT STIX in Idaho Springs / Colorado in April and by the end of June it had to qualify (demonstrate an autonomous ride, show functionality of manual and remote EMERGENCY STOP and demonstrate the passage through a narrow space). The competition itself begins on 15 August 2019.

Freya: as of 27.5.

Freyja was born. Its weight (without batteries) is 25 kg. A little can be shaved off by removing some electronics (pc, stereocamera) and placing it into the backpack (see attachment).

The design is mostly completed. A couple of components such as SICK lidars are missing but they are not required for homologation. The cable is not ready. Batteries are not yet procured.

The good news is that it can withstand weight of a person. The bad news is that combining the selected tires with skid-steering was not thought through. So now I am afraid not just of it ripping apart but also of turns. I almost want to redesign it as an articulated robot kloubak, but in reality there is no risk of that given the time constraints Also, it wouldn't fit into my luggage.

IMG_20190527_211726883.jpg

Zbyněk: Wow. That's pretty impressive! Have you sent the link where you bought its wheels?

https://www.uumotor.com/9-10-13-15-350w-500w-800w-mono-shaft-motor.html respectively. https://www.uumotor.com/ws/p/48v-800w-gearless-brushless-mono-shaft-motor/

PavelS: It is a pity that no one has learned from Robík - I wrote and spoke a lot regarding problems with skid-steering, most of the participants saw it on their own eyes ...

"Nobody learned" is a bit of an extreme statement. I took note of it and made design changes, for example the wheels are rounder in the transverse direction. The frame is designed for excess strength. Hence the fear of tearing. And I regret that due to the luggage contraints the robot can't be wider to have better grip.

On the other hand, despite repeated attempts to find out exactly what the problems are I was only able to find out that "I would not again design a skid-steering robot"," Eduro had no chance because of the caster "and other advice on what NOT to build. Just yesterday: "I wouldn't (yet) duplicate Kloubák". I can combine all this knowledge with my own experience - for example that to design a suspension for a heavy robot is not easy. In such circumstances I have two options: Do nothing, or take a guess and choose a variant that may be functional and that I may be able to manufacture.

After all, I rode with both "mob" and six-wheeler, so I have some experience with skid-steering robots. Which is why my previous designs didn't involve skid-steeing. If I guessed wrong, "do nothing" may still very well be the path I ultimately choose. I'll live with it.

MD: Well, it looks like a flame ... :(

So far, as far as I am concerned, Robík was the only robot that was able to navigate more complex terrain - and that is still true. Further, it's still the "simplest design" - I would stick with that assessment too. Other teams chose this design as well so it is not completely misplaced (CMU, Colorado / Husky, now CRAS). Even after a month, Kloubík does not go forward on a straight line and it is quite possible that it will end up being reconfigured as Robík.

I disagree with PavelS (we've heard it many times, but in practice it used to be better) ... and for the reasons I saw back then I would have chosen it again (see my older emails about proposing to buy it). I will change my mind once someone builds an alternative platform which within 30 days will be able to handle the terrain in the tunnel.

So for the time being I have no problems. Just fears. So it is hard to describe the problem. One concern is that at this point the grip on the smooth floor is such that no skidding will take place. Not at all.

The best way to describe it would probably be by showing a video from the perspective of an outside observer in a situation where a skidding robot is in trouble. Otherwise, as he says, it is quite a vague description.

A somewhat agitated debate where we clarify our views and assumptions is useful. If we were only to scream at each other and repeat the same thing over and over again, then there would be no point.

At the moment I see it pretty much like Martin — it was the only platform which had some achievements and has a non-zero chance of doing it again. And when tanks use this method, it must be possible to make it work. I don't have time for inventions. In the same time I am aware of the risks, and therefore, all my participation is conditioned on making it "run a meter and then turning". If the robot can do this, it will be able to do the other things too. If not, it was fun and I have a lot of new parts for my old robots.

Freyja: Status to 2.6.

The light is on, the wheels are spinning (in the air). I.e. the base cabling is complete. Including the Red button.

Scheduled for the next week: Drive it manually with a joystick. And if I am really lucky, getting the remote stop to work.

MD: When you finally place the robot on the ground (I am sure you've done so already), do you want to just shoot a video with the STOP button - manual and remote (Ctrl + C)? If you file it as unlisted "" or something like "Robotika / Freyja SubT Tunnel Circuit Qualification ", I can forward it directly""

No, I didn't put it on the ground yet. It's too menacing for that But driving it with a joystick while in the air seems to work. It is a bit disappointing that I can't (yet) feed the controllers faster than 20 Hz. The pleasant surprise is that "odrive" (already?) supports watchdog, so when I implement it on my side, the engines should stop maintaining speed after CTRL + C is pressed.

To qualify, do you really just need a red button and ctrl + c or do you need the remote e-stop as well? I assume that joydrive is acceptable for homologation given that some of the teams do nothing else in the tunnel. Do we need to pretend object detection?

MD: no need to pretend to detect an object for sure (we've already done that at STIX and once is enough per team). e-stop is debatable but I will tell them that we use unified SW and if they insist, they can send two samples to Switzerland (I suppose they won't insist after that). What we talked with Zbyňek, the kill switch is probably primarily for drones and "dangerous monsters" and Freyja looks friendly. But the earlier I send them the "homologation videos", the sooner I will be sure that they won't bother us with the E-stop.

Freya - first videos (milestone set) (7/6/2019)

Martin, tell me if the first video suits you.

The second one shows that on four wheel vehicles it will probably be better to measure odometry as a minimum from the encoder on one side instead of the average of all of them. This seems obvious, but it's implemented wrong in the code. PID is not tuned, the electrical current limit is low, so I wouldn't make big conclusions based on the second video.

I even saw it make a turn (milestone reached!) But because of the rubber and weak PID it was either a very uncontrolled slip on that smooth floor, or a really wide turn outdoors on asphalt. I also rode on it for a meter

MD: :) I was just startled by the darkness in the first half of the first video - the lights just go off when you press the STOP button. Hopefully they will understand that the second STOP it is from the keyboard (you may have commented on it, I watched it without sound). I will send it and we will see

Good idea, but did not comment. "Remote stop" is in the caption below the video.

PavelJ: Nice :-) I just don't want to believe it's just 45cm wide. It appears more massive.

46 cm is a more accurate number. But almost half of it is wheels, so that's why it looks a little wild. The body is narrow. 24 cm could be the width mobos without one wheel, right?

With a better PID setting, it looks better: https://youtu.be/ROKj9tp_a94

And now I'm going to reinforce the wheel attachments because they got loose :-/

Maybe this is my "low week". Paradoxically, because the development takes place precisely as expected :-) No miracles are happening.

Freyja: as of 16.6.

Good news: Driving it with joystick works including logging data from cameras and stereo cameras.

Bad news: Mostly.

Source problem: USB is reaching the limit of its capabilities or just crossed them. Each device requests certain transmission speed and each of them asks for the upper bound of what they may need. Given four cameras, two stereo cameras, a joystick and the wifi module it all adds up. The USB then refuses to cooperate. Kayeton cameras simply require the maximum bandwidth available which is the final straw : - /

Current Solution: Custom fork of uvcvideo drivers, which for compressed stream cameras (i.e. kayeton) makes its own estimation of the data transferred, whereas for uncompressed stream (Stereo Mynt Eye) respects the device's override. I also attached the joystick and the wifi in various ways to make sure they are on other USB "bus".

Future Risk: I haven't yet connected IMU and Franta's LoRa module. They also attach via USB: - /

Possible future solutions:

Get rid of the USB wifi and Wifi router instead of the current silly Ethernet switch. Or try to get virtual wifi going on an integrated wifi module.
Maybe we could add RaspberryPI or something like a USB proxy, but I don't really want to. Among other things, because it would not fit.
Reduce FPS cameras from the current 30 Hz to 15 Hz.

Another unfortunate consequence: Looks like the USB controller is warming up so much that even the CPU next to it complains of high temperature. And I haven't started any processing yet.

Interesting tidbit: I log about 3 GB per minute. I.e. The disk drive I use can store only data from two hours of driving and even the largest disk I have laying around does not fit dazzlingly much.

MD: good god! :).

3GB / min - do you have some " - -stat", how much each process uses up? I assume this is without lidar, right? 4 cameras, 2 stereo cameras?

Excellent question. I added a log of statistics to the logviewer. It looks like approx half of the data is the depth map from the front of the stereo camera. So when I include the rear one, I'm screwed. But the good news is that the depth is at the moment meters in floats. When I change it to centimeters or millimeters and protobuf saves it as varint, it should decrease drastically (to about half?). For the price of more demanding serialization / deserialization. The bad news is that the rear stereo camera has almost twice higher framerate. Maybe we need to look for compression algorithms for depth maps.

Four minute log (hm, so it's more than 3GB / min outside):

.configuration: 1.83 KB
                camera_back.jpeg: 1.34 GB
               camera_front.jpeg: 1.57 GB
                camera_left.jpeg: 1.54 GB
               camera_right.jpeg: 1.32 GB
                  freyja.buttons: 163.86 kB
              freyja.pose2d_info: 78.62 kB
          freyja.velocity2d_info: 69.56 KB
            heartbeat.heart_beat: 154.78 KB
                   joydrive.beep: 217.01 KB
         joydrive.velocity2d_cmd: 239.72 KBs
               joystick.joystick: 683.92 KB
             logging.LoggingInfo: 385B
               loginfo2text.text: 313B
           selfcheck.LoggingInfo: 392 B
                stereo_back.jpeg: 1.04 GB
          stereo_front.depth_map: 6.20 GB
               stereo_front.jpeg: 545.89 MB

MD: stereo_front.depth_map: 6.20 GB is it a zipped output? or an unpacked array? (working with Husky or the virtual track I couldn't survive handling the depth map without compression) :( thanks m. ps assume you use your own code for all the logging, right?

Unpacked array. I wouldn't expect much from the zip compression. You found it helpful? If I store integers and subsequent values are stored as a difference from the previous value, then due to the high "flatness" it could produce a very small number of different values and their combination and then the zip compression could work well.

Yes, they are all protocol buffers.

Zbyněk: Yeah, but zipping it isn't a good idea CPU-wise. The only thing worked somewhat reasonably was lz4. Unless you had an unused core that could take care of it.

$ ls -lh / tmp / depth
-rw-r- -r- - 1 Jirka Jirka 6.2G Jun 17 18:57 /tmp/depth.log
-rw-r- -r- - 1 Jirka Jirka 898M Jun 17 19:11 /tmp/depth.log.gz

When gzip -9.

So there would be room for improvement. Regarding cpu, it may be worth considering to log the data uncompressed and then packing it afterwards.

And logging it in centimeters is even smaller.

$ ls -lh /tmp/depth_cm.log
-rw-r- -r- - 1 Jirka Jirka 2.0G Jun 17 20:12 /tmp/depth_cm.log
-rw-r- -r- - 1 Jirka Jirka 522M Jun 17 20:32 /tmp/depth_cm.log.gz

Freyja: as of 24.6.

I was slowed down by a cold. And my daughter keeps throwing up. And on top of all that we have some 60 people at work coming for a visit from all over the world: - /

In theory, I have programmed a drive following the right wall according to the stereocamera. That should be sufficient for homologation.

In practice, it did not drive more than three meters on the balcony, where there is not much space. At home, the stereocamera has problems with a not very textured, highly reflective floor. In is possible, that at the test polygon (ie in the basement) it will be similar.

MD: Do you have a lidar involved? Wouldn't that be easier? OSGAR on Freya is probably still not available, right?

Lidar is not involved and will not be by the end of the week. And yes, it would be easier for the drive along the wall.

SubT Qualification - Robotika Robots Freyja and Kloubak (28/6/2019)

Thanks for sending Martin. We'll go ahead and accept these videos as sufficient for qualifying the two additional platforms. We would still be interested in seeing any other videos, but nothing else is required for bringing your platforms to the Tunnel Circuit and competing with them.

Martin, can you send them a new video?

https://youtu.be/VMXuGFwEE8I

@ "piece of cake": You don't even know how I froze when the next turn would not succeed

Freyja: as of 30.6.

Qualified.

What was the problem:

Sometimes (I suspect high cpu or motherboard temperature) odrive does not start and the log contains "not enough bandwidth" messages. I filmed the homologation videos with the cameras off.
Even though everything runs (including cameras), the drive seems sluggish.
Driving around a corner without a map, when the stereo camera looks just forward and can't see the corner.
The compass sometimes jumps sixty degrees at a time. For now I ignore such jumps but they should not occur.

What worked nice:

Freyja forceful turns no longer loosen the wheel mounts.

What I have planned for the next week:

Not much. My parents are visiting.
If I find some time, I will be either solving some of the known problems or I will look into the suitability of the Jupyter Notebook as an environment for the operator. Running Python on a robot and accessing it from a browser seems like an interesting option.

Freya: as of 7.7.

SICKs are attached and connected. They're producing (somewhat strange) data.
I added a 1.8 TB hard disk formatted as ZFS with compression. An estimated 2.5 - 3.5 TB of log (~ 13 - 19 hours of driving) should fit on it.

Overcome problems:

SSD is so fast that the ZFS driver can't manage the data inflow, crashes and takes the system down with. There were no error messages I could use : - / The solution was to switch ZFS from asynchronous to synchronous mode. I don't know why. Lucky guess.
I can change SICK's IP address even without magic applications.

Unconquered problems:

SICK Sopas and App Studio for Linux do not exist and do not run under Wine. Without the App Studio, I cannot package their Luu properly. I don't plan to worry about this.
The measured distances from both SICKs somehow "pulsate". The whole thing oscillates about ten centimeters back and forth. If you've seen it before, let me know what to do with it.

Remains to be added:

Critical hw: Remote shutdown.
Noncritical hw:
Better side boxes with on / off switches, emergency stop button, cameras and lightbulbs. Cameras and bulbs stick out and suffer from friction when carrying the robot around and on impacts into walls.
Lora. Although I still don't know what we're going to do with it.
Sw: Everything.
Organization: plane tickets, batteries for USA.

Franta: Re LoRa - of course it could be used to some coordinated exploration (swarm, etc.), but even without this, robots should at least broadcast found artifacts and position, speed, orientation, etc. and be on receiving end for stop, turn, return to base, go to x / y coordinates etc.

Sounds nice. And it has a few weak spots:

We don't have artifact detection, and we're just talking about setting up a coordinate system, so there's nothing to report.
The boxes are with you, so no one can integrate them into either Osgar or Erro. So there is no * where to report.
We don't have a Control Station and nobody's programming it. So there is nowhere to report.
The operator doesn't know the robot's status, so * why * would he call it back?
* Who * program this and * when *?

If there is a plan for these things, I want to hear it. I don't know there is. If it is a long-term vision, not a short-term plan for Pittsburgh, that's different. Then I would postpone this whole discussion to after Pittsburgh and resolve it properly.

Freyja can drive through a door (open )

https://youtu.be/ZlWl-0S2OXk

A lot of sensors are not yet integrated, so a big part of that debugging video is black. By the time I start using ima, I should be able to detect stereo obstacles closer to the ground. I also removed the side lamps because they are in the way. I want to redo them. And I will have to shade the front and rear lights to keep them from shining directly to the cameras.

However, I expected that my first big robot to successfully pass through the door will be Clementine. I wasn't able to do it with Eduro if I remember well.

PS: It can probably drive through closed doors too

Freya: as of 14.7.

Add hw:

I redesigned the side camera mounts and the lights so they wouldn't damage so easily.
I have replaced the plastic spacer screws with metal ones, which should prevent cross threading.
I swapped the board under the PC whose corner I broke off in the middle of the call on Wednesday.

I'm starting to put sw together:

Local planner over lidar data (no mapping) works. See video "Passing through the Door" in the week. Stereo cameras are not yet integrated into it.
Global localization: I have a prototype with MRTP rbpf-slam https://www.mrpt.org/. It's basically what Pavel tried but without ROS. Again, just over the lidar data. And (so far) only in 2D. It is quite irritating that even after ten years of attempts I cannot write my own custom SLAM :-(

Catching up on organizational things:

I bought plane tickets.

SLAM

Freyja: as of 21.7. 01.10 The Good, The Bad, The Ugly

The Good:

SLAM is integrated. If the robot feels like it, it's not too far and it's full moon, the robot returns back to start.

The Bad:

I wrote off one SICK. Freyja * can * climb a wall, but can't *stay* there : - /

The Ugly:

For some reason, the relatively trivial processing of lidar data is slowing down and messages are piling up there. When not driving, it can handle almost 10k messages per second, during a drive sometimes data from 15 FPS lidar are piling up. The first suspicion falls on cpu throttling due to overheating. After increasing the speed of the cooling fan it no longer overheats but the problem persists. Another suspect is the Linux task scheduler, but according to "perf sched record" et al. everything is fine and nothing is throttled. According to htop the CPU load is around 20%. The accumulation of messages results in driving based on data that is several seconds old so the robot gets lost and crashes into the wall. If it doesn't climb it. I'm starting to feel hopeless.

So I managed to link the slow processing to high CPU temperature (> = 75 C). The trouble is that it gets warm like this, even if I leave the robot open. So it's not due to insufficient ventilation. Probably need to install liquid nitrogen tanks.

MD: 1) how to read SICK data - do you use sleep to get to 15Hz, or did you force it to "stream"? By default, it is capable of sending you the same data 10 times

Yes, I'm streaming. So unless I don't remember correctly or unless I measured something else, it runs at 15 Hz. I can check … I confirm.

MD: 2) do you plan to temporarily replace TIM with your old (TIM551?)

Yes, my TIM551 is now screwed in and I carefully run after the robot

I needed such an uncle sooner And there were times, not so long ago, when I couldn't write such an email: - /

Context for others: SICK replacement is on its way.

The problem was / is quite complicated. A little like an airplane disaster.

1) The computer is overheating and the CPU responds by slowing down.

2) After slowing down the individual modules, messages begin to accumulate in various places instead of reaching their destination.

3) Watchdog runs on ODrive. If it doesn't receive the control signal for a while, it stops.

4) Such a stop can only be recovered from by reboot of ODrive, which the code attempts.

5) Reboot of ODrive takes about 20 seconds. (It takes a long time to negotiate between the variety and the PC on the current protocol and to set all possible RPCs.)

6) In the case of a reboot after the watchdog stop, I unfortunately managed to trigger a blocking call until ODrive wakes up.

7) During the blocking call, more messages were accumulating.

8) After restarting odrive there would be half a minute worth of buffered control messages.

9) A lot of confused instructions follow because they were calculated based on delayed measurements.

10. Odrive executes and rushes to climb a wall.

11) That 20s wait along with a listing on the console that it had already returned to base, was the reason why I didn't respond fast enough.

PavelS: Hi, just such an idea - heatpipe cooling could be more effective and the radiator could be placed outside the cooled compartment.

I was wondering if anyone would respond to that nonsense (or not?) Thanks.

First, I will try software solutions, such as setting BIOS fan speed to maximum, possibly also disabling Turbo Boost. Intel Pstate, Linux Control of the cpu frequency, demonstrates typical properties of Intel software: It is a piece of crap. I'll try to reset it, or turn it off & replace it. For example when I switch from "performance" to "ondemand", it takes * much * longer to overheat the cpu again. "ondemand" holds it just below 75 ° C much more aggressively without anything freezing. I.e. in the "performance" mode I get worse performance. Ehm.

Zbyněk: Yeah, trying to turn off Turbo Boost also occurred to me. If you figure out how to do it let us know. A while back I was looking for a case that acts as a cooler and the processor is connected by a heatpipe - ie basically what Pavel suggested. At work I used to use such a large CPU cooler to cool the warm side of a peltier and it for sure chilled over 100W.

Freya: as of 28.7. (Own SLAM 5/5)

Resolved problems with overheating: I turned off the BIOS Turbo Boost cpu, turned on fans to 100%, I am significantly subsampling data from kayeton cameras. RBPF SLAM a) thought for a long time, b) got lost. ICP SLAM behaves better, but it also gets lost. Finally, I wrote my own hybrid with the help of Ceres between ICP and GraphSLAM using the ORB SLAM trick (keyframes). It's written taking into account real-time requirements and is customized for the specific task (rotation information is absolute because the compass; "closed loop" is usually a special case, because the robot returns home following its own tracks). It should be easier to integrate detected april tags.

The result is five successful returns of the house in five consecutive trips. Of these five rides, it came back three times with its butt first, twice with its front. Long live symmetrical robots.

Also, in almost two hours of testing, the robot only lightly touched the wall twice. No wild bumps. This is new. This means that for now it is processing data fast enough.

A new SICK has arrived, but I'm still driving with my own old one.

Concerns for the future: i) There is little time and a lot of work to do. ii) I have no representative test environment. iii) SLAM may not work with the same parameters in different environments. iv) I obviously operate close to the thermal / computing / power limits. And I still miss one stereo vision and artifact detection from four cameras. (v) In a narrow space or in a corner, Freyja can get into a situation where it is afraid to go both forward and backward.

MD: :) congratulations :) 5/5 good enough! Another gotcha scenario I can think of - can you incorporate a sloping area / garage ramp? What about the obstacles that do not show on the lidar? There is nothing better than a regular Freyja update --- it always gives me hope :)

Well, I got depressed in the middle of the week. The PC overheated and resisted my attempts, the messages were delayed and it wasn't possible to debug, SLAM didn't work and I knew that to write a functional myself was something I never managed to do.

And you are right, "it's 2D" should be on the list of risks. In addition to the whole inclined surface problem I would also include "the robot drove one wheel on a brick". That's what I meant by "I don't have a representative test space." However, I do have a garage ramp. I could try that.

Freya: as of 4.8.

Freyja got its suitcase (see appendix).
Starting / stopping the program and displaying and playing data in the browser works reasonably well (see next appendix). Control via a browser is not finished yet. Lesson learned: ipywidgets do not support mouse click on image, I didn't manage to make ipyevents work.
The soldered power cord has fallen off of one of the encoders. It is in an unfortunate place making the repair difficult. The repair is completed. I would hate to see something like this happen during the competition.
I'm getting message delays again. The current main candidate is Erro itself in the place where I store logs. If I don't flush after every message, it gets better. If I don't log at all, it gets even better. Not logging to a compressed file system also helps. But I haven't found a solution that works to my complete satisfaction.

Freyja 2.0, spring and summer 2023

Freyja 2.0

Since the last photos four years ago, Freyja grew up. New OAK-D Pro W stereo cameras replaced older cameras from now bankrupt MyntEye. The new cameras have their own RGB sensors, so I removed the original standalone RGB cameras. I also replaced RGB cameras on the sides with OAK-D SR stereo cameras. This way Freyja lost color perception to the sides, but gained depth perception and thus can detect obstacles next to the robot.

Freyja now carries a single four-line lidar from VanJee with a full circle view instead of two single-line SICK lidars with 270 degrees field of view.

I have added two simpleRTK3B GNSS modules with an RTK base station. These modules tell the robot the heading, pitch and roll, because after exploring coal mines in SubT, Freyja will participate in ELROB, where she is going to drive back and forth outdoors in a role of a robotic mule.

I will use UWB BU01 to follow the leading person in the initial stage of the ELROB run.

What's left from version 1.0? ODrive motor controllers, even though with much better settings of current limits. They are much less timid now and do not shut down at every increase of current. I optically isolated their USB connection, because ODrives on other robots in SubT burned because of ground loops.

The robot is still controlled by an Intel NUC. Besides Hall sensors in hub motors, only one original sensor is left. And that is CMPS14, a magnetic compass combined with a gyroscope and an accelerometer.

With new 3d-printed wheel mounts from carbon-reinforced PLA, Freyja is ready for new off-road adventures.

contact form

Paula

2021-02-02T00:00:00Z

Obsah

Blog / Paula

2. únor 2021 — Základní info

Na Tello dronu jsem narazil před pár dny, kdy mi na YouTube vyskočilo 3 hodinové video Drone Programming With Python Course (2021). Jednak mne zaujalo, že je někdo schopen v tomto prostoru vysvětlit základy létání s dronou, programování v Pythonu, OpenCV a pod. + i ta malá drona vypadala zajímavě. Autor videa sice píše, že s DJI a Intel nemá nic společného, ale za mne jim reklamu rozhodně dělá. Mne zviklal, že jsem si dronu objednal a dnes by měla dorazit (možná je to i motivace začít sepisovat poznámky, než budu realitou nemile překvapen). Evidentně se nemohu dočkat/dospat, protože bylo 3:45, když jsem prvně koukl na hodiny.

Co je na té droně tak zajímavého? No připomíná mi to kombinaci staré Parrot ARDrone2 (Heidi) s SDK a možností řízení přes WiFi a o něco novější mini-drony Parrot Rolling Spider (Jessica). Reklama slibuje 13 minut letu, streaming HD videa a snadné ovldádání. Je fakt, že Tello SDK 1.3 (pdf) má pouhých 8 stránek a projdete to za pár minut.

Řízení

Drona se ovládá pomocí UDP paketů, kde na první pohled vidím tři kanály pro tři porty:

8889 — posílání příkazů
8890 — příjem stavů
11111 — příjem videa

Defaultní IP adresa je 192.168.10.1 a předpokládám, že drona má DHCP s nastavitelným zabezpečením.

Příkazy jsou textové, jako takeoff, land, streamon, streamoff, tj. vlet, přistání, zapnutí a vypnutí posílání videa. Dále emergency vypne všechny motory, up 20-500 vzlétne nahoru 20cm až 5m, podobně down, left, right, forward, back … a to už jsme na čtvrté stránce dokumentace SDK. Zbývá otočení ccw 1-3600 (conterclockwise/proti směru hodinových ručiček), tj. až 10 otáček, podobně cw ve směru hodinových ručiček. S flip a go x y z speed už máte všechny jednoduché stavební bloky „pro děti” (ano, těm je tato hračka primárně určena).

Drsněji vypadá curve x1 y1 z1 x2 y2 z2 speed což by měl být oblouk. Rychlost se pak nastavuje pomocí speed 10-100 v cm/s, tj. do 1m/s. No a kdyby někomu nestačily tyto základní příkazy tak ještě existuje rc a b c d, který nastavuje podobně jako u ARDrone2 RC kanály left/right, forward/backward, up/down, yaw, vše s hodnotami -100 až 100.

Čtení stavu

Průběžně se můžete dotazovat na stav jednotlivých parametrů jako: speed?, battery?, height?, temp? (teplota), attitude? (IMU data pitch, roll, yaw), baro? (barometer v metrech?), acceleration? (ve všech osách x, y, z), tof? (time of flight, předpokládám sonar dolu), wifi? (SRN … seriové číslo?). A to je všechno.

Konečně se lze zeptat na Tello State, což by měl být string a jako příklad uvádí:

"pitch:%d;roll:%d;yaw:%d;vgx:%d;vgy%d;vgz:%d;templ:%d;temph:%d;tof:%d;h:%d;bat:%d;baro:%.2f;
  time:%d;agx:%.2f;agy:%.2f;agz:%.2f;\r\n"

… hmm, to vypadá spíše jako print příkaz do Pythonu nebo C … tj. asi se lze zeptat na vše najednou?? To by asi byl i můj případ ale otázka, jak často se člověk může ptát?

Závěr

O videu se v SDK PDFku nic nepraví, tak doufám, že to bude nějaký standardní video stream nebo JPEG obrázky. Stejně tak očekávám ještě nějaký „druhý protokol”, binární, pro interní účely. No možná to byly vyhozené peníze, ale to se člověk nedozví, dokud to nezkusí (ano, nebo dokud nebude více sledovat internet, ale to už mne pomalu přestává bavit). Tak uvidíme — držte mi palce.

p.s. pokud dronu máte a už s ní máte i nějaké zkušenosti, tak napište … díky!

3. únor 2021 — Google Play 2.8

Včera jsem si ještě před vyzvednutím balíčku nainstaloval Google Play aplikaci Tello. Co mne ale „trošku” vyděsilo bylo její hodnocení:

hodnocení Tello aplikace

Možná jsem měl zrovna smůlu, ale vzhledem k tomu, že nejčastější hodnocení byla pouze jedna hvězdička, to bylo asi očekávané.

Tello drones are garbage. Ordered 1 new for my son for christmas and came with a dud battery. Returned and replaced with a 2nd and it worked for 1 day, tho never stable and always floated to the side banging into objects. Then day 2 the back propellers began going haywire, outspinning the front making the piece junk flip over every takeoff. Returned a 2nd time for full refund, no replacements. We're done. Our worst experience ever on Amazon was this garbage. … no hned jsem se těšil více (ironie).

Dronu a extra ochrannou klec jsem si včera večer vyzvedl. Pro referenci jsem kupoval:

RYZE Tello Boost Combo (4 190 Kč)
RYZE Tello ochranná klec (299 Kč)

První, co mne překvapilo, jak je to hrozně malinké. Balíček je jak malá svačinka. Těch by se opravdu bez problému vešlo 10 do komínkui i na Kloubáka K2.

Druhé pozorování bylo, že jsem udělal dobře a koupil combo. V praxi to znamená dvě baterky navíc a malá nabíječka. V opačném případě by totiž člověk chvíli lítal a pak musel dronu použít jako nabíječku a za hodinu by mohl udělat další mini-pokus. Baterky se nabíjí postupně s tím, že u každé svítí, zda je nabitá (zelená), právě se nabíjí (blikající zelená) nebo je ve frontě na nabíjení (žlutá). Předpokládám, že jsou ještě nějaké chybové stavy, ale ty snad hned tak neuvidím.

Baterky jsem nechal nabíjet přes noc, tj. teď mám „tři dávky”, jenom to bude muset počkat (pes, snídaně, práce, Robotour webinář, SubT středeční call …), takže report z prvního pokusu o navázání komunikace až zítra.

p.s. ještě jsem se dozvěděl, že EDU verze podporuje SDK 2.x a swarm dronů, což základní (moje) verze nepodporuje, ale tím se nechám znervózňovat až zítra …

p.s.2 přiložený český manuál říká „revidovaná verze 1.2 z roku 2018”, takže tyto mini-drony žádná novinka nejsou

4. únor 2021 — command "command"

… aby k tomu nedošlo, prozradím vám konec celé detektivky:

první úspěšný pohovor

(Cimrman)

No nechtěla se se mnou mrcha bavit. Stáhl jsem si příklad Tello3.py odkazovaný z SDK a ani to nefungovalo. Aplikace na Android byla také taková „zvláštní”. Obraz z kamery byl rozbitý, ale když jsem si uložil obrázek, tak pak v galerii vypadal OK. Když jsem ale přepnul na nahrávání videa, tak aplikace po chvíli napsala Overheet, shutting down?!

A rozuzlení? No ono je to vlastně v tom SDK v úvodu napsané: Remark2: Send “command” command to Tello via UDP PORT 8889 to initiate Tello’s SDK mode, before sending all other commands, prostě je nejprve třeba poslat příkaz/commnad "command", aby se zapnul SDK mód.

A vlastně mi už funguje i první pokus v OSGARovi:

python -m osgar.logger tello-210203_225017.log
 k           name bytes | count | freq Hz
- - - - - - - - -  - - - - - - - - - - - - - -
 0            sys   916 |   6 |   0.6Hz
 1      tello.cmd     9 |   1 |   0.1Hz
 2    udp_cmd.raw     0 |   0 |   0.0Hz
 3 udp_status.raw 13343 | 101 |   9.9Hz
 4  udp_video.raw     0 |   0 |   0.0Hz

Total time 0:00:10.163582

… tj. po odeslání command už chodí stavové data na 10Hz.

Data pak vypadají takto:

0:00:00.110007 3 b'pitch:0;roll:0;yaw:-2;vgx:0;vgy:0;vgz:0;templ:92;temph:94;tof
:10;h:0;bat:27;baro:358.34;time:0;agx:-2.00;agy:6.00;agz:-999.00;\r\n'
0:00:00.213012 3 b'pitch:0;roll:0;yaw:-2;vgx:0;vgy:0;vgz:0;templ:92;temph:94;tof
:10;h:0;bat:27;baro:358.35;time:0;agx:-3.00;agy:7.00;agz:-998.00;\r\n'
0:00:00.314018 3 b'pitch:0;roll:0;yaw:-2;vgx:0;vgy:0;vgz:0;templ:92;temph:94;tof
:10;h:0;bat:27;baro:358.39;time:0;agx:-4.00;agy:4.00;agz:-1000.00;\r\n'
…

… tj. baterky jsou asi skoro vybité (27%). Na večer experimentování z jedné baterky OK. Tak první krůček snad učiněn.

5. únor 2021 — H.264 video

Včera jsem se kousek posunul i s nahráváním videa, ale bohužel skoro o zanedbatelný kousek:

python -m osgar.logger tello-210204_154413.log
 k           name   bytes | count | freq Hz
- - - - - - - - - - - - - - - - - - - - - - - - -
 0            sys     918 |    6 |   0.6Hz
 1      tello.cmd      30 |    3 |   0.3Hz
 2    udp_cmd.raw      12 |    3 |   0.3Hz
 3 udp_status.raw   13737 |  101 |  10.0Hz
 4  udp_video.raw 2494746 | 1801 | 178.6Hz

Total time 0:00:10.085510

Tj. vidíte tam zhruba 2.5MB video UDP paketů. Přidal jsem i jednoduchou sekvenci:

python -m osgar.logger tello-210204_154413.log –stream tello.cmd
0:00:00.017842 1 b'command'
0:00:02.009850 1 b'streamon'
0:00:05.010625 1 b'streamoff'

tj. v čase 0 zapni SDK protokol mód, v čase 2s spusť nahrávání a v čase 5s ho zase vypni. Datově cca 1MB/s myslím zní celkem rozumně.

Z https://github.com/dji-sdk/Tello-Python/blob/master/doc/readme.pdf cituji:

Listen to the data stream with the port number 11111 through UDP. The data stream is encoded with the format of h264. Because size of encoded data of one frame image in this stream is larger than the maximum load for a single udp transmission, every segment of one frame encoded picture’data are divided into different blocks, with the unit size of 1460bytes. And the last block of a image data is smaller than 1460 bytes.

… toto zní celkem rozumně. Jeden frame může být (typicky je) veliký a tak se rozdělí na několik o velikosti 1460 bajtů

So by detecting the size of the block, it can be determined whether the data block is the end of the data of the current single image. Splicing the last block in sequence with the data blocks previously listened to, you can get the complete encoded data of a single image.

… toto ale už je divočina! Pokud vám přijde kratší paket, tak je to konec frame?! A co výpadky?

python -m osgar.logger tello-210204_154413.log –format "{timestamp} {len(data)}" 
    –stream udp_video.raw | head -n 25
0:00:00.036130 1460
0:00:00.036936 1460
0:00:00.037336 1460
0:00:00.038663 1460
0:00:00.038781 1460
0:00:00.039000 1460
0:00:00.039154 1460
0:00:00.041383 1460
0:00:00.041505 1460
0:00:00.041573 1460
0:00:00.041779 1460
0:00:00.041900 552
0:00:00.070896 1460
0:00:00.071040 1460
0:00:00.071232 1460
0:00:00.071323 1460
0:00:00.073455 1460
0:00:00.073628 1460
0:00:00.073719 1460
0:00:00.073964 1460
0:00:00.075897 1460
0:00:00.076018 1460
0:00:00.076285 1460
0:00:00.076400 729
0:00:00.105331 1460

Takto to vypadá skoro rozumně, časově jsou si ty bloky blízko a pak začíná nový, ale dekódovat to jako H.264 frame se mi zatím nedaří. Parrot u každého paketu měl jeho index a délku, tak možná něco podobného je i zde?? Z nostalgie bych se po letech mohl podívat zase dovnitř, viz starý článek H.264 pro vidění dravce.

6. únor 2021 — Takeoff!

První vzlet je vždycky drama, obzvláště pokud se jedná o start autonomní mise. A ani Paula nezklamala.

Sekvence byla poměrně minimalistická:

self.tasks = [
            [2, b'streamon'],
            [3, b'takeoff'],
            [5, b'land'],
            [8, b'streamoff']
        ]

tj. zapni nahrávání videa, odstartuj a po dvou sekundách zase raději přistaň a následně vypni nahrávání videa. A jak to dopadlo?

první let

Program skončil, ale drona stále visela ve vzduchu (necelý metr nad zemí). Byl jsem rád, že jsem použil ochrannou klec, ale stejně, jak jí sundat dolů?!

Nenapadlo mne nic lepšího, než ten jediný program, co jsem dosud měl, pustit znova:

druhý let

Home, sweet home! Předpokládám, že u vzletu drona neakceptuje další příkazy nebo se něco porouchalo. Mám pocit, že podobné chování měla i Jessica — což bylo extrémně nepříjemné, pokud se na startu vymkla kontrole, prostě neakceptovala ani příkaz přistaň.

python -m osgar.logger tello-210205_190125.log –stream tello.cmd udp_cmd.raw
0:00:00.032778 1 b'command'
0:00:00.046018 2 b'ok'
0:00:02.086795 1 b'streamon'
0:00:02.137147 2 b'ok'
0:00:03.002316 1 b'takeoff'
0:00:05.000937 1 b'land'
0:00:08.001190 1 b'streamoff'
0:00:08.003700 2 b'ok'

… no nevypadá to, že by "takeoff" byl potvrzený!

A v druhém pokusu, začínaje ve vzduchu, na "takeoff" odpověděla "error":

python -m osgar.logger tello-210205_190142.log –stream tello.cmd udp_cmd.raw
0:00:00.032203 1 b'command'
0:00:00.076145 2 b'ok'
0:00:02.065302 1 b'streamon'
0:00:02.115965 2 b'ok'
0:00:03.024324 1 b'takeoff'
0:00:03.036509 2 b'error'
0:00:05.026166 1 b'land'
0:00:08.023093 1 b'streamoff'
0:00:08.034631 2 b'ok'
0:00:09.106121 2 b'ok'

… a to potvrzení přistání vypadá také jako až po jeho skončení. Byla by pěkná nějaká stavová proměnná, nebo holt na ten start musím počkat o něco déle.

7. únor 2021 — Selfie

Další cíl dosažen a vypadá takto:

Paula selfie z tello-210205_190125.log

To řešení je brutální, ale šlo o „prokopnutí cesty” a stačí náznak světla na konci tunelu. Prostě video jsem nahrával už předevčírem, ale nebyl jsem schopen ho dekókovat. Potvrdil jsem si, že je to H264 kodek, dokonce upravený starší kód vylámal počty makrobloků, tj. zjistil jsem, že výsledný obrázek je menší než u ARDrone2 … ano, marketingový klam 720p … jen to není 16:9, ale 4:3, tj. rozlišení je 960x720. Ale pokusy dekódovat I-frame (jestli to nepletu) selhal.

Když už jsem propadl malomyslnosti, tak jsem koukal dále na to 3h video. Říkal jsem si, že on to také musí nějak řešit?! Pro řízení drony používá DJITelloPy a tam je čtení videa řešeno přes cv2.VideoCapture() a jako parametr dostává address_schema = 'udp://@{ip}:{port}'. Prostě pustí pomocné vlákno a to přímo čte UDP pakety a OpenCV to i rovnou dekóduje do numpy obrázků. Pěkné! Ale funguje to? Jako první jsem zkusil jsem take-picture.py

Napůl mne vlastně potěšila záplava hlášek:

(osgar) md@md-ThinkPad-P50:~/git/DJITelloPy/examples$ python take-picture.py 
[INFO] tello.py - 104 - Tello instance was initialized. Host: '192.168.10.1'. Port: '8889'.
[INFO] tello.py - 418 - Send command: 'command'
[INFO] tello.py - 443 - Response command: 'ok'
[INFO] tello.py - 418 - Send command: 'streamon'
[INFO] tello.py - 443 - Response streamon: 'ok'
[h264 @ 0x153f740] non-existing PPS 0 referenced
[h264 @ 0x153f740] non-existing PPS 0 referenced
[h264 @ 0x153f740] decode_slice_header error
[h264 @ 0x153f740] no frame!
[h264 @ 0x153f740] non-existing PPS 0 referenced
[h264 @ 0x153f740] non-existing PPS 0 referenced
[h264 @ 0x153f740] decode_slice_header error
[h264 @ 0x153f740] no frame!
[h264 @ 0x153f740] non-existing PPS 0 referenced
[h264 @ 0x153f740] non-existing PPS 0 referenced
[h264 @ 0x153f740] decode_slice_header error
[h264 @ 0x153f740] no frame!
[h264 @ 0x153f740] non-existing PPS 0 referenced
[h264 @ 0x153f740] non-existing PPS 0 referenced
[h264 @ 0x153f740] decode_slice_header error
[h264 @ 0x153f740] no frame!
[h264 @ 0x153f740] non-existing PPS 0 referenced
…

… ale drona vzlétla, opravdu jeden snímek udělala a přistála. Dveře do „tajemné komnaty” jsou tímto pootevřeny.

V druhém pokusu, kdy jsem zkoušel příklad nahrávání videa, už to bylo divočejší, protože drona se zamotala do věšáku — ochranná klec byla dobrá investice. Ono to trošku vypadá jak míč, tak jsem to zkusil vzít do ruky a po vzoru starých ARDrone2 to otočit vzhůru nohama a motory se zastavily. To se také může někdy hodit.

Problém je tedy množství nevalidních snímků v úvodu nahrávání videa a zatím nevím, jak ty nástroje přesvědčit, aby to ignorovaly. Alternativa byla vytvořit fiktivní Tello dronu, předstírat, že vysílá UDP pakety s daným časováním a výsledek vypadá takto (po spojení obou kousků pomocí ffmpeg -i "concat:video1.avi|video2.avi" -c copy video.avi).

8. únor 2021 — cv2.Stitcher_create

Přemýšlel jsem, co by nejlépe vystihlo dnešní pokusy s dronou (neděle 7/2 … je to takové posunuté) a je to pokus o poskládání panoramatu z videa drony. Nejprve jsem trošku ladil kód, abych droně posílal další příkazy až když předešlé vykoná (hlavně takeoff) a když toto začalo celkem rozumně fungovat, tak jsem chtěl udělat panoramatický snímek, resp. video 360 stupňů dokola. Asi rovnou naznačím co je další cíl — udělat dva panoramatické snímky nad sebou. Drona má totiž senzor na měření vzdálenosti od země a tak bych mohl udělat panoramatické stereo.

Příkaz pro dronu:

command
streamon
takeoff
cw 360
land
streamoff

cw 360 je „otoč se o 360 stupňů po směru hodinových ručiček”. Samozřejmě jsem tam měl překlep, což je ve vzduchu vždy „komické”:

0:00:01.069556 SEND b'streamon'
0:00:01.119955 — b'streamon' b'ok'
0:00:02.004058 SEND b'takeoff'
0:00:03.263466 Battery: 78 -> 77
0:00:07.193178 Battery: 77 -> 76
0:00:08.315170 — b'takeoff' b'ok'
0:00:09.183728 Battery: 76 -> 75
0:00:10.010189 SEND b'cv 360'
0:00:10.050536 — b'cv 360' b'unknown command: cv'

… ale pak to správně přistálo, takže OK.

No a teď to skládání obrázků. Je to na dva řádky (!):

stitcher = cv2.Stitcher_create()
status, result_img = stitcher.stitch(images)

Drsné, nemyslíte? Uplně se mi nechce sdílet panoramatický snímek pracovno-ložnice, ale …

První pokus je jen pár snímků „obrazu” (takové to černé je ochranný kryt drony).

Poskládaný obraz

Druhý pokus skončil Killed (pravděpodobně na nedostatek paměti) a tak místo všech obrázků z 360 stupňové otočky jsem tomu podhodil jenom každý pátý snímek. A dopadlo to takto:

360deg snímek z videa z drony

13. červen 2023 — Tello go, go, go!

Na robotickém víkendu jsme zase po letech vytáhli různé „kostlivce ze skříně”. Sám jich pár mám a nakonec padl los na mini-dronu Tello (to, že jsem ji pojmenoval Paula, jsem už za ty dva roky zapomněl). Nepamatoval jsem si nic, tak mne potešilo, že jsem našel tématicky pojmenovou větev v gitu feature/tello a poslední commit Date: Thu Feb 11 14:08:03 2021 +0100 … to už tak veselé nebylo.

Dobrá zpráva byla, že stačilo jen pustit nahrávání

python -m osgar.record config/tello.json –note "test na zahrade"

a drona vzlétla, cca v metru se otočila o 360 stupňů, pak vystoupala ještě cca 1 metr, znova provedla scan 360 stupňů a přistála. Pohoda. Celý „program” byl schován v seznamu příkazů:

self.tasks = [
             [1, b'streamon'],
             [2, b'takeoff'],
             [10, b'cw 360'],
             [11, b'up 30'],
             [12, b'cw 360'],
             [20, b'land'],
             [22, b'streamoff']
         ]

… a odkazy na dokumentaci jsem si naštěstí napsal do tohoto článku. Koukám do gitu a nebyl to tedy 1m, ale pouze 30cm a ještě připomenu, že streamon pouští kameru, resp. streamování, a streamoff kameru vypíná.

První, co jsem si do kódu doplnil byl seznam existujících příkazů:

class TelloCmd(Enum):
    COMMAND = b'command'  # entry SDK mode
    TAKEOFF = b'takeoff'  # Tello auto takeoff
    LAND = b'land'  # Tello auto land
    STREAMON = b'streamon'  # Set video stream on
    STREAMOFF = b'streamoff'  # Set video stream off
    EMERGENCY = b'emergency'  # Stop all motors immediately
    UP = b'up'  # Tello fly up with distance x cm, x: 20-500
    DOWN = b'down'  # Tello fly down with distance x cm, x: 20-500
    LEFT = b'left'  # Tello fly left with distance x cm, x: 20-500
    RIGHT = b'right'  # Tello fly right with distance x cm, x: 20-500
    FORWARD = b'forward'  # Tello fly forward with distance x cm, x: 20-500
    BACK = b'back'  # Tello fly back with distance x cm, x: 20-500
    CW = b'cw'  # Tello rotate x degree clockwise, x: 1-3600
    CCW = b'ccw'  # Tello rotate x degree counter-clockwise, x: 1-3600
    FLIP = b'flip'  # Tello fly flip x, l (left), r (right), f (forward), b (back)
    GO = b'GO'
    # go x y z speed - Tello fly to x y z in speed (cm/s) (x: 20-500, y: 20-500, z: 20-500, speed: 10-100)
    CURVE = b'curve'
    # curve x1 y1 z1 x2 y2 z2 speed - Tello fly a curve defined by the current and two given coordinates
    # with speed (cm/s) If the arc radius is not within the range of 0.5-10 meters, it responses false
    # x1, x2: 20-500, y1, y2: 20-500, z1, z2: 20-500, speed: 10-60
    # x/y/z can’t be between -20 – 20 at the same time .
    SPEED = b'speed'  # set speed to x cm/s, x: 10-100
    RC = b'rc'
    # rc a b c d - Send RC control via four channels.
    # a: left/right (-100~100), b: forward/backward (-100~100),
    # c: up/down (-100~100), d: yaw (-100~100)

a v rámci experimentování jsem se dostal k testu go:

self.tasks = [
            [1, b'streamon'],
            [2, b'takeoff'],
            [11, b'up 300'],
            [12, b'cw 360'],
            [12, b'go 200 0 300 50'],
            [12, b'go 200 200 300 50'],
            [12, b'go 0 0 300 50'],
            [12, b'go 0 0 100 50'],
            [20, b'land'],
            [22, b'streamoff']
        ]

kontrolní otázka — co si myslíte, že tento kód udělá? No můžu vám řící, co jsem chtěl aby udělal: drona vystoupá do 3m, zatočí se, aby se neřeklo, a pak poletí dopředu 2m, pak vlevo 2m, pak se vrátí, klesne na 1m nad zemí a přistane. No úplně takto se to fakt nechovalo. go je relativní (!!!), takže s každým příkazem si nastoupal další 3 metry. Skončil cca ve 12m a tam se drona zasekla a já už jenom čekal, kdy jí dojdou baterky a spadne. Fouknul ale větřík a dostal jsem tyto výstupy:

…
0:04:58.926733 Battery: 11 -> 10
0:05:00.051663 — b'go 0 0 300 50' b'error Big wind'
0:05:00.051663 SEND b'go 0 0 100 50'
0:05:00.918411 Battery: 10 -> 9
0:05:03.160410 — b'go 0 0 100 50' b'error Auto land'

a pak už byl v seznamu příkaz na přistání, tak šla celkem elegantně k zemi. S tímto zážitkem bych testování skončil, ale OndraL trval na opravě, takže ještě správná verze kódu:

self.tasks = [
            [1, b'streamon'],
            [2, b'takeoff'],
            [11, b'up 300'],
            [12, b'cw 360'],
            [12, b'go 200 0 0 50'],
            [12, b'go 0 200 0 50'],
            [12, b'go -200 -200 0 50'],
            [12, b'go 0 0 100 50'],
            [12, b'go 0 0 -200 50'],
            [20, b'land'],
            [22, b'streamoff']
        ]

Mimochodem v SDK dokumentaci jsou nesmysly (přepsal jsem je i do popisu, ale asi to v nějakém dalším commitu opravím), protože go akceptuje i nulu a záporné hodnoty (všechna čísla jsou v centimetrech, nebo ve stupních + rychlost v cm/s).

Ještě rekonstrukce „z černé OSGARovi skříňky” (logy) ukázala, proč se drona na cca 12m výšky zasekla:

měřená vzdálenost od země

Proste někde okolo 9m nad zemí přestal senzor fungovat a začal vracet 65m, přesněji 6553cm, což modří už vědí, že interně nejspíše počítá v milimetrech a toto je max uint16, tj. 65535.

Čas na googlení "tello max altitude": https://dronies.org/tello-drone/ (April 28, 2022) The altitude limit for the tello drone is 30 meters (100 feet). Upon the drone’s initial release, Ryze had set the altitude limit to only 10 meters, but after a firmware update, a new setting was added. The new feature grants the user to set the altitude limit from 2 up to 30 meters.

Zajímavé, možná bych si měl dronu flashnout?! Asi bude i lepší si o tom něco přečíst … v poslední sekci, jestli se Tello může koupat píšou: Tello lacks GPS and compass, therefore it uses a belly camera facing downwards and a sophisticated algorithm to locate itself and find its course, allowing distance measurement and RTH emergency maneuver into third-party apps, like Tello FPV. Unfortunately, Optical Flow fails when flying above a patterned or moving body like grass or water, and the drone crashes. Despite this, some people had managed to fly over water bodies. The trick is choosing a flight path carefully by finding calm, shallow water or islands, rocks, dams, and every fixed reference (not floating objects) you can find. Any fixed object is enough for the belly camera to recognize its location. … tak už chápu, proč se relativně dobře visela na místě — má tam ještě jednu kameru směrem dolu.

p.s. čtu ten článek od začátku Tello drone is mainly aimed at the younger audience. ha ha ha

p.s.2 vypadá to, že je k dispozici ještě binární protokol, kdyby mne ty ASCII znaky přestaly bavit, viz tello.py hack 30m alt limit … odkazovaný z této diskuse na tellopilots.com.

p.s.3 ještě nějaký „důkazový materiál”

python -m osgar.tools.play_udp_video /home/md/git/osgar/tello-230610_134957.log

drona ve 12m

… ta divná věc v obraze je ochranný kryt/kopule

kontaktní formulář

Pozyx

2021-12-17T00:00:00Z

Creator Kit

pozyx.io

Firma Pozyx nabízí několik sestav pro lokalizaci uvnitř budov. (*) V tomto článku se budeme zabývat sadou Creator Kit, který jsme na experimenty pořídili. Není to úplně levná hračka (cca 1000EUR), ale pokud systém umožní lokalizaci s přesností na 10cm do vzdálenosti 100m od majáčků (anchors), tak se to možná vyplatí. Uvidíme.

A pokud to úplně fungovat nebude, tak tento blog je ideální místo, kde se ventilovat.

(*) Pozyx by měl fungovat i venku, ale v některých zemích platí různá omezení.

Obsah

Blog

17. prosinec 2021 — První test

Včera dorazil balíček z Belgie. Po odtranění DHL expres obalovací krabice z něj vypadlo toto:

Zabalená krabice

A co je uvnitř? K tomu použiji foto přímo od výrobce:

Obsah Creator kit balíčku

Je tam 5 kotev (anchor) majáčků, které jsou typicky umístěny na známých pozicích po budově. Dále najdete 4 vývojové tagy pro mobilní zařízení, které chceme lokalizovat. Zbývají ještě 3 power banky, 5 USB zdrojů (je dobré správně zvolit zemi, pro kterou budou zástrčky), nějaké uchyty na suchý zip a spousta USB kabelů.

A jak dopadl první test? Podle očekávání — selhal. Zapojil jsem anchor přes USB kabel do počítače, ale nic. Žádná zpráva v dmesg, nic nového v lsusb? Nějaké nápady? Ano, asi mne to mělo hned napadnout, že „napájecí kabely” z power banky komunikaci podporovat nebudou. No byl tam ještě jeden super-kabel, který ma na sobě dokonce display. Podle čísel tipuji že je to napájení a proud, který kabelem protéká, ale hlavně to komunikuje:

[1063478.914191] usb 1-6: new full-speed USB device number 8 using xhci_hcd
[1063479.064155] usb 1-6: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[1063479.064161] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1063479.064164] usb 1-6: Product: Pozyx Virtual ComPort in FS Mode
[1063479.064167] usb 1-6: Manufacturer: Pozyx Labs
[1063479.064170] usb 1-6: SerialNumber: 203E359F484E
[1063479.113745] cdc_acm 1-6:1.0: ttyACM0: USB ACM device
[1063479.114345] usbcore: registered new interface driver cdc_acm
[1063479.114349] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Hodí se balíčk pypozyx a fajn je Pozyx-Python-library na GitHubu. Asi nejrychlejší je si repository stáhnout, editovat tutorials/ready_to_range.py (je tam třeba vyplnit vůči kterému ID chcete měřit vzdálenost) a pak už jenom vidíte výpis jako:

1966732 ms, 1034 mm, -79 dBm
1966777 ms, 959 mm, -79 dBm
1966823 ms, 1006 mm, -79 dBm
1966868 ms, 1011 mm, -79 dBm
1966912 ms, 1002 mm, -79 dBm
1966957 ms, 1020 mm, -79 dBm
1967001 ms, 992 mm, -79 dBm
1967045 ms, 978 mm, -79 dBm
1967090 ms, 983 mm, -79 dBm
1967137 ms, 974 mm, -79 dBm
1967183 ms, 988 mm, -79 dBm
1967228 ms, 974 mm, -79 dBm

Asi očekávané chování, že když mezi majáčky cca 1m od sebe dám ruku, tak se detekovaná vzdálenost nepatrně změní. Příště by to chtělo autodetekci, jaké majáčky jsem vůbec zapnul.

19. prosinec 2021 — pozyx.doRanging()

Pypozyx knihovna má „trošku” zvrhlou notaci volání jednotlivých funkcí. Asi je to inspirováno Arduinem, ale … prostě místo aby funkce vrátila daný výsledek, tak je třeba jí předat třídu (resp. strukturu?), kam se výsledky uloží a funkce pouze vrací kód pro úspěch nebo selhání.

Jako další plán jsem chtěl zkusit remote ranging, tj. mám-li zařízení A, B a C, kde v počítači mám zapojený přes USB (jo, tentokrát již spravným kabelem) zařízení A, tak se chci dozvědět vzdálenost mezi B a C. A opravdu to je přímočaré, prostě zavoláte pozyx.doRanging(B, C) a je to. Ono totiž všechna zařízení spolu komunikují a tak si to nasdílí. Celkový kód vypadá takto:

import pypozyx

serial_port = '/dev/ttyACM0'
pozyx = pypozyx.PozyxSerial(serial_port)

remote_id = 0x0D53
destination_id = 0x0D67

device_range = pypozyx.DeviceRange()
status = pozyx.doRanging(destination_id, device_range, remote_id)
print(device_range)

A výsledek je jednoduše:

63812 ms, 1081 mm, -80 dBm

p.s. tak už mi funguje i ta autodetekce — funkce getDeviceListSize() mi stále vracela 0, i když jsem měl zapnuto hned několik zařízení. Trik je v tom, že je třeba nejprve zavolat doDiscoveryAll(). Pak už číslo sedí a pokračování kódu vypadá takto:

pozyx.doDiscoveryAll()
list_size = pypozyx.SingleRegister()
pozyx.getDeviceListSize(list_size)
device_list = pypozyx.DeviceList(list_size=list_size[0])
pozyx.getDeviceIds(device_list)
print([hex(i) for i in device_list])

a výsledek jsou ta dvě vzdálená zařízení:

['0xd53', '0xd67']

21. prosinec 2021 — Lillyino robotické kvarteto

Jedna z motivací, proč jsem si Pozyx pořídil, bylo demo Lilly Clark se čtyřmi autonomními mobilními roboty. Všichni mají na sobě anchor majáček a v daném čase se vždy pohybuje pouze jeden a jeho pozici odměřují zbývající tři stojící roboti. A tak se postupně střídají a jako skupina udržují celkem kvalitní globální pozici.

K dispozici je TEAM (Trilateration for Exploration and Mapping with Robotic Networks) článek a video. Je to nějaká studentská prezentace a některé „detaily” jsou tam možná až moc zjednodušené, ale jako motivační video snad OK. Konkrétně popis GPS je v realitě 3D a neznámá je i absolutní čas. Demo s robotama je ale ve školních prostorách v jednom patře, tj. 2D, a navíc Pozyx přimo vrací vzdálenost mezi zařízeními.

22. prosinec 2021 — Hodinový test a mrtvé kotvy

Je čas vrátit se do reality. Chtěl jsem udělat první test, kdy budu měřit vzdálenost mezi dvěma majáčky po dobu jedné hodiny. První divnost byla, že zařízení, které je přímo zapojené přes USB do počítače své ID zamlčuje, resp. lze zjistit, ale přes pozyx.doRanging() místo ID potrebuje remote_id=None.

Po 50 minutách už jsem to nevydržel, vypnul test a přidal další majáček. A po chvíli koukám, že dva majáčky/kotvy jsou mrtvé (nebliká ani LEDka na majáčku ani LEDka na powerbance). Co to?

Ono asi stačí jenom trošku počítat. Ten vychytralý USB kabel, co ukazuje proud a napětí, říká 5V a 0.2A. Pronásobením je tedy spotřeba cca 1W (potvrzeno i supportem, kdy ale záleží na konfiguraci, množství majáčků v dosahu a režimu měření). A teď powerbanky. Jsou překvapivě malé = tak malé jsem ještě neviděl. ;-( … 1200mAh. Zkrátím to, napájet majáček ta powerbanka (nebo powerbančička) vydži max tu hodinu.

Ještě je možné, že po prvním nabití nemají plnou kapacitu, protože se dvěma plně nabitými a jednou napůl jsem dostal tento graf:

hodinový test se čtyřmi majáčky

Dobrá zpráva je, že ty dva majáčky vydržely celou hodinu. Ale ten částečně nabitý jen cca 20s. Je vidět i rozptyl, jak to poskakuje cca těch +/- 10cm.

Možná ještě podivné pozorování ze včerejška, kdy jsem měřil pouze vzdálenost dvou vzdálených majáčků a je tam vidět díra, kdy žádná měření nejsou k dispozici — dnes bych podezříval tu baterku, tj. možná se jeden resetoval a po nějakém čase se vzpamatoval??

včerejší 50min běh s výpadky

p.s. pro to hraní jsem si udělal pracovní feature/pozyx větev a je tam i experimentální OSGAR Pozyx driver.

p.s.2 nabití všech třech powerbank trvalo 2 hodiny, tak jsem ready na další hodinový test …

MartinL píše: S největší pravděpodobností je v té powerbance LiON baterka, která má nominální napětí 3,6V a tebou uváděnou kapacitu 1200 mAh. Obsahuje měnič na 5V, který nebude mít 100% učinnost, ale takových 80% to snad bude. Tudíž proud odebíraný z baterky bude cca dvojnásobný oproti tomu, co teče na těch 5V. Tj. pro 5V a 0,2A to bude asi 0,4A. Takže teoretická výdrž baterky by měla být 1200 / 400 = 3 hodiny. Pokud to vydrží jen tu hodinu, tak je ta baterka hodně špatná nebo je ten odběr podstatně vyšší.

23. prosinec 2021 — Decaware, DWM1000 a další

Na včerejším Robotika post SubT pravidelném callu došlo i na Pozyx a jestli to není nějaká mrtvá větev v oblasti indoor radiové lokalizace. Jirka říkal, že existuje FIRA Consortium, do kterého jsou zapojeni velcí hráči (Apple, Google, Samsung, …) a jestli spíše to není cesta? A že také existují i jiné hračky za $40 ve srovnání s 1050EUR za Pozyx Creator kit?!

Dobrá zpráva je, že obě cesty mají společný základ a to jsou UWB (Ultra Wide Band) čipy od firmy Decawave, kterou loni koupila firma Quorvo (viz. Qorvo Completes Acquisition of Decawave). Když jsem o Pozyxu slyšel poprvé a psal o tom svému bývalému šefovi z Haptica/Irsko (podle mailu to bylo před šesti lety), tak to komentoval: I don’t know the guys but their kit is based on the UWB sensors of another Irish company http://www.decawave.com/. Malý svět.

Jirka také zmiňoval firmu Locatify, kde lokalizaci použivají pro audio doprovod v galerii. A až to bude standard v telefonech, tak nebudete potřebovat ani žádné další zařizeni.

Franta posílal odkaz na článek ESP32 UWB board features DW1000 module for accurate indoor positioning (aha, to jsem si ani nevšiml, že je ze včerejška), tak se nám to pěkně schází.

Teď je asi na čase si přečíst to společné jádro — DWM1000 datasheet.

Ještě přidám dvě poznámky ke včerejšímu blogu. Když jsem zkoušel měřit jenom vůči jednomu majáčku, tak to vydrželo skoro dvě hodiny a to jsem před tím ještě cca 20min jen tak měřil sensory s pohybem. Tj. výdrž powerbanky není jen 1 hodina, ale ani ty 3 hodiny co počítal MartinL. 2 hodiny je ale na test už OK, tak se posunu k dalším pokusům.

Ještě bylo zvláštní, že když jsem zase zkoušel měřit vzdálenosti mezi čtyřmi majáčky, tak se to po nějaké době „kousne” (dříve jsem myslel, že to došla ta baterka). Možná to má něco společného s tím, co píše Lilly, kdy jednotlivé anchor moduly měla zapojené přes USB do robotů, ale dávala si velký pozor, aby nemluvili současně:

One thing I've wondered about is that it seems you can't call .doRanging(device B) on pozyx device A and .doRanging(device A) on pozyx device B at the same time -- in my experience it would cause them to stop outputting anything usable until reboot. Have you observed the same thing? … zatím ještě nevím, ale možná to je to, co vidím na grafu níže:

20 minutový test se třema zařízeníma

Na co se to koukáme? Jenotlivé barvy odpovídají páru majáčků/kotev, pro které v daném čase volám doRanging(). None odpovídá zařízení zapojenému přímo do PC. Na začátku jsem to nechal vše staticky v pokoji, ale po cca 10 minutách (čas 600s) mne to přestalo bavit a každý jednotlivý majáček jsem vzal a prošel se s ním a pak ho vrátil na své místo. Ještě bych měl říci, že ta funkce vrací 3 hodnoty: POZYX_SUCCESS, POZYX_FAILURE, POZYX_TIMEOUT. V grafu vidíte pouze ty POZYX_SUCCESS.

Jedna z divností je třeba zelená (3431, 3455), která je po chvíli konstantní. Mimochodem ta funkce vrací ve struktuře i čas měření, ale bohužel netuším jakého zařízení, protože je to čas od spuštění. Tato čára má stále stejný čas. Skoro to vypadá, že modro-žlutá 3431 umře, ale fialovo-hnědá 3455 žije dál a reportuje základně poslední měření z 3431??

Ještě mám jednu obavu, jestli mi prostě neusínají? Ona cena Pozyxu je i v nástrojích na konfiguraci, které jsem ještě ani nezkoušel instalovat … a auto-sleep tam je …

p.s. přemýšlím, jestli vedle dotazu pozyx.doRanging(A, B) bych neměl také zkoušet pozyx.doRanging(B, A), aneb jak to vidí ze svého pohledu to druhé zařízení?

24. prosinec 2021 — Creator Anchor vs. Developer Tag

Vánoce, vánoce, přicházejí …

Včera jsem to nevydržel a rozšrouboval anchor/kotvu, abych se podíval dovnitř. Zkoumal jsem totiž nově i na Developer Tag (Arduino shield) a přišlo mi, že rozměrově jsou si hodně podobné. Zkoušel jsem ale také Pozyx Device Configurator a ten nějak poznal, že to jsou různá zařízení:

Developer Anchor

Developer Tag

„Trošku” zklamání bylo „množství” věcí co lze nastavit — vlastně je všechny vidíte výše: Channel, Datarate, Preamble, PRF a Power.

Creator Anchor vs. Developer Tag

Jak vidíte, tak desky jsou jiné — na kotvách chybí akcelerometry, gyra, kompas, tlakoměr … prostě se očekává, že budou statické.

acc = pypozyx.Acceleration()
pozyx.getLinearAcceleration_mg(acc)
print(acc)

s výsledkem:

X: -4.0, Y: -7.0, Z: -33.0

Ještě drobná mezihra byla, že po připojení developer tagu jsem zkoušel zase anchor a vůbec nic nefungovalo! Trošku jsem se vyděsil, že jsem v konfiguraci něco zmenil. Panika. Zkusím další kotvu a stejné chování! A důvod? No změnilo se číslo portu.

[1146360.588322] usb 1-6: new full-speed USB device number 20 using xhci_hcd
[1146360.738850] usb 1-6: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[1146360.738855] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1146360.738859] usb 1-6: Product: Pozyx Virtual ComPort in FS Mode
[1146360.738861] usb 1-6: Manufacturer: Pozyx Labs
[1146360.738863] usb 1-6: SerialNumber: 359E385B3438
[1146360.741406] cdc_acm 1-6:1.0: ttyACM1: USB ACM device

No jo no … asi žádné překvapení ttyACM1 místo nuly na konci.

Pěkné je, že se můžete ptát na stavy senzorů i vzdálených zařízení: pozyx.getLinearAcceleration_mg(acc, 0x680a). Pro kotvu je pak odpověď poměrně nudná: 'X: 0.0, Y: 0.0, Z: 0.0'

Ještě existuje raw varianta, která najednou vrací měření ze všech senzorů:

>>> raw = pypozyx.RawSensorData()
>>> pozyx.getAllSensorData(raw)
1
>>> str(raw)
'97840500, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0'

>>> pozyx.getAllSensorData(raw, 0x680a)
1
>>> str(raw)
'97824750, -101, 224, 949, -28, -224, -520, -2, -1, 2, 202, -87, -217, 16152, 2007, 567, -1788,
    -8, -4, 0, -93, 229, 948, 32'

Včera jsem také koukal na ten datasheet DWM-1000 a on je to vlastně pouze modul co obaluje čip DW1000:

Schema DWM-1000

A jak vidíte, tak SPI komunikace jde přimo do čipu, žádný extra konvertor tam není. Ale to si necháme až na příště …

25. prosinec 2021 — DW1000 první přiblížení

Nevím, kolik toho k tématu dnes sepíšu, tak alespoň dva odkazy, ze kterých budu vycházet:

První PDFko jsem před pár dny jenom narychlo prolílt, abych se ujistil, že to moc číst nemůžu. A to druhé (application note) mi naopak přišlo čtivé a zajímavé. Teď mám pocit, že bych se měl zase vrátit k tomu prvnímu, protože z toho by mělo být jasné co všechno řeší čip DW1000 a o co se musí postarat řídící počítač, ale uvidíme …

The DW1000 is a physical layer ultra-wideband (UWB) radio and brings the features of location awareness, robust communications and resilience to multipath fading to a wireless sensor network (WSN).

A more formal definition of a WSN is that it could be considered as a physically distributed computing system that interacts with the surrounding environment and provides a means to efficiently transfer this interaction over a span of physical area larger than the transmission range of the individual radio links between nodes.

The radio communications over a link between nodes is relatively expensive in terms of power. The communications of 1-bit of information over a radio link is equivalent to the execution of 1000 to 3000 instructions on a microprocessor.

... this means a sensor node needs a quarter of the transmit power to communicate over half the distance. This means that multi-hop networking is more efficient in terms of transmit power and the expense of more nodes.

Mesh multi-hop wireless sensor network architecture

A node in any WSN could use a routing table with range to neighbouring nodes as a metric to control the transmit power to the minimum it requires to reliably communicate with that neighbouring node.

For the DW1000 UWB PHY, the receive power is a constant for any link distance, therefore the policy or protocol that controls when the receiver is active is very important for energy conservation.

The DW1000 physical layer (PHY) has the capability to provide communication and precision ranging functions, even where a line of sight (LOS) radio path may not exist.

Ve zkratce — vyplatí se posílat signál na kratší vzdálenost, protože je to méně energeticky náročné. DW1000 umožňuje jak komunikaci tak měření vzdálenosti a je to tedy základní kámen pro mesh-sítě.

Ve článku následuje vysvětlení generování signálu a přeposílání +1 a -1 pulzu.

The DW1000 derives ranging capability from calculations using its ability to precisely timestamp message transmission and reception events. The DW1000 acquires these precision timestamps by building an accurate estimate of the channel impulse response (CIR) and processing this data.

The DW1000 builds estimates of the CIR by correlating a known preamble sequence against the received signal and accumulating the result over a period of time. These preamble sequences are based on preamble codes from the large family of codes called perfect ternary sequences.

The estimated CIR provides information about the first received radio path from another node. This radio path is known as the first path or leading edge of the CIR. The DW1000 contains signal processing technology that finds this leading edge in the CIR and produces timestamps to a resolution of 15 picoseconds. By using the DW1000 generated timestamps a ranging application can produce ranges to a precision of 10 cm.

The method used by DW1000 for ranging is known as threshold based time of arrival (TOA).

The DW1000 payload consists of a number of symbols. A single symbol carries two information bits.

The payload bit is encoded as a burst in the symbol position
The convolutional parity bit is encoded as the polarity of the burst.

A coherent receiver such as the DW1000 has the ability to see the polarity of a transmitted burst and so may utilise it in a convolutional decoding algorithm. This is known as systematic forward error correction (FEC) as the encoding preserves the original data bits.

In two-way ranging, a node exchanges timestamps with another node to calculate a time of flight (TOF) between the nodes. This allows the calculation of a range between the two nodes.

In one-way ranging, a node can transmit blinks to a number of other receiving nodes. The timestamps from these other receiving nodes are used as time difference of arrival (TDOA) values. A multilateration algorithm can then calculate the position of the transmitting node from the TDOA values.

If the receiving nodes are in fixed location then the scheme is known as anchor based location. If the receiving nodes are mobile then the scheme is known as anchor-less location, however the receiving nodes may need to locate themselves before the TDOA multilateration is performed.

DecaWave is a pioneering fabless semiconductor company whose flagship product, the DW1000, is a complete, single chip CMOS Ultra-Wideband IC based on the IEEE 802.15.4- 2011 UWB standard. This device is the first in a family of parts that will operate at data rates of 110 kbps, 850 kbps and 6.8 Mbps.

To by asi na copy and paste stačilo. Za mne to UWB vypadá zajímavě. Možná ještě než se pokusím znova prokousat tím uživatelským manuálem k DW1000, tak motivační český článek ze Smartmanie:

Vše, co potřebujete vědět o UWB. Technologie budoucnosti, které fandí Samsung, Apple i Xiaomi

Co mne tam zaujalo, že nové (resp. už skoro rok staré) Samsung Galaxy S21+ a další telefony již UWB technologii podporují! Bylo by zajímavé to zkusit zkombinovat s Pozyxem, ale mám obavy, že si „moc rozumnět nebudou”. Leda by existovala nějaká zadní vrátka a přes seriák se dalo bavit přímo s SPI čipu … ale je to spíše nepravděpodobné. :-(

Což mne ještě přivádí k otázce, co měl Jirka: kdo tedy tu pozici počítá? No je to na 90% ten extra čip, kterému po seriáku čtete nebo zapisujete registry a případně i pouštíte extra funkce. Seznam dostupných registrů/příkazů je na pypozyx/definitions/registers.py. Je to cílené jako aplikace pro Arduino a Python wrapper je jen malý extra bonus.

p.s. tak ještě doplním řádově levnější alternativu k Pozyx Creator Kit: MDEK1001 přímo od Decawave/Qorvo:

12 modulů (konfigurovatelné jako anchor nebo tag)
cena $199
MDEK1001_System_User_Manual-1.1.pdf

27. prosinec 2021 — DWM1001 API a Jirkovy dotazy

Dnes bych se vrátil k modulu DMW1001, který prodávají za cca 5x nižší cenu než Pozyx. Ono tam ještě může být nějaké „ale” … no to se asi časem vyjasní. Jirka mi poslal několik odkazů a pár dotazů, na které asi zatím nemám odpověď, ale třeba někdo z vás ano.

První dokument je DWM1001-API-Guide.pdf, kde o modulu píší: The DWM1001 module is a radio transceiver module integrating the Nordic Semiconductor nRF52 MCU and Decawave’s DW1000 IC. The nRF52 MCU, which has Bluetooth v4.2 protocol stack implemented, is acting as the main processor of the DWM1001 module. … a možná nám pomůže rozlousknout otázky, co řeší čip DW1000 a o co se musí starat main processor (tady ten Nordic Semiconductor nRF52).

Uhh, chtěl jsem připsat, že na rozdíl od Pozyxu budou k DMW1001 i zdrojové kódy … a jsou: DWM1001, DW10001-DEV AND MDEK1001 DOCUMENTS, SOURCE CODE, ANDROID APPLICATION & R2.0 FIRMWARE IMAGE … jen je to 1.8GB!

No nic, zpět k API dokumentu. Každé jednotlivé zařízení si můžete nakonfigurovat jako anchor nebo tag, kde anchor je očekáván, že je statický se známou pozicí a tag je pohyblivý a pozici určuje vůči pozorovaným anchors/kotvám. Většina příkazu je typu set/get. Příkladem může být dwm_pos_set, který nastaví pozici, pokud je zařízení konfigurované jako kotva (v tag módu je pozice uložena, ale jinak je ignorována). Odpovídající funkce je dwm_pos_get, která vrátí aktuální pozici a pokud není k dispozici, tak tu jenž je uložena.

Funkce, která mne asi nejvíce zaujala je dwm_loc_get — Get last distances to the anchors (tag is currently ranging to) and the associated position. The interrupt is triggered when all TWR measurements have completed and the LE has finished. Vrací to pole jak vzdáleností ke kotvám, tak jejich pozice. Pole má maximálně 15 prvků. A také to posílá pozici samotného zařízení … prostě kompletní info na jakém základě je pozice počítaná.

Je tam ještě spousta funkcí pro konfiguraci, správu verzi firmware (všechny zařízení se umí automaticky updateovat) a Bluetooth. Zatím jsem moc nepochopil co jsou user data (max 34 bajtů) a co je label (max 16 bajtů). A ještě jsem zapomněl na GPIO, tj. vzdálené digitální vstupy a výstupy.

Modul poskytuje i jednoduchý terminál přes UART. Zajímavě vypadají např. příkazy: la, ln a lr, tedy list anchors, list nodes a list routes. Předpokládám, že je to popis aktuální sítě, ale třeba větě: List nodes heard by BN through backhaul, only works for BN. moc nerozumím. :( Aha, tak BN = Bridge Node, to zatím ještě neznám.

Další link od Jirky: https://www.decawave.com/sites/default/files/aps010_dw1000_wsn.pdf The DW1000 provides the physical layer of the protocol stack and has some MAC protocol assist features. The remaining layers of the protocol stack are realized as software executing on an external microprocessor. [kapitola 5]

A Jirkův dotaz: Tj. zajímalo by me, jestli se Pozyx umí domluvit "za roh." Z robotika.cz vím, ze se můžeš nodu A zeptat na vzdálenost mezi B a C. Ale je nutné, aby A aspoň na jeden z těch dvou měl přímé spojeni? Nebo se můžu zeptat i na Y a Z, které jsou dostupné jen s meziskoky přes další uzly? Pokud umi Pozyx i meziskoky, je tam nezanedbatelný value-add nad DW1000, asi i ospravedlňující cenový rozdíl.

Hmm, ale jak to vyzkoušet? Byt máme malý a tak si myslím, že když je všude WiFi, tak všude bude i signal pro kotvy/tagy. Napadl mne jeden pokus s tagem ve výtahu a monitorovat z domova, ve kterém je patře … ale zas tak moc jich nemám a na hru follow me teď úplně náladu nemám.

p.s. jinak s tím Androidem to úplně růžově nevypadá. Viz článek Google has added an Ultra-wideband (UWB) API in Android, kde ale pak píšou update, že to API pro Android 12 zatím nebude dostupné aplikacím třetích stran … ale2 už je to skoro rok a třeba se něco brzy změní

p.s.2 procházka se psem …

Procházka se psem

… no na sledování polohy výtahu to rozhodně není. Jediné co z toho vidím je, že procházka byla cca 15 minut a že ten signal se ztratil už na chodbě, tak ten Jirkův pokus by asi šel udělat i tady …

p.s.3 tak se ta vzájemné měření propagují … bez spojky nevidím vzdálenosti … ale vlastně vzájemné vzdálenosti těch přimo nedosažitelných nodů nedostanu :(

vzdálené měření

(je tam také úlet na začátku — těch cca 70 metrů, ale pak se to srovná)

4. leden 2022 — Informační střípky

Minulý týden jsem toho moc na počítači neudělal — to jsem si raději užival tajících hor, kde se turistické stezky změnily v divoké horské potoky. Ale Jirka se činil a mám plnou schránku nejrůznějších odkazů, článků a doporučení. Také jsem dostal nějaké odpovědi od podpory Pozyxu a od Lilly.

Začal bych od opovědi Pozyxu. Poslali jednak datasheet k Development tagu a pak odpověď na téma kompatibility a otevřenosti SW: Regarding your other question, there is no compatibility with other devices due to the software which is indeed closed source. We also don't provide a way to directly communicate with the DW1000 chip. Ještě přidali přání do nového roku, ale tyto špatné zprávy (asi očekávané) to přebily. Obávám se, že svým dalším dotazem, jak je to ve srovnání s DMK1001 za 199USD jsem asi podporu ukončil …

… tak ne, před chvíli ještě Robb odpověděl: I understand your remarks, the creator kit was our first product when the company just started and is thus already quite a few years old by now. Regarding the advantage compared to the MDEK1001 Kit. Our product has different features that I don't find for the other kit such as:

Arduino compatibility
Python programming using the python library
Extensive documentation with code examples
Visualization on a floor plan
on board IMU with access to IMU data
Access data via the MQTT stream (locally or via the cloud)
Implementation of certain filters
Implementation of localization algorithms
Auto calibration for more than 4 anchors
Easy configuration using the creator controller
Cleaner looking application with more options

If you want program on the MDEK1001 Kit you will need a good technical knowledge and invest a significant time in reading the documentation whereas our system is much more user-friendly for people who don't have such a technical background.

Tak jo, tolik info přímo od Pozyxu. Zatím srovnání nemám, ale Jirka vypadal, že si možná ten alternativní kit pořídí.

A teď co nového od Jirky, který se rozhodně mezi svátkama neflákal.

Asi první skupina se týká komunikace. Ona mesh komunikace je primární účel této technologie a lokalizace je takový vedlejší prodkut, i když je nutná k vytvoření rozumné komunikační sítě. DWM1001 kit podporuje pouze 34 bajtů pro uživatelská data což je na jeden packet hrozně málo.

DWM1001-Firmware-User-Guide-2.1.pdf — After reading this guide developers should be able to compile, build and run the DWM1001 firmware, including custom modifications.

Decawave does not provide the library source code, or support any use of the PANS library except through the PANS API which is described in the API Document. … hmm, tak také samá voda. A po pravdě žádné info o 1023 bajtových zprávách jsem tam neviděl (ale prošel jsem to hodně rychle).

Dále tu mám dotaz k minulému experimentu — doplňuji obrázek bytu a umístění kotev ke grafu:

Pozice kotev k experimetu z 27/12

Sedím u počítače, kde základna je None, bez 3455 další kotvy vůbec nevidím, a když přidám 3455 tak můžu zjistit pouze vzdálenosti k 3455, ale nikoliv vzdálenosti sousedních kotev 3411 a 3431.

Jirka píše: Při činnosti skrz zdi a za roh doporučuje Decawave přenastavit parametry: APS006_Part-2-NLOS-Operation-and-Optimizations_v1.5.pdf. Pak si věří na zhruba 10m skrz dvě slabé zdi. Tj. na byt by to mohlo při troše štestí a dobrém umístění kotev stačit. V dalším dokumentu pak přidávají "nižši frekvence, vyšší dosah" (což je vidět i na 2.4 GHz wifi vs 5 GHz wifi): aps017_max_range_in_dw1000_systems.pdf

6. leden 2022 — Follow me

Dnes bych přidal druhou dávku „kompilovaných mailů od Jirky”. Včera jsme se na callu bavili, že není špatné najít všechny odkazy na jednom místě, tak je to lepší hledat na webu než v mailech.

Začal bych mailem z 30/12: A trochu pro pobavení UWB Follow Me - čtyři kotvy na robotovi, jeden tag na clověkovi:

… něco podobného bych rád zkusil s Edurem, pak John Deere a případně i se Spiderem (ten má rozhodně širší základnu).

Další maily se točili kolem toho, jak moc je UWB s DW1000 čipem certifikované a použitelné v různých zemích.

JI: Odkazy táham z téhle přednašky (půl hodiny, asi za ten čas asi stojí): https://www.youtube.com/watch?v=TR-rahy3Y2k (Po třinácté minutě jsou tyhle regulace.)

Evropská regulace

As per the ECC/DEC/(06)04 [i.2] and Decision 2007/131/EC [i.4] and its amendments [i.5], [i.6], the UWB transmitter equipment conforming to the present document is not to be installed at a fixed outdoor location, for use in flying models, aircraft and other forms of aviation. The present document applies to UWB equipment with an output connection used with a dedicated antenna or UWB equipment with an integral antenna. ETSI.ORG en_30206501v020101p.pdf (strana 7) Mobilní nelétající užití venku je asi OK.

Nicméně, navazující pravidla přidávají: (LT = Location Tracking) LT2 systems: These systems, operating in the 3,1 GHz to 4,8 GHz region (see ECC/REC(11)09 [i.8]), are intended for person and object tracking and industrial applications at well-defined locations. The transmitting terminals in these systems may be located indoors or outdoors, and may be fixed or mobile. They operate at fixed sites and may be subject to registration and authorization, provided local coordination with possible interference victims has been performed, ECC Report 167 [i.10] and ECC Report 170 [i.11]. ETSI.ORG en_30206502v020100a.pdf (strana 8) Tj. pro určité frekvence je asi lokalizace (ne přenos dat) možná i outdoor fixed. Auta a vlaky v pohybu (!) budou asi jestě další speciální kategorie: Furthermore, it does not cover LT1 UWB transmitters that are operated on board a road or rail vehicle running on a public network or highway.

Jestli ty frekvence čtu dobře, jsou to kanály 1 až 4. Z nějakého Decawave dokumentu si vybavuju default: 5.

Martine, v tom 1.8 GB zipu od Decawave je sice hromada zdrojaků, ale to nejdůležitější, co běží na tom Nordic cosi Armu řídícím DW1000, je tam jenom v binarní formě:

Otázka: ... But I can’t fing the PANS’s source code

Odpověď: PANS is shipped as a library/binary only. There is no source code for this library available for download. https://decaforum.decawave.com/t/dwm1001-pans-release-2/4347/17

Je tam dost knihoven a zdrojáků, aby si člověk napsal vlastní, ale je nutné začít od nuly.

Koukám na to, protože hledám původ omezení uživatelských zpráv na 34 B. Jeden strop je TLV format, který používá 1B pro délku zprávy. Nicméně jsou tam 3B headeru a 252 B zbývá (anebo víc? počítá se ten header do délky?). Takže nevím. Jenže „prostě to zkompiluju s vyšší hodnotou” kvůli nepřítomnosti zdrojáků nepůjde.

U mě se podobně ochladilo po zjištení, že ten Decawave firmware pro dev board je closed source. Je tam pár drobností, které bych dělal jinak. Jednak těch 34 B pro usr_data packet, jednak celé chovaní kolem bluetooth - kupříkladu tam neni mesh , takže při nastavování musí být všechna zařízení v dosahu BLE. Vždyť je to komunikační modul s dlouhym dosahem, proboha!

Tj. koukám, kolik může dát práce to celé přeprogramovat.

Což je zajímavá výzva pro matfyzáky:

Vstup:

N komunikačních zařízení, která umí Send, Receive, GetTime a GetUniqueId.
Všechna komunikují na jednom komunikačním kanálu a když mluví dvě blízká zařízení najednou, ruší se.
Ne všechna zařízeni jsou v komunikačním dosahu, ale každé je v dosahu aspoň tří dalších, která nejsou v jedné přímce.

Výstup:

Všech N zařízení zná své 3D souřadnice.

Volitelný výstup:

Schopnost routovat zprávy z A do B, i když nejsou v přímém komunikačním dosahu.

S pomocí Send, Receive, GetTime a GetUniqueId se snadno udelá GetDistanceTo (two-way ranging), takže předpokladejme, že ta existuje taky. Akorát spotřebuje 2xSend, ideálně těsně po sobě.

Rozšířená varianta úlohy:

Některá z těch N zařízení jsou mobilní a průběžně mění jak pozici, tak topologii sítě.

Alternativni vyrobce podobné technologie: www.nxp.com Plus: FIRA stack installed (ať už to znamená co přesně) Mínus: Nevidím volně dostupné velké množství datasheetu, jako ma Decawave.

p.s. Oprava matfyzácké úlohy: „Vždycky jsou v dosahu alespoň čtyři další zařízení a nejsou v jedne rovině.” Nebo tak nějak. Proste „cokoli je geometricky potřeba, je splněno.”

MD: nebylo by použitelné některé to jejich repo? https://github.com/Decawave/uwb-apps

JI: Jo, jo, z těch příkladů se dá vyjít. Jsou to, mimochodem, ty zdrojáky v tom 1.8 GB balíku.

Jsou nejspíš dobré na ověření toho, že dokážeme zkompilovat, nahrát a pustit funkční kód. Mezi těmi příklady a celou tou jejich closed source PANS funkcionalitou je ale dlouhá cesta.

MD: oni tam těch repo mají 8 … není toto blíže? https://github.com/Decawave/uwb-core

JI: Jo, to vypada sloziteji. Já jsem se napoprvé lekl někde u NewtOS („Co prosim?”), ale asi jsem měl pokračovat.

Mimochodem, proklikal jsem se odtamtud na https://lohmega.com/faq/, kde dole zmiňují důležitost výšky antény nad zemí. A když si tak vybavuju snímky některých průmyslových instalací z přednášek, co jsem videl, asi by se to mělo aplikovat i na výšku pod stropem a vlastně vůbec vzdálenost od odrazive plochy (https:/wikipedia.org/wiki/Fresnel_zone).

p.s. Autoři článku Error-Corrections-for-Ultrawideband-Ranging.pdf (obr. 5), který je teda hlavně o něčem jiném, pozoruji nekolikaminutový (až ~18 min) warmpup DW1000, než začne hlásit stabilní čísla.

10. leden 2022 — pozyx.doPositioning()

Asi je na čase udělat pár pokusů ve scénáři, pro který je Pozyx primárně určený — lokalizace. Přiznám se, že voláním jednotlivých funkcí jsem neuspěl a od automatické kalibrace sítě autoři odrazují. Používám tedy manuální nastavení a vzor tutoriál Ready to localize.

Přepsaný kód vypadá následovně:

from pypozyx import PozyxSerial, DeviceCoordinates, Coordinates

serial_port = '/dev/ttyACM0'
pozyx = PozyxSerial(serial_port)

anchors = [DeviceCoordinates(0x0D53, 1, Coordinates(2980, 2240, 1250)),
           DeviceCoordinates(0x0D67, 1, Coordinates(2980, 3140, 1250)),
           DeviceCoordinates(0x0D7F, 1, Coordinates(710, 160, 930)),
           DeviceCoordinates(0x6826, 1, Coordinates(130, 4350, 2230))]

remote_id = None
status = pozyx.clearDevices(remote_id)
for anchor in anchors:
    status &= pozyx.addDevice(anchor, remote_id=remote_id)

position = Coordinates()
status = pozyx.doPositioning(position, 3, remote_id=remote_id)
print(status, position)

A výsledek:

1 X: 2841.0, Y: 1249.0, Z: 776.0

To je OK. Stejně tak potěšila vzdálená lokalizace, kdy místo remote_id=None vyplníte konkretní ID zařízení. Jen poznámka, že informace o všech kotvách je třeba nejprve do zařízení nahrát (lze případně uložit dlohodobě pomocí pozyx.saveAnchorIds() a pozyx.saveRegisters()).

Aby to zas nebylo tak moc růžové, tak ta pozice 2x extra stabilní není, ale to může být mým rozložením kotev:

POS ID 0x0000, x(mm): 2780.0 y(mm): 1240.0 z(mm): 834.0
POS ID 0x0000, x(mm): 2882.0 y(mm): 1177.0 z(mm): 856.0
POS ID 0x0000, x(mm): 3541.0 y(mm): 1390.0 z(mm): 1539.0
POS ID 0x0000, x(mm): 2618.0 y(mm): 1414.0 z(mm): 754.0
POS ID 0x0000, x(mm): 2710.0 y(mm): 1233.0 z(mm): 1133.0
POS ID 0x0000, x(mm): 2860.0 y(mm): 1212.0 z(mm): 845.0
POS ID 0x0000, x(mm): 2881.0 y(mm): 1228.0 z(mm): 858.0
POS ID 0x0000, x(mm): 2864.0 y(mm): 1225.0 z(mm): 842.0
POS ID 0x0000, x(mm): 2890.0 y(mm): 1122.0 z(mm): 933.0
POS ID 0x0000, x(mm): 2882.0 y(mm): 1227.0 z(mm): 844.0
POS ID 0x0000, x(mm): 2871.0 y(mm): 1158.0 z(mm): 940.0
POS ID 0x0000, x(mm): 2896.0 y(mm): 1218.0 z(mm): 847.0
POS ID 0x0000, x(mm): 2898.0 y(mm): 1206.0 z(mm): 863.0
POS ID 0x0000, x(mm): 2675.0 y(mm): 1356.0 z(mm): 888.0

14. leden 2022 — (Ne)dostupnost a časové známky

Dlužím vám pár informací ohledně vývojového kitu MDEK1001 za $199 (teoreticky). První co mne při objednání trošku zklamalo byla cena dopravy:

Cena dopravy pro MDEK1001 z Smmetry Electronics

Plus to nebylo na skladě, tak jsem se 2x rozhoupával, zda do toho jít. Naskladněné to mělo být 12. ledna 2022 (ano, to již bylo — ja to objednával 5. ledna). Jirka přiznal, že si to již objednal a to mne poštouchlo, ale chyba lávky. Nejprve přišel formulář, na co že se to chystáme používat. Byl jsem varován Jirkou, takže OK. Druhý den ale přišel mail: Unfortunately, we are now out of stock and it will take until April for item to arrive. Please confirm if you would like to wait and keep your order opened. Hmm, no Jirka objednával dříve a tak snad se vešel do té várky k 12/1 … jo jo, to by bylo moc jednoduché. 11/1 přeposílal mail: Unfortunately, the supplier had a delay and the new date is May 2022. Jirka objednávku zrušil a hledá alternativy. Já bych asi také měl … aneb Pozyx je předražený, ale na druhou stranu jsem ho dostal ještě ten týden před vánoci.

Tak a teď ty časové známky. V úterý jsem dělal nějaké experimenty v hale ČZU a to také úplně růžové nebylo. Vedle informace kolik je naměřená vzdálenost mezi A a B? je třeba se i ptát jak stará je tato informace?. Krabičky totiž s radostí odpoví to vím, to vím, ale může to být několik minut staré! Měřil jsem totiž nejprve krátké (cca 5m) vzdálenosti a pak přes celou halu (cca 20m) a chodily mi dál ty krátké … ale se starou časovou známkou, což zase oceňuji.

A ještě se mi často děje jedna nepěknost — zapomínám některé kotvy zapnout (případně jim může dojít baterka). Pokud se ptáte jen na pozici, tak je schopné si to něco vymyslet, tedy nejčastěji (0, 0, 0), což možná člověka trkne. Ale pokud to jsou jiná čísla a vezme to v úvahu měření z minulého století, tak špatný, špatný, špatný, abych citoval jednu sci-fi co jsem dostal pod stromečkem.

A jak moc velká skleróza může být naznačuje tento obrázek (pozn. že ty časové známky jsou interní, od času 0 od okamžiku napájení kotvy) … hmm, takže jsem si ten obrázek interpretoval „naruby”??

zapomenuté (nenapájené) kotvy

No jsou vidět dvě hlavní „časové” skupinky, ale ta červená mne mate … to bude chtít ještě nějakou revizi.

15. leden 2022 — Dosah 100 metrů? Ha, ha, ha

Jo, jo, jak titulek z Blesku. Jirka by to jistě rozporoval, že pro jiný kanál a preambuli bych mohl dostat více, takže první dálkové měření venku na zahradě bylo s defaultním nastavením: kanál 5, datarate 110, preambule 1024, PRF 64, power 11.5 (vycházím z toho obrázku pro 0x6867, kterou jsem měl zapojenou do počítače). Bylo to na výšku na monitoru na notebooku (jinak položeném na zemi) a s druhou krabičkou (0x0D67) připojenou na powerbance jsem šel přes zahradu tam a pak zpět. Přidal jsem tam cca 5s pauzy u „visuálně význačných bodů”, ale nutně jsem trasu nezopakoval. A výsledek vypadá takto:

No 100m to není. Je zvláštní, že v druhém pokusu je to ještě horší než v tom prvním — že by se ta powerbanka tak rychle vybila? Skoro to vypadá jistější do 30m a někdy do 50m. Možná znova zkusím projít nastavení, jestli nemůžu zvětšit citlivost a ty powerbanky nabiju na max, ale s tímto nastavením by pořádně nefungovalo ani sekání zahrady, resp. by to chtělo hustější síť kotev.

p.s. koukám znova na to nastavení a kanál můžu nastavit na 1, 2, 3, 4, 5, 7 (ano, 6 tam chybí). Datarate můžu zvýšit z 110 na 850 nebo 6810. Preambule je od 64 do 4096 (mám 1024). PRF je 16 nebo 64 a power je od 0.0 do 33.0 (používám 11.5). Závěr — je tam prostor pro zlepšení/experimenty.

16. leden 2022 — UWB channels

Dnes bych začal opisem tabulek z dw1000_user_manual_2.11.pdf. Jirka včerejší post komentoval: Co nejnižší kanál, co nejnižší datarate, co nejdelší preamble, PRF netuším, "power" zní jako "moarrrrre", anténu aspoň půl metru nad zemí ve volném prostoru, ještě lépe metr nad zemí, a v cestě by neměla být žádná překážka nebo odrazová plocha, jako třeba země, takže nejlépe testovat přes údolí nebo mezi mrakodrapy.

První tabulka naznačuje, že defaultní kombinace co používám (110kbs a 1024 preambule) není výrobcem doporučovaná:

Tabulka doporučených délek preambule

The preamble sequence used at all data rates is the same, i.e. it does not depend on the chosen data rate. The preamble sequence length, (i.e. the number of symbol intervals for which it is repeated), has a significant effect on the operational range and the accuracy of timestamps. Table 57 gives some recommended preamble sequence lengths to use depending on the data rate. In general, a longer preamble gives improved range performance and better first path time of arrival information while a shorter preamble gives a shorter air time and saves power. When operating a low data rate for long range, then a long preamble is needed to achieve that range. At a high data rate the operating range is naturally short so there is no point in sending a very long preamble as it wastes time and power for no added range advantage.

There are two choices of mean pulse repetition frequency (PRF) within the DW1000. These are 16 MHz PRF or 64 MHz PRF. The higher PRF gives more accuracy on the first path timestamp and perhaps slightly improved operating range, however this comes at the price of additional power consumption.

Tabulka frekvencí a šířka pásma pro jednotlivé kanály

Strana 209, sekce 9.1 Operating Range: The operating range also varies depending on the channel centre frequency and channel bandwidth selected – a lower centre frequency gets more range than a higher one, while the wider bandwidth channels channel 4 and channel 6 have more range than the standard 500 MHz bandwidth channels as the wider channel allows more energy to be sent at a given dBm / MHz regulatory limit. (předpokládám, že 6 má být 7?)

Zatím si to interpretuji tak, že nejlepší výsledek bych měl dostat pro kanál 1 (možná 4?), datarate nechat na 110kbps, preamble zvýšit na 4096, PRF nechat na 64 a power „co to dá”???

…

No nic, dnes to nebude. :( Ten úžasný nastavovač device-configurator-1.3.6.appimage sice dovolí vyplnit co jsem napsal výše, ale neuloží to do zařízení a po zapnutí se to vrátí do defaultu. Divné. Je tam možnost si vytvořit vlastní profil pro danou kombinaci (našel jsem tam např. High range a High update rate), ale do zařízení se to uloží jen krátkodobě. Co je nastavené lze zjistit i z Pythonu:

>>> serial_port = '/dev/ttyACM0'
>>> pozyx = pypozyx.PozyxSerial(serial_port)
>>> data = pypozyx.SingleRegister()
>>> pozyx.getUWBChannel(data)
1
>>> print(data)
0x5

Je tam i odpovídající setUWBChannel(), s popisem If using this remotely, remember to change the local UWB channel as well to make sure you are still able to communicate with the remote device. Trošku mi to připomíná „Kdyby tisíc klarinetů” — až vyhodíte pojistky bude tma … no nic, je čas sekat třisky a vrátit se do civilizace.

23. leden 2022 — Channel 1, preambule 4096, gain 33 = více jak 80 metrů

Dnešní měření mi zase dodala naději. Udělal jsem drobný hack, který všem vypsaným zařízením nastaví:

settings = pypozyx.UWBSettings()
settings.bitrate = 0  # {0: '110 kbit/s', 1: '850 kbit/s', 2: '6.81 Mbit/s'}
settings.channel = 1
settings.prf = 2  # {1: '16 MHz', 2: '64 MHz'}
settings.gain_db = 33.0
# {0x0C: '4096 symbols', 0x28: '2048 symbols', 0x18: '1536 symbols', 0x08: '1024 symbols',
#  0x34: '512 symbols', 0x24: '256 symbols', 0x14: '128 symbols', 0x04: '64 symbols'}
settings.plen = 0x0C
self.pozyx.setUWBSettings(settings, remote_id=remote_id)

A když jsem nechal jednu kotvu uvnitř a druhou obešel chatu, tak nebyl žádný výpadek. Podobně pak dole na zahradě stejný test jako před týdnem. Základnu jsem dal tentorkát na převráceny plastový sud (tj. mělo by to být alespoň ten metr nad zemí) a druhou kotvu jsem napájel z 5000mA powerbanky dříve používané na lodičce. Primárně jsem zkoušel nové nastavení výše (kanál 1, preambule 4096, max gain 33 čert ví čeho). A výsledky (opakované 2x) mne tak potěšili, že jsem se prošel ještě vedle na „pole” a na 80 metrech to stále něco měřilo. Je tam mezera, protože čast zakrýva skoro padlý strom. No a nakonec jsem použil defaultní nastavení jako referenci.

Maximální vzdálenost pro (1, 4096, 33)

Původní nastavení

Bezztratové měření s novým nastavením

Ještě bych zmínil, že při testování změny nastavení mi vzdálenost mezi dvěma kotvama skočila v průměru z 3.93m na 4.01m, ale to je vlastně v toleranci — možná by s různým nastavením šlo zjistit, zda je mezi zařízeními nějaká překážka?? No nic, příště, možná, …

1. únor 2022 — DW1000 + BU01 (Jirka)

Už mi zase ten seznam co jsem všechno za poslední dobu neudělal nějak nezdravě narostl. Navíc dnes není 1. února, ale už 5. To datum se ale váže k Jirkovu mailu (začal psát s diakritikou, abych při přepisování nedělal tolik chyb ), kde popisuje své první úspěchy s alternativní deskou používající DW1000 čip.

Za sebe bych si udělal alespoň „záložku” na českou IoT stránku, kde jednak je celá technologie UWB popsána, a dále jsem tam poprvé viděl grafy energetické náročnosti v závislosti na typu vysílané/přijímané části zpráv:

Určování polohy v reálném čase s přesností na 10 cm (2018-08-23)

Tak teď ten slibovaný mail od Jirky:

NodeMCU-BU01 (ai-thinker.com)

Pracuju s NodeMCU-BU01, což je poměrně minimalistická deska s STM32F103C8 mikrokontrolérem kolem BU01 modulu s DW1000 čipem od Decawave pro komunikaci a následně pro měření vzdálenosti. Koupil jsem těch desek deset a vypadá to, že některé přišly flashnuté jako "anchor" a jiné jako "tag". To je ale zatím vcelku jedno, protože s defaultním firmware jsem je zatím nedonutil k vzájemné komunikaci. Ani se moc nesnažím, protože chci firmware vlastní.

Slušnou nadvládu nad tou deskou získávám, když vyjdu z "opencm" příkladu na https://github.com/satoshinm/pill_blink. OpenCM3 je knihovna dostatečne nízkoúrovňová, abych mohl řešit potíže, a dostatečně vysokoúrovňová na to, abych se nezbláznil z registrů a prescalerů a všeho možného. V důsledku dokážu blikat všemi třemi LED na palubě, komunikovat s PC přes UART a reagovat na přerušení vyvolané stiskem tlačítka. Dokumentaci OpenCM3 bych ale hodnotil jako nedostatečnou.

Mikrokontrolér programuji a debuguji pomocí stlink-tools přes ST-LINK/V2 Mini. Občas sáhnu po OpenOCD, které se zdá mocnější, ale konkrétní výhody jsem zatím nenašel. Resp. tu jednu, o které vím, zatím nevyužívám. Snad až se budu snažit flashovat firmware větší než 64kB. Ono totiž tenhle procesor má podle datasheetu 64kB flash a to samé o sobě i tvrdí, ale ve skutečnosti má často 128kB. Jak je to konkrétně s mými kousky zatím nevím. S OpenOCD jde při flashování ignorovat, co o sobě ten procesor hlásí.

Co zatím taky nevím, je, jestli funguje USB pro přenos dat a ne jen pro napájení. Defaultní firmware přes USB nekomunikuje. USB bootloadery, které jsem nahrával - HID Bootloader a STM32duino-bootloader - nefungují. PC ani nedetekuje připojené zařízení. Včera jsem asi konečně vykopal psa, který to způsobuje. Externí oscilátor na NodeMCU-BU01 tiká na 16MHz, zatímco většina desek se stejným procesorem používá oscilátor na 8Mhz. Pokud bootloadery předpokládají 8MHz, je pak časování na USB úplně mimo.

Nejspíš z podobného důvodu, kvůli oscilátoru, jsem zatím nerozchodil ani Arduino pro STM32. Zephyr OS jednak naráží na to samé, jednak i po pokusu o přenastavení padá program v nějakém ošetření přerušení, o které jsem ani neprosil. Zephyr i Arduino prozatím odkládám.

Jako další krok bude nutné rozchodit SPI, abych se měl jak domluvit s DW1000. Jako bonus by se mi líbilo rozchodit to USB, abych nemusel pořád pracně připojovat USB-UART převodník. Pak by možná i znovu nastal čas na bootloader, aby nebyl potřeba ani ten STLINK.

10. únor 2022 — Decawave driver (Jirka)

OK, dnes to budou zase novinky od Jirky, jeden starší a jeden nový …

[Update 5/2/2022]

0xdeca0130! Tj. dokážu přes SPI přečíst device id z DW1000. Zádrhel byl opět v mizerné dokumentaci knihovny OpenCM3. Pro zápis a čtení přes SPI neslouží funkce spi_write() a spi_read(), a to dokonce navzdory tomu, že jsou tyhle dvě funkce použité ve vzorovém příkladu pro SPI. Je potřeba použít spi_xfer(). Teď ještě k tomu vlastnímu readfromspi() přidat writetospi() a měl by začít fungovat celý driver od Decawave. Kus jsem ho už použil pro to čtení device id.

[Update 10/2/2022]

Mám portovaný Decawave driver. Funguje mi posílání a příjem zpráv. Mačkáním tlačítka na jedné desce blikám ledkou na druhé. Na obou deskách je stejný firmware, takže se přepínají navzájem.

Zajímavý zádrhel je vnitřní stavový automat DW1000. Kupříkladu ze stavu "přijímám" neumí přejít přímo do stavu "vysílám". Nejdříve je potřeba příjem přerušit a přejít do stavu "nic nedělám". Zároveň se taky ve stavu "přijímám" sám od sebe neudrží. Když přijde částečná, či jinak porušená zpráva, přejde DW1000 do stavu "chyba, nic nedělám". Takže je nutné pořád kontrolovat, zda pořád ještě přijímá, a případně ho znovu nahodit. Nebo si nastavit přerušení, aby pokrylo nejen příjem nové platné zprávy, ale i různé chyby, a v rámci obsluhy přerušení pak řešit, jestli přišla zpráva, nebo nastala chyba. A když tak znovu zapnout příjem.

Když už mluvím o přerušení … Na desce je bohužel tlačítko na portu A, pinu 0, zatímco DW1000 IRQ pin je připojený na port B, pin 0. Ztěžuje to život. U procesoru stm32f103 jsou oba připojitelné pouze na ten stejný interrupt, EXTI0. Řešit v jedné obslužné rutině dva možné zdroje přerušení není nic pěkného. Vlastně jsem to ani nezkoušel, takže nevím, jestli to zkombinovat vůbec jde. Alternativou je jeden z těch zdrojů pollovat. Protože v budoucnu asi tlačítko nebude potřeba, polluju to. Později tuhle ošklivou část kódu smažu.

Blíží se čas na nižší aplikační vrstvu: Komunikační protokol z PC přes sériák, komunikace se vzdálenými moduly přes proxy modul a UWB, časem snad včetně výroby mesh sítě. Pro vyšší aplikační vrstvu budou potřeba pokusy s časováním a měřením vzdálenosti.

13. únor 2022 — Pozyx + GPS

Dnes jsem udělal pár rychlých testů na zahradě. Zasloužilo by si to pořádně rozměřit a udělat už pořádné kotvy, ale … raději něco málo než vůbec nic. Graf (z druhého pokusu) mne zaujal:

vzdálenosti pro 3 kotvy a opakovaný okruh

Je na něm pěkně vidět, že ty tři kotvy se nepohybovaly, zatímco None „základna” (notebook s GPS a Pozyxem) vzdálenost je proměnná. Špatná zpáva je, že tam byla ještě čtvrtá kotva a ta při druhém pokusu vůbec vidět není.

set OK 3431
set OK 3455
set OK 3411
ERROR 26662
set OK None

Tak jo, už to vidím … ono již při prvním pokusu vypadlo spojení v čase 150s a pak už se tedy spojení neobnovilo. :-( … moc spolehnutí na to tedy není.

výpadek 4. kotvy v čase 150s

Teď bych měl přidat obázek z JOSM a spočítat pozici pomocí trilaterace, ale asi na to úplně při nedělním večeru nemám sil. Možná zítra. Pro referenci si sem schovám logy gps-pozyx-220213_142833.log a gps-pozyx-220213_143221.log.

16. únor 2022 — No GPS vs. BU01 Single Sided

Ještě o víkendu jsem si říkal, že by mohla být zábava jet s Jirkou „paralelní slalom” a porovnávat, kdo se kam za jakou dobu dostal, ale teď už vím s jistotou, že by to divácky byla hrozná nuda: Jirka by byl v cíli dříve než já se vůbec rozhoupu vyjet.

Tak jsem si konečně rozchodil JOSM (ano, nakonec zbaběle pod Windows) a dupnul data z GPS seriáku:

python -m osgar.logger gps-pozyx-220213_142833.log --stream gps_serial.raw --raw

$GPGSA,A,1,,,,,,,,,,,,,,,*1E $GPRMC,142833.775,V,,,,,,,130222,,*25 $GPGGA,142834.775,,,,,0,00,,,M,0.0,M,,0000*5B $GPGSA,A,1,,,,,,,,,,,,,,,*1E $GPRMC,142834.775,V,,,,,,,130222,,*22 $GPGGA,142835.775,,,,,0,00,,,M,0.0,M,,0000*5A $GPGSA,A,1,,,,,,,,,,,,,,,*1E $GPRMC,142835.775,V,,,,,,,130222,,*23 $GPGGA,142836.775,,,,,0,00,,,M,0.0,M,,0000*59 $GPGSA,A,1,,,,,,,,,,,,,,,*1E $GPGSV,2,1,07,29,54,218,31,02,43,079,27,31,23,084,26,27,28,165,*76 $GPGSV,2,2,07,04,22,045,,24,13,156,,20,01,100,*4F

(zdá se, že ani naformátovat text s dolarama a dvěma mínus mi moc nejde) … no nic, o co jde? Není tam žádná pozíce!

Nechal jsem se naivně ukolébat "statistikou":

python -m osgar.logger gps-pozyx-220213_142833.log
 k           name bytes | count | freq Hz
---------
 0            sys   715 |    6 |   0.0Hz
 1   gps.position   540 |  180 |   1.0Hz
 2 gps_serial.raw 36730 | 5731 |  31.8Hz
 3    pozyx.range 56498 | 3104 |  17.2Hz
 4 pozyx.settings   796 |   10 |   0.1Hz

Total time 0:03:00.231309

ale ona ta `gps.position` je

python -m osgar.logger gps-pozyx-220213_142833.log --stream gps.position

0:00:01.093414 1 [None, None]
0:00:02.105047 1 [None, None]
0:00:03.097231 1 [None, None]
0:00:04.101952 1 [None, None]

… tak teorie, že Pozyx (na plný výkon) nejspíše trošku ovliňuje i příjem GPS. Zároveň se přiznám, že jsem se nijak nesnažil je od sebe extra odstínit.

A teď příspěvky Jirky:

Update 14-02-2022 (Jirka)

Posílám strukturované zprávy, včetně hlavičky podle IEEE 802.15.4. Díky tomu může DW1000 filtrovat příchozí zprávy podle adresáta a nezatěžovat mikroprocesor cizími zprávami.
Prvním uživatelem strukturovaných zpráv je Single-sided Two-way Ranging, aneb cesta tam a zase zpátky. To je nejjednodušší způsob měření vzdálenosti a Decawave ho v uživatelské dokumentaci srdečně nedoporučuje kvůli velké citlivosti na různé nepřesnosti. Dobrá zpráva je, že mi naměřená doba letu signálu roste se vzdáleností mezi moduly. Ne tak dobrá zpráva je, že při malých vzdálenostech, pod 1.5 metru, ten vztah není lineární.

V dalším kroku nejspíš přejdu na Double-Sided Two-way ranging, které je sice složitější, vyžaduje více poslaných zpráv, ale mělo by být o řád až dva přesnější. Pak bude potřeba přijít na to, jak je to s těmi zpožděními signálu při cestě k anténě a z ní, což do naměřené doby letu signálu zanáší konstantní chybu.

Takhle nějak, viz příloha, vypadá odhad vzdálenosti vůči skutečné vzdálenosti. Tohle je hodně optimistický případ, protože to jsou stejná data, na kterých jsem ten převod kalibroval. Přijde mi to dost citlivé na umístění předmětů, včetně mě, kolem antén(y). Něco takového asi způsobovalo i tu nelinearitu včera, kterou dneska nevidím. Po 1.9 m se změní typ povrchu podlahy a celé to skočí.

Single sided two way ranging

Update 16-02-2022 (Jirka)

Doporučované Double-sided Two-way Ranging na krátké vzdálenosti vypadá skoro nerozlišitelně od Single-sided Two-way Ranging. Viz příloha. Střední kvadratická chyba je téměř stejná. Rozdíly v rychlosti hodin obou zařízení, a tedy výhody Double-sided, se ale asi více projeví až při větší vzdálenosti. Budu muset vymyslet, jak testovat na větší vzdálenost a nezmoknout při tom

Double sided two way ranging

17. únor 2022 — Pozyx path vs. BU01 default range

Tak jo, nejlepší je mít nějakou urgentní nezajímavou práci a pak hraní jde úplně samo. A ano, zase jsem to „lehce” ošidil, protože místo pořádné trilaterace je to pouze průběžný update pozice vůči měření k právě přijaté vzdálenosti ke kotvě. Ty chodí v různé časy … a vlastně by to i Kalmanem skončilo, jen tam teď není žádný model pohybu a K=1.

Přehled trasy

Detail cesty

Co mne ale zase znervónilo byl assert na měření vzdálenosti mezi kotvami:

AssertionError: ((0, 0, 0), (12.721, 29.308, 0), 31.94969021759053, 12.417)

Prostě dvě kotvy co mají být cca 32 metrů od sebe „naměříme” 12.4m! No je to na 95% přetečení měření k mezi jinými uzly …

Update 17-02-2022 12:44am (Jirka)

Maximální hlášená vzdálenost v garáži je těsně nad 30 metrů. Až překvapivě se to shoduje s délkou té garáže, resp. toho parkoviště, odhadnuté podle Google maps. Kolem 29 metrů to měření začalo vypadávat. Těžko říct, jestli kvůli vzdálenosti, nebo kvůli rušivým odrazům.

V bytě přes zdi končím po pěti metrech.

Nastavené je to podle příkladu od Decawave. Zkusím si s tím pohrát.

Update 17-02-2022 8:50pm (Jirka)

Na čerstvém povětří: channel=5, prf=64M, prefix_len=128,preamble_code=10: 77 m hlášených, ale podle Google maps to dost možná bylo ke 100 m. Že by se našla ta chybějící třetina rychlosti světla při převodu? Pak bych měl ale při malých vzdálenostech docela velkou chybu. channel=4, prf=64M, prefix_len=128,preamble_code=20: 60 m hlášených, ale nad 50 m už to bylo mizerné, s mnoha výpadky. Podle map 80 m.

Zajímavostí terénního profilu je, že jsem šel přes mělký ďolík. Na protějším svahu byl příjem spolehlivější, než uprostřed dole. Navzdory tomu, že to bylo pořád v přímé viditelnosti. Tj. pro lokalizaci sekačky bude nejvhodnější, bude-li sekačka létat.

Update 17-02-2022 9:54pm (Jirka)

(to bylo po mém dotazu, zda to nechce vyzkoušet na více zařízeních)

Dost vysoko na mém seznamu priorit je kalibrace a ta chybějící třetina rychlosti světla. Dokud neměřím vzdálenost, nechce se mi to komplikovat více zařízeními. Decawave driver obsahuje korekční tabulku a magický offset, které používá pro opravu odhadu. To ale můj problém neřeší. Takže tady ještě nějaká práce zbývá.

Update 17-02-2022 9:54pm (Jirka)

Application Note 11 popisuje, kde se bere ta korekční tabulka. Silnější signál dřív překročí threshold pro detekci jeho přítomnosti. Různí uživatelé interpolují různě nelineárně [ 1, 2 ]. V [ 1 ] taky pozorovali citlivost na náklon antény a na přítomnost vodivých předmětů v jejím okolí.

Zajímavá je taky Application Note 17, která tvrdí, že kvůli odrazům od země může nastat situace, kdy je signál detekovaný do nějaké vzdálenosti, pak kus není a pak zase je.

p.s. k tomu mé pozorování, že ta pozice je taková klikatice je očekávaně, protože se nutně nepohybuji v rovině kotev a tak jsou vzdálenosti větší a budou moji pozici odstrkovat ... mi přijde v kontextu tech šílených kalibrací jen takové drobné placnutí do vody

21. únor 2022 — BU01 korekce korekce

Doplňuji víkendové reporty od Jirky …

Update 19-02-2022 9:01am (Jirka)

Kalibrace na větších vdálenostech s anténou výš nad zemí, i když jen 80 cm místo doporučených 140 cm, vypadá lépe. Viz příloha. Na obrázku je méně bodů, než minule, protože různá měření v jedné vzdálenosti tentokrát nejdříve průměruji a pak až interpoluji.

Strmost převodu z tiků DW1000 na vzdálenost tentokrát odpovídá 97.4 % očekávané rychlosti světla. To je o řád lepší, než minule. A stále o řád horší, než abych byl spokojený. Pořád je to čtvrt metru rozdílu v desetimetrové vzdálenosti.

Jedním možným vysvětlením je ta dříve vysvětlená korekce pro klesající sílu signálu. Jestli čtu kód dobře, je zhruba na úrovni 3 % vzdálenosti. Podle odpovědi na fóru na poměrně detailní dotaz je korekci potřeba odečítat, což po zamyšlení dává smysl, ne přičítat, jak jsem myslel podle názvu funkce. To už by pak sedělo o kus lépe.

Druhým zajímavým prvkem je výrok ve stejné odpovědi: "As was mentioned in the code comment, uus indicates UWB microsecond, not microsecond. In calculation, 1 uus is around 1.025 us." To je jako co, tyhle dvoje různé mikrosekundy, které se liší o 2.5 %, resp. 2.4 % v opačném směru porovnání? Na to se budu muset ještě podívat.

Double sided two-way ranging ver2

Update 19-02-2022 9:58am (Jirka)

Tak ten 1.025 faktor to není. To je něco specifického pro jejich kód a mého se to netýká. Převádí tam zadanou dobu odezvy kotvy z mikrosekund na tiky pomocí *512, jenže 512 tiků je ve skutečnosti trochu více, než jedna mikrosekunda, což pak musí zohlednit. Já všechno zadávám a měřím v ticích a takový převod tam nikde nemám.

V tuhle chvíli mi asi jako možná příčina zbývající chyby zůstávají odrazy signálu od zdí a podlahy a ten pokles síly signálu se vzdáleností, který pak ovlivňuje čas detekce.

Martine, přijde mi to, že ty tomu Pozyxu prostě věříš a že jsi přesnost s metrem v ruce neměřil. Je to tak? Pravda, je, že s metrem v ruce beztak nepoznáš, jestli pro převod nepoužívají nějakou podezřelou rychlost světla, nebo nějakou magickou konstantu či tabulku :-/

Tady bych asi měl připsat nějakou odpověď. Nahrubo jsem to měřil na začátku, ale teď tomu opravdu "slepě věřím", resp. nevěřím a ptám se na vzdálenosti mezi kotvami, které už by měly být konstantní. Měl jsem sem dát grafy od Lilly, které jsem úplně nepochopil, ale třeba někdo jo. A vlastně graf rozdílů k Ground Truth mi přijde čitelnější. Tak tedy skok v čase ..."

Update 19-01-2022 (Lilly, před měsícem)

I didn't experiment with the settings (so as to not have to reconfigure them every reboot). Looking through your blog, I see you got ranges 30-50m, which is pretty good!

I did all my experimenting indoors (much smaller ranges) but one thing I noticed was that there appeared to be different and non-zero biases for different pairs of pozyx anchors:

Another thing I was trying to figure out was whether estimates would be equally good in every direction. Here "UWB inside" was when I had installed the pozyx anchors next to the RPis on the robot (so the body of the robot itself was causing obstructions), and "UWB on top" was after moving the pozyx anchor externally, above the lidar. It looks like there might be some directionality, but hard to say from this one test.

Update 27-01-2022 (Lilly, cca před měsícem)

80m is really promising!

My old notes are somewhat unorderly, but I have these plots of error and true distance. The pozyx devices were around 20cm off the ground, and the hallway width changed from about 2m to about 5m, which probably had a significant impact. I only realized that after these tests, so it's not carefully noted in my measurements.

Update 19-02-2022 8:11pm (Jirka)

Když si tu korekční tabulku od Decawave překreslím do grafu "korekce relativní vůči vzdálenosti" (příloha), je vidět, že ve vzdálenostech 4 až 12 metrů dochází k opravě o 1.8 % až 3.5 %. Zuby v grafu jsou artefakty toho, že je ta korekce po částech konstantní. O 2.6 % nižší rychlost světla v mé lineární interpolaci dělá v tomto rozsahu vzdáleností něco podobného. Z poklesu křivky korekčního grafu se dá tušit, že pro vyšší vzdálenosti vyjde moje lineární interpolace špatně.

korekce relativní vůči vzdálenosti

Asi ještě zkusím, jestli tu korekční tabulku nejde aplikovat na měření z mého modulu. Nebo najít nějakou pěknou výpočetně nenáročnou nelineární aproximaci. Pokud ne, nechám to být, protože vevnitř nad 10 m stejně nenaměřím a ven se s tím zatím nechystám.

Update 19-02-2022 8:11pm (Jirka)

Při započtení korekcí od Decawave pro jejich vývojové moduly se mi interpolační převodní konstanta z času na vzdálenost přiblíží k rychlosti světla na 0.6 %. Dovedl bych si představit, že to při pečlivější kalibraci dokážu ještě srazit tak na polovinu, či třetinu. O řád už to nesrazím, tam někde už narazím na závislost rychlosti světla ve vzduchu na teplotě/tlaku.

Update 21-02-2022 7:53pm (Jirka)

UWB na špejli

Tohle není konečná verze, ale spíš proof-of-concept na uchycení modulu, který nemá díry na šrouby. Zatím to použiju jako stojan pro kalibraci ve volném prostoru.

3. březen 2022 — BU01 měření rychlosti světla

Dnes bych začal zase s víkendovými novinkami od Jirky. Vlastně mi celkem přijde vtipné, že s těma UWB krabičkami si člověk na koleně může měřit rychlost světla … (no teď koukám, že chybí i nějaké dovětky k poslednímu reportu, takže toho bude více).

Update 21-02-2022 9:20pm (Jirka)

Ano, za ideálních podmínek to vypadá dobře. Ale znáš mě … jak to nemám na mikrometry, jsem nesvůj

Je potřeba brát v potaz, že jsem pro tu interpolaci vždycky průměroval dvanáct měření. Jednotlivá měření mi pořád ještě dost skákala. Nicméně včera jsem výrazně zkrátil pevnou dobu odezvy v two-way ranging a vypadá to, ťuk ťuk na dřevo, že poskakování ubylo. Tak uvidíme při příští kalibraci, na špejli, ve volnějším prostoru.

Dost se bojím těch různých efektů, které popisuje Lilly a na které narážím já: Směrovost, citlivost na náklon, citlivost na předměty okolo a především v cestě signálu, snížený výkon u podlahy. Většinu času to bude fungovat v podmínkách hodně neideálních. Proto to chci zpřesnit co nejvíc, aby to i při zvýšené chybě pořád stačilo. Na tu závislost na konkrétní dvojici zařízení, kterou zmiňuje Lilly, jsem teda taky hodně zvědavý.

Update 24-02-2022 12:47pm (Jirka)

Kalibrace i na větší vzdálenosti venku ve volném prostoru, průměrování přes ještě víc měření plus opravená optimalizace interpolačních parametrů rovná se naměřená rychlost světla 0.013 % od udávané (ve vzduchu). Takže nakonec až někde u té hranice závislosti na tlaku, teplotě, vlhkosti a spol. To jsem nečekal. Pro srovnání, ve vzduchu je světlo o 0.03 % pomalejší než ve vakuu (wikipedia).

V dalším kroku zkusím naměřit rozptyl jednotlivých měření, bez průměrování. A pak asi přijde na řadu zkusit, nakolik je to se stejnými parametry přenositelné na jinou dvojici modulů.

Interpolace

Update 27-02-2022 10:34pm (Jirka)

Různé dvojice modulů dávají, asi podle očekávání, trochu jiná měření. Viz příloha. Jedna dvojice odhaduje stejnou vzdálenost na 174 cm, druhá na 179.5 cm. Obě dvojice se směrodatnou odchylkou "šumu" pod tři centimetry.

Když matematicky ne úplně korektně smíchám chybu, kterou vidím v kalibraci převodu z tiků na vzdálenost, směrodatnou odchylku šumu, a těch pět centimetrů rozdílu mezi moduly, čekal bych dvě třetiny měření tak do osmi centimetrů od správné hodnoty a téměř všechna do šestnácti cm. V tomhle odhadu ještě nejsou zahrnuty chyby vzniklé náklonem antény a blízkostí k různým překážkám. To přidá k odhadu dalších pár centimetrů. Tohle platí pro jednotlivá měření. Při prohnání série měření Kalmanem a při kalibraci každé antény zvlášť, jak doporučuje Decawave, zase pár centimetrů zmizí.

Malý robot bez dalších senzorů takhle přesně na nabíječku nejspíš nenajede, ale dveřmi v bytě by naslepo projet mohl. Větší robot by mohl zvládnout mostek v Martinově japonské zahradě, aniž by polekal pádem kapry koi.

Měření pro dva různé páry

p.s. Odvolávám. Příště se musím nejdřív víc zamyslet. Šum jednotlivých měření není 3 cm. To je šum průměrovaných (!) měření. Ten 5cm rozdíl mezi dvěma dvojicemi modulů platí.

Update 03-03-2022 1:17pm (Jirka)

Jenom rychlá poznámka …

Zatímco u dev kitů z Decawave by měla být zpoždění antén změřená v továrně a zapsaná v One Time Programmable paměti, u mých modulů na dané OTP adrese není nic.

Toto se váže k úternímu mailu, že Mouser psal, že už má MDEK1001 na skladě: mouser.com:MDEK1001 … v úterý tam bylo něco přes 300, teď je 216 a než dám push na web, tak už možná nebudou. No nic.

Vidím to tak, že své "novinky" s "dual tagem" si nechám na příště ... (md)

4. březen 2022 — Auta a UWB stereo tag

Téma „k čemu je to vlastně vůbec dobré?” je takové „oblíbené”, resp. se stále vracející. Zhruba před 14 dny jsme se s Jirkou bavili, že BMW používá UWB zámky a jestli by z toho nešlo vymačkat trošku více? Jirka navrhoval, že by bylo fajn se dozvědět, že auto před autem, za kterým jedete, prudce brzdí. Mohlo by tuto informaci poslat a člověk (resp. jeho stroj) by se to dozvěděl dříve než by to uviděl. To by jako aplikace šlo, co říkate? U těch zámků asi nebude extra velký radiový výkon, ale třeba jich tam bude více?

Já cvičně experimentoval s párem — přidělal jsem ho na prkno 115cm dlouhé a to má přijít na zahrádku auta. No a pro první pokusy vlastně auto vůbec není potřeba. Po pravdě ani nevím, jestli ta motivace byl Jirkův nápad nebo jsem chtěl zjistit, jak dobře by šla zjišťovat vedle absolutní pozice i absolutní orientace pouze z UWB tagů, ale to je teď asi už jedno. V praxi je rozhodně užitečné vědět, že to zuřivě brzdící auto je před vámi nebo v sousedním pruhu, což se z jednoho majáku úplně snadno nedozvíte. Jo a ultra rychle zipování by se mi také líbilo. (trávíce včera půl hodiny v koloně způsobené jenom zipem)

Sběrná kotva

Stereo tag

Kotva u růží

Hrál jsem si zase pouze s pěti Pozyx kotvama — dvě na prkně a tři statické. Jako vedlejší efekt je pozorování, že autodetekce statických kotev by asi selhala, protože to jsou dva „pod-grafy”, resp. dvě soustavy, které se vůči sobě pohybují. Začnu s dalším kryptickým obrázkem, který jsem posílal Pozyx supportu:

Ztráta modulu 26727

Co na obrázku vidíme? Minimálně v čase 40s končí fialovo-modré koleje. Prostě v grafu už nejsou žádná měření vůči krabičce s ID 26727. Dále mne tam rozčiluje žlutá tečka na šedivé stopě take okolo 40s … skoro jako by to souviselo?! (za mne je to záměna IDs — prostě ta naměřená vzdálenost patří jinému páru)

Co ještě můžu řící, že počítač aneb „sběrné místo” jsem měl připojen k jedné statické kotvě a ta ID na prkně byla 0x0D7F a 0x0D53. hex(3411), hex(3455) = ('0xd53', '0xd7f') … takže opravdu ta šedivá stopa jsou "tagy" na prkně.

Co je snad dobrá zpráva je, že ostatní kotvy si povídaly celou dobu i když jsem rozhodně nebyl v přímé viditelnosti. Byl jsem zvědav co Z-ová souřadnice mimo rovinu těch třech kotev … příště.

Ještě jeden obrázek, resp. 2D mapka dvou okruhů s prknem/stereo-tagy. Trošku to skáče, což může být Z-ová souřadnice, případně zastínění "operátorem". Ale nahrubo je myslím vidět, že ty dva okruhy jsou cca 1m od sebe:

Stereo-track, dva okruhy

6. březen 2022 — 2+D vs. 2.5D

Dnes nemám nic nového, jen takové „bloumání” nad tím co dále. Přemýšlel jsem nad scénářema, které bych rád realizoval. Vlastně je to klasické dostaň se z místa A na místo B a vyplň ohraničený prostor (sekání, uklízení, sázení stromků, …).

U té cesty si přestavuji, že jako uživatel „vytýčím koridor” pomocí majáčků/kotev, možná bych to jednou projel ručně a zbytek „kyvadlové dopravy” už by jezdil sám. Na robotovi bych nechal dva tagy, to se mi zatím líbí, ale pro trilateraci bych typicky viděl pouze maják před a za sebou. Že by to byla spíše bilaterace? Před naší za naší cesta má ať nepráší … jestli to teď nebude na blacklistu, vlastně na blocklistu. No nic, co jsem to chtěl říci? Že situace, kdy uvidím právě dvě kotvy bude nejběžnější a měl bych se s tím tedy vypořádat.

Sledování cesty definované UWB kotvami

U posekání zahrady nebo osázení mýtiny bych si představoval typicky 4 kotvy po obvodu a zase pár na robotovi/robotech. Vlastně mi přijde UWB technologie v lese daleko rozumnější než DGPS … schválně jestli na podobný projekt ještě znova dojde.

A teď ten název 2+D vs. 2.5D … určitě existuje nějaký termín pro povrchovou lokalizaci vs. 3D lokalizaci v prostoru. Nechť mám pozemního robota a jezdím v terénu, tj. pro každé XY mám pravě jediné Z, na které robot skonči, když ho „pustím”. Ale to není 2.5D, co používá Pozyx. Tam je jedním ze vstupů Z-ová souřadnice (konstantní) a 3D pozice kotev vůči této hladině pozici kompenzují. Pokud ale pojedu přímo od kotvy K(i) na K(i+1) se stereo-tagem, tak bych asi měl být schopen dopočítat i ten Z-ový profil.

To mi připomíná stále ty Jirkovy kapry koi co jsem ještě nekomentoval. … no je to spíše polorozpadlá, cca 1m široká, lávka, po které bych chtěl být schopen spolehlivě navigovat robůtky, třeba s cihlou, taškou nebo barelem na zádech …

8. březen 2022 — Eduro a dosažené BU01 milníky

Dnes jsem jezdil s Edurem na ČZU a bylo to celkem užitečné cvičení. Nejprve „klasika” aneb staré bolesti, na které jsem už s radostí zapomněl:

nepoužívat STOP tlačítko (občas se resetuje APU3 počítač)
odometrie občas „skočí”

Zásilka s MDEK1001 dnes nedorazila a v rozčílení jsem si nakonec na testy vzal jen dvě kotvy na hraní. Na Eduru jsem doinstaloval pypozyx balíček a hned to fungovalo. Drobný problém byl, když jsem kotvu vypnul a zapomněl, že ta stále napájena na robotovi se s tou nově nabootovanou nedomluví (jiný kanál, preambule, atd.).

K věci — zajímavé mi přišlo toto měření:

Eduro jízda 5m

Trošku jsem hacknul "go.py", aby robot jel 2x tam a zpět a výstup byl následující:

Opakovaná jízda 5m

Asi je jasné o co mi jde — v oblasti mezi 3. a 4. metrem je nějaká divnost. Obě kotvy byly po celou dobu jízdy vzájemně viditelné, volný koridor byl minimálně 1m (odhad). Skoro to vypadá, že došlo k nějakému odrazu od zaparkovaného Spidera nebo nějaká interference s WiFi??

Další pokusy na chobě bez překážek bohužel byly k ničemu, protože jsem si nevšiml, že umřela powerbanka u kotvy a následně jsem zapomněl vypnout kotvu na Eduru, takže každá komunikovala na jiném kanálu.

A teď ještě novinky od Jirky …

Update 07-03-2022 11:30pm (Jirka)

Dosáhl jsem několika milníků najednou:

Přidal jsem jednoduché textové rozhraní přes sériák, včetně automatického doplňování příkazů a vyhledávání v historii na straně PC.
K použitému printf() přibylo sscanf(), takže se nevejdu do 64 kB flash a žiju i z těch druhých 64 kB, které oficiálně neexistují. Šlo by to udělat úsporněji, ale chtěl jsem to zkusit i takhle.
Moduly teď "blikají", takže si můžu vypsat seznam viditelných sousedů. Soused, který se nějakou dobu neozval, je ze seznamu odebrán.
Dohromady tak místo broadcastové adresy můžu při měření vzdálenosti měřit vůči konkrétnímu viditelnému sousedovi. Zatím nepodporuji měření, kdy iniciátorem není modul připojený k PC.

"Blikání" je zárodek mesh protokolu - záblesk posílá routovací informace - ale mám toho ještě hodně k rozmyšlení. Statická spolehlivá síť je jednoduchá, ale mizení a roaming modulů to zesložiťují.

20. březen 2022 — BU01 mesh a Babel

Update 11-03-2022 1:49pm (Jirka)

Mesh síť funguje, včetně roamingu, mizení a restartování uzlů. Můžu provádět traceroute na uzel mimo přímý dosah. Klíčové slovo je Babel, i když jsem ten algoritmus pro své účely hodně zjednodušil.

Teď je otázka, jestli budu nějak zobecňovat přeposílání traceroute packetů, nebo to řešit "case by case". Pokud začnu zobecňovat, skoro abych si nastudoval OSI vrstvy.

Update 20-03-2022 9:50am (Jirka)

Upravil jsem mesh protokol, aby fungovalo nejen restartování jednotlivých uzlů, ale i celých podsítí. To se například hodí, když jsou moduly v jedné místnosti napájené z jednoho zdroje. Teď se během pár sekund přisynchronizuje všechno a ne jen krajní uzel připojený do vnějšího světa.

A hlavně, přidal jsem schopnost uzlu A zeptat se uzlu B na jeho vzdálenost k uzlu C. V kombinaci s tou mesh sítí mohou být B a C kdekoli v síti. Jestli jsem to dobře pochopil, u Pozyxu musí být B v přímém rádiovém dosahu A.

Když už teď můžu z modulu připojeného k PC měřit vzdálenost mezi jinými moduly, je asi čas vrátit se ke kalibraci antén a provést ji nejen pro jednu konkrétní dvojici zařízení. Při té příležitosti asi vznikne na straně PC nějaká knihovna ke komunikaci moduly, abych nemusel všechno pořád zadávat a kopírovat ručně. A pak už snad dojde na lokalizaci …

30. březen 2022 — BU01 kalibrační čtverec

Update 29-03-2022 8:30pm (Jirka)

Když umístím moduly do čtverce a změřím vzdálenost mezi všemi dvojicemi, dokážu z toho vypočítat zpoždění na jednotlivých anténách. Podle očekávání vyjde pro každý modul jiné.

Respektive, protože je double-sided two-way ranging lehce asymetrické, dokážu spočítat zvlášť zpoždění na anténě při vysílání a při příjmu. Nicméně pro všech pět modulů, které jsem zatím zkoušel, vychází obě hodnoty, až na drobné odchylky, stejně.

Teď musím přijít na to, jak vyrobit, nejspíš na flash, konfiguraci, abych mohl každý modul nastavit jinak, aniž bych překompilovával kód. Na "write once" paměť v DW1000 se mi moc sahat nechce. Jednak je to "once" a to nemám rád, jednak je to podle dokumentace podivné cvičení, ve kterém dokonce vystupuje vyšší napětí.

Abych mohl stavět velký kalibrační čtverec, začal jsem taky řešit napájení z baterie a plastové krabičky, abych nebyl omezený délkou USB kabelů. Dobrá zpráva je, že když zapojím Li-Ion článek s napětím 3.6 V na napájecí piny pro 5 V, modul funguje. Takže tam možná nemusím přidělávat vlastní step down z 3.6 V na 3.3 V. Připojovat těch 3.6 V, resp. až 4.2 V (?), rovnou na 3.3 V se mi nechce. Ještě musím vyzkoušet chování při téměř vybitém článku, kolem 3 V. Ten step down, který mám, je totiž zároveň step up, takže tady by mohl pomoct. Ale zase bude mít nějaké vlastní ztráty, takže se to celé vybije dřív. No nevím. Asi "keep it simple". Vlastně už při vyšších napětích to bude "zajímavé", protože palubní regulátor z 5 V na 3.3 V na výstupu klesne pod 3.3 V. Ještě je co zkoušet

13. duben 2022 — BU01 zapouzdřeno jest

Update 4/4/22, 10:20 AM (Jirka)

Zapouzdřeno jest. Viz příloha. Teď se můžu pustit do prostorově rozsáhlejších instalací a můžu zkoušet životnost na baterie.

Zapouzdření BU01

Dobrá zpráva: Modul přestane fungovat až někde mezi 3.25 - 3.3 V na 5V napájení, po téměř čtyřech hodinách běhu s 32 měřeními vzdálenosti za sekundu plus režie pro mesh síťování. V tu chvíli je baterie téměř vybitá. Nabíječka do ní pak dostane 670 mAh, při kapacitě baterie 700 mAh. Takže připojovat step down/up converter je zbytečné, déle to stejně nepoběží.

Špatná zpráva: Moduly, které vybijí baterii až do dna, po jejím nabití a opětovném spuštění "blbnou". Opraví to přeflashování kódu. Což mě vede k podezření, že při nízkém napětí se poruší data na flash. Takže se modul až do tak hlubokého stavu vybití dostat nesmí.

Dobrá zpráva: Palubní mikrokontrolér umí monitorovat vlastní napájecí napětí a umí se uspat. Jestli si dobře pamatuju, DW1000 je také možné uspat. Takže příští krok je naprogramovat pud sebezáchovy.

Update 4/6/22, 3:49 PM (Jirka)

Uspání při vybité baterii už funguje. Sledování napětí na mikrokontroléru jsem sice nerozchodil, ale to nevadí, protože DW1000 ho umí také, ve větším rozsahu a s jemnějším rozlišením. Za cenu další SPI komunikace.

Víte, co se stane, když si chcete ověřit sleep kontroléru tím, že ho dáte hned na začátek main()? Šípková Růženka! Takový sebeuspávající se modul se blbě flashuje novým kódem. No nic. Ponaučení pro příště.

Zajímavé debugování bylo na téma "jednou za čas se to zasekne." Když jsem zvýšil četnost komunikace po sériáku, pravděpodobnost záseku vzrostla. Když jsem povypínal okolní moduly, klesla. Abych tu detektivku zkrátil: Pokud seriák na mikrokontroléru nestíhá, nastane "overrun error", nastaví se error flag, zavolá se interrupt, ten zjistí, že nejsou k dispozici žádná data, ukončí se, mikrokontrolér najde nastavený error flag, zavolá interrupt, ehm. A zatímco se ten interrupt handler takhle krásně cyklí, všechno ostatní musí počkat. Na věky věků. Ámen. Mazání toho flagu jeho přečtením následovaným voláním recv() mi taky nepřijde zrovna intuitivní.

Kdyby ode mně někdo tohle chtěl koupit, tak by mi cena nastavená Pozyxem snad ani nepřišla nesmyslná. Pro jednohubku na ochutnávku. Takových "pitomostí", které je potřeba vyřešit, je docela hodně. A to to ještě vlastně ani nedělá nic užitečného. reklama-begin Potřebujete sledovat objekty ve vymezeném prostoru? Můžeme vám pomoct s řešením na míru! Ptejte se Martina, co a jak.reklama-end A tak

20. duben 2022 — BU01 Follow Me

Dal jsem tři moduly na Deedee, malého domácího robota, a zkouším jízdu za čtvrtým modulem, neseným v ruce. Takové malé "follow me". Jenže. Jak je ten robot úzký, pod 30 cm, tak 2d trilaterace protíná téměř soustředné kruhy. Takový výpočet je, jak by řekla dcera, hodně hodňácky citlivý na chybu měření vzdálenosti. Ať už systematickou, nebo nesystematickou. Empiricky vzato, odhad polohy majáčku neseného dva metry rovně před robotem poskakuje o půl metru na každou stranu a dost často trilaterace ani nenajde platné řešení. Ze zjednodušené simulace mi vychází šum s odchylkou do strany (1 sigma) 0.4 m, tj. většina odhadů Y, které je ve skutečnosti 0, někde mezi -1 m a +1m. To je na dvoumetrové vzdálenosti hodně. Robot se podle toho chová: zmateně.

Částečným řešením pro nesystematickou chybu bude co nejvíc zvýšit frekvenci měření a průměrovat polohu majáčku v čase. Dobrý den, pane Kálmáne. Pro vyřešení systematické chyby je užitečný všechen ten předchozí čas investovaný do kalibrace modulů.

Jiným řešením by byl větší robot. Podle simulace alespoň půl metru široký. Metr by byl ještě lepší, ale to už by se robot ani nevešel do dveří. Každopádně nový robot na doma, natož větší, není na pořadu dne.

Další zajímavý zdroj potíží je umístění modulů na robotovi i majáčku nízko nad zemí. V závislosti na výšce majáčku nad zemí vzniká při trilateraci systematická (!) chyba do strany zhruba taky někde mezi 0.3 a 0.5 m. S tou asi nepůjde dělat nic. Jedině už opravdu pevná instalace "kotev" v prostředí, místo na robotovi, a víc krmit dítě, aby rychleji rostlo a mohlo držet majáček výš. Do dvou metrů nad zemí doporučených v dokumentaci dceři ještě "něco málo" zbývá.

26. duben 2022 — BU01 Follow Me obrázky

Update 4/21/22, 7:58 PM (Jirka)

Chtěl jsi obrázek, máš ho mít. Červeně polohy robota, zeleně odhadnuté polohy majáčku. Je to dost smutný pohled.

p.s. No, nejel rovně. Navigoval na poskakující maják a vyhýbal se při tom překážkám. Ta červená trajektorie podle tracking kamery je asi dobře.

Update 4/24/22, 7:41 PM (Jirka)

Ale jo. Když lépe nastavím parametry antén a proženu odhad pozice majáčku Kalmanovým filtrem, něco to dělá.

Lépe to funguje na krátkou vzdálenost tak do tří metrů. A i tak to občas mívá několikasekundové výpadky. Budu se muset podívat, jestli nefunguje měření vzdálenosti, nebo chodí odhady, ze kterých je zmatená trilaterace.

4. květen 2022 —BU01 stavový automat

Update 4/30/22, 10:23 PM (Jirka)

Ach, ten stavový automat. Výpadky při jízdách za majáčkem byly způsobené tím, že chodily nesmyslné vzdálenosti, řádově v kilometrech, a kód na PC je zahazoval. Nesmyslné vzdálenosti chodily, protože mikrokontrolér při měření vzdálenosti často používal časovou známku následující příchozí zprávy. Následující zpráva ale neměla ani přijít, protože DW1000 neměl ani být na příjmu. Jenže byl. Jak to? Protože ze stavu RX (příjem) po přijetí zprávy nejdříve (!) přejde do IDLE (nicnedělání) a až potom (!) ohlásí mikrokontroléru, že přišla zpráva. Na základě předchozí zkušenosti, že DW1000 přechází z RX do IDLE i při chybách při příjmu, mikrokontrolér monitoroval stav DW1000 a při IDLE okamžitě znovu aktivoval příjem. Když se to špatně sešlo, aktivoval příjem před zpracováním příchozí zprávy.

Řešením je aktivovat příjem až po zpracování příchozí zprávy, po ukončení vlastního vysílání a když nastane chyba při příjmu. Jenže ne všechny chyby při příjmu, ukazuje se, přepnou DW1000 z RX do IDLE. Když RX znovu aktivuji při všech chybách příjmu, nastane předchozí problém. Jenom v tom řetězci musí ještě těsně před přijetím zprávy nastat chyba příjmu, čímž se to stává vzácnějším. Takže jsem musel zjistit, co které chyby způsobují. Které přepnou do IDLE a které ne. Dokumentace je bohužel neúplná a, řekl bych, v tomhle bodě dokonce špatně. Takže jsem jsem strávil několik dní čekáním na každý jednotlivý typ chyby příjmu. Moc pěkné cvičení.

Teď už to vypadá, že race condition nenastává (přidal jsem její detekci) a že neplatné vzdálenosti jsou řádově v metrech, což může klidně být nějaký odražený signál. Tak snad to teď, ťuk ťuk na dřevo, bude lepší.

MD: o jaké dvě skupiny zpráv se tedy jedná?

Update 5/1/22, 1:33 PM (Jirka)

Z RX do IDLE přepíná Frame Wait Timeout (RFTO). V RX to zůstane po PHY Header Error (RPHE), CRC Error (RFCE), Sync Loss Error (RFSL), Preamble Timeout (RXPTO), SFD Timeout (SFDT) a Frame rejected due to filtering configuration (ARFE).

Podle dokumentace by to mělo přinejmenším při RXPTO, SFDT a RFTO přejít do IDLE. Ostatní nejsou dokumentované.

Až na ten Frame Wait Timeout se to chová, jako by bylo zapnuté RX-auto-reenable (RXAUTR), což ale nedělám. Asi bych se měl aspoň podívat, jestli tohle je zapnuté, nebo není. Podle dokumentace by default měl být "vypnuto", i když fráze typu "děje se X, pokud není zapnuté RXAUTR, pak Y", vlastně o defaultu, v matematickém smyslu, nic neříkají. Tak odvolávám: "The default value is 0." To zní jednoznačně.

8. leden 2023 — Pozyx digital I/O

Přes vánoční prázdniny jsem měl domácí úkol, který jsem samozřejmě neudělal. :( V rámci příprav na ELROB 2024 Jirka navrhl, že bychom mohli využít další z vlastnosti UWB modulů a to jejich digitálních vstupů a výstupů. Konkrétně po úvodní fázi „follow me” (následuj mne) je třeba robotu „říci”, že má přepnout do módu „vrať se na start” a proč k tomu rovnou nepoužít UWB tag?

Ano, Jirkova motivace je „oprášit všechny technologie co tu tak leží” a tak už samotný follow me by používal jak prastarý lidar (viz Eduro follow me na Floriade 2012, tj. před deseti lety), RGBD kamery a UWB tagy a kotvy. Jirka plánuje (resp. on na rozdíl ode mne úkol přes vánoce samozřejmě udělal, takže bych měl použít už minulý čas) použít své čínské moduly s vlastním kódem, já pak Pozyx.

Pozyx digitální I/O moc popsané nejsou. Našel jsem zmínku v developer tag_v1.5 datasheet.pdf, ale tento dokument není veřejně dostupný, resp. jsem ho nenašel. Tam píšou: A general purpose input/output pin. By default this pin is not configured and it can be used for other purposes. When configured as an output pin, the maximum output voltage is 3.3V (the operating voltage of the board). The pin is 5V tolerant. + tabulka:

GPIO1 Pin 9
GPIO2 Pin 10
GPIO3 Pin 11
GPIO4 Pin 12

Další indicie jsou popisy Pozyx konstant:

# The GPIO modes
    GPIO_DIGITAL_INPUT = 0
    GPIO_PUSH_PULL = 1
    GPIO_OPEN_DRAIN = 1

    ALL_GPIO_MODES = [GPIO_DIGITAL_INPUT, GPIO_PUSH_PULL, GPIO_OPEN_DRAIN]

    # The GPIO pull resistor configuration
    GPIO_NO_PULL = 0
    GPIO_PULL_UP = 1
    GPIO_PULL_DOWN = 2

    ALL_GPIO_PULLS = [GPIO_NO_PULL, GPIO_PULL_UP, GPIO_PULL_DOWN]

a konečně např. funkce setConfigGPIO().

Kód asi nikoho neohromí, ale stejně

>>> import pypozyx
>>> pozyx = pypozyx.PozyxSerial('/dev/ttyACM0')
>>> reg = pypozyx.SingleRegister()
>>> pozyx.getConfigModeGPIO(1, reg)
1

>>> pypozyx.POZYX_SUCCESS
1
>>> pypozyx.POZYX_FAILURE
0
>>> pypozyx.POZYX_TIMEOUT
8

>>> mode = pypozyx.SingleRegister()
>>> pull = pypozyx.SingleRegister()
>>> mode.value = pypozyx.PozyxConstants.GPIO_DIGITAL_INPUT
>>> pull.value = pypozyx.PozyxConstants.GPIO_PULL_UP
>>> pozyx.setConfigGPIO(1, mode, pull, 0x6827)
/home/md/.virtualenvs/osgar/lib/python3.8/site-packages/pypozyx/lib.py:194: UserWarning: setConfigGPIO: 0 wrong GPIO mode
  warn("setConfigGPIO: {} wrong GPIO mode".format(mode[0]))
/home/md/.virtualenvs/osgar/lib/python3.8/site-packages/pypozyx/lib.py:196: UserWarning: setConfigGPIO: 1 wrong GPIO pull
  warn("setConfigGPIO: {} wrong GPIO pull".format(pull[0]))
1
>>> pozyx.setConfigGPIO(1, mode, pull, 0x6827)
1

>>> pozyx.getGPIO(2, reg, 0x6827)
1
>>> reg.value
0
>>> pozyx.getGPIO(1, reg, 0x6827)
1
>>> reg.value
1
>>> 
>>> pozyx.getGPIO(1, reg, 0x6827)
1
>>> reg.value
0
>>> pozyx.getGPIO(1, reg, 0x6827)
1
>>> reg.value
1

trošku omáčky — už jsem dost zapomněl, jak se Pozyx používá, takže na vše je třeba nějaký pomocný "register" (pypozyx.SingleRegister()), co obsahuje vstupně-výstupní hodnoty. Funkce vrací úspěch, selhaní nebo timeout … co je co ale není zřejmé, tak proto ten výpis konstant (1 je úspěch). Pak mne zmátlo, že konfigurace GPIO 1 jako vstup s pull upem generovalo varování?! Ale jak vidíte, tak pouze jednou. Neodolal jsem a vytvořil pull request #78 do jinak dost mrtvého projektu. No a co není úplně vidět, tak po zapnutí pull-upu je vstup 1 (u GPIO 2 jsem to neudělal a tam zůstala 0) a když jsem spojil drátkem pin 9 a GND, tak jsem ze vzdáleného zařízení vyčetl 0. Hurá!

A teď už to jenom celé udělat pořádně …

10. leden 2023 — Look-at-me ver0

Dnešní pokusy s robotem Eduro, třema Pozyx kotvama a jedním tagem bych úplně za úspěšné neprohlásil. Na druhou stranu je to po několika měsících (na Eduru byl posledni git log z Fri Mar 4 19:40:45 2022 +0100), bylo fajn, že balíčky s Pozyxem už tam byly nainstalované a tato část hned fungovala. Co tedy nefungovalo?

Rozhodl jsem se kopirovat Jirkův setup se třema kotvama na robotovi a pouze jedním tagem, který má být sledován. Plán byl rovnostranný trojúhelník s tím, že jsem nejprve zvažoval jeden vrchol dopředu, ale pak mi přišlo snažší jen porovnávat měření z levé a pravé kotvy a zadní si nechat jen jako „zálohu”, pokud by robot byl otočený o 180 stupňů, tak aby měl šanci to vůbec zjistit.

Skript se jmenuje follome_uwb.py, ale fakticky jsem skončil u nějakého Look-at-me, kdy dopřednou rychlost jsem dal 0 a manipuloval pouze s úhlovou rychlostí (a robot se tedy pouze otáčel na místě). „Mrtvou zónu” jsem nechal pro rozdíl levého a pravého měření +/- 5cm a jinak se robot točil rychlostí math.degrees(10) ve směru korekce. A ano, toto byla první chyba — stále se mi vracející. Toto převádí 10 radiánů na stupně, které pak interpretuji jako radiány! Škoda mluvit i když po opravě ten assert naznačuje, jak moc jsem byl mimo.

AssertionError: ([0, 1000], [0, 3282806], datetime.timedelta(microseconds=907468))

Je to hodně citlivé a ten mechanický setup si holt zaslouži revizi. Konstrukci je třeba dát výše, dál od všech železných divnosti, wifi anténa 15cm od UWB krabičky také není ideální. Robot „tančil” i když tag byl položený na židli. Také mi přišlo, že 0 není uprostřed a bude třeba tam doplnit nějaký umělý offset, ale to se pomalu dostáváme k ultra přesné kalibraci co dělal Jirka loni.

to be continued (teď už timeout, než nás vyhodí ze školy) …

24. leden 2023 — Dva na jednoho

Dnes to celkem šlo. Zapojil jsem dvě Pozyx kotvy přímo do počítače a oba moduly současně měřily vzdálenost na společný tag. Co mne trošku překvapilo byly průběžné výsledky. Nejprve statistika měření s dotazem na vstupy a výstupy:

k           name bytes | count | freq Hz
---------
 0            sys   458 |   5 |   0.3Hz
 1    pozyx.range 10251 | 603 |  40.0Hz
 2 pozyx.settings   158 |   2 |   0.1Hz
 3     pozyx.gpio  3618 | 603 |  40.0Hz

OK, tj. cca 40Hz (i když jak jsem později zjistil, z těchto měření může být netriviální zlomek nevalidních).

k           name bytes | count | freq Hz
---------
 0            sys   497 |   5 |   0.5Hz
 1    pozyx.range 10897 | 641 |  62.4Hz
 2 pozyx.settings   158 |   2 |   0.2Hz
 3     pozyx.gpio     0 |   0 |   0.0Hz

Pak jsem GPIO vyhodil z konfigurace a frekvence se zvýšila. Prima, ale to bylo očekávané. A pak přišla to nečekané měření:

k                 name bytes | count | freq Hz
---------–
 0                  sys   996 |   8 |   0.8Hz
 1     pozyx_left.range 15279 | 900 |  85.4Hz
 2  pozyx_left.settings    78 |   1 |   0.1Hz
 3      pozyx_left.gpio     0 |   0 |   0.0Hz
 4    pozyx_right.range 15131 | 893 |  84.7Hz
 5 pozyx_right.settings   158 |   2 |   0.2Hz
 6     pozyx_right.gpio     0 |   0 |   0.0Hz

Zapojil jsem dvě kotvy na dva různé seriové (resp. USB) porty a frekvence ještě více narostla?!

No zakopaný pes, velmi pravděpodobně, je v tom, že vždy i druhá kotva „slyší” komunikaci té první a reportuje to do PC. Tj. jednotlivá měření nejsou pouze vlastní, ale i přeslechy. Tam jsem i viděl neplatné (status pro doRanging() je 0) záznamy.

Asi nejlepší je tabulka se zapojeným followme, kde příkaz s rychlosti (followme.desired_speed) se odešle pouze pro validní měření:

k                   name bytes | count | freq Hz
---------—-
 0                    sys  1504 |   9 |   0.9Hz
 1       pozyx_left.range 15475 | 914 |  86.7Hz
 2    pozyx_left.settings   158 |   2 |   0.2Hz
 3        pozyx_left.gpio     0 |   0 |   0.0Hz
 4      pozyx_right.range 15041 | 893 |  84.7Hz
 5   pozyx_right.settings   158 |   2 |   0.2Hz
 6       pozyx_right.gpio     0 |   0 |   0.0Hz
 7 followme.desired_speed  2090 | 418 |  39.6Hz

… zhruba tedy cca na 20Hz pro každou kotvu.

Zkoušel jsem to pak na Eduru a tam mne zase iritovalo, že záleží jakou kotvu připojím dříve, aby získala port 0. Přimé dotazy jsou s remote_id=None, ale tím se ztrácí ID té přípojené kotvy. Řešení je identifikace na začátku:

>>> pozyx = pypozyx.PozyxSerial('/dev/ttyACM0')
>>> pozyx.getNetworkId(network_id)
1
>>> hex(network_id.id)
'0xd67'

>>> pozyx = pypozyx.PozyxSerial('/dev/ttyACM1')
>>> network_id = pypozyx.NetworkID()
>>> pozyx.getNetworkId(network_id)
1
>>> hex(network_id.id)
'0xd53'

Moc pokusů jsem pak už neudělal, tak alespoň jeden vzorek. Ono většina videí je obráceně, což bych možná z pohledu ELROBu24 zvážil? Prostě na kameře nebude překážet osoba, které robota vede.

p.s. zapomněl jsem napsat, že k řízení jsem používal statistics.median pro okénko posledních deseti měření

31. leden 2023 — followme_uwb ver0

OK, první pokus Eduro sleduje UWB maják … a stejně tak i první (ano, samozřejmá) pozorování:

prohodím-li pravou a levou kotvu, tak je třeba i prohodit směr jízdy dopředu (za směr dozadu)
jezdí-li robot jenom dopředu a člověk je dál za robotem, tak vyrazí úplně špatným směrem
detekci nárazu moc neodkádat

Možná jsem měl neprve zmínit ten primitivní algoritmus co robota řídí:

diff = self.left_range - self.right_range
dist = (self.left_range + self.right_range)/2

speed = 0.0
if dist > 1.2:
    speed = 0.1

angular_speed = math.radians(10)
if abs(diff) < 0.05:
    self.send_speed_cmd(speed, 0.0)
elif diff > 0:
    self.send_speed_cmd(speed, -angular_speed)
else:
    self.send_speed_cmd(speed, angular_speed)

Ano, tak primitivní, žádné počítání průsečíků kružnic … a ano, také teď používám jen dvě kotvy, takže ani nepoznám co je vpředu a co je vzadu.

Chtělo by to nějaké srovnání, tj. asi lidar data (když už je stejně mám). Na druhou stranu lidar vidí nohy a jak je vidět na videu, tak dost zuřivě mávam rukama, abych robota nasměroval. Pak by se měl rychleji pohybovat a rychleji otáčet … ale tím spíše potřebuje collision avoidance.

eduro-followme-dual-uwb-230131_175427.log

Úplně „růžově” ty data nevypadají, ale ještě je tam skrytý ten median na 10 prvků, který to snad trošku srovná…

diff mediánů

No nesrovnal. Pokud jsou kotvy od sebe 25cm, tak rozdíl 80cm je fakt marnost. No nevím, zda mám z toho obrázku úplně radost, ale je asi očekávaný. Další pokus bude s dřevěnou lištou od Standy a tedy se širší základnou.

Eduro se širokýma (80cm) ramenama

A také o trošku zábavnější video. Ještě tam byla meziverze, ale ta byla pomalá/nudná, tak jsem zvedl rychlost:

speed = 0.0
if dist > 1.2:
    speed = min(0.5, 0.1 + (dist - 1.2) * 0.4)

tj. max 0.5m/s, ale s těma širokýma ramenama a pomalou úhlovou rychlostí už to trošku adrenalin je. Jasný další krok je ověření bezpečnosti a jak to teď je, tak si i myslím, že možná ta vysunutá ramena i vidí 270deg lidar … takže možná i uvidí ten okamžik, kdy si je urazí.

Další vylepšení bude třeba u rychlosti korekce směru, resp. omezení rychlosti když je směr pravděpodobně hodně špatně (např. kolmo vlevo).

7. únor 2023 — Bezpečnost především, časem …

Dnešek byl celkem poučný. Opakoval jsem pokus na chodbě, jen jsem vyrazil na druhou stranu a šel poměrně daleko od robota (4 až 5 metrů). A najednou se robot „zbláznil” a málem to napral plnou rychlostí do zdi:

hurá do zdi

No doběhl jsem ho a zastavil těsně před nárazem, ale … proč mi to dělá?!

diff a potenciální náraz v čase 90s

Prostě najednou bylo měření skoro o metr vedle. A ano, myslím si že už jsem minule sliboval, že tam bude třeba dodělat „collision avoidance” a místo toho jsem přidal sběr senzorických dat z tagu (jak to dělat jsem našel tady). To jsem zvědav, jestli tam bude alespoň vidět, že jsem popoběhl?

V každém případě se ptám na stav senzorů jen na jedné straně robota a tak se tam snížil update na cca 10Hz, zatím co na druhé zůstal cca na 30Hz. Nemyslím si, že tím to bylo, ale vyloučit to nemůžu.

Senzorická data tagu vypadají, že odpovídají tabulce registrů:

registers:
    PRESSURE = 0x50  # Pressure data in mPa
    ACCELERATION_X = 0x54  # Accelerometer data (in mg)
    ACCELERATION_Y = 0x56
    ACCELERATION_Z = 0x58
    MAGNETIC_X = 0x5A  # Magnemtometer data
    MAGNETIC_Y = 0x5C
    MAGNETIC_Z = 0x5E
    GYRO_X = 0x60  # Gyroscope data
    GYRO_Y = 0x62
    GYRO_Z = 0x64
    # Euler angles heading (or yaw)  (1 degree = 16 LSB )
    EULER_ANGLE_HEADING = 0x66
    EULER_ANGLE_YAW = 0x66
    EULER_ANGLE_ROLL = 0x68  # Euler angles roll ( 1 degree = 16 LSB )
    EULER_ANGLE_PITCH = 0x6A  # Euler angles pitch ( 1 degree = 16 LSB )
    QUATERNION_W = 0x6C  # Weight of quaternion.
    QUATERNION_X = 0x6E  # x of quaternion
    QUATERNION_Y = 0x70  # y of quaternion
    QUATERNION_Z = 0x72  # z of quaternion
    LINEAR_ACCELERATION_X = 0x74  # Linear acceleration in x-direction
    LINEAR_ACCELERATION_Y = 0x76  # Linear acceleration in y-direction
    LINEAR_ACCELERATION_Z = 0x78  # Linear acceleration in z-direction
    GRAVITY_VECTOR_X = 0x7A  # x-component of gravity vector
    GRAVITY_VECTOR_Y = 0x7C  # y-component of gravity vector
    GRAVITY_VECTOR_Z = 0x7E  # z-component of gravity vector
    TEMPERATURE = 0x80  # Temperature

je to 24 čísel s tím, že první asi opravdu je tlak, poslední teplota (ta odpovídá i startu ve studené hale a pak po třetí minutě návrat) a aktivita před 90s je trošku vidět na „linear acceleration”:

tlak

lineární zrychleni

teplota

14. únor 2023 — Follow me UWB on/off

Na posledním callu Jirka říkal, že ještě před vyhybáním se překážkam nejprve zapojí ten digitální vypínač. A to bych nebyl já, abych se hned neopičil. Tímto tedy děkuji TomášoviP za připájení konektoru a tlačítka — mini demo můžete vidět na mini-videu. Po minulých zkušenostech jsem tam také rovnou přidal test na volný prostor — pokud je překážka blíž jak 1m, tak dovol pouze otáčení. To se ukázalo až moc opatrné, tak půlením intervalu a přeměřováním robota, kdy 50cm je málo, jsme skončili na 70cm.

Další kousek je rychlost otáčení odpovídající chybě natočení robota. Zatím jsem to ignoroval a byl „pyšný” na kód, kdy detekuje tag vlevo/uprostřed/vpravo a neřeší jak moc … tak teď by mne to celkem zajímalo a jestli jsem neudělal chybu ve výpočtu, tak by to mělo být relativně jednoduché. Nechť je robot v pozici (0, 0) a kouká ve směru osy X. Kotvy nechť jsou od sebe daleko B, jako base, a tak jejich pozice je (0, B/2) a (0, -B/2). Pak změřím dvě vzdálenosti L a R. Pro pozici tagu na (x, y) platí, že

L = sqrt(x^2 + (y-B/2)^2)
R = sqrt(x^2 + (y+B/2)^2)

L^2 - R^2 = x^2 + (y-B/2)^2 - x^2 - (y+B/2)^2
L^2 - R^2 = -2*y*B*/2 - 2*y*B*/2 = -2*y*B
y = (R^2 - L^2)/(2*B)

Jak se znám, tak tam bude určitě nějaká „drobná numerická chybička” … hlavně by to nemělo fungovat, když R bude větší než L + B, není-liž pravda?! Nevidím to, tak opravu nechám zkušenému čtenáři.

p.s. jestě jedna drobnost z dnešního testování — ty USB konektory nejsou nějak super spolehlivé a při „ťuknutí” o zeď nejspíše částečně vypadly. Po opětném zapojení se ale detekovaly jako nová zařízení /dev/ttyACM2 a /dev/ttyACM3 … no asi by to chtělo ta USB pravidla.

21. únor 2023 — Pull request #953

Dneska jsem to do limitu (22h) nedal. A ani není žádný velký posun, kterým bych se mohl pochlubit. Jirka už minulou středu říkal, že řeší návrat po trase a problém s průjezdem úzkými dveřmi … no holt se mi pomalu ztrácí za horizontem, sigh.

Tak co je nového? Říkal jsem si, že bych si měl odložit skoro-použitelné UWB follow me demo a tak jsem vytvořil pull request do OSGARa. Tedy nejprve jsem asi 10 minut hledal, jak se sakra pull requesty vytváří, než mi došlo, že nejsem přihlášený a tak tam tlačítko create pull request chybí. V druhém kroku všechny testy na linuxu (Ubuntu 18.04) byly ve stavu canceled s odkazem na github issue, že nebude tato vykopávka dále v CI podporovaná. Po domluvě s Jakubem jsem tedy zvedl na poslední stabilní Ubuntu 22.04, ale tam jsem zase narazil na nepodporovaný Python 3.6. Ten jsem tedy nahradil za Python 3.9 (OSGAR byl testovaný pro linux a windows s Python 3.6, 3.7 a 3.8), ale to zase kolidovalo s prastarými balíčky a … vzdal jsem to a teď je tam pouze Python 3.7 a Python 3.8. TODO. … nějak pomalu tuším, kde jsem propálil trošku toho času …

Vznikla nová větev feature/follow-uwb-path a pokusil jsem se o první „návrat na základnu”. Původní název dnešního zápisu měl být „červená a modrá” (tlačítka na Eduru) nebo „Freudovo nabájení” (když chcete zároveň říci napájení a nabíjení, to byla zase řeč o Spiderovi) … ale to by asi bylo kryptické i pro mne. Jo, tak ty tlačítka červené mi evokuje nahrávání, tj. follow me mode a zbylé modré je tedy follow recorded path. Nejjednodušší varianta, co mne napadla, bylo si průběžně ukládat pose2d, tj. (x, y, heading) do pole a když se měl po trase vrátit domu, tak pokud o 180 stupňů otočený heading robota z první pozice od startu bližší než 20cm byl menší než jeden stupeň, tak jeď jinak se pomalu otáčej, aby rozdíl nahraného a současného (převráceného) headingu byl menší. Možná kód bude srozumitelnější:

elif self.navigation_mode == MODE_FOLLOW_PATH:
            for i, p in enumerate(self.path):
                d = math.hypot(data[0] - p[0], data[1] - p[1]) / 1000.0
                if d < DIST_STEP:
                    break
            if i == 0 or not self.follow_enabled:
                self.send_speed_cmd(0, 0)
            else:
                speed = 0.0
                diff = (data[2] - p[2]) % 36000 - 18000
                if abs(diff) < 100:
                    angular_speed = 0
                    speed = 0.1
                elif diff < 0:
                    angular_speed = math.radians(10)
                else:
                    angular_speed = -math.radians(10)
                self.send_speed_cmd(speed, angular_speed)

V prvním pokusu jsem špatně odhadl singularitu na 360deg, ve druhém zapomněl robota zastavovat, když UWB tlačítko je ve stavu off … a pak to vlastně zhruba dělalo co mělo. … no resp. ne úplně, viz např. poslední video. Vybral jsem ho, že je tam vidět Spider, což byl ještě další bod na seznamu a ten skončil s

File "/home/md/git/osgar/osgar/drivers/spider.py", line 186, in update
    assert False, channel  # unsupported channel
AssertionError: move

takže je jasné, kde budeme navazovat příště. Jinak i u Spidera jsem uvažoval o aplikaci follow me (možná se čtyřma kotvami, každá v jednom rohu … ve spider módu totiž může jet libovolným směrem), ale po dnešních pokusech s oživením bych udělal opak, že ten tag by uživatele chránil a pokud bude blíže jak 3 metry, tak se Spider automaticky zastaví až už jede jakýmkoliv směrem!

Ještě jsem chtěl napsat doplnění k minulému záznamu … teď vím, že mám alespoň dva čtenáře . Ano, ten problém s počítáním pozice tagu nastane, když se pokusím vedle y ještě zjistit x a tam mohu mít odmocninu ze záporného čísla … díky ML za potvrzeni.

p.s. koukám, že ani do 00:00 limitu jsem to nedal :(

p.s.2 ono vlastně není překvapivé, že Eduro do Spidera narazilo, protože algoritmus výše řeže zatáčky o 20cm …

sledování cesty zpět

1. březen 2023 — pypozyx.SingleRegister(size=2)

Včera se toho na poli Pozyxu moc nedělo. TomášP mi vytvořil druhé tlačítko na UWB tag, takže teď můžu (stejně jako Jirka) přepínat vzdáleně mód sledování a návratu po trase. Motivace byla přechod z robota Eduro na Kloubáka K2, který žádný přepínač přímo na robotovi nemá.

Koukal jsem do kódu pypozyx knihovny, protože jsem odmítal kvúli vyčítání druhého bitu posílat extra dotaz. Implementace je taková, že každý GPIO má vlastní registr:

GPIO_1 = 0x85  # Value of the GPIO pin 1
GPIO_2 = 0x86  # Value of the GPIO pin 2
GPIO_3 = 0x87  # Value of the GPIO pin 3
GPIO_4 = 0x88  # Value of the GPIO pin 4

a pro dotaz se pak používá funkce getGPIO(), která je implementovaná následovně:

def getGPIO(self, gpio_num, value, remote_id=None):
    gpio_register = PozyxRegisters.GPIO_1 + gpio_num - 1
    return self.getRead(gpio_register, value, remote_id)

getRead už je pak obecné čtení spojené s komunikací s dalším zařízením pokud remote_id není None. Co s tím? No trik je v tom, že volání toho čtení neobsahuje (tedy na první pohled) informaci, kolik se toho má přečíst?! Toto je dané typem vstupně/výstupní struktury předávané ve value. Zde je použitý SingleRegister, tedy jeden bajt. Ale … registry můžou být i 2 a 4 bajtové, takže pokud změníte defaultní size=1 na 2, tak vyčtete stavy obou pinů najednou. Ano, mají pak třeba hodnotu 257 = 0x101 … ale to už se dá.

Na K2 jsme popozyx doinstalovali, ale vlastně jsem ho už nestihl vyzkoušet. USB by měla být k dispozici, ale vše je „pod kapotou”.

Ještě jsem udělal pár pokusů s Edurem s testem návratu po trase (stejný kód jako minule) a moc slavné to nebylo, tj. dnes bez videa.

kontaktní formulář