czech english

Matty (dvojčata)

stavebnicový robot

Matty je další robot z dílny Martina Lockera s časovou známkou Listopad 2024. Jedná se o čtyřkolového kloubového robota (zatím s pasivním kloubem) s pohonem na všechna čtyři kola. Je to relativně malý robot, ale s velkými plány. Blog update:17/3/2025 — Bugfix PR #1006

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:

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.
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:
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:

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

Včera jsem si vyzvednul a dnes rozbalil balíček:
… a ano, byl to „dárek”, který jsem si opravdu přál
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:
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



11. ledna 2025 — Nastevení serv a kalibrace kloubu

Toto dokumentační foto asi MartinaL moc nepotěší, ale … takto vypadá aktuální stav:
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é …
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áž):
… 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”).
… 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ě!)
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ě.

28. ledna 2025 — Matty M03 a DTC-WS2

Začnu obrázky:
… 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ý:
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:
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í.
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í:
Pak jsem tam objevil ještě toto starší foto:
… 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.
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]
…
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ů):

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
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
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.
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á.