Aby zde nebylo tak hobby-roboticky mrtvo, jak někteří kritizují ve svých příspěvcích, zkusím sem nepravidelně podle možností psát něco jako stavební deník zaznamenávající stavbu a provoz outdoor robota.
Hned na začátku předesílám, že se zde NEVYSKYTUJE ani jedno Arduino a už vůbec ŽǍDNÝ ROS !!!
Loni v prosinci (2021) jsem si postavil nový stroj jménem Rocky pro letošní sezónu (což v mém případě znamená Robotem rovně, Roboorienteering a Robotour).
Různé události způsobily, že jsem letos po dlouhé době musel vynechat probuzení po zimním spánku, což je Robotem rovně. Roboorienteering byl zrušen pro nezájem a s Robotour se teprve uvidí.
Bez ohledu na to všechno se pokusím robota dovést do soutěženíschopného stavu.
Podvozek je typu rocker používaný na marsovských roverech. Pro zjednodušení má poháněná pouze dvě kola a druhá dvojice je nahrazena castory.
Moc to nefuguje, protože tento typ podvozku opravdu musí mít hnaná všechna kola. Na mírně zpevněném povrchu (Robotem rovně, Robotour) ale snad vyhoví.
Video z jízdy řízené joystickem je ke zhlédnutí zde:
Technická data:
- Pohon zajišťují kola z terénního hoverboardu
- Driver pohonu Odrive https://docs.odriverobotics.com/v/lates ... board.html
- Řídící počítač Odroid H2 (Intel J4115 (14nm) with 4MiB Cache, up to 2.5Ghz(Single Thread) or 2.3Ghz(Multi Thread)) + 16GB RAM + 512GB SSD
- Bohužel už jej nevyrábí. https://www.hardkernel.com/shop/odroid-h2plus/
- Depth kamera Intel Realsense D455 https://www.intelrealsense.com/depth-camera-d455/
- Tracking kamera Intel Realsense T265 https://www.intelrealsense.com/tracking-camera-t265/
- GPS https://www.gnss.store/neo-m9n-gnss-mod ... lt137.html
Data získávaná ze senzorů:
- RGB bitmapa z D455
- Hloubková (depth) bitmapa z D455
- 6 DOF póza z T265 (https://en.wikipedia.org/wiki/Six_degrees_of_freedom)
- 3D Absolutní poloha (lokalizace) z T265
- Geolokace z GPS
Vhodným zpracováním dat ze senzorů je k dispozici:
- Úplná 3D lokalizace a orientace robota
- Point cloud vypočítaný z hloubkové bitmapy (https://en.wikipedia.org/wiki/Point_cloud)
- RGB obraz viděný robotem
- Geolokace z GPS
Je velmi užitečné ukládat surová data ze senzorů do logovacích souborů, takže i tato funkce je implemetována.
Ke správnému robotovi patří také softwarová základna pro přehrávání logů, dálkové ovládání a monitoring a testování různých částí řídícího software.
Pro tyto účely jsem si napsal "basestation", což lze vidět například zde, kde je část mapy jeskyně Výpustek v Moravském krasu mapované mým předchozím robotem:
Abych mohl ověřit správnost zpracování dat a pracovat na nové implementaci mapy okolí robota, zkusil jsem využít známý robotický simulátor Gazebo v poslední verzi (11) před zaplevelením ROSem (lze vygooglit: from Gazebo to Ignition).
Hardware robota mám vždy zabalený do objektu s názvem "platform", který má unifikované rozhraní, které vystavuje data ze senzorů popsaná v odstavci výše. Stačilo tedy přepsat tento objekt tak, aby poskytoval data získaná se světa v simulátoru.
Teď je tedy možné snadno pracovat i v noci nebo ve špatném počasí.
Výsledek integrace dat ze senzorů robota v Gazebu je k vidění zde:
Pokračování příště.
Stavební deník
Stavební deník
Soldering fumes make you stronger!
Re: Stavební deník
Hezký článek, držím palce a mám dotaz. Dá se v tom Gazebu nějak simulovat zdroj akustického signálu. Například formou druhého robata (auta se spalovacím motorem). A jak výkonné PC pro aspoň trochu smysluplnou simulaci.
Re: Stavební deník
Fyzikální enginy jsem nezkoumal a jakožto pouhý uživatel to ani nemám v úmyslu.
Dokumentace zmiňuje následující:
"Currently Gazebo supports 4 physics engines: ode, bullet, simbody and dart. The default physics engine is ode."
Je tedy potřeba zjistit, co daný engine simuluje.
Můj kvalifikovaný odhad je, že pouze mechanické interakce (tření, gravitace, kolize...) plus vítr a atmosférický tlak, protože jsou běžně simulovány drony.
V každém případě je potřeba vzít v úvahu že data ze simulátoru jsou velmi nerealistická a systém se dá použít pouze k ověření konceptu a odladění základních věcí, jak jsem popsal v úvodu.
Dokumentace zmiňuje následující:
"Currently Gazebo supports 4 physics engines: ode, bullet, simbody and dart. The default physics engine is ode."
Je tedy potřeba zjistit, co daný engine simuluje.
Můj kvalifikovaný odhad je, že pouze mechanické interakce (tření, gravitace, kolize...) plus vítr a atmosférický tlak, protože jsou běžně simulovány drony.
V každém případě je potřeba vzít v úvahu že data ze simulátoru jsou velmi nerealistická a systém se dá použít pouze k ověření konceptu a odladění základních věcí, jak jsem popsal v úvodu.
Soldering fumes make you stronger!
Re: Stavební deník
Díky, že jsi si našel čas se s námi podělit o svůj výtvor a už se moc těším na pokračování
"all your robots are belong to us"
robodoupe.cz
robodoupe.cz
Re: Stavební deník
Zapoměl jsem napsat, že pro simulování stačí libovolné "hráčské" PC s dedikovanou grafikou.
Je to z toho důvodu, že čas v simulátoru běží nezávisle na reálném čase. Přesněji, simulátor se snaží o realtime, ale pokud se mu nedaří, zpomalí a zobrazí příslušný časový skluz.
Pracuju na předpotopním 4x Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz s hyperthreadingem, takže se tváří jako 8 jader + 16 GB RAM + GeForce GTX980
Gazebo s velkým světem (viz video) vytíží procesor na cca 20% a s mojí neoptimalizovanou "basestation" to vytáhne na cca 40%.
Vizualizace je samozřejmě na bedrech grafické karty.
Je to z toho důvodu, že čas v simulátoru běží nezávisle na reálném čase. Přesněji, simulátor se snaží o realtime, ale pokud se mu nedaří, zpomalí a zobrazí příslušný časový skluz.
Pracuju na předpotopním 4x Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz s hyperthreadingem, takže se tváří jako 8 jader + 16 GB RAM + GeForce GTX980
Gazebo s velkým světem (viz video) vytíží procesor na cca 20% a s mojí neoptimalizovanou "basestation" to vytáhne na cca 40%.
Vizualizace je samozřejmě na bedrech grafické karty.
Soldering fumes make you stronger!
Re: Stavební deník
Je takové vedro, že se dá tak akorát programovat, takže dneska ještě jeden update.
Mapa.
Bez nějaké mapy okolí to opravdu nejde. Minimálně je nutné použít alespoň reaktivní vyhýbání překážkám, ale to nestačí pro navigaci.
Robotem rovně se dá vyhrát s magnetometrem a sonarem, lépe však s nějakým druhem laserového scanneru.
Potom lze držet azimut k cíli a pro vyhýbání se překážkám místo přesné mapy použít něco jako VFH:
- https://en.wikipedia.org/wiki/Vector_Field_Histogram
- https://www.researchgate.net/figure/Col ... _265229091
Roboorienteering se dá vyhrát s podobným vybavením doplněným o GPS pro jízdu po waypointech a RGB kameru pro detekci oranžového kužele.
Pro Robotour stačí stejné vybavení, jenom se například RGB obraz využije pro detekci cesty, ale bez mapy se zde už neobejdeme.
Ideální je mít prostorovou nebo alespoň elevační mapu, která nám popíše okolí s dostatečnou úrovní detailů.
V poslední reinkarnaci mého robota (Skiddy) jsem se snažil použít pravděpodobnostní voxelovou mapu Octomap:
https://courses.cs.washington.edu/cours ... 13auro.pdf
Ukázalo se však, že aktualizace mapy novými daty je pomalá a se zvětšující se mapou nevhodná pro použití v reálném čase.
Později jsem narazil na odvozeninu zvanou UFOmap:
https://github.com/UnknownFreeOccupied/ufomap
Díky lehce změněné datové struktuře je update mapy novými daty výrazně rychlejší.
Po delší pauze se tedy k této mapě vracím a zusím ji použít na skutečném robotovi.
Zatím je hotová reimplementace pro simulovaného robota.
Je to ověření konceptu, takže jsou zde jisté ošklivosti:
- Všechno běží v jednom vlákně a protože vložení point cloudu do větší mapy zabere čas v řádu vyšších desítek milisekund, pěkně to celé trhá. Je nezbythé, aby update mapy probíhal ve zvláštním vlákně a nenarušoval řízení robota.
- Neřeším zde úplně přesnou synchronizaci vkládaného point cloudu a pozice robota, takže se 3D data při rychlejším otáčení (yaw) pěkně rozmáznou.
Jinak jsem ale spokojen a pustím se do psaní vícevláknové verze.
Výsledek je k vidění zde:
Pokračování příště.
Mapa.
Bez nějaké mapy okolí to opravdu nejde. Minimálně je nutné použít alespoň reaktivní vyhýbání překážkám, ale to nestačí pro navigaci.
Robotem rovně se dá vyhrát s magnetometrem a sonarem, lépe však s nějakým druhem laserového scanneru.
Potom lze držet azimut k cíli a pro vyhýbání se překážkám místo přesné mapy použít něco jako VFH:
- https://en.wikipedia.org/wiki/Vector_Field_Histogram
- https://www.researchgate.net/figure/Col ... _265229091
Roboorienteering se dá vyhrát s podobným vybavením doplněným o GPS pro jízdu po waypointech a RGB kameru pro detekci oranžového kužele.
Pro Robotour stačí stejné vybavení, jenom se například RGB obraz využije pro detekci cesty, ale bez mapy se zde už neobejdeme.
Ideální je mít prostorovou nebo alespoň elevační mapu, která nám popíše okolí s dostatečnou úrovní detailů.
V poslední reinkarnaci mého robota (Skiddy) jsem se snažil použít pravděpodobnostní voxelovou mapu Octomap:
https://courses.cs.washington.edu/cours ... 13auro.pdf
Ukázalo se však, že aktualizace mapy novými daty je pomalá a se zvětšující se mapou nevhodná pro použití v reálném čase.
Později jsem narazil na odvozeninu zvanou UFOmap:
https://github.com/UnknownFreeOccupied/ufomap
Díky lehce změněné datové struktuře je update mapy novými daty výrazně rychlejší.
Po delší pauze se tedy k této mapě vracím a zusím ji použít na skutečném robotovi.
Zatím je hotová reimplementace pro simulovaného robota.
Je to ověření konceptu, takže jsou zde jisté ošklivosti:
- Všechno běží v jednom vlákně a protože vložení point cloudu do větší mapy zabere čas v řádu vyšších desítek milisekund, pěkně to celé trhá. Je nezbythé, aby update mapy probíhal ve zvláštním vlákně a nenarušoval řízení robota.
- Neřeším zde úplně přesnou synchronizaci vkládaného point cloudu a pozice robota, takže se 3D data při rychlejším otáčení (yaw) pěkně rozmáznou.
Jinak jsem ale spokojen a pustím se do psaní vícevláknové verze.
Výsledek je k vidění zde:
Pokračování příště.
Soldering fumes make you stronger!
Re: Stavební deník
Takže mapa už vesele běží v samostatném vlákně a proto se robot může pohybovat plynule bez trhání.
Vkládání pointcloudu do voxelmapy probíhá tak rychle, jak stíhá procesor. Na robotovi to samozřejmě bude pomalejší, ale to lze ošetřit omezením maximální rychlosti pohybu a zejména předzpracováním dat v pointcloudu (decimace, filtrace...), což zde neřeším.
Voxelmapu jsem změnil na barevnou verzi, což vypadá na pohled hezky, ale není to cílem.
Barva voxelu jsou totiž 3 byte a ty se dají využít různě bez nutnosti upravovat poměrně složitý zdrojový kód voxelmapy.
Velmi krátké video s ukázkou výše popsaného je k vidění zde:
Pokračování příště.
Vkládání pointcloudu do voxelmapy probíhá tak rychle, jak stíhá procesor. Na robotovi to samozřejmě bude pomalejší, ale to lze ošetřit omezením maximální rychlosti pohybu a zejména předzpracováním dat v pointcloudu (decimace, filtrace...), což zde neřeším.
Voxelmapu jsem změnil na barevnou verzi, což vypadá na pohled hezky, ale není to cílem.
Barva voxelu jsou totiž 3 byte a ty se dají využít různě bez nutnosti upravovat poměrně složitý zdrojový kód voxelmapy.
Velmi krátké video s ukázkou výše popsaného je k vidění zde:
Pokračování příště.
Soldering fumes make you stronger!