TurtleBot

Z DCEwiki
Skočit na navigaci Skočit na vyhledávání
Autorem obsahu této stránky, který je stále průběžně aktualizován, je Aleš Kapica, administrátor laboratorní disklessové infrastruktury na DCE a DC.
Veškerá fakta ohledně vývoje, uvedená v textu, jsou podložena dokumentací v rámci této wiki, jeho e-mailovou korespondencí a veřejně dohledatelnými internetovými zdroji, na které odkazuje v textu.

Výrobcem těchto zařízení, je Open Source Robotics Foundation, Inc.. První kusy které se ocitly na Karlově náměstí v roce 2018, byly zakoupeny jako stavebnice a poprvé použity při výuce v zimním semestru univerzitního roku 2018/2019 k praktickému cvičení v rámci předmětu B3M33MKR: Mobile and and Collective Robotics, kde s nimi pracoval Gaël Écorchard s Karlem Košnarem.

Po technické stránce měl tyhle stroje na starosti Petr Novák a z počátku se na nich používala předinstalovaná linuxová distribuce Ubuntu, pro kterou se softwarový balík utilit pro práci se senzory, distribuovaný pod názvem ROS vyvíjí.[1] Šlo tedy o Non-Diskless instalaci, se všemi neduhy a problémy spojenými s administrací instalovaného systému, proto jsem byl již v říjnu 2018 osloven, je-li technicky možné, aby na TurtleBotech běžel stejný operační systém, jako na ostatních laboratorních strojích, tedy Full-Diskless Debian.

Co je TurtleBot?

TurtleBot, je robotické zařízení, jeho „tělem” a zároveň nosičem senzorů je robotický vysavač a „mozkem” mikropočítač, kterým je v případě našich strojů Intel NUC.[2] Ten sice má ethernetový port, přes který by mohl Intel NIC komunikovat po síti, ale TurtleBot je v prvé řadě autonomní zařízení, které se využívá coby nosič nejrůznějších senzorů s nimiž se studenti učí pracovat, a na základě zpracovaných nasnímaných dat řídí jeho pohyb v prostoru.

Pokud by se měl TurtleBot pohybovat prostorem napojený do sítě ethernetovým kabelem, byl by to stejný anachronismus jako potápěč 19. století spojený vzduchovou hadicí s pramicí na hladině, v době dýchacích potápěčských přístrojů s uzavřeným okruhem. Proto komunikují TurtleBoty primárně přes Wi-Fi. Jenže Full-Diskless si jádro s ramdiskem stahuje přes PXE a to je čistě ethernetová technologie, kterou Wi-Fi nepodporuje. Takže mým úkolem bylo najít co nejlepší řešení.

Konverze Non-Diskless systému TurtleBota na Half-Diskless

TurtleBot se neliší liší od normálního laboratorního PC jen tím, že komunikuje jen přes Wi-FI, ale také tím, že nemá připojenou myš s klávesnicí. Intel NUC má k dispozici jen omezený počet USB portů a ty jsou – až na jeden – obsazeny připojenými senzory. A na ten jeden port, co je k dispozici je připojen dotykový diplej, takže ten, kdo pracuje s TurtleBotem má dvě možnosti jak s ním pracovat:

  1. Vzdáleně přes SSH
  2. Nebo přes připojený dotykový displej – jenže ten nemusí vždy fungovat, proto by měl každý student vědět, jak s TurtleBotem pracovat přes SSH (viz níže)
Zde je potřeba zmínit, že naše TurtleBoty, přestože jsou všechny z řady verze 2, nejsou hardwarově identické jelikož první várku stavebnic z roku 2018 následovala další, která dorazila počátkem roku 2019. Stroje, které měly mít Intel NUC s výkonnějším procesorem, větším množstvím RAM a rychlejším NVME diskem měly rozšířit naší „flotilu” TurtleBotů, jenže dodávka nedošla kompletní – chyběly mechanické díly, nezbytné k instalaci platformy pro senzory. A tak Petr Novák, který měl za úkol stroje sestavit, nic dalšího nerozbaloval a sháněl chybějící díly.

To se vleklo až do září 2019 a tak až těsně před začátkem semestru – při finální kompletaci – zjistil, že je poškozená i většina dodaných dotykových displejů, takže sestavené stroje stále nebylo možné použít. Pokračovalo se tedy ve výuce na strojích z první várky a Petr Novák měl za úkol do dalšího semestru (který měl začít od poloviny února 2020) displeje vyreklamovat. Jenže z toho nebylo z toho nic, protože koncem roku Petr Novák odešel na CIIRC aniž by tu záležitost dořešil.

A tak až jeho nástupce, Bedřich Himmel, vyřešil tuhle situaci po vzájemné dohodě všech zainteresovaných, tím že použil displeje ze starších, výkonostně slabších TurtleBotů (číslo 3 až 7), které byly odstaveny. Vše co se dalo použít, se použilo, takže byste neměli být překvapeni, až u některého TurtleBota zjistíte, že nereaguje na dotyk (TurtleXX), nebo že během zavádění nevypisuje na displeji žádný výpis (Turtle13).

Podpora zavádění přes PXE

Řešení veškerých problémů Non-Diskless systému na stroji, co nemá k dispozici klávesnici, a je bez funkčního síťového připojení, je komplikované. Proto bylo nutné v prvé řadě každého TurtleBota přenastavit tak, aby přednostně zaváděl disklessový operační systém přes PXE a teprve pak zavaděč, jehož menu se zobrazuje na dotykovém displeji. Ke každému stroji tedy bylo nutné připojit dočasně klávesnici a přenastavit UEFI.

  1. Každý Intel NUC měl z výroby zapnutý legacy boot, který bylo potřeba vypnout – teprve po uložení změny a restartu TurtleBota nabídlo lokální UEFI, možnost zavádění přes UEFI PXE.
  2. Pak teprve bylo možné v konfiguraci povypínat všechny ostatní možnosti zavádění a změnit pořadí zavádění následujícím způsobem:
    1. Na první místo dát UEFI PXE Boot…
    2. …a teprve za touhle volbou ponechat zavedení lokálního zavaděče GRUB verze 2, který do té doby spouštěl lokálně instalované Ubuntu.
Upozornění Je velmi důležité bylo v menu Boot Configuration vypnout parametr Unlimited Boot to Network Attempts. Bez toho se totiž Intel NUC neustále pokoušel zavádět systém jenom přes PXE a na lokální boot vůbec nedošlo!

Diskless přes Wi-Fi

A pak přišel na řadu další krok, který měl zajistit, aby bylo možné TurtleBota nastartovat jako Diskless i bez připojené klávesnice a ethernetové konektivity.

Výhodné v tuto chvíli bylo, že v rámci disklessové infrastruktry DC již od roku 2016 jelo několik virtuálních strojů v režimu Half-Diskless, takže bylo nutné dořešit pouze to, jak zajistit, nahození Wi-Fi sítě v prostředí ramdisku. Half-Diskless se totiž liší od Full-Disklessu tím, že jádro s ramdiskem nezavádí zavaděč poskytovaný on-line z DHCP serveru, ale lokálně instalovaná verze zavaděče. Takže se o nahození sítě místo PXE postará samo jádro po úspěšném nahození Wi-Fi a systém dál pokračuje v zavádění systému expertovaného přes NFS server. A zavedený systém, podobně jako Full-Diskless už dál s lokálním blokovým zařízením pracovat nemusí.

V takovém stavu byly TurtleBoty během zimního semestru roku 2018. První testy zcela jasně ukázaly, že propustnost připojení přes Wi-Fi nestačí a je potřeba najít technologické řešení, které srazí potřebu síťové komunikace ze strany operačního systému spuštěného TurtleBota na minimum.

Bylo nutné vyčkat na období mezi semestry, kdy neprobíhá výuka. Během výuky totiž nelze měnit systém pod rukama. V minulosti bylo tohle období zárukou, že se dá v laboratořích nerušeně pracovat na údržbě laboratorního systému, aniž by tam někdo přišel něco dělat. Byl to čas vyhrazený na údržbu, který je už dnes (2024) minulostí, protože se v rámci tohoto období propůjčují katederní laboratoře pro jiné akce, co bezprostředně nesouvisejí s výukou, ale zvyšují renomé katedry.


Omezující faktory u TurtleBotů

Problematická ethernetová kabeláž
Dál vyšlo najevo, že laboratoř E:130, kde se nalézá pracoviště s TurtleBoty, má dlouhodobě ethernetovou kabeláž ve velmi špatném stavu. Bohužel z nejrůznějších důvodů na rekonstrukci ještě nedošlo. Je nutné se o tom zmínit, jelikož jde o výrazně limitující faktor, a každý kdo s TurtleBotem pracuje by měl znát jeho slabiny, aby mohl zvolit optimální řešení a zbytečným problémům se vyhnout.
Internetové připojení si lze představit jako vodovodní trubku, kterou za určitý čas proteče jen omezené množství vody. A celá laboratoř E:130 – včetně Wi-Fi AP, je připojená přes jeden 1 GBitový port. Tedy trubku, přes kterou za 1 sekundu proteče maximálně 128MB. A jeden Full-Diskless, ještě dříve než se na něj vůbec někdo přihlásí, si po sítu z NFS serveru pokaždé stáhne zhruba 300 MB dat.
Jen pro představu. V roce 2018 bylo na tuhle trubku „navěšeno” 8 laboratorních desktopů, tři laboratorní desktopy pro robotické ruky a jedno WiFi AP, přes které se připojovalo 8 TurtleBotů.
Aby to vše najelo ve Full-Diskless módu, muselo přes tuhle trubku projet cca 5,7 GB. Což by za normálních okolností zabralo asi 44 sekund. Jenže kvalita kabeláže v E:130 je tak špatná, že u delších drátů klesala rychlost datového přenosů až na úroveň 100 MBitové sítě, která má propustnost pouhých 11,5MB/s. A to už bylo pod hranicí použitelnosti. A jako naschvál, na jednom takovém drátu „viselo” AP, které mělo zajistit konektivitu pro 8 TurtleBotů.
Propustnost Wi-Fi
U 2,7GHz Wi-Fi je teoretická maximální propustnost kolem 56Mbit/s, tedy ještě horší než u 100 Mb sítě. Data se tahají rychlostí cca 2MB/s, o kteráou se ale dělí mezi všechny stroje připojené k AP – každý studentský notebook, se kterým se musí TurtleBoty dělit o Wi-Fi tak situaci zhoršuje. A pokud s nimi pracují studenti, co NECHÁPOU, že i data jejich uživatelských profilů se tahají přes tu samou Wi-Fi, jsou-li přihlášeni svým uživatelským jménem, může úroveň použitelnosti TurtleBotů velice rychle spadnout na nulu. Studenti s musí být vědomi faktu, že TurtleBoty žádnou jinou alternativu pro síťové připojení nemají, proto by se měli pokud možno vyvarovat chyb, které k takovému stavu vedou.

Nejhorší jsou zdánlivě banální operace, jako např. automatické doplňování příkazů na příkazové řádce, kdy se zdánlivě žádná data nepřenáší. Je to dáno tím, že mezi NFS serverem a klientem probíhá komunikace kterou tvoří mraky malých paketů. Ty sice neobsahují žádná data, ale mají svou režii. A jak se říká: „Tisíckrát nic by umlátilo slona.” Operace, která u stroje připojeného etherenetovým kabelem proběhne prakticky ihned, dokáže konektivitu TurtleBota dokonale zasekat i na několik desítek sekund. Záleží jen na tom, kolik zbytečného „smetí” má uživatel ve svém profilu, sdíleném přes NFS. I tak bylo nutné najít řešení, jak minimalizovat objem dat přenášených po síti během práce s TurtleBotem.

Řešení, která pomohla situaci zlepšit...

  1. V prvé řadě to bylo přemění Wi-Fi AP na protilehlou stěnu, kde byla zásuvka připojená ke switchi kratším drátem, což zlepšilo propustnost ethernetového připojené Wi-Fi AP.
  2. A TurtleBoty byly přepracovány na kešovaný Half-Diskless, který si na lokálním blokovém zařízení průběžně ukládal použité soubory pro budoucí opakované použití.

Lokální kešování přes mcachefs

Bylo efektivní, ale mělo dost podstatnou vadu – bylo závislé na aplikaci mcachefs. Ta sice dělala přesně to, co jsme po ní chtěli – ukládala do lokální keše vše, nač uživatel sáhnul – ale nepodporovala atomické změny a nekontrolovala symlinky.

  1. To, že jela přes FUSE, bylo to nejmenší. Pomalejší natahování souborů se dá přežít. Bohatě se to vyvážilo zlepšením výkonu při opakovaném spouštění stejných aplikací po restartu.
  2. Mnohem vážnější bylo to, že neměla podporu pro automické změny. A pokud došlo u souboru na straně NFS serveru na nějakou změnu, projevila se až po restartu.
  3. A velice vážným problémem bylo to, že nekontrolovala nakešované symlinky, protože systemd, na který jsme přešli od verze Bookworm, je na symlincích založen.

Nicméně během zimního semestru roku 2019 se zdálo, že jde o uspokojivé řešení[3] a v únoru 2020, během přípravy na další semestr nikdo netušil, že o pouhý měsíc později bude prezenční výuka na rok a půl přerušena.

Vynucená pauza od března 2020 do října 2021

Krátce na to, v březnu 2020, vypukla koronavirová panika. Využil jsem nucené přestávky k tomu, abych přizpůsobil disklessový systém pro vzdálený přístup. Ale na TurtleBoty padal více než rok a půl prach, přestože byly připraveny k provozu. Jenže to by vyžadovalo pracovní sílu, trvale přítomnou v laboratoři, která by na základě pokynů od studentů zajištovala fyzické přemístění TurtleBota od nabíječky do pracovního pole sledovaného on-line kamerou, přes kterou by mohli vzdáleně pracující studenti sledovat co TurtleBot dělá.

Při aktualizaci kešovaných souborů na TurtleBotech se v plné nahotě projevily nedostatky mcachefs. Měl jsem představu, jak to udělat jinak a lépe. Jenže jsme naskořili do prezenční výuky tak rychle, že na to nebyl žádný čas a jednodušší bylo kešování opět vypnout, takže se TurtleBoty opět provozovaly jako Full-Diskless přes Wi-Fi – se všemi již zmíněnými nedostatky.

Studentské notebooky připojené na laboratorní Wi-Fi

Dříve nepředstaovaly problém, protože jen málokterý student vlastnil notebook, který by si na cvičení připojil na laboratorní Wi-Fi, určenou pro TurtleBoty. Ale během koronavirového šílenství přizpůsobili vyučující svou výuku tomu, že většina studentů pracovala doma na notebooku, a to sebou přineslo problém, se kterým roku 2018 nikdo nepočítal.

Vzhledem ke špatnému stavu kabeláže má laboratoř E:130 nedostatek ethernetových přípojných bodů. A na těch, co ještě fungují visí Wi-Fi AP, přes které komunikují TurtleBoti a dva 8 portové switche, do kterých jsou zapíchnutá školní laboratorní PC. Vše, co je v této laboratoři připojeno do sítě, se tak dělí o 1GBit!

Také Wi-Fi AP má své omezení, proto je zde manual pro konfiguraci a testy Wi-Fi

A kritická situace nastala, když počet připojených zařízení překročil únosnou mez. Wi-Fi AP totiž řeší takovou situaci tím, že odpojí všechny klienty a pak čeká, které z nich se připojí znovu. Jenomže systém TurtleBotů zůstane v takové situaci viset, protože – na rozdíl od studentských notebooků – bez síťové konektivity nedostane na knihovny, potřebné k obnově připojení přes Wi-Fi. Takže se na Wi-Fi AP navěsily zpátky už jen notebooky studentů, zatím co TurtleBoty bylo nutné natvrdo restartovat. A je vcelku logické, že ten, kdo nepsal kód na laboratorním stroji, ale přímo v prostředí TurtleBotu, o veškerá data nenávratně přišel.

Bylo jediné možné řešení – omezit studenským strojům v přístup na laboratorní Wi-Fi AP.

Pro studentské notebooky je tak v současné chvíli vyhrazeno celkem 8 ethernetových portů, do kterých mají být napevno zapojeny také patch kabely s USB ethernetovými adaptéry, pro notebooky co nemají ethernetový port.

Autonomní Half-Diskless

Na realizaci tohoto konceptu došlo až na konci roku 2023[4], ale až do poloviny února 2024, probíhal intenzivní vývoj potřebných nástrojů a metod.

Použití

Tušíte jakou největší pitomost může udělat student, který chce na TurtleBotu vzdáleně pracovat? – Spustit příkaz find na adresáře s miliony malých souborů, které mu do profilu nacpaly pofiderní aplikace typu flapack, pip, nix, atp.

Pro Wi-Fi platí – méně keců, více dat. Jeden velký soubor se přenese rychleji, než několik menších o stejném objemu dat.

Je to tím, že každý síťový paket má svou vlastní režii, bez ohledu na to, kolik „užitečných” dat se jeho prostřednictvím přenáší.

Jak dostat data na TurtleBota

Zpracovávat data v desktopovém prostředí laboratorního PC, je nejjedodušším, nejbezpečnějším a zároveň nejrychlejším způsobem, jak se dostat svůj kód, či binárku na TurtleBota. Cokoliv jiného je špatně!

Uživatelský adresář TurtleBota, je totiž stejně jako u laboratorního PC identický adresář sdílený přes NFS. A pokud někdo TurtleBota omylem vypne, nebo se zhroutí bude výsledek vaší práce stále v bezpečí NFS serveru.

Programuj a kompiluj na PC a v prostředí TurtleBota spouštěj hotovou binárku.

Pochopitelně jsou situace, kdy je potřeba data posílat ven z TurtleBota. V takovém případě si protáhněte po síti jen konkrétní okno a ne celou aplikaci typu Firefox se 150 tabelátory.

Používej SSH klíč!

Pokud si do svého profilu přidáš svůj veřejný SSH klíč notebooku na kterém pracuješ, nebudeš muset na SSH konzoli řešit žádné laboratorní heslo.

Zalogování do grafického prostředí TurtleBota přes ssh

Na každém TurtleBotu je k dispozici utilita sendkeys, která umožňuje odesílat z prostředí SSH konzole řetězce do grafického prostředí.

Pomocí této aplikace, se můžete také do grafického prostředí zalogovat, takže se nemusíte trápit s dotykovým displeje. Jenom nesmíte zapomenou na sudo.

~$ sudo sendkeys login <username> pass <password>

Pro další použití, včetně odhlášení už sudo nepotřebujete. K odhlášení z grafické konzole stačí použít:

~$ sendkeys logout
Poznámka Naučte se používat atributy help, -h, --help či ? – ušetříte si čas.

Jak pracovat na desktopu TurtleBota prostřednictvím vzdáleného stroje

Pokud jse přihlášení na TurtleBotu do grafického rozhraní, můžete využít utilitu x2x, ořes kterou můžete pracovat s TurtleBotem, jako byste k němu měli připojenou svou klávesnici a myš. Použití je stupidně prosté. Následující ukázkový příklad, je včetně použití utility sendkeys:

user@notebook~$ ssh -X username@turtleXX
user@turtleXX~$ sudo sendkeys login <username> pass <password>
user@turtleXX~$ x2x -to :0 -north

A pak již můžete pracovat ze svého stroje a na displeji TurtleBota sledovat pohyb kurzoru, který se v případě atributu -north bude pohybovat na desktopu TurtleBota, pokud s ním vyjedete „severně” ze svého linuxového desktopu.

Využívej tmux!

U tmuxu přes SSH mohou nastat problémy spojené s přemapováním kláves. Se základní klávesovou zkratkou (Ctrl+b) nebývá problém, ale znaky pro vytvoření nového okna (uvozovka " a procento % se mouhou psát jinak, než na lokální klávesnici, jakou aktuálně používáte.

Psaní uvozovky
Na české linuxové QWERTY klávesnici se uvozovka píše přes klávesu Shift + ů (na anglické klávesnici je na klávese středník a dvojtečka).
Na US klávesnici je uvozovka o klávesu vedle
Psaní procenta
Na české linuxové QWERTY klávesnici se procento napíše přes klávesu Shift a klávesu, která je hned vedle nuly na horní řadě kláves – bez shiftu píše znak =
Alternativně se dá napsat přes pravý ALT + klávesu s číslem 5
Na US klávesnici by se napsal znak procenta Shift + klávesa s číslem 5

Pokud lezete přes SSH na stroj, kde nejsou nainstalované stejné fonty a lokály a kde není podpora fontu na textové konzoli, posílá se stejný znak jaký píšete na své klávesnici. Pokud ho ten vzdálený systém nezná, nenapíše nic!

Singulatity

Pokud používáš ROS v kontejneru pro singularity, nalezneš další informace na stránce k použití singularity.

Hardware

V současné době provozujeme tyto TurtleBoty:

CPU (počet jader a typ) RAM (v GB) swap (v GB) Disk (kapacita + typ) Astra[5] RealSense[6] Převodník USB na UART CP2102[7] Dotyková vrstva[8] Převodník USB na UART TTL[9] Typ Poznámka
turtle01 4 Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz 7,65 0 120 GB Intel 540 Series SSDs INTEL SSDSCKKW120H6 CVLY617600BH120H LSBG100 Y N N Y Y NUC6i5SYB Intel(R) Client Systems verze ? Někdy se Wi-Fi nechytne na poprvé
turtle02 4 Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz 7,65 7,81 120 GB Intel 540 Series SSDs INTEL SSDSCKKW120H6 CVLY61760044120H LSBG100 Y N Y Y Y NUC6i5SYB Intel(R) Client Systems verze ? Někdy se Wi-Fi nechytne na poprvé
turtle08 8 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz 7,63 7,88 240 GB KINGSTON SA1000M8240G 50026B7682756FAC E8FK11.R N Y Y Y Y NUC7i7DNKE Intel(R) Client Systems verze J85069-205
turtle09 8 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz 7,63 7,88 240 GB KINGSTON SA1000M8240G 50026B7682884D07 E8FK11.R N Y Y Y Y NUC7i7DNKE Intel(R) Client Systems verze J85069-205
turtle10 8 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz 7,63 7,88 240 GB KINGSTON SA1000M8240G 50026B7682756D7D E8FK11.R N Y Y Y Y NUC7i7DNKE Intel(R) Client Systems verze J85069-205
turtle11 8 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz 7,66 7,88 240 GB KINGSTON SA1000M8240G 50026B76827572DB E8FK11.R N Y Y Y Y NUC7i7DNKE Intel(R) Client Systems verze J85069-205
turtle12 8 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz 7,63 7,88 240 GB KINGSTON SA1000M8240G 50026B7682756D38 E8FK11.R N Y Y Y Y NUC7i7DNKE Intel(R) Client Systems verze J85069-205 Někdy se Wi-Fi nechytne na poprvé a při zavolání systemctl poweroff stroj nevypne a udělá reboot.
turtle13 2 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz 7,63 7,88 240 GB KINGSTON SA1000M8240G 50026B7682756D8D E8FK11.R N Y Y Y Y NUC7i7DNKE Intel(R) Client Systems verze J85069-205 Displej má pravděpodobně HW problém, protože nefunguje dotyková vrstva a zavaděč se s ním při startu rovněž nedomluví, takže zavádí jádro v blind módu (není vidět žádný výstup).

Od roku 2018 se na řešení problémů TurtleBotů aktivně podíleli

S Alešem Kapicou, autorem a vývojářem technologie autonomního Half-Disklessu, v průběhu času spolupracovali následující vyučující a kolegové:

  • Karel Košnar
  • Gaël Écorchard (optimální postupy pro singularity)
  • Libor Wágner (příprava ROS image)
  • Tomáš Petříček (příprava ROS image)
  • Pavel Krsek
  • Vojtěch Šalanský
  • Bedřich Himmel (technická spolupráce)
  • Martin Pecka (příprava ROS image)
  • Ondřej Votava (pomoc s konfigurací firewallu a DDNS)

Jejich pomoc, byla jak technického rázu, tak formou hlášení problémů, připomínek a návrhů řešení.

  1. Viz PDF Karla Košnara https://cw.fel.cvut.cz/b191/_media/courses/b3m33mkr/turtlebot.pdf
  2. Původní TurtleBoty byly dodávány jako stavebnicové kity, na kterých byl umístěn notebook ASUS. U TurtleBotů verze 2 byl místo nich Intel NUC, původně s procesorem i5, 8GB RAM a 128GB SSD SATA diskem. Novější verze TurtleBotů 3 a 4 se již dodávají s lacinějším, ovšem také výkonostně slabším Raspberry Pi. Šablona:at
  3. Více jsem se o něm rozepsal na své soukromé wiki, kde je mimo jiné uvedeno, proč byla použita právě aplikace mcachefs.
  4. První virtuální stroj založený na konceptu squashovaných vrstev se podařilo rozběhnout do konce roku 2023
  5. ID 2bc5:0401 Orbbec 3D Technology International, Inc Astra
  6. ID 8086:0b07 Intel Corp. RealSense D435
  7. ID 10c4:ea60 Silicon Labs CP210x UART Bridge
  8. ID 04d8:0c02 Microchip Technology, Inc. AR1100 HID-MOUSE
  9. ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC