Dlouho jsme přemýšleli nad tím, jak k naším tiskárnám zapojit kameru tak, aby výsledné řešení bylo jak cenově dostupné tak snadno integrovatelné pro těch víc jak 400,000 tiskáren Original Prusa, které jsme už rozeslali do světa… Až jsme jednoho dne narazili přesně na to, co jsme hledali! Skvělé, opensourcové řešení určené specificky pro Prusa Connect, se kterým přišel člen naší komunity – Miroslav Pivovarský. Modul ESP32-CAM s vlastním, upraveným firmwarem.

Tenhle šikovný modul má integrovanou flash LEDku a WiFi, a navíc je dostupný téměř všude. Není to sice úplná revoluce v průmyslu ale rozhodně to je jednoduché, levné a hlavně funkční řešení pro vzdálené monitorování vaší tiskárny kamerou. Koupíte, naflashujete firmware od Miroslava a můžete ho začít používat.

Po naflashování firmwaru je zbytek nastavení záležitost na pár kliknutí. Stačí zaregistrovat kameru v Prusa Connectu, zkopírovat její access token a za chvíli máte první snímky. Jasně, nedá se čekat 4K60 video stream – v aktuální verzi kamera posílá jeden snímek každých 10 vteřin, ale to je pořád víc než dost na vzdálenou kontrolu průběhu vašeho tisku. Nebo snímek poslat neuronové síti pro automatickou detekci chyb tisku, jak jsme naznačili v epizodě Prusa Podcastu o AI v 3D tisku. A protože firmware podporuje OTA updaty, dají se funkce modulu snadno rozšiřovat i v budoucnu. Podrobné instrukce najdete v tomto PDF. Mezitím si můžete vytisknout šikovný rám na kameru, který se dá snadno přidat na rám vaší tiskárny. Je nastavitelný, odolný a snadno s ním nastavíte vhodnou pozici kamery. Navrhl ho skvělý designér Michal Fanta a je zdarma ke stažení na Printables, spolu s krytem pro kamerový modul.

A pokud vás zajímá, co všechno je potřeba k vývoji takového řešení (včetně OTA updatů firmwaru a dalších zajímavostí) – máme pro vás o vývoji celý příběh! 🙂

Bylo nebylo… 

Miroslav začíná vyprávět, jak s prací na tomhle řešení kamery pro tiskárnu vůbec začal: “Měli jsme v práci pár 3D tiskáren MK3S+ a ty byly napojené na síť pomocí Raspberry Pi, na které běžel PrusaLink.” PrusaLink umožňuje připojení do Prusa Connect a použití pokročilých síťových funkcí i na starších, 8-bitových, tiskárnách. “A já jsem sice místo kamery používal starší smartphone (což je funkce zabudovaná do Prusa Connect), ale díval jsem se po něčem skladnějším. Nejlíp nějaké malé kamerce, která by fungovala sama o sobě,” dodává.

A tak v mezičase začal zkoumat a analyzovat, jak vlastně celý systém funguje – zejména způsob jakým smartphone posílá snímky do Connectu. Modifikovat NodeJS skript, který je za přenos obrazu zodpovědný tak, aby snímky přijímal skrz CSI sběrnici z malé Raspberry Pi kamery namísto z telefonu netrvalo dlouho. Miroslav pak skript nahrál na další Raspberry Pi, připojil k ní kameru a pustil skript tak, aby snímky z kamery předával Connectu. Tohle řešení ale pořád mělo zásadní nedostatek: potřebovalo DVĚ desky RPi – jednu pro kameru a druhou pro PrusaLink. Sice fungovalo, ale jak řekl sám Miroslav – zdaleka nebylo ideální.

Kamera připojená k Original Prusa MK4

A jak už to tak často bývá, klíčový průlom byla naprostá náhoda. „Uklízel jsem si takhle jednou stůl a šuplíky po kterých mám spoustu různých modulů a addonů pro Arduino a koukám – to je přesně ono! Malý modul ESP32-CAM.“ vzpomíná Miroslav. Tenhle levný MCU (Micro Controller Unit) má svůj vlastní ARM procesor, velkou Flash paměť, dostatek RAM, a navíc i vlastní Wi-Fi modul. Naprosto ideální! 🙂

Cesta k funkčnímu řešení samozřejmě nebyla až tak přímočará – i když by se mohlo zdát, že základní IDE (vývojářské prostředí) Arduina bude stačit, nebylo tomu zdaleka tak. Miroslav si nakonec vytvořil vlastní HTTP server pro příjem a ukládání příchozích obrázků – vlastně stejný, jako Prusa Connect. S pomocí tohohle serveru pak testoval první verze svých skriptů – těch, které už fungovaly na Raspberry Pi.

Na Raspberry Pi mi to funguje! 

Další krok byl jasný – „donutit“ modul ESP32-CAM dělat stejnou práci, kterou dělala Raspberry Pi. K tomu bylo potřeba pochopit jak kamerový modul funguje a jak fotky posílat nejen po HTTP, ale i HTTPS – které používá Prusa Connect a se kterým je práce o něco složitější. Ale po troše výzkumu a získání a správném nastavení potřebného certifikátu Miroslav úspěšně odeslal správná data z ESP32-CAM na server a dokonce i do Prusa Connect! Chvíli to vypadalo že všechno šlape jako hodinky – ale první problémy na sebe nenechaly dlouho čekat. Jedním z těch největších byla velikost a rozlišení posílaných obrázků. Nejvyšší rozlišení, které se posílalo bez problémů bylo 320×240 pixelů, což není zrovna moc. Tohle omezení měl na svědomí samotný modul ESP32-CAM, ve kterém nastal problém pokud velikost souboru odesílaného po HTTPS přesáhla 9kB. Po troše výzkumu a pár pokusech Miroslav zjistil, že když soubor rozdělí na 5kB fragmenty a ty pošle sekvenčně, funguje všechno správně. A i když tohle řešení trochu zpomalovalo upload, bylo, alespoň v tu chvíli, tím nejvhodnějším. 

Stačilo dokonce na streamování videa do místní sítě. Miroslav se původně obával, že maximální framerate bude kolem 1 FPS, ale po vyřešení některých problémů, kdy streamování například způsobovalo různé barevné artefakty a špatnou horizontální synchronizaci, se dostal na 5-7 FPS při rozlišení 1024×768, což byl v této fázi naprosto skvělý výsledek 🙂. A MCU by mělo mít potenciál na ještě víc FPS a lepší rozlišení, takže na tom Miroslav dál pracuje. No a teď, když měl Miroslav hotové jednoduché, ale funkční softwarové řešení, jej hned nasdílel na GitHubu a fórech Prusa, protože prostě chtěl být první, kdo s takovým řešením přišel.

V aplikaci Prusa Connect se můžete podívat na poslední záběr z kamery Zbývala ale ještě spousta věcí k vyřešení – například nebylo úplně ideální, že celá konfigurace MCU je integrovaná do zdrojového kódu. Token, fingerprint, WiFi SSID, nastavení kamery a další – to všechno se kompiluje dohromady a pak flashuje do paměti MCU, bez možnosti dalších změn. Miroslav tedy začal hledat řešení v oblasti se kterou moc zkušeností neměl – webovém rozhraní. A i když to nikdy nebylo jeho hlavní zaměření, ujal se toho s nadšením a po několika večerech intenzivního programování převedl svůj původní nápad do reality – funkční webové aplikace pro konfiguraci kamery, která běží přímo na kamerovém modulu. “Sice to celé vypadalo jak z devadesátek ale fungovalo to, takže jsem s tím byl spokojený.” směje se Miroslav.

Jedna z prvních verzí webového rozhraní kamery 

Vývoj se rozjíždí Jeho řešení jsme si všimli i my – a opravdu se nám líbilo, takže jsme Miroslava kontaktovali mailem a nabídli mu spolupráci pro další vývoj. „Nabídka mě příjemně překvapila a rovnou jsem ji přijal. Mimo jiné proto, že bych rád víc přispíval do opensourcové komunity.“ říká Miroslav. Po pár diskuzích a code review jsme přišli hned s několika nápady na vylepšení jak softwaru tak webového rozhraní – například implementaci moderněji vypadajícího uživatelského rozhraní atp. Miroslav všechny ty návrhy nadšeně vstřebal a rovnou na nich začal pracovat. „Největší výzvou pro mě na celém projektu byl vývoj té webové aplikace,“ řekl nám o vývoji řešení v téhle fázi Miroslav. Stránka aplikace musela vypadat moderně, hezky, nejlíp být v Prusovském designu a přitom se pořád musela vlézt do limitované Flash paměti MCU. Na druhou stranu to neznamenalo, že se všechno muselo vyhodit – po analýze a přečtení pár článků dospěl Miroslav k závěru, že jeho dosavadní přístup kombinující HTML, JavaScript a jQuery je pořád funkční.

A taky tuhle příležitost využil k tomu si zkusit práci s AI – ta mu pomohla s vytvořením stránky. Tahle spolupráce probíhala například tak, že AI popisoval jednotlivé komponenty, jak se jmenují, jak je použít atp. „Bylo to celkem legrační. Zkoušel jsem AI vysvětlit co chci ale přitom jsem to sám nevěděl. Věděl jsem jen jak by to všechno nakonec mělo vypadat.“ dodává. Přiznal nám taky, že i když webové rozhraní mohlo být optimálnější a hezčí, práce na něm ho bavila a naučil se u toho spoustu nových věcí. Potřeba konfigurace Když byl design webového rozhraní v podstatě hotový, začal Miroslav přemýšlet nad dalšími funkcemi. Například updatovat firmware by mělo být možné právě skrz rozhraní – kamera by si mohla sama zkontrolovat nejnovější verzi firmwaru, kdyby bylo potřeba si ji i stáhnout a všechno by tak bylo maximálně uživatelsky přívětivé.

Aktuální vzhled webového rozhraní kamery 
Pak přišel čas zabývat se jednou z opravdu důležitých věcí – prvním spuštěním a nastavením MCU. Miroslav přišel se dvěma různými řešeními, která mohou existovat vedle sebe a každý si tak může vybrat preferovaný způsob inicializace kamery. Prvním je režim AP, kdy se po zapnutí MCU vytvoří přístupový bod s konkrétním SSID. Klient se pak může připojit k AP prostřednictvím WiFi a nastavit přihlašovací údaje své bezdrátové sítě a konfigurovat kameru. Aby nepoužívané přístupové body zbytečně nezatěžovaly 2,4GHz pásmo WiFi (představte si, že jich máte zapnuté desítky naráz na jednom místě – například na tiskové farmě nebo u nás v kancelářích 🙂 ), tak pokud se do pěti minut od zapnutí kamery nepřipojí žádné zařízení, režim AP se zase automaticky vypne. Když už jednou máte kameru nastavenou, můžete se na její správu v síti dostat pomocí IP adresy. To ale není moc extra pohodlné, obzvlášť pokud IP adresu neznáte a nemáte přístup do správy vašeho routeru. Aby tenhle proces zjednodušil, přidal Miroslav do softwaru kamery taky funkci mDNS – to znamená, že k vašemu zařízení můžete přistupovat na vaší lokální síti pomocí záznamu DNS (představte si to třeba jako „přezdívku“ pro vaši správu kamery). Nemusíte si tak pamatovat celou IP adresu zařízení, které chcete spravovat. Záznam mDNS se dá konfigurovat – teď je to například http://prusa-esp32cam.local

Nicméně řešení s AP módem odhalilo problém, Webový interface při něm musí pracovat v offline režimu když se uživatel ke kameře připojuje v AP módu. Bylo tak nutné přidat knihovnu jQuery přímo do zdrojového kódu MCU. Naštěstí přesně pro takováhle využití a situace existují malé, optimalizované jQuery knihovny – i když i tak si jQuery zabere přibližně 86kB z Flash paměti MCU, což je docela dost.

Dalším způsobem konfigurace kamery se kterým Miroslav přišel bylo sériové komunikační rozhraní. To mohou uživatelé použít místo režimu AP, pokud AP nemohou nebo nechtějí používat. V rozhraní může uživatel nastavit přihlašovací údaje pro WiFi a autorizační token pro backendovou aplikaci, zobrazit IP adresu kamery v síti nebo použít další příkazy prostřednictvím konzole.

Čím větší… V této chvíli se projekt už značně rozrostl. Miroslav web asi 3-4krát přepsal, protože vždycky našel něco, co se dalo udělat lépe. První verze kódu byla napsána v C, takže se pokusil vše přepsat do C++, to sice ještě není úplně hotové, ale kód se po částech upravuje a vylepšuje. A přestože se projekt docela dost rozrostl, pokračuje tak, jak začal – jako projekt Arduino, takže komunita může snadno upravovat zdrojový kód bez toho, aby musela používat další specializované IDE s překladačem. Dál bylo potřeba zjistit, jak na aktualizaci firmwaru OTA (over-the-air). Současná verze MCU má 4 MB Flash paměti, což znamená, že pro celou aplikaci je možné využít jen 1,9 MB. Pokud vás zajímá proč, tak je to proto, že pro aktualizaci firmwaru se používá takzvaný „double banking“, což znamená, že paměť je rozdělena na dva sektory (ve skutečnosti víc, ale pro zjednodušení řekněme dva). V jednom sektoru běží aktuální, platná aplikace (nazvěme ho sektor A). Ve druhém sektoru běží neplatná, zastaralá verze aplikace (hádáte správně, to bude sektor B).

Systémové informace kamery, včetně možností updatu firmwaru OTA 
Při stahování nového firmwaru se přepíše sektor B (neplatná aplikace). Pak se zkontroluje integrita nainstalovaného firmwaru, a pokud je vše v pořádku, aplikace v sektoru B se nastaví jako aktivní. Díky tomuto systému aktualizace OTA nikdy nepřepisuje aktuálně spuštěnou aplikaci. Hardwarová omezení Kromě různých softwarových problémů se vyskytlo i několik problémů se samotným hardwarem. Některé testovací vzorky přestaly odesílat fotografie, neustále se odpojovaly od WiFi, restartovaly se atd. „Byla to spousta různých problémů, ale jejich řešení mě bavilo. Bylo zajímavé sledovat, jak problémy vznikají, a pak vymýšlet, jak je odstranit,“ komentuje Miroslav. Největší problémy způsobila konstrukce samotné desky ESP32-CAM. Například – protože procesor má málo pinů a poměrně velký počet periferií, použil konstruktér pin pro rozsvícení LED diody také jako jeden z pinů pro komunikaci s kartou microSD. To mělo za následek problém s komunikací mezi MCU a kartou microSD, když LED svítila. Řešením bylo použití „jednovodičového režimu“ microSD karty – v tom se data čtou a zapisují pouze přes jeden digitální vstup/výstup. A ještě větší problém je s flash LED na desce – konstruktér tuhle LED připojil přímo na 3,3 V bez proudového omezovacího rezistoru, což způsobuje, že proud protékající LED je příliš vysoký a dioda po určité době odumře. Na jedné desce LED zhasla po měsíci blikání každých 30 sekund. Miroslav přišel hned s několika řešeními tohoto problému, včetně připájení rezistoru mezi kolektor tranzistoru a PCB nebo použití externího zdroje světla spínaného relé, MOSFETu nebo něčeho podobného. Některé desky se taky dost zahřívají, ale to záleží na dodávce, ze které desky pocházejí. Na tomhle problému se stále pracuje, protože jsme sice zkusili už několik pokusů o řešení, jako například snížení taktovací frekvence procesoru, ale zatím nepřinesly příliš velké zlepšení.

Několik možných řešení problému s LEDkami, které navrhl Miroslav 

Jak sami vidíte, na tomhle projektu je pořád ještě spousta věcí k vyřešení a vylepšení. Ale Miroslava baví jak projekt tak práce na něm. Nejvíc ho baví zkoušet, co všechno se dá s malým, levným kamerovým modulem dělat. Chtěl by například ještě zapracovat na multitaskingu, protože zatím všechno běží současně pouze na jednom z jader procesoru, i když ten má jádra dvě (dual core). A určitě je ještě spousta dalších vylepšení, která by rád přidal. Neváhejte tedy toto zajímavé kamerové řešení vyzkoušet a jakékoliv připomínky pak prosím sdílejte s námi a autorem.

Tisku zdar!