TurtleBot
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:
- Vzdáleně přes SSH
- 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)
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.
- 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.
- 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:
- Na první místo dát UEFI PXE Boot…
- …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.
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.
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 vylepšit...
- 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.
- 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í.
Řešení na bázi mcachefs
Elegantní, jednoduché, ale s jednou dosti podstatnou vadou, která se projevila až při aktualizaci disklessového systému na novější verzi – špatný návrh aplikace mcachefs. Zmiňuji to především pro poučení všech co čtou tyhle řádky. Je snadné naprgat hromadu kódu, ale udělat dobrý návrh, který lze do budoucna dále rozvíjet, na to každý nemá.
Proč nebylo využito kešování, které nabízel linuxový kernel? Z jednoho prostého důvodu. Tehdejší technologie ještě nebyla dostatečně zralá – soubory se po každém rebootu kešovaly znovu, do souborů s unikátními názvy, dokud se nezaplácnul celý souborový systém lokálního blokového zařízení. Aplikace mcachefs dělala přesně to, co jsme po ní chtěli – ukládala na lokální disk vše, nač uživatel sáhnul. Takže po restartu nebylo nutné stejný soubor stahovat znovu. |
Šlo o velice zajímavé řešení[3], které ovšem mělo několik zásadních nedostatků:
- To, že mcachefs jel přes FUSE, bylo to nejmenší. Pomalejší natahování souborů se dá přežít. Bohatě se to vyvážilo při opakované spouštění stejných aplikací po restartu.
- Mnohem vážnější bylo to, že mcachefs nepodporoval automické změny. Aby se promítla změna na straně NFS serveru, bylo nutné udělat nový restart.
- Velice vážným problémem bylo to, že neuměl aktualizovat nakešované symlinky, protože systemd, na který jsme přešli od verze Bookworm, je na symlincích založen.
A to byly také důvody, proč jsme museli v zimním semestru roku 2021 kešování vypnout a začít opět používat TurtleBoty Full-Diskless přes Wi-Fi, se všemi již zmíněnými nedostatky co to má. Ale zimní semestr roku 2019 proběhnul bez problému a v únoru 2020, kdy díky Bedřichu Himmelovi byly uvedeny do provozu TurtleBoty, kterým chyběly displeje nikdo netušil, že o měsíc později bude prezenční výuka na rok a půl přerušena.
Hardware
V současné době tedy máme v provozu 8 TurtleBotů s různou hardwarovou konfigurací!
CPU (počet jader a typ) | RAM (v GB) | swap (v GB) | Disk (kapacita + typ) | Astra[4] | RealSense[5] | Převodník USB na UART CP2102[6] | Dotyková vrstva[7] | Převodník USB na UART TTL[8] | 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). |
Editace původního grub.cfg
Jelikož se pro zavádění jádra měl využívat zavaděč z předinstalovaného Ubuntu, byla nutná následující úprava souboru /mnt/grub/grub.cfg
:
...
Vynucená pauza od března 2020 do října 2021
Krátce na to, v březnu 2020, vypukla koronavirová panika a na TurtleBoty padal více než rok prach, přestože byly připraveny k provozu – ovšem to by vyžadovalo pracovní sílu, 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 a instalovanou on-line kameru, přes kterou by mohli vzdáleně pracující studenti sledovat co dělá TurtleBot.
Kritická slabina Full-Diskless řešení přes Wi-Fi
Studentské notebooky připojené na laboratorní Wi-Fi
Dříve také nebylo běžné, že by si studenti nosili sebou do výuky vlastní notebooky, s nimiž by se připojovali na laboratorní Wi-Fi, určenou pro TurtleBoty.
Roku 2018 ještě nepředstavovaly studentské notebooky pro TurtleBoty závažnější problém – nebylo jich mnoho. Ale během koronavirového šílenství přizpůsobili vyučující svou výuku tomu, že většina studentů pracuje s TurtleBoty z vlastních notebooků, a to sebou přineslo řadu negativních dopadů, s nimiž roku 2018 nikdo nepočítal, které bylo nutné vyřešit. Robotické ruky si naštěstí sebou vzali do CIIRCU. Počet laboratorní PC se o dva snížil, takže následující přehled popisuje je aktuální stav k polovině února 2024.
- A vzhledem ke špatnému stavu kabeláže v místnosti je nedostatek ethernetových přípojných bodů. A na těch, co ještě fungují je navěšeno jedno Wi-Fi AP a dva 8 portové switche, do kterých jsou zapíchnutá školní laboratorní PC. A vše, co je v téhle místnosti připojeno do sítě, se dělí o 1GBit!
- Pro studentské notebooky je v současné chvíli vyhrazeno celkem 8 ethernetových portů. Do některých by měly být napevno zapojené patch kabely s USB ethernetovými adaptéry, pro notebooky co nedisponují ethernetovým portem.
- V laboratoři je nedostatek silových zásuvek – každý TurtleBot vyžaduje svoji nabíjecí stanici (8x), každé laboratorní PC s monitorem vyžaduje 2 silové zásuvky (celkem
Slabiny autonomního Half-Diskless založený na mcachefs nevyhovující se ukázalo již od obnovení prezenční výuky, v zimním semestru 2021.
Jenže bylo příliš pozdě na jiné řešení, proto se opět přešlo na Full-Diskless, přes jeho nevýhody a realizaci nového konceptu, založeného na squashfs odložit na neurčito, protože bylo nutné prioritně dořešit jiné, naléhavější úkoly jako:
- sjednocení domovských adresářů
- a sjednocení operačního systému
Autonomní Half-Diskless
Na realizaci tohoto konceptu došlo až na konci roku 2023. Ale implementace zabrala období od prosince 2023[9] až do poloviny února 2024, protože bylo nutné paralelně připravit nástroje pro přípravu squshovaných vrstev a jejich kryptování.
Úprava instalace disklessu
Po spuštění lokálního systému:
- Nahození aplikace wpa_supplicant
- Získání adresy přes aplikaci dhclient
- Mount NFS adresáře budoucího disklessu
Přejmenování
# hostnamectl set-hostname bullseye
Vytvoření ramdisku s podporou Wi-Fi
Při vytvoření ramdisku s podporou Wi-Fi jsem postupoval podle webové stránky Marka Fargase. Bohužel se ukázalo, že uvedený postup pro připojení přes WPA2 nestačí.
Aby fungovalo ověřování přes WPA2, musí mít wpa_supplicant k dispozici další dva jaderné moduly: ccm a ctr[10]. Bez nich funguje pouze anonymní připojení. |
busybox
Soubor /etc/initramfs-tools/hooks/enable-wireless
, je spustitelný skript, který spustí příkaz update-initramfs -u
při sestavení ramdisku. Skript se postará o nakopírování potřebných modulů, utilit, knihoven a konfiguračních souborů pro nahození wi-fi, tak aby byly splněny všechny potřebné závislosti.
#!/bin/sh set -e PREREQ="" prereqs(){ echo "${PREREQ}" } case "${1}" in prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions manual_add_modules cfg80211 mac80211 iwlwifi iwlmvm ccm ctr copy_exec /bin/ip copy_exec /sbin/wpa_supplicant copy_exec /sbin/wpa_cli copy_exec /sbin/dhclient copy_exec /sbin/dhclient-script copy_file config /etc/initramfs-tools/wpa_supplicant.conf /etc/wpa_supplicant.conf
V tomto ukázkovém skriptu je uvedena pouze je minimální sada nástrojů potřebná k rozběhání připojení přes wifi na turtlebotu. Na většinu ostatních věcí stačí příkazy, které jsou součástí busyboxu. V souvislosti s připojením se ale mohou vyskytnout různé problémy, proto není od věci si do ramdisku přidat i užitečné nástroje, které umožní testování kvality síťového připojení či testování blokového zařízení:
Utilita | Inst. balík | Použití | Kolik přidá na objemu ramdisku |
---|---|---|---|
ip | iproute2 |
Příkaz ip, se kterým pracuje busybox má omezené konfigurační možnosti, proto se k nastavení sítě v našem případě používá plnotučný nástroj ip | |
iwconfig | wireless-tools |
Příkaz iwconfig je užitečný v pokud si nejste jisti zda wpa_supplicant navázal spojení. S jeho pomocí totiž můžete zjistit aktuální nastavení vašeho zařízení, nebo zda-li došlo k připojení. Pokud si přidáte i nástroj iwlist, který je ve stejném instalačním balíku, tak si můžete vypsat i parametry sítí, které vaše wifi "vidí". | |
dhclient | isc-dhcp-client |
Standardně se pro nastavení sítě v ramdisku používá tzv. mikro klient udhcp. Ovšem v našem případě získanou adresu nebyl schopen nastavit, proto je lepší použít "plnotučného" DHCP klienta. | |
ping | iputils-ping |
Nástroj ping vám umožní rychle zjistit zda-li stroj na druhé straně sítě žije. V nouzi místo něj můžete použít telnet, když po otevření portu na druhé straně odklepnete GET | |
arping | iputils-arping |
- | |
tracepath | iputils-tracepath |
- | |
termshark | termshark |
Je GUI rozhraní pro tshark, což terminálová verze utility wireshark, která vám umožní zachytávat síťové pakety na vaší wi-fi. Je to jediné místo, kde můžete zjistit co běhá vzduchem mezi AP a vaším klientem, protože komunikace mezi nimi je jinak šifrovaná. | |
nc | iputils-ping |
- | |
tcpdump | tcpdump |
||
netstat | net-tools |
Umožňuje zjistit jaké jsou aktuálně otevřené porty. |
Obsah souboru /etc/initramfs-tools/wpa_supplicant.conf
network={ ssid="jmenowifi" #psk="heslowifi" psk=989c6426c04864f7f386d12ca3bb776131d5eece0860c6c84f1ce2e1d3bac5ec }
K vygenerování obsahu tohoto souboru můžete použít utilitu wpa_passphrase, která je součástí instalačního balíku wpasupplicant . Řetězec 'psk' se vygeneruje kombinací 'ssid' a plain hesla 'psk'.
|
Sledování provozu na Wi-Fi síti
Jak se jmenuje wifi zařízení a případně jakou má adresu lze zjistit přes ip
~# ip addr show
Síla signálu
Jaký je stav signálu na Wi-Fi zjistíme ze souboru /proc/net/wireless
. Následující příkaz vypisuje jeho obsah ve vteřinovém intervalu
~$ watch -n 1 cat /proc/net/wireless
Pokud nás z toho zajímá pouze síla signálu, můžeme použít tohle:
~$ watch -n 1 "awk 'NR==3 {print \"WiFi Signal Strength= \" \$3 \"00 %\"}' /proc/net/wireless"
Probíhá vůbec síťová komunikace?
Pro rychlé zjištění jestli na zařízení wlp1s0
nějaká komunikace vůbec probíhá, stačí tcpdump. Pokud nás zajímá jen konkrétní adresa, kupř. to co vrací DHCP server, můžeme si vyfiltrovat pouze pakety s jeho adresou:
~# tcpdump -i wlp1s0 -s 0 host 192.168.210.5
- adresa - IPv4 resp. IPv6 adresa
- maska - maska
- rozsah -
- dst net adresa
- src net adresa
- net adresa
- net adresa mask maska
- net adresa/rozsah
- https://serverfault.com/questions/354102/tcpdump-filter-on-network-and-subnet-mask filtrování výstupu z tcpdump
termshark
Pro sofistikovanější monitoring, kdy potřebujeme nahlédnout do paketů lze použít termshark. Klientská stanice je totiž jediným místem, na kterém se dá sledovat síťová komunikace, která probíhá přes Wi-Fi. Mezi NUCem přes AP až po kontroler, který ho spravuje ji nelze sledovat, protože je šifrovaná.
Pokud jsme na klientskou stanici připojeni přes SSH, tak je vhodné odfiltrovat vlastní komunikaci. To můžeme udělat kupř. tak, že odfiltrujeme svoji MAC sdresu:
~# termshark -i wlp1s0 -f "not ether host 9a:5d:9c:ee:11:a0"
Ale pokud nás SSH provoz nezajímá můžeme odfiltrovat rovnou veškerou komunikaci která probíhá přes port 22:
~# termshark -i wlp1s0 -f "not port 22"
Filtry se dají také řetězit:
… -f "not ip.addr == xxx.x.xx.xxx and not ip.src == xxx.x.xx.xx and not mac == xx-xx-xx-xx-xx-xx and not mac == xx-xx-xx-xx-xx-xx and not ip == xxx.x.x.x and not ip.dst == xxx.x.xx.xxx and not ip.src == xxx.x.xx.xxx"
- https://www.cyberpunk.rs/termshark-terminal-ui-for-tshark termshark
- https://github.com/gcla/termshark/blob/master/docs/UserGuide.md termshark
- https://github.com/gcla/termshark/blob/master/docs/FAQ.md tshark
Overlay nad NFS
Standardní sendwich:
NFS → TMPFS → FS
NFS → FS → TMPFS → FS
Adresáře sdílené přes NFS jsou namountované na adresáře, které jsou přes mcachefs namountované na přípojné body ze kterých se pak skládá sendvič pro overlay, který změny z disklessového systému ukládá na tmpfs, který se po restartu zahodí – tak jako u standardního disklessu
Rozdíl je v tom, že mcachefs při načítání souborů z NFS do RAM paralelně ukládá jejich kopie do kešovacích adresářů na lokálním disku. Jejich obsah se ale (na rozdíl od změn uložených z prostředí disklessu) při restartu nezahodí, takže při opětovném sestavení sendviče nemusí znovu tahat z NFS – catfs pouze zkontroluje zda-li jsou rozšířené atributy souboru stejné.
Na mcachefs jsem se dohmátl přes catfs. Obojí používá FUSE. Rozdíl jsou v tom, že:
- mcachefs napsané v C má velikost ~0,5 MB kdežto catfs které je naprogramované v rustu má 2,9 MB
- mcachefs, na rozdíl od catfs, pracuje se žurnálem a symlinky interpretuje jako symlinky – na rozdíl od catfs, který je zobrazuje v závislosti a tom nač odkazují.
- mcachefs může mít podklad připojený jako readonly – změny se vždy zapisují do cache. U catfs se readonly podklad propaguje jako readonly i do horní vrstvy
Použití mcachefs
# mount … /tmp/backend # mount -t btrfs -o subvol=cache LABEL=local /tmp/cache # mcachefs /tmp/backend /target -o cache=/tmp/cache/root,journal=/tmp/cache/journal … # systemd-nspawn -D /target … ## odpojit /target, znovu připojit a pak už to projde # systemd-nspawn -b -D /target
Spuštění systému z keše
Úpravy v instalaci disklessu
Pro aktualizaci podkladového systému je třeba namountovat základní system na adresář /mnt/background
jako rw (pokud je to na onom stroji možné)
Poté se spustí kontejner, ve kterém je možné upravit instalaci:
systemd-nspawn -b -D /mnt/background
Tím se pochopitelně může dostat do nesouladu lokální cache s podkladem. Opravu lze provést tak, že se porušené soubory z keše odstraní
Lokální keš je třeba namountovat na adresář /mnt/cache
jako rw a následně zkontrolovat jestli je cksum všech souborů identický s jejic verzemi které nabízí podkladová vrstva z NFS serveru (ta může být namountovaná ro).
Pokud kontrolní součet nesedí, je dobré udělat nejprve truncate na nulovou velikost a potom soubor smazat
Použití
Konfigurace sítě
S TurtleBoty se na Katedře kybernetiky (dále jen DC) komunikuje v rámci VLAN-210. Více ke konfiguraci DHCP a přidělování IPv4 adres naleznete tam. Rychlý sken sítě lze provést pomocí utility nmap:
~# nmap -sn 192.168.210.0/24
Přístup na spodní vrstvy sendviče
Pokud běží v ramdisku proces, který je vidět ze spuštěného systému, lze se dostat ke připojeným mountpointům přes jeho proces. Pokud jako lokální uživatel 'root' spustíte následující příkaz:
~# ls /proc/*/root/
Vylistuje se vám aktuální kořenový adresář příslušného procesu. Pro většinu z nich je to stávající kořenový adresář, ale u těch co běží v ramdisku, je to kořen ramdisku a v něm je adresář i s připojenými mountpointy, co nebyly přesunuty z ramdisku do systému.
A můžete zjistit i další zajímavé informace, jako kupř. to, odkud jsou tyto adresáře namountované. Stačí k tomu:
~# cat /proc/<číslo procesu>/mounts
- Uvedený "problém" se netýká strojů, které běží jako full-diskless přes pevnou linku, protože tam v ramdisku žádný takový proces neběží.
- A navíc k tomu potřebuje uživatel nejprve získat práva uživatele root, což ovšem ale u disklessové distribuce, která má povoleno sudo, není problém.
tmux přes ssh připojení
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!
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í.
- ↑ Viz PDF Karla Košnara https://cw.fel.cvut.cz/b191/_media/courses/b3m33mkr/turtlebot.pdf
- ↑ 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
- ↑ Více jsem se o něm rozepsal na své soukromé wiki. Šablona:at
- ↑ ID 2bc5:0401 Orbbec 3D Technology International, Inc Astra
- ↑ ID 8086:0b07 Intel Corp. RealSense D435
- ↑ ID 10c4:ea60 Silicon Labs CP210x UART Bridge
- ↑ ID 04d8:0c02 Microchip Technology, Inc. AR1100 HID-MOUSE
- ↑ ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
- ↑ První virtuální stroj založený na konceptu squashovaných vrstev se podařilo rozběhnout do konce roku 2023
- ↑ Trvalo téměř týden, než jsme na to díky Marku Beliškovi přišli.