Astorino od kuchni, czyli gdy matematyka mówi: „teraz sobie radź”

Pierwsze pytanie jest oczywiste: jak się to zaczęło?

Marek Niewiadomski: Wszystko zaczęło się mniej więcej na trzecim roku studiów. Wtedy odkryłem, że istnieje coś takiego jak mikrokontroler Atmega. Było dla mnie niesamowitym odkryciem, że jestem w stanie zaprogramować coś na komputerze, wgrać na taki mały układzik, który mam na biurku, a on potrafi zapalić diodę, i ona na przykład miga. Tak się zaczęło, a z biegiem czasu pojawiały się coraz bardziej ambitne zastosowania.

Pierwszym większym projektem była praca inżynierska, która polegała na zrobieniu heksapoda, takiego kroczącego robota podobnego do pająka. Zbudowaliśmy go wtedy wspólnie z kolegą. Ja zajmowałem się programowaniem, on – symulacjami w Matlabie. To nadal był mikrokontroler Atmega, więc moce obliczeniowe były znikome. Ale poskładaliśmy tego robota i on działał. Chodził, podpięty przez Bluetooth do komputera.

To niesamowite. W moich czasach, trochę wcześniej, myśmy też robili takie rzeczy na robotyce, ale na papierze.

Fakt jest taki, że to też by się skończyło na papierze, gdybyśmy nie zainwestowali z kolegą prywatnych pieniędzy. Trzeba było kupić te 18 serwonapędów, bo każda noga miała trzy serwa. To były oczywiście proste serwa, takie modelarskie, ale jak sobie policzymy, że każdy kosztował około 60 zł, a do tego trzeba było kupić jeszcze elektronikę i inne części, to dla studentów była to konkretna inwestycja.

To była praca inżynierska. Domyślam się, że kolejnym krokiem była „magisterka”.

W ramach pracy magisterskiej powstał robot typu delta. Już od trzeciego roku studiów byłem na stażu w firmie ASTOR, tutaj właśnie zobaczyłem roboty Kawasaki i Epson. Zobaczyłem, jak to wszystko działa też trochę od kuchni, wiele takich bardziej zaawansowanych rzeczy. Mogłem się trochę zainspirować „prawdziwymi” robotami.

Ten robot delta, który powstał w latach pracy magisterskiej, też działał. Z perspektywy czasu muszę przyznać, że był on dużo bardziej skomplikowany niż powinien być. Wtedy wydawało mi się, że im bardziej coś jest skomplikowane, tym jest lepsze, a to nieprawda. Tak czy inaczej obroniłem pracę, a roboty zostały ze mną jako hobby.

Wiemy już, że to nie był twój ostatni robot.

Tak, w kolejnych latach powstawały kolejne konstrukcje, ale i tamtą deltę nadal rozwijałem. Dorobiłem do niej taśmociąg, system wizyjny, więc potem umiała łapać z taśmociągu jakieś przedmioty. A potem przyszła pandemia, trzeba było siedzieć w domu, nie można było wychodzić. Coś trzeba było robić, więc zamiast siedzieć i oglądać kolejne seriale na Netfliksie stwierdziłem, że może zbuduję coś konkretnego. W ten sposób jakoś spożytkuję tę energię, która gdzieś tam krąży we mnie cały czas.

Pomyślałeś zatem: czas na sześć osi?

Tak, zrobiłem drugiego, już sześcioosiowego robota. Zobaczył go właściciel pewnej firmy, który powiedział, że go ode mnie kupi, jak będzie mógł się ruszać. Chciał sobie tam palnik zamontować i pokazywać klientom. Więc dorobiłem do tego robocika pilot, żeby mógł wykonywać proste ruchy, i sprzedałem go. Za pieniądze, które wtedy otrzymałem, mogłem kupić pierwsze części do Astorino. Stwierdziłem, że nie będę się już bawił w tanie zabawki, które mogę kupić za kilkadziesiąt złotych, bo to nie ma sensu.

Czyli od razu miałeś wizję, żeby zbudować coś takiego, co będzie prawdziwym robotem.

Już wtedy pracowałem w ASTORZE jako konstruktor pozycjonerów, nabierałem więc praktycznego doświadczenia. Szybko się nauczyłem, że złej mechaniki nie da się naprawić żadnym programem. Jak mechanika sama w sobie jest zła, to choć nie wiem jak długo byś siedział nad programem, poprawkami, jakimiś obejściami, to nie naprawisz złej mechaniki. Najpierw musi być dobra mechanika, żeby potem program działał poprawnie. Inaczej to nie ma sensu. To było też doświadczenie płynące z moich wcześniejszych eksperymentów z robotami. Budując je często się borykałem z problemami: a to jakieś luzy, a to coś nie pasowało.

A w przypadku robota precyzja jest niezbędna.

No dokładnie tak, matematyka jest nieubłagana. Jak mam wymiar 10 mm, no to musi być wymiar 10 mm, a nie 11 czy choćby 10,1. No bo inaczej to potem się to wszystko rozjeżdża.

W tym samym czasie mocno rozwinęły się drukarki 3D, stały się bardziej przystępne, więc takie drukarki też sobie kupiłem. Pozwoliło mi to myśleć o jakiejś porządniejszej konstrukcji, nie chciałem już budować robotów z przysłowiowej „sklejki”. Te wcześniejsze roboty były zrobione z kiepskich materiałów, bo tylko takie były dla mnie dostępne.

Kiedy pomyślałeś, że ta hobbystyczna zabawa może przerodzić się w coś poważnego?

Myślę, że szybko to poczułem. Zdawałem sobie sprawę, że ta konstrukcja ma duży potencjał. Zastanawiałem się nad jakimś programem startupowym. Ale projektem zainteresował się ASTOR, który sfinansował dalsze prace konstrukcyjne, a potem wdrożenie do produkcji.

Tak powstała pierwsza wersja produkcyjna Astorino. Drukowaliśmy ją sami, kupiliśmy drukarki 3D, ja je modyfikowałem po swojemu, tak aby dało się drukować na nich te części, z których składa się robot. Drukowaliśmy na hali w ASTOR Robotics Center. Było z tym trochę problemów, druk 3D to proces dość wrażliwy na zmiany temperatur czy wilgotności. Typowe problemy wieku dziecięcego. Dziś zlecamy druk części do Astorino profesjonalnej firmie.

Robota Astorino programujemy w języku AS Language. To jest ten sam język, w którym programowane są „dorosłe” roboty Kawasaki.

Wspominałem wcześniej, że już będąc na stażu w ASTORZE inspirowały mnie roboty, które tu mogłem poznać. Nie tylko Kawasaki, również EPSON. Ja cały czas miałem taką koncepcję, żeby Astorino rozwijać właśnie w tym kierunku, aby było podobne do Kawasaki. Szczerze powiedziawszy interfejs, który jest w tym robocie, bierze trochę z Kawasaki, a trochę z Epsona. Wziąłem z obu to, co najlepsze, połączyłem i dodałem coś od siebie.

Natomiast programowanie odbywa się w języku AS Language, znanym z Kawasaki. Został napisany profesjonalny lekser i parser tego języka. Powstało środowisko do programowania, tzw. IDE, z dość rozbudowanym edytorem kodu. Mamy nawet kolorowanie składni.

Pomówmy o tym, co najważniejsze, czyli o mózgu Astorino.

Astorino jest sterowane przez kontroler Teensy 4.1 z rodziny Arduino. To jest mikrokontroler 32-bitowy w architekturze ARM, z taktowaniem 600 MHz. Jest to takie Arduino na sterydach.

Naprawdę najważniejsze jest jednak oprogramowanie dla tego kontrolera, czyli firmware robota.

Wszystko, co potrafi Astorino, wszystkie jego funkcjonalności, są zaszyte w firmware. Na komputerze mamy wyłącznie taką nakładkę komunikacyjną, czyli tak naprawdę nic innego poza przyciskiem, który wysyła coś do robota i odbiera coś z robota. Oprogramowanie narzędziowe jest właściwie tylko środowiskiem programistycznym, edytorem tekstu. Wszystko się dzieje w samym robocie. Program napisany w AS Language jest przesyłany do kontrolera robota tekstowo. Firmware interpretuje ten program, to właśnie tam działa ten parser języka AS, o którym już wspominałem. Tam też zaszyte są wszystkie algorytmy sterowania robotem. Całość jest napisana w C++.

„Algorytmy sterowania robotem” – brzmi dość niewinnie. Przypuszczam jednak, że to właśnie było najtrudniejsze?

To jest zagadnienie trudne samo w sobie, ale tu była też trudność dodatkowa. Proces programowania Astorino jest generalnie analogiczny do procesu programowania robota Kawasaki, więc cały sęk w tym, by zrobić to dokładnie tak samo. By jak najdokładniej odzwierciedlić to, co robi się na Kawasaki.

Z daleka pachnie to inżynierią odwrotną.

Właśnie. Wszystkie te funkcjonalności robotów Kawasaki, które chcieliśmy mieć w Astorino, trzeba było zbadać metodą reverse engineeringu. Nie mówię tu o takich podstawowych rzeczach, jak trajektorie liniowe, tylko o bardziej wyspecjalizowanych, jak na przykład wyznaczenie układu narzędzia metodą 4- lub 6-punktową, czy wyrównywanie narzędzia. Nawet takie pozornie proste zadania w języku AS, jak dodawanie do siebie punktów – co to znaczy, że dodam do siebie dwa punkty? To nie jest proste dodawanie współrzędnych, tylko tam się dzieje matematyczna magia. Więc konieczny był reverse engineering. Brałem symulator K-Roset, uczyłem punktów, dodawałem, patrzyłem co wychodzi i musiałem „wymyślić” matematykę, która za tym się kryje.

Delikatnie powiem: nie wydaje się to łatwe.

To nie było łatwe. Aby zrozumieć poziom trudności to powiedzmy, że mamy taką sytuację: 2 [jakaś operacja] 3 = -31,32. I teraz trzeba wymyślić, co to za operacja. Macierze, kwaterniony, kąty Eulera i kąty OAT to tylko wierzchołek góry lodowej, która była potrzebna do zrozumienia całego procesu. Na przykład funkcja ALIGN – wyrównanie osi robota do najbliższej osi układu BASE, podobny matematyczny koszmar.

Algorytmy pozwalające na obliczenia punktu TCP są również z matematycznego punktu widzenia bardzo skomplikowane. Jak ktoś pamięta macierze z matematyki, to tutaj mogą śnić się po nocach. Podobnie algorytmy pozwalające na bezpieczną i predykcyjną pracę robota w punktach osobliwych, czyli tam, gdzie matematyka mówi: „policzyłam Ci nieskończoność albo dzielę przez zero, teraz sobie radź”.

Oczami wyobraźni widzę godziny, które musiałeś poświęcić na te kwaterniony i macierze. Ale powiedz – udało się zaimplementować wszystko, co chciałeś?

Ostatnia rzecz, nad którą teraz pracujemy, i już jest na ukończeniu, to generator trajektorii ciągłej ścieżki.

Oczywiście również konieczny jest reverse engineering?

Niestety musiałem to wymyślić praktycznie od zera, bo nie ma tego nigdzie. Firmy, które produkują roboty, strzegą tego typu wiedzy jak receptury Coca-coli. Nawet jeśli coś jest w Internecie, jakieś na przykład prace naukowe, które opisują wszystkie te generatory trajektorii, to te opisy są takie, że niewiele z nich można się dowiedzieć.

Firmware robota to również obsługa komunikacji. Co umie Astorino w tej dziedzinie?

Generalnie z robotem komunikujemy się po USB. Mamy też obsługę komunikacji szeregowej na USB. Jest też Ethernet, komunikacja po TCP/IP, jest obsługa UDP, Modbus TCP. W najnowszym firmware dodatkowo jest wprowadzony tak zwany „communication protocol”, który służy do wymiany danych pomiędzy robotem, a jakimś programem zewnętrznym. Czyli możemy stworzyć swoją własną aplikację na pececie, która będzie się mogła komunikować z robotem. Wykorzystujemy do tego interfejs API, który napisałem w C#.

Zainteresował mnie jeszcze taki temat: „pseudo-równoległe wykonywanie kodu na sterowniku w celu realizacji algorytmów detekcji kolizji”.

Największy problem polega na tym, że ten układ, który jest głównym CPU Astorino, to jest procesor jednowątkowy. Trzeba było jakoś rozwiązać problem tego, żeby sterownik cały czas sterował ruchem robota, by generowana była trajektoria, silniki sterowane, a jednocześnie by można było odczytywać akcelerometr i wykrywać kolizje. Kłopot w tym, że kolizja jest wykrywana jako impuls, więc jak ją przegapisz, to przepadło. Więc trzeba jak najczęściej czytać ten akcelerometr, bo inaczej przegapimy kolizję i wszystko na nic. Musiałem zagłębić się bardzo mocno w ten układ komunikacji pomiędzy kontrolerem a akcelerometrem i w poszczególne biblioteki, aby to faktycznie działało.

Masz poczucie, że po zrobieniu tego wszystkiego, tej całej matematyki, doszedłeś do kresu możliwości procesora Teensy 4.1?

Właśnie nie. Bardzo mnie ten układ zaskakuje. Mam wrażenie, że im więcej na niego włożę, to on sobie lepiej radzi.

Myślisz o tym, żeby w przyszłości zastosować lepszy procesor?

Gdy taki się pojawi, na pewno tak. Ale najważniejszy warunek to zachowanie wstecznej kompatybilności.

Umiesz ocenić objętość tego całego kodu? Potrafisz to w liniach określić?

Myślę, że obecnie jest to około 100 000 linii kodu.

No to jest gigant. I nadal jednoosobowo panujesz nad tym? Dokładnie wiesz, co jest w którym miejscu?

Tak.

Pytam o to, bo na pewno wciąż coś modyfikujesz w kodzie, wprowadzasz poprawki. Ten firmware cały czas żyje.

To prawda. Ostatnio ludzie z Kawasaki w Japonii i USA zgłosili trochę poprawek. Chcieli na przykład pewne rzeczy troszkę inaczej, tak żeby jeszcze bardziej były podobne do Kawasaki. No to zrobiliśmy.

„Zrobiliśmy”? Czy „zrobiłem”?

No, zrobiłem. To jest taka przypadłość osób, które programują, że mówią w liczbie mnogiej.

To nie taka częsta sytuacja, żeby ktoś mógł liczyć na tak szybkie poprawki.

Więc tutaj było zgłoszenie, a trzy dni później było zrobione.

Dużo testujecie?

Bardzo dużo. Obecnie mamy już wielu użytkowników, którzy intensywnie używają Astorino. Wielu nauczycieli używa robota na lekcjach – i oni zgłaszają nam zauważone błędy czy niedoskonałości. To jest bardzo cenne, bo sami nie jesteśmy w stanie zweryfikować każdego scenariusza użycia, każdej kombinacji funkcji. Choćbyśmy spędzili na testach tysiące godzin, i tak by się nie udało znaleźć wszystkiego.

To tak, jak z każdym oprogramowaniem. Można przetestować milion przypadków, ale gdy wypuścisz program do użytkowników, oni natychmiast znajdą milion pierwszy.

Na przykład ostatnio miałem taką sytuację, że uczeń nazwał program w sposób, którego nikt nie przewidział. Dał tam jakieś symbole dolara, kreskę, te ukośne znaki zamknięcia. To spowodowało, że kolorowanie składni w edytorze stwierdziło, że to nie jest nazwa, tylko jakaś reguła regeksowa. No i program się kompletnie rozsypał w tym momencie, bo nie wiedział, o co tu chodzi. Nikt z nas by nie wpadł na to, że można takie znaki dać w nazwie w takiej kolejności.

A co jest największym problemem w testowaniu Astorino?

Największe zagadnienie wynika ze specyfiki samego języka C++.

Zarządzanie pamięcią…

Nieszczęsne zarządzanie pamięcią. Nasze aplikacje narzędziowe pracujące na komputerze są napisane w C#. Tam nie ma tego problemu, jest garbage colector. Kontroler z konieczności jest programowany w C++, to standardowy język dla platformy Arduino. Jest po prostu najszybszy i najbardziej czasowo przewidywalny.

Zapewne w żadnym takim języku, który nie jest kompilowany do kodu natywnego, takiej wydajności byś nie uzyskał.

Właśnie, coś za coś. Więc mamy nieustanną walkę z wyciekami pamięci. Jeden niefortunny malloc albo calloc – i po godzinie działania nagle okazuje się, że pamięć się zapchała albo jakiś null pointer wskoczył. Robot sobie działa godzinę, dwie godziny, nagle jest reset układu CPU, no bo on gdzieś się chce odnieść do jakiejś komórki pamięci, która nie istnieje.

Z wyciekami pamięci jest ten problem, że one nie są widoczne od razu. Przykre konsekwencje mogą nastąpić po długim czasie.

I właśnie to był największy problem, nad którym najdłużej siedziałem. Bo jeżeli mówimy o programie działającym na komputerze, to sprawa jest niemalże banalna, jeżeli chodzi o możliwość debugowania kodu. Mamy wszystko, dowolne narzędzia. Mamy Visual Studio. W przypadku mikrokontrolera nie masz tych wszystkich narzędzi do debugowania i trzeba wymyślać, gdzie to draństwo się pojawiło. Trzeba szukać czasem na oślep. Ostatnio miałem na przykład problem z komunikacją pomiędzy teach pendantem a robotem. Wszystko dobrze działało, ale raz na jakiś czas w ramce komunikacyjnej pojawiały się jakieś śmieci. Dlaczego? W końcu okazało się po prostu, że pamięć gdzieś się przepełniła, coś się nadpisywało – i pojawiały się śmieci. Ale znajdź błąd, który w 120 ramkach się nie pojawia, potem zdarza się w 121 ramce, a potem przez kolejne kilkaset znowu się nie pojawia.

W końcu się udało?

W końcu się udało, ale na komputerze można by to szybko wykryć, zdebugować. Pojawiłyby ci się śmieci, pojawiłby ci się null pointer. Komputer to zgłosi, wykryje.

Można pułapkę założyć.

Pułapkę założysz, różne są możliwości. A na kontrolerze tego wszystkiego nie ma, a przynajmniej na tym używanym przez nas.

Wspomniałeś o teach pendancie.

Dla Astorino jest dostępny teach pendant, którego funkcjonalność jest bardzo zbliżona do tego, co oferuje programator dla dużych robotów Kawasaki. Obudowa jest wydrukowana, a w środku to jest właśnie osobny komputerek, dzięki któremu wszystko na robocie można zaprogramować. To tak de facto bliźniacza aplikacja do tego, co jest na komputerze, trochę tylko okrojona.

Kod też na nim napiszesz?

Owszem, są po prostu predefiniowane funkcje, które można wybierać. Czyli po prostu dodajesz funkcję po funkcji, linię po linii. Nie wpisujemy kodu ręcznie, z klawiatury, tylko dodajemy gotowe bloki.

Mamy więc korpus, jest elektronika, jest oprogramowanie. Ale to przecież nie wszystko. Są jeszcze napędy. I są tak prozaiczne rzeczy, jak kable. Wszystko sam projektowałeś?

Tak. Zaprojektowałem wszystko, łącznie z kablami, ich długościami, wszystkie płytki PCB i tak dalej. Budując Astorino już na etapie projektu miałem w głowie to, żeby był on jak najprostszy w produkcji i serwisowaniu. W Internecie znajdziesz mnóstwo robotów do samodzielnego zrobienia, są różne takie opensource’owe konstrukcje. Ale one wszystkie mają taki mankament, że po prostu są trudne w serwisie. Jak coś się zepsuje to musisz pół robota rozmontować. Jeżeli jakiś kabel nie styka, no to musisz go już na robocie lutować, bo go nie wyciągniesz. Podobnie z czujnikami. Chciałem, aby z Astorino było zupełnie inaczej, żeby wszystko było jak najprostsze. By jak najłatwiej można było wymieniać różne części.

Mnie się wydaje, że to jest bardzo trudne do pogodzenia z pełną funkcjonalnością, wydajnością, powtarzalnością.

Oczywiście łatwiej jest zrobić coś, co jest do jednorazowego zbudowania w ramach zabawy, a trudniej jest zaprojektować coś przeznaczonego do masowej produkcji. Konieczne jest dogłębne badanie różnych możliwości, po prostu bardzo duży „risercz”, przeczesanie rynku. Są teraz możliwości zamawiania przez Internet rzeczy, których wcześniej nikt nawet do Polski nie sprowadzał. Trzeba było poświęcić wiele godzin na samo rozpoznawanie dostępnych możliwości. Często na przykład znalazłem coś w Internecie i zamówiłem, czekałem trzy czy cztery tygodnie. A potem okazywało się na przykład, że to jest nie to, że coś nie działa tak, jak oczekiwałem. Najprostszy przykład: zamówiłem pierwszą przekładnię właśnie do tego robota, jeszcze na samym początku, jak to był prototyp. Przyszła ta przekładnia i okazało się, że przysłali mi złe przełożenie. Więc coś mi nie działało i dopiero metodą prób i błędów doszedłem do tego, że to z powodu innego przełożenia.

Są tysiące ślepych uliczek w takim procesie. I tysiące roboczogodzin.

Myślę, że pewnie około 7500 godzin.

Tymczasem ktoś, kto po prostu nie wie tego wszystkiego, przyjdzie, stanie przy tym robocie, popatrzy…

Jak wejdziesz na sekcję komentarzy pod filmami z Astorino na YouTube, to tam są ludzie, którzy piszą: „ja takie robiłem w latach 90” albo „ja takiego zrobiłem za 200 dolarów”. Ludzie po prostu nie wiedzą, ile tam było do zrobienia.

A nie myślisz, że taki komentarz świadczy przede wszystkim o tym, że ktoś w ogóle nie rozumie, czym jest i jak działa robot przemysłowy?

Może tak być. Może takie osoby uważają, że to jest w sumie proste urządzenie. Ale tak nie jest. Trzeba te wszystkie macierze liczyć, te wszystkie kinematyki, żeby to wszystko współgrało ze sobą. A przecież to musi być jeszcze bezpieczne. Nawet to, że my deklarujemy, że ten robot nie będzie się poruszał szybciej niż 250 mm na sekundę – nawet to jest niebanalnym problemem. Program musi tego cały czas pilnować. Jeżeli masz na przykład ramię robota złożone i będziesz ruszał pierwszą osią blisko podstawy, to końcówka będzie się poruszała wolniej na pierwszej osi. Ale gdy go wyprostujesz, to ramię już masz większe i ruch jest szybszy.

Więc musisz liczyć te macierze Jacobiego i odwrócone macierze Jacobiego, i to liczyć diabelnie szybko na, jak już mówiliśmy, dość ograniczonym procesorze. Wszystko po to, żeby kontroler wiedział, z jaką prędkością porusza się robot. I żeby być pewnym, że nie przekracza tej magicznej granicy 250 mm/s.

Ta praca uczy pokory?

Jest taki wykres, który pokazuje ci zależność pewności siebie od ilości wiedzy, jaką masz na dany temat. Przy małej wiedzy pewność siebie jest wysoko, ale potem się uczysz – i ta pewność leci na łeb, na szyję. Dopiero gdy zdobędziesz już dużą wiedzę, dopiero gdzieś tam powoli rośnie z powrotem. Prawda jest taka, że im więcej się zagłębiasz w dany temat, tym lepiej wiesz, czego nie wiesz. I ile w ogóle w danym temacie jest zagadnień. Na początku coś się wydaje proste, na pewno łatwo sobie z tym poradzę. Ale potem jak zaczynasz to implementować w całość, okazuje się, że to podejście się nie sprawdza, że to nie działa. I trzeba zawrócić, przeorać jeszcze raz, sprawdzić, zawrócić, przeorać jeszcze raz, sprawdzić i tak często wiele razy.

Tak miałem z generatorem ciągłej trajektorii. Zacząłem pracę nad nim w 2020 roku, a dopiero teraz jest na ukończeniu. W tym czasie powstało chyba pięć różnych wersji, różnych metodologii, żeby to działało, żeby to liczyć w prawidłowy sposób. Za każdym razem dochodziłem do ściany, wyrzucałem na przykład cztery miesiące pracy do kosza i zaczynałem od zera. Potem wracałem do punktu wyjścia, inną metodą dochodziłem do kolejnej ściany, znowu okazywało się, że coś tutaj nie jest OK, wyrzucałem wszystko do kosza i zaczynałem jeszcze raz.

Skąd masz tyle cierpliwości?

Jak mam jakieś wyzwanie, jak mi coś nie działa, to mnie to dręczy. Drążę więc temat, aż go rozwiążę. I rozwiążę go w taki sposób, który mnie satysfakcjonuje. „Wystarczająco dobrze” mnie nie satysfakcjonuje. Tak, mam duże pokłady cierpliwości, ciężko jest mnie zirytować. Bardzo lubię zajmować się rzeczami nowymi, rutyna mnie nudzi, nienawidzę robić tego samego cały czas. Z Astorino ciągle coś się dzieje, co chwilę mam nowe wyzwanie. Wciąż coś poprawiamy. Planujemy wersję C. Chcemy, by ten produkt był coraz lepszy.

A co cię motywuje?

Uważam, że jeżeli nasza motywacja jest wyłącznie finansowa, to nic się nie uda. Zaraz się sfrustrujesz, że robisz, robisz, a wciąż nic z tego nie ma. Mnie najbardziej motywuje satysfakcja, że wymyśliłem coś, co działa. Że ktoś tego używa, że komuś się to przydaje. Że to trafiło nawet do innych krajów.

Jeżeli traktowałbym ten projekt jak zwykłą pracę od 8:00 do 16:00, to też by się nie udało, a w najlepszym razie trwałoby pięć lat dłużej. Ja do tego podchodzę trochę hobbistycznie, a trochę ambicjonalnie. Jak coś nie działa, to siedzę nad tym, aż zadziała. Czyli to jest taka praca, która jest jednocześnie pasją i w ogóle czymś, od czego mnie ciężko oderwać. Tutaj też chciałbym podziękować mojej żonie za jej pokłady cierpliwości i wyrozumiałości. Nieraz wieczory spędzałem nad tym projektem.

Jesteś konstruktorem robota Astorino, ale za jego sukcesem stoi cały zespół.

Oczywiście. Projekt Astorino to nie tylko „dłubanie” w sprzęcie i oprogramowaniu. To również wizyty w szkołach i na uczelniach, pokazy, wykłady, akcje marketingowe i materiały promocyjne. To także szkolenia, które są prowadzone w całym kraju. No i oczywiście produkcja! Bez tego wszystkiego nie osiągnęlibyśmy sukcesu. Chciałem pogratulować i gorąco podziękować wszystkim zaangażowanym w ten projekt Koleżankom i Kolegom. Dziękuję za Waszą pracę i wiarę w ten projekt! Jesteście wielcy!

Masz w głowie jakieś nowe Astorino? Coś zupełnie nowego?

Gdzieś tam w głowie cały czas ta delta siedzi. Gdy powstawało Astorino, poprzeczkę postawiłem sobie bardzo wysoko. Zbudować sześciosiowego robota – to było duże wyzwanie. Ale wszystko zaczęło się od tej delty i gdzieś tam mi chodzi po głowie jakaś jej nowa wersja. Żeby udostępnić szkołom nie tylko robota sześcioosiowego, ale także właśnie taką deltę. Może gdy się pojawi trochę więcej przestrzeni, pomyślę o tym poważniej.

Rozmawiał: Mateusz Pierzchała