czech english
Robotika.cz » Roboti » Freyja

Freyja

Autor: Jiří Iša (zkompiloval Martin Dlouhý), 2019-08-07
čtyřkola na SubT Challenge

Freyja je čtyřkolový diferenciálně řízený robot, který zatáčí pomocí smyku. Je dílem švýcarského Cogito Teamu, který je jednou z „organizací” zapojených do SubT Challenge Tunnel Circuit. Freyja vznikala 3 měsíce z nuly v jednom člověku a je to až neuvěřitelné, že je to vůbec možné … tak mi přišlo líto to nezdokumentovat! Update: 4/10/2023 — Freyja 2.0, jaro a léto 2023

Tento „článek” je kompilací Jirkových mailových reportů během přípravy na SubT Challenge Tunnel Circuit.
Je třeba vzít v úvahu hodně omezený časový rámec v jakém Freyja vznikala — rozhodnutí padlo po našem návratu ze SubT STIX v Idaho Springs/Colorado v dubnu a do konce června se musela kvalifikovat (předvést autonomní jízdu, funkčnost ručního a vzdáleného EMERGENCY STOP a demonstrovat průjezd úzkým prostorem). Soutěž samotná začíná 15. srpna 2019.

Freyja: Stav k 27.5.

Narodila se nám Freyja. Na lačno (= bez baterek) váží 25 kg. Trochu váhy se dá ubrat přestěhováním elektroniky (pc, stereokamery) do batohu. Obrázek v příloze.
Konstrukce je v zásadě hotová. Pár kousku, jako třeba SICKy, zatím chybí, ale pro homologaci nejsou potřeba. Kabeláž hotová není. Akumulátor tam, jak jsem napsal o pár řádků výš, zatím taky není.
Dobrá zpráva je, že mě unese, když si na ni kleknu. Špatná zpráva je, že kombinace těchhle pneumatik a zatáčení smykem je nedomyšlena. Takže teď se kromě roztrhnutí obávám i neschopnosti zatočit. Skoro mám chuť přestavět ji na kloubáka, ale to v časovém limitu nehrozí A taky by se mi pak nevešla do jednoho zavazadla.
IMG_20190527_211726882.jpg
IMG_20190527_211726882.jpg
Zbyněk: Wow. To je dost impozantní! Už jsi posílal link, kde jsi kupoval ta kola?
PavelS: Trochu je škoda, že se nikdo nepoučil z Robíka - o problémech smykového podvozku (potažmo v terénu) jsem psal a mluvil opravdu hodně a většina ze zúčastněných to viděla v akci...
"Nikdo nepoučil" je trochu extrémní vyjádření. Na vědomí jsem to vzal a mimo jiné jsou ta kola kupříkladu kulatější v příčném směru, než má Robík. Taky je to silově celé dost výrazně naddimenzované. Odtud obava o roztrhnutí. A dost me mrzí, že kvůli přepravním rozměrům nemůže být širší, aby měl lepší zatáčecí páku.
Na druhou stranu, navzdory opakovaným a opakovaným snahám zjistit kde přesně je s tím problém jsem se dozvěděl tak nanejvýš "smykový podvozek bych už znovu nestavěl", "Eduro nemělo šanci kvuli casteru" a co všechno jiného by kdo nestavěl. Naposledy včera: "Kloubáka bych (zatím) neduplikoval". To všechno můžu zkombinovat s vlastními zkušenostmi, jako třeba že odpružit těžkého robota není žádná sranda. Za takových okolností mám dvě možnosti: Nedělat nic, nebo odhadnout některou variantu jako možná funkční a možná pro mě vyrobitelnou.
Koneckonců, jezdil jsem jak s mobem, tak se šestikolkou, takže nějaké zkušenosti se smykovými roboty mám. Což je i důvod, proč moji předchozí roboti smykoví nebyli Na nedělat nic ještě dojít může, pokud se ukáže, že jsem to odhadl špatně. Jsem ochotný s tím žít.
MD: well, to vypadá na flame ... :(
Za mne byl zatím Robík jediný robot, který dával i složitější terén - a to za mne stále platí. Dále je to stále "nejjednodušší konstrukce" - i toho bych se držel. Volili ho ostatní, tak to "úplně mimo" není (CMU, Colorado/Husky, teď CRAS). Koloubák ani po měsíci ještě nejede rovně a je dost možné, že skončí v "Robík konfiguraci".
Takže s hláškou PavlaS nesouhlasím (slyšeli jsme to mnohokrát, ale v praxi to dával lépe) ... a pravě důvod jak jsem ho viděl bych ho i znova volil (viz mé starší maily o odkupu). Až někdo bude mít alternativní platformu, která do 30dni bude zvládat terén v tunelu, tak rád změním názor.
Tak já zatím hlavně nemám problém. Jen obavy. Takže těžko problém popisovat. Obava je, že v tuhle chvíli je přilnavost k hladké podlaze taková, že se smyk nebude konat. Vůbec.
Jako nejlepší popis by mi asi přišlo video z pohledu vnějšího pozorovatele v situaci, kdy má robot potíže. Jinak, jak říkáš, je to dost vágní popis.
Vzrušenější debata, kdy si navzájem ujasníme názory a výchozí předpoklady, mi přijde užitečná. Kdybychom na sebe měli jen křičet a dokola opakovat to samé, pak by neměla smysl.
V tuhle chvíli to vidím dost podobně jako Martin — byla to jediná platforma, která něco dělala a je nenulová šance, že udělá znovu. A když jezdí tanky, nějak to jít musí. Na vynálezy nemam čas. Zároveň ale jsem si vědom rizik, a proto všechnu svoji účast podmiňuju "ujede metr a zatočí". Pokud tohle zvládne, dá i to ostatní. Pokud ne, byla sranda a mám spoustu nových dílu na staré roboty.

Freyja: Stav k 2.6.

Světla svítí, kola se točí (ve vzduchu). Tj. základní kabeláž je hotova. Včetně červeného tlačítka.
Plán na další týden: Jízda na joystick. A pokud by se opravdu hodně poštěstilo, tak i remote stop.
MD: Až robota dáš na zem (což už jsi touto dobou určitě udělal), nechceš rovnou natočit video se STOP tlačítkem - ručním a vzdáleným (Ctrl+C)? Pokud to dáš jako unlisted"" něco jako "Robotika/Freyja SubT Tunnel Circuit Qualification", tak to mužu rovnou přeposlat??""
Kdepak, na zem ještě nešla. Na to je moc hrozivá Ale joydrive ve vzduchu, zda se, funguje. Trošku zklamání je, že ty odrive kontrolery nedokážu (zatím) krmit rychleji, než na 20 Hz. Příjemné překvapeni je, že odrive (už?) podporuje watchdog, takže, až to připrogramuju na své straně, motory by mely po CTRL+C přestat udržovat rychlost.
Stačí pro homologaci opravdu červené tlačítko a ctrl+c, nebo je potřeba i remote e-stop? A vycházím z předpokladu, že joydrive je přípustná homologační jízda, protože některé týmy koneckonců v tunelu nic jiného nedělají. Je potřeba předstírat detekci objektu?
MD: předstírat detekci objektu určitě ne (to už jsme dělali na STIX a to jim stačí per team). e-stop je diskutabilní, ale budu jim tvrdit, že používáme jednotný SW a jestli na tom trvají, tak ať ti pošlou dva vzorky do Švýcar (předpokládám, že pak na tom trvat nebudou). Co jsme se bavili se Zbyňkem, tak ten kill switch je asi primárně pro drony a "nebezpečné potvory" a Freyja zatím vypadá přátelsky. Ale čím dříve jim ty "homologační videa" pošlu, tím dříve budu mít jistotu, že s E-stopem nebudou prudit.

Freyja - první videa (milnik dosazen) (7/6/2019)

Martine, řekni si, jestli ti to první video vyhovuje.
To druhé ukazuje, že na čtyřkolce bude asi lepší pro odometrii brát minimum z enkoderu na jedné straně místo jejich průměru. Takhle je to zjevné, ale v kódu to mám blbě. PID ještě není naladěné, proudový limit je nízký, takže nějaké velké závěry bych z toho druhého videa nedělal.
Viděl jsem ji i zatočit (milník dosažen!), ale kvůli gumovému a slabému PID to byl buď hodně neřízený prosmyk na té hladké podlaze, nebo opravdu široký oblouk venku na asfaltu. Taky jsem se na ni metr svezl
MD: :) super! Jen mne v první chvíli vylekala ta tma v půlce prvního videa - prostě po stisknuti STOP tlačítka to i zhasne. Snad pochopí, že ten druhy STOP je na klávesnici (možná jsi to komentoval, já to pouštěl bez zvuku). Pošlu a uvidíme
Dobry nápad, ale nekomentoval. "Remote stop" je v popisku pod videem.
PavelJ: Pěkný :-) Akorát se mi pořád nechce věřit, že je to jen 45cm široké. Působí to na mne mohutněji.
46 cm je možná přesnější číslo. Ale skoro půlka z toho jsou kola, takže proto to vypadá trochu divočeji. To tělo je úzké. 24 cm by mohla být šířka mobose bez jednoho kola, ne?
S lepším PID nastavením to vypadá lépe: https://youtu.be/ROKj9tp_a94
A teď jdu zpevňovat upevněni kol, protože povolilo :-/
Možná je tohle můj "low week". Paradoxně kvůli tomu, že vývoj probíhá přesně podle očekávání :-) Žádné zázraky se nekonají.

Freyja: Stav k 16.6.

Dobrá zpráva: Funguje jízda na joystick s logováním kamer a stereo kamer.
Špatná zprava: Většinou.
Zdroj potíží: USB na limitu svých schopností, nebo těsně za ním. Každé zařízení si vyžádá nějakou přenosovou rychlost, každé z nich udělá horní odhad a napříč přes čtyři kamery, dvě stereo kamery, joystick a wifi se to nasčítá. USB pak odmítá spolupracovat. Kayeton kamery, které si pro jistotu vyžádají maximum možné to jistí :-/
Současné řešení: Vlastní fork uvcvideo ovladače, který pro kamery s komprimovaným streamem (tj. kayeton) udělá vlastní odhad přenášených dat, kdežto pro nekomprimovaný stream (stereo Mynt Eye) respektuje přání zařízení. Taky jsem různě pozpřehazoval joystick a wifi, aby byly na jiných USB "bus".
Budoucí riziko: Ještě jsem nezapojil IMU a Frantův LoRa modul. Ty taky přijdou do USB :-/
Možná budoucí řešení:
  • Zahodit USB wifi a Wifi router místo současného hloupého ethernetoveho switche. Nebo se pokusit rozchodit virtuálni wifi na integrovaném wifi modulu.
  • Možná by tam šlo přihodit RaspberryPI nebo něco jako USB proxy, ale moc se mi do toho nechce. Mimo jiné proto, že by se to nevešlo.
  • Snížit FPS kamer ze současných 30 Hz na 15 Hz.
Další nešťastný důsledek: Vypadá to, že USB řadič se zahřeje natolik, že i CPU o kousek vedle nadává na vysokou teplotu. A to jsem ještě nezačal nic počítat.
Zajímavá zpráva: Loguju cca 3 GB za minutu. Tj. na disku mam místo na dvě hodiny jízdy a ani na největší disk v domácnosti se nevejde nijak oslnivě mnoho.
MD: řekl bych "no tě bůh!" (i když poslední dobou všichni okolo říkají "Zdař Bůh"! :).
3GB/min - máš nějaký "- - stat", kolik co žere? To je předpokládám ještě bez lidaru, right? 4 kamery, 2 stereo kamery?
Výborná otázka. Přidal jsem do logvieweru výpis statistiky. Vypadá to, že cca půlka dat je hloubková mapa z přední stereo kamery. Takže až začnu počítat zadní, jsem v háji. Dobrá zpráva na tom ale je, že hloubka jsou v tuhle chvíli metry ve floatech. Když z toho udělam centimetry nebo milimetry a protobuf to uloží jako varinty, mělo by se to výrazně srazit (zhruba na půlku?). Za cenu náročnější serializace/deserializace. Špatná zpráva je, že zadní stereo kamera má skoro dvakrát vyšší framerate. Možná to bude chtít podívat se po kompresních algoritmech pro hloubkové mapy.
Čtyřminutový log (hm, takže venku je to víc jak 3 GB / min):
.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 kB
               joystick.joystick:  683.92 kB
             logging.LoggingInfo:     385 B
               loginfo2text.text:     313 B
           selfcheck.LoggingInfo:     393 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 to je zippovany výstup? nebo nebalené pole? (u Huskyho ani ve virtuálu jsem neměl šanci přežít s hloubkovou mapou bez pakování :( dík m. p.s. předpokládám, že zatím loguješ vše svým kódem, right?
Nebalené pole. Od zipu bych si moc nesliboval. Tobě něco dělal? Ale pokud bych uložil inty a každá další hodnota by byla uložena jako rozdíl od hodnoty předchozí, pak by to vzhledem k vysoké "plochosti" mohlo dát velmi malý počet různých hodnot a jejich kombinaci a to už by zipovat jít mohlo.
Ano, jsou to všechno protocol buffery.
Zbyněk: To jo, ale balit to zipem není dobrý nápad CPU-wise. Jediný, co působil jakž takž rozumně bylo lz4. Leda že bys měl nějaké zbytečné jádro, co by se tomu mohlo věnovat.
$ 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
Při gzip -9.
Takže prostor ke zlepšení by tam byl. Co se cpu týče, možná stojí za úvahu logovat nekomprimované a zabalit to až po jízdě.
A centimetrové inty jsou ještě o kus menší.
$ 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: Stav k 24.6.

Zbrzdila mě rýmička. A dcera zvrací. A do toho se nám v práci tenhle týden sjíždí ~60 lidi z celého světa :-/
Teoreticky mám naprogramovanou jízdu pomocí pravé zdi podle stereokamery, což by pro homologaci mělo stačit.
Prakticky to ještě nejelo víc než tři metry na balkóně, kde není moc místa. Doma má stereokamera potíže s ne moc texturovanou hodně odrazivou podlahou. Je možné, že na testovacím polygonu (tj. ve sklepě) to bude podobné.
MD: máš zapojený lidar? Nebylo by to jednodušší? OSGAR na Freyje asi ještě není right?
Lidar zapojený není a do konce týdne nebude. A ano, pro jízdu podél zdi by to bylo jednodušší.

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 further videos, but nothing else is required for bringing your platforms to the Tunnel Circuit and competing with them.
Martine, můžeš jim poslat nové video?
@"piece of cake": Ani nevíš, jak jsem pak ztuhnul, když se následující zatáčka ne a ne podařit

Freyja: Stav k 30.6.

Kvalifikováno.
S čím byly potíže:
  • Pořád ještě někdy (mám podezření, že při vysoké teplotě cpu nebo motherboardu), nenaběhne odrive a v logu je oblíbené "not enough bandwidth". Homologační videa jsem natáčel s vypnutými kamerami.
  • I když všechno naběhne (včetně těch kamer), je řízení jakési zpomalené.
  • Jízda kolem rohu bez mapy, když stereo kamera kouká jenom dopředu a onen roh nevidí.
  • Kompas občas najednou poskoci o ~šedesát stupňů. Zatím natvrdo takové skoky ignoruju, ale především by neměly nastat.
Co fungovalo pěkně:
  • Freyja zatáčení urve a už ji při tom nepovoluje uchyceni kol.
Co mám v planu další týden:
  • V zásadě nic. Mám tu na návštěvě rodiče.
  • Když najdu nějaký čas, budu buď řešit některé ze známých problémů, nebo budu zkoumat vhodnost Jupyter Notebooku jako prostředí pro operátora. Python běžící na robotovi a přístupný z prohlížeče mi zní jako zajímavá možnost.

Freyja: Stav k 7.7.

  • SICKy jsou připevněny a zapojeny. Lezou z nich (trochu divná) data.
  • Přidal jsem 1.8 TB harddisk naformátovaný jako ZFS s kompresi. Mělo by se na něj vejít odhadem 2.5 - 3.5 TB logu (~ 13 - 19 hodin jízdy).
Překonané potíže:
  • SSD je tak rychlé, že to ZFS driver při ukladáni plnou parou vpřed nedá, crashne a vezme s sebou systém. Žádné chybové hlášky, kterých bych se dokázal chytit :-/ Řešením bylo přepnout ZFS z asynchronního do synchronního režimu. Nevím proč. Šťastný odhad.
  • Umím změnit IP adresu SICKa i bez magických aplikaci.
Nepřekonané potíže:
  • SICK Sopas a App Studio pro Linux nejsou a na Wine neběží. Bez App Studia tu jejich Luu podle všeho patřičně nezabalím. Tohle řešit nehodlám.
  • Naměřené vzdálenosti obou SICKu nějak divně "pulzuji". Celé to kmitá o zhruba deset cm tam a zpátky. Pokud jste to někdy viděli, dejte vědet, co s tím.
Zbývá dodělat:
  • Kritický hw: Dálkové vypínání.
  • Nekritický hw:
  • Lepší boční krabičky se zapínáním/vypínáním, s nouzovým stop tlačítkem, kamerami a žárovičkami. Kamery a žárovičky teď trčí a při nošení a bočních nárazech do zdi trpí.
  • Lora. Ačkoli pořád nevím, co s ni jako budeme dělat.
  • Sw: Všechno.
  • Organizace: Letenky, baterky do USA.
Franta: Re LoRa - samozřejmě by se to dalo použít k nějaké koordinované exploraci (swarm, atd), ale i bez toho by roboti měli minimálně broadcastovat nalezené artefakty a pozici, rychlost, orientaci, atd a být na příjmu pro instrukce typu zastav, otoč se, vrať se na základnu, jed' na koordináty x/y apod.
Zni to pěkně. A má to pár slabých míst:
  • Nemáme detekci artefaktů a u pozice teprve domlouváme systém souřadnic, takže není *co* hlásit.
  • Krabičky jsou u tebe, takže je nikdo neintegruje ani do Osgara, ani do Erra. Takže není *odkud* hlásit.
  • Nemáme Control Station a nikdo ji neprogramuje. Takže není *kam* hlásit.
  • Operátor neví stav robota, takže *proc* by ho volal zpátky?
  • *Kdo* to naprogramuje a *kdy*?
Pokud pro tyhle věci existuje plán, sem s ním. Nevím o něm. Pokud je to dlouhodobá vize, ne krátkodobý plán pro Pittsburgh, tak je to ovšem jiná. Pak bych ale celou tuhle diskuzi s radosti odložil za Pittsburgh a vyřešil to pořádně.

Freyja umí projet dvěřmi (otevřenými )

Spousta senzorů ještě není integrována, takže velká část toho debugovacího videa je černá. Až začnu používat imu, měl bych dokázat stereo detekci překážek protáhnout níž k podlaze. Taky jsem vytáhl boční žárovičky, protože zavazí. Chci je předělat. A přední a zadní svícení budu muset odstínit, aby nesvítilo přímo do kamer.
Nicméně čekal jsem, ze můj první velký robot, který úspěšně projede dveřmi, bude Clementine. S Edurem jsem to, pokud si dobře pamatuju, taky nedal.
PS: Zavřenými dveřmi možna taky umí projet

Freyja: Stav k 14.7.

Dodělávám hw:
  • Předělal jsem uchyceni bočních kamer a světla, aby nepřečnívaly a nepřišly tak snadno k úrazu.
  • Vyměnil jsem plastové distanční šrouby za kovové, kterým by se měl méně ochotně strhnout závit.
  • Vyměnil jsem desku pod PC, které jsem během středečního callu v přímém přenosu ulomil roh.
Začínám dávat dohromady sw:
  • Lokální plánovač nad daty z lidaru (bez nahromaděné mapy) funguje. Viz. video "průjezd dveřmi" v týdnu. Stereo kamery do něj ještě integrované nejsou.
  • Globalní lokalizace: Mám prototyp s rbpf-slam z MRTP https://www.mrpt.org/. Je to v zásadě to, co zkoušel Pavel, ale bez ROSu. Opět zatím jen nad daty z lidaru. A (zatím?) jen ve 2D. Dost mě irituje, že ani po deseti letech pokusů nedokážu napsat vlastní SLAM na míru :-( A že jsem to (zase) zkoušel
Doháním organizační věci:
  • Koupil jsem letenky.
SLAM
SLAM

Freyja: Stav k 21.7. (The Good, The Bad, The Ugly)

The Good:
  • SLAM je integrovaný. Když se robotovi chce, není to moc daleko a měsíc je v úplňku, vrátí se robot zpátky na start.
The Bad:
  • Odepsal jsem jeden SICK. Freyja *umí* vyjet na zeď, ale pak se tam *neudrží* :-/
The Ugly:
  • Z nějakého důvodu se mi zpožďuje poměrně triviální zpracovaní lidaru a hromadí se mi tam zprávy. Mimo jízdu to dá skoro 10k zprav za sekundu, během jízdy se mi tam občas hromadí data z 15 FPS lidaru. První podezření je na cpu throttling způsobený přehřátím. Po zvýšení rychlosti otáček větráku se to už nepřehřívá, ale problém trvá. Další podezřelý je linuxovy plánovač úloh, ale podle "perf sched record" a spol. je všechno v pohodě a nic se nepřiškrcuje. Podle htop je zátěž někde kolem 20% cpu. Hromadění zpráv má za následek jízdu podle až několik sekund starých dat, takže se robot ztrácí a bourá do zdi. Když na ni zrovna nevyjede. Začínám být krapet bezradný.
Tak zpozděné zpracování se mi podařilo vztáhnout k vysoké teplotě na CPU (>=75 C). Potíž je, že se to takhle zahřeje, i když robota nechám otevřeného. Takže ventilací to není. Asi nainstaluju nádrže s tekutým dusíkem.
MD: 1) jak vyčítáš data ze SICKu - máš tam sleep aby to vycházelo na 15Hz, nebo jsi ho donutil, ať "stremuje"? Defaultně ti totiž klidně pošle 10x stále stejná data
Ano, streamuju. A jestli si špatně nepamatuju, nebo jsem neměřil něco jiného, chodit by to mělo na těch 15 Hz. Můžu zkontrolovat … potvrzuji.
MD: 2) plánuješ nahradit dočasně TIM svým starším (TIM551?)
Ano, je tam teď našroubovaný můj TIM551 a pečlivě běhám za robotem
Takového strýčka bych potřeboval dřiv A byly doby, ne tak dávno, kdy bych takový e-mail napsat neuměl :-/
Kontext pro ostatní: Náhradní SICK je na cestě.
Problém byl/je poměrně komplikovaný. Trošku jak letecká katastrofa.
1) Počítač se přehřívá a CPU reaguje zpomalením.
2) Po zpomalení běhu jednotlivých modulů se mi tam začínají hromadit na různých místech zprávy a nedorazí do cíle.
3) Na ODrive je puštěný watchdog. Když delší dobu nedorazí řídicí signál, zastaví.
4) Z takového zastavení se dá dostat jenom rebootem ODrive, o což se kód pokouší.
5) Reboot ODrive trvá zhruba 20 sekund. (Nějak dlouho trvá domluva mezi odrivem a PC na aktuálním protokolu a nastaveni všech možných RPC.)
6) V případě rebootu po watchdogu se mi podařilo nešťastně blokující volání dokud se ODrive neprobudí.
7) Během toho blokujícího volání se hromadily další zprávy.
8) Po restartu odrive tam mohlo byt nabufferovanych řídicích pokynů tak na půl minuty.
9) Hodně zmatených pokynů, protože byly vypočítané na základě různě navzájem opožděných měření.
10) Takže se je odrive jal vykonávati. Hurá na zeď.
11) To 20s stání spolu s výpisem na konzoli, že už se vrátil domů, byl důvod, proč jsem nestihl zareagovat dost rychle.
PavelS: Ahoj, jenom takový nápad - heatpipe chlazeni by mohlo byt účinější a radiátor můžeš případně umístit mimo chlazený prostor.
Byl jsem zvědavý, jestli na tu blbost (nebo ne?) někdo zareaguje Díky.
Nejdřív zkusím softwarová řešení, jako třeba v BIOSU nastavit výkon větráku na maximum bezpodmínečně a možná vypnout Turbo Boost. Intel Pstate, linuxové řízení frekvence cpu, vykazuje navíc všechny znaky software od Intelu: Je to piece of crap. Zkusím ho různě přenastavit, nebo vypnout&nahradit. Například když přepnu z "performance" na "ondemand", trvá to o *hodně* dýl než to cpu zase přehřeju. "ondemand" ho mnohem agresivněji drží těsně pod 75 C, aniž by se mi něco začalo zasekávat. Tj. s "performance" mam horší výkon. Ehm.
Zbyněk: Jo zkusit vypnout Turbo Boost mě taky napadlo. Až přijdeš na to, jak se to dělá, tak to sem určitě napiš. Svého času jsem hledal case, který je vlastně chladič a s procesorem je spojený pomocí heatpipe - tj. v podstatě to, co navrhoval Pavel. V práci jsem kdysi takový velký chladič na procesor použil na chlazení teplé strany peltiera a určitě uchladil přes 100W.

Freyja: Stav k 28.7. (Vlastni SLAM 5/5)

Vyřešeny potíže s přehříváním: Vypnul jsem v BIOSU Turbo Boost cpu, zapnul větráky na 100 %, výrazně subsampluju data z kayetoních kamer. RBPF SLAM se a) chvílemi zamyslel na moc dlouho, b) ztrácel. ICP SLAM se chová lépe, ale taky se ztrácí. Nakonec jsem napsal s pomoci Ceresu vlastní hybrid mezi ICP a GraphSLAMem s využitím triku z ORB SLAMu (keyframes). Je psaný více s ohledem na real-time požadavky a na míru konkrétní úloze (informace o otočení je absolutní, protože kompas; "uzavření smyčky" je většinou speciální případ, protože robot se vrací domů zpátky po vlastních stopách). Mělo by být snazší integrovat detekované april tagy.
Výsledkem je pět úspěšných návratů domu v pěti po sobě jdoucích jízdách. Z těch pěti jízd se třikrát vrátil zadkem napřed, dvakrát předkem. Ať žijí symetričtí roboti.
Taky se robot za skoro dvě hodiny testovaní jen dvakrát lehce dotkl zdi. Žádné divočejší nárazy. To je novinka. Tj. (zatím) stíhá zpracovat data.
Dorazil nový SICK, ale ještě jezdím se svým vlastním starým.
Obavy do budoucna: i) Zbývá málo času a hodně práce. ii) Nemám reprezentativní testovací prostredí. iii) SLAM nemusí se stejnými parametry fungovat v jiném prostředí. iv) Zjevně operuju poblíž hranice teplotního/výpočetního/io výkonu. A to mi ještě chybí jedno stereo vidění a detekce artefaktů ze čtyř kamer. v) V úzkém prostoru nebo v rohu se dokáže Freyja dostat do situace, kdy se bojí jet jak dopředu, tak dozadu.
MD: :) gratuluji :) 5/5 zni dost dobře! Ze zrad co mne napadá - mužeš tam zakomponovat šikmou plochu/nájezd do garáže? Co překážky, které nevidí lidar? Není nad pravidelný Freyja update --- ten mne vždy vrátí naději :)
No, na mě padal splín v týdnu. PC se přehřívalo a odolávalo mým zásahům, zprávy se opoždovaly a nebylo to jak debugovat, SLAM nefungoval a já jsem věděl, že funkční vlastní se mi navzdory mnoha pokusům nikdy napsat nepodařilo.
A máš pravdu, "je to 2D" mělo být na seznamu rizik. Kromě celé šikmé plochy bych tam zařadil i "robot najel jedním kolem na cihlu". Něco takového jsem měl na mysli v "nemám reprezentativní testovací prostor." Nicméně šikmý nájezd do garáže mám. To bych zkusit mohl.

Freyja: Stav k 4.8.

  • Freyja dostala kufr (viz příloha).
  • Spouštění/vypínání programu a zobrazování a přehráváni dat v prohlížeči víceméně funguje (viz další příloha). Zatím není hotové řízení z prohlížeče. Lesson learned: ipywidgets nepodporují mouse click na obrázek, ipyevents jsem nějak nerozchodil.
  • Upadl připájený napájecí drát k jednomu z enkoderů. Je na tak nešťastném místě, že oprava je náročná. Opraveno jest. Hrozně nerad bych aby se něco podobného stalo na "soutěži".
  • Zase se mi někde zdržují zprávy. Aktualní hlavni kandidát je samotné Erro, a to v místě, kde ukladám logy. Když neflushuju za každou zprávou, zlepší se to. Když neloguju vůbec, zlepší se to ještě víc. Nelogovat na komprimovaný souborový systém taky pomáhá. Ještě jsem ale nenašel řešení, které by fungovalo úplně k mé spokojenosti.

Freyja 2.0, jaro a léto 2023

Freyja 2.0
Freyja 2.0
Od posledních fotek z před čtyř let Freyja povyrostla. Přední a zadní stereo kamery MyntEye od nyní již zkrachovalého výrobce nahradily Oak-D Pro W od Luxonis. Ty obsahují integrované RGB senzory, takže přední a zadní samostatné RGB kamery už nejsou potřeba a šly pryč. Boční RGB kamery byly nahrazeny za stereo kamery OAK-D SR. Freyja tím sice ztratila schopnost vnímání barev do stran, ale získala schopnost vnímat hloubku a tím detekovat překážky vedle sebe.
Místo dvou jednořádkových lidarů od SICku s úhlem pohledu 270 stupňů vozí jeden čtyřřádkový lidar VanJee s výhledem do všech stran.
Přibyly dva Ardusimple simpleRTK3B GNSS moduly a korekční RTK základnová stanice pro určení pozice, směru a náklonu, protože Freyja se po SubT, kde se projela v uhelném dole, chystá na ELROB, kde bude jezdit tam a zpět v úloze robotické muly.
Pro úvodní fázi, kdy má robot následovat vůdčí osobu, zužitkuji UWB BU01.
Co zůstalo z verze 1.0 jsou ODrive kontroléry motorů, i když nyní s podstatně lépe nastavenými proudovými limity, takže kontroléry jsou méně lekavé a nepřestávají řídit při sebemenším náznaku vyššího proudu. Jejich USB jsem opticky odizoloval, protože na jiných robotech na SubT vznikaly zemní smyčky, které ODrivy odpalovaly.
Robota nadále řídí Intel NUC. Kromě hallových senzorů v motorech v kolech zůstal asi jediný senzor, a to CMPS14, což je magnetický kompas kombinovaný s gyroskopem a akcelerometrem.
S novým upevněním kol vytištěným z PLA s uhlíkovými vlákny se Freyja směle vrhá do nových off-road dobrodružství.
kontaktní formulář