Z Kurtem Leuchtem, kierownikiem ds. rozwoju oprogramowania w NASA i jednym z prelegentów tegorocznej konferencji DevDay, rozmawiamy o tym, w jaki sposób kolonie mrówek zainspirowały NASA? Dlaczego najnowsze technologie nie zawsze są najlepszym wyjściem? I dlaczego film „Marsjanin” nie był wcale fantastyką naukową?
Czy to prawda, że pan i pański zespół inspirowały kolonie mrówek, kiedy tworzyliście roboty „Swarmie”?
Tak. Naukowcy z Uniwersytetu w Nowym Meksyku badali mrówki w naturalnym środowisku. Udokumentowali ich zachowania, sposób, w jaki opuszczają mrowisko, by szukać pożywienia, jak się przemieszczają i znoszą pokarm z powrotem do mrowiska. Uświadomili sobie, że pozornie skomplikowane zachowania owadów podlegają kilku prostym zasadom, czyli algorytmom, które działałyby równie dobrze, gdyby użyto ich w robotach. Naukowcy dowiedli, że roboty mogłyby być równie skuteczne jak mrówki. Pracownicy NASA dowiedzieli się o tym projekcie i zrozumieli, że być może algorytm podejrzany u mrówek da się spożytkować w systemach robotów eksplorujących.
W jakim celu?
Aby poszukiwać zasobów na innej planecie, zbierać je, a następnie przenosić do jednostki przetwarzającej. Nawiązaliśmy więc współpracę z Uniwersytetem w Nowym Meksyku i stworzyliśmy robot o większych możliwościach niż pierwszy model. Dodaliśmy pewne cechy, które przydadzą się w misjach badawczych na Marsie czy Księżycu. Nasze roboty, które nazwaliśmy „Swarmies”, wyruszają z centralnej lokalizacji, a potem jadą w teren, aby szukać zasobów, tak jak mrówki. W naszym projekcie „zasobami” były rozmieszczone na ziemi kody paskowe. Roboty szukały ich, posługując się kamerami. W sposób wirtualny „chwytały” kody i zanosiły je do „domu”, czyli gniazda. A potem znów ruszały w teren. Jako że „Swarmies” naśladują zachowania mrówek, roboty współpracują, aby zwiększyć wydajność całej kolonii, tak jak robią to mrówki. Korzystają również ze „śladów feromonowych”, podobnie jak owady oznaczające teren substancjami chemicznymi, aby zachęcić do pomocy innych członków kolonii, kiedy muszą zebrać całą stertę zasobów. Projekt badawczy „Swarmie” dowiódł, że możemy wykorzystywać niewielkie, niedrogie roboty, wyposażone w tanie komputery i czujniki. Jeśli zainstalujemy w nich dość prosty algorytm oparty na systemie biologicznym, te jednostki mogą wykonywać pożyteczną pracę.
Uważa się powszechnie, że NASA wykorzystuje najnowsze technologie. Ale w projekcie „Swarmie” korzystaliście z oprogramowania opracowanego kilkanaście lat temu.
Przyjrzeliśmy się kilku dostępnym platformom programistycznym. Nie chcieliśmy, żeby coś nas ograniczało, ale nie mieliśmy też ochoty zbytnio skupiać się na programowaniu niższego poziomu. Interesował nas tylko najwyższy poziom programowania zachowań. System operacyjny ROS wyglądał na niezłe rozwiązanie, odpowiednie do naszych potrzeb. ROS działa najlepiej na systemie Ubuntu, więc użyliśmy Ubuntu. Spełnił wszystkie oczekiwania związane z projektem. Nie potrzebowaliśmy niczego bardziej złożonego czy nowszego.
Czy korzystanie z najnowszych, przełomowych technologii bywa zbyteczne w kosmosie? Korzystanie z prostszych technologii wiąże się z większą niezawodnością?
Czasami wystarczy usiąść i rozejrzeć się w koło, żeby zrozumieć, że problem został już rozwiązany. Na przykład kwestia wynajdywania i zbierania zasobów oraz znoszenia ich do bazy została rozwiązana przez mrówki. System oparty na rozwiązaniu stosowanym przez mrówki nie jest może tak wydajny jak coś, co np. mógłbym wymyślić sam, ale w projekcie badawczym „Swarmie” chodziło o udowodnienie, że nie potrzeba wiele mocy przeliczeniowej i pamięci, żeby osiągnąć cel. A ryzyko niepowodzenia jest przy tym bardzo niewielkie. Weźmy np. technologie komunikacyjne. Komputery mogą porozumiewać się ze sobą na wiele sposobów. Wi-fi to stara technologia, ale jest prosta i skuteczna. To rozwiązanie typu plug and play, czyli podłącz i korzystaj: podłączasz adapter wi-fi do gniazda USB i nie musisz nawet zmieniać konfiguracji systemu operacyjnego. Wszystko działa „samo”. Mogliśmy wybrać inną technologię, ale w przypadku tego projektu stare rozwiązanie działa jak trzeba. Jest bardzo stabilne i tanie, więc decyzja była prosta. Chociaż ten projekt miał charakter naziemny. Nie będzie na razie wysyłany na inną planetę. Gdybyśmy przedobrzyli, moglibyśmy mieć problem z nadmiernie skomplikowanym, trudnym w eksploatacji systemem, który trudno zrozumieć. Algorytm oparty na pracy mrówek jest bardzo prosty. Gdybyśmy chcieli go bardziej rozbudować, ryzyko błędu by się zwiększyło. Jasne, że wydajność systemu da się poprawić na różne sposoby, np. montując na pokładzie lepsze sensory. Ale ten projekt to pierwszy krok. Po drugie, umieszczenie na pokładzie nowszych rozwiązań będzie wiązać się z wyższymi kosztami, a jest to zbyteczne, jeśli „stara” technologia sprawdza się w projekcie. Nowa technologia oznacza większe obciążenie procesorów i wykorzystanie pamięci, co niepotrzebnie zwiększa stopień skomplikowania. A im bardziej skomplikowany będzie robot, którego w końcu wyślemy na Marsa, tym więcej ryzykujemy.
Wszystkiego z nami nie weźmiemy, ale jakie mamy alternatywy? W filmie „Marsjanin” pokazano znaczenie ISRU.
To prawda. ISRU oznacza „In Situ Resource Utilization”, czyli korzystanie z lokalnych zasobów. Po łacinie in situ oznacza „w miejscu”, w tym przypadku na Marsie, czy na Księżycu. ISRU polega więc na wykorzystaniu tego, co ma się pod ręką, żeby nie trzeba było wszystkiego ze sobą przywozić. Kiedy prowadzę prezentację o naszych wyprawach na Księżyc w ramach Programu Apollo, posługuję się pewną analogią. Wówczas nie korzystaliśmy z lokalnych zasobów. Wieźliśmy ze sobą wszystkie rzeczy, których potrzebowaliśmy, żeby tam dolecieć, przetrwać i wrócić. No ale podróż na Księżyc trwała 3 dni, pobyt – kilka dni, a powrót – znowu tylko 3 dni. To był króciutki spacerek. Przypuszczalnie sama podróż na Marsa będzie trwać 6 miesięcy. Więc nie będziemy lecieć 6 miesięcy, żeby zostać tam raptem kilka dni. Trochę tam posiedzimy. Obecny plan zakłada, że pobyt na Marsie będzie trwał około roku. Więc kiedy planuje się tak długą misję, absolutnie nie będzie się opłacać wieźć ze sobą wszystkiego, czego będziemy potrzebować. Ale jeśli możliwe jest wytworzenie wody i tlenu z lokalnych zasobów… Jeśli możliwe jest wygenerowanie paliwa rakietowego poprzez pobranie molekuł z powietrza i gleby oraz przetworzenie ich, to znaczy, że zbędne byłoby zawożenie paliwa na drogę powrotną. Dzięki temu oszczędzamy mnóstwo obciążenia i pieniędzy, a cała misja staje się wykonalna – tego po prostu nie da się zrobić, jeśli musielibyśmy wszystko ze sobą zabrać. Musimy umieć korzystać z ISRU. Autor powieści „Marsjanin” szczegółowo przeanalizował technologie NASA i nasze badania. Wykorzystał wiele rozwiązań, nad którymi rzeczywiście teraz pracujemy i których chcemy użyć na Marsie. Ile kilogramów tego, a ile litrów czegoś innego – wszystkie te kalkulacje są w książce. W książce i w filmie pojawiło się zaledwie kilka rzeczy, które ja i koledzy uznaliśmy za całkowicie zmyślone.
Tworzenie zupełnie nowego oprogramowania, czy korzystanie z narzędzi dostępnych na rynku – co lepiej się sprawdza w projektach NASA?
Kiedy trzeba wybrać oprogramowanie, np. sterujące rakietą, na ogół przygotowuje się ścisły zestaw wymagań. W takiej sytuacji nie ma zbyt wielu opcji, jeśli chodzi o wybór systemu. W niektórych projektach, nawet jeszcze na etapie badań, kiedy wszystko dopiero się ustala, już wówczas trzeba napisać autorski kod – choćby po to, żeby zapewnić współpracę między dwoma komercyjnymi rozwiązaniami.
Czy zatem korzystanie z otwartego oprogramowania jest popularne w NASA?
Każdy z kierowników projektu musi przeanalizować opcje i podjąć decyzję, kierując się dostępnym budżetem, harmonogramem, wymaganiami itd. Jeśli chodzi o mnie, to gdy wiem, że dostępne jest rozwiązanie typu open source, i jestem pewien, że spełni ono swoje zadania, na pewno go użyję. Dzięki temu mogę wydać środki z budżetu projektu na coś innego. Jeśli chodzi o krótkoterminowe projekty badawcze, wiele osób, z którymi współpracuję lub kontaktuję się w NASA, bez problemów korzysta z otwartego oprogramowania.
Który język programowania zna pan najlepiej?
Najwięcej doświadczenia mam z C i C++. Wiele lat temu brałem udział w kilku projektach, gdzie używano języka Java, i to również było fajne. Bardzo lubię ten język, ale w żadnym z moich obecnych projektów już go nie używamy. W ramach każdego z projektów, w których biorę udział w NASA, korzysta się z oprogramowania, które najlepiej spełnia swoje zadanie. NASA nie narzuca nam rozwiązań programistycznych, ani nic z tych rzeczy.
Czy ważne jest korzystanie z oprogramowania, które cieszy się popularnością wśród deweloperów i jest łatwo dostępne na początku projektu? W ten sposób jego „obsługa” będzie stosunkowo prosta przez kilka kolejnych lat lub nawet dekad, zwłaszcza w branży kosmicznej?
Na pewno jest to prawda, zwłaszcza w zakresie tak długich programów jak loty wahadłowcami, które trwały 30 lat. Kiedy pracujesz nad programem, który ma wytrzymać wiele lat, musisz być pewny, że technologia, którą wybrałeś, jest stabilna i że łatwo da się ją uaktualniać. Trudno to przewidzieć na początku projektu. Były sytuacje, kiedy próbowaliśmy uaktualnić pewne rzeczy w programie lotów wahadłowcami, ale z różnych powodów nam to nie wyszło, albo wyszło, tyle że kosztowało mnóstwo pracy. Z drugiej strony NASA realizuje też wiele krótkich projektów badawczych, w których jest większa dowolność. Projekt badawczy „Swarmie” trwał 12 miesięcy. Jak tylko ruszył, ja i moi koledzy zaczęliśmy rozglądać się za technologiami i narzędziami, z których moglibyśmy skorzystać, a które byłyby najbardziej aktualne i najmniej kosztowne, i które oczywiście spełniłyby nasze oczekiwania i gwarantowały efekt, o który chodziło.
W projekcie „Swarmie” jeden z robotów wytworzył „osobowość” i zachowania, których inne roboty nie miały. Okazało się, że był to błąd w oprogramowaniu. Jak dużym obciążeniem dla projektów takich jak ten jest czynnik ryzyka i perspektywa potencjalnych błędów?
Ten konkretny problem wystąpił, ponieważ jedna z jednostek „Swarmie” wykorzystywała nieco inne podzespoły, a różnica była naprawdę niewielka. Zawsze mamy do czynienia z ryzykiem, pewnym prawdopodobieństwem, że w trakcie testów przeoczyliśmy jakąś usterkę. Akurat ten projekt nie był obarczony dużym ryzykiem i nie odgrywał bardzo istotnej roli. W przypadku szczególnie istotnych projektów obarczonych dużym ryzykiem NASA podejmuje wszelkie środki ostrożności, rozważa wszystkie najgorsze scenariusze i stara się im zawczasu przeciwdziałać. Kiedy pracujemy, staramy się stworzyć warunki, w których nic nas nie zaskoczy. Jeśli pojawia się problem, otwieramy instrukcję na odpowiedniej stronie i wykonujemy wskazane czynności. W przypadku prawdziwych misji w zasadzie nic ważnego nas nie zaskakuje. Niemal każdy detal jest analizowany przed rozpoczęciem misji i mamy gotowe recepty na każdy z problemów. Zakładam, że niemal każdy kawałek sprzętu, który wyślemy na Marsa, będzie wyposażony w jakąś formę oprogramowania do automatyzacji, głównie z powodu opóźnień czasowych pomiędzy Marsem a Ziemią. Wszystkiego oczywiście nie przewidzimy, zwłaszcza na innej plancie, ale robimy, co w naszej mocy.
Wracając do kwestii odkrywania – jakie były pana pierwsze doświadczenia z eksplorowaniem możliwości nowej technologii?
Moim pierwszym komputerem był Apple IIe. Przy jego pomocy tworzyłem moje pierwsze gry – w całości tekstowe. Kiedy nabrałem doświadczenia, wziąłem się za bardziej skomplikowane gry z „wysokiej jakości” grafiką, jak na standardy tamtych czasów. Kiedy zrozumiałem potencjał tkwiący w komputerach, zapragnąłem zostać w przyszłości twórcą oprogramowania.
Wciąż jest pan tym farciarzem, który bywa odkrywcą w godzinach pracy?
Wciąż eksploruję. Podoba mi się internet rzeczy, nowe technologie, jak choćby sensory stosowane w telefonach komórkowych. Lubię bawić się nowymi technologiami. Zawsze się wtedy czegoś uczę. Bardzo mnie interesują nowe platformy, metodologie i środowiska programistyczne, które pomagają programistom w pracy. W obecnych czasach można tworzyć oprogramowanie, nie będąc pełnoetatowym programistą. Niektóre rozwiązania działające na zasadzie „przeciągnij i upuść”, dzięki którym nawet małe dzieci mogą programować i tworzyć działające oprogramowanie… to są wielkie osiągnięcia. W czasach, kiedy jako 12- czy 13-latek bawiłem się moim komputerem, nie mógłbym sobie ich nawet wyobrazić. Kto wie, kim byłbym dziś, gdybym wówczas nimi dysponował?
I nie miał pan do dyspozycji tutoriali na YouTube.
To prawda! Kiedy byłem w tym wieku, internet jeszcze nie istniał (śmiech). Trzeba było po prostu rozmawiać z ludźmi żeby uzyskać odpowiedzi na nurtujące nas pytania. Mam w domu nastoletnich synów i cieszę się, że oni mogą teraz korzystać z tylu świetnych narzędzi. Chodzą na zajęcia pozalekcyjne z robotyki i tworzenia oprogramowania. Do takich klubów nie przychodzą już same „geeki”. Wiele z tych technologii jest dostępnych dla wszystkich, a ponieważ stały się częścią życia codziennego, zajęcia przyciągają najróżniejsze dzieciaki o różnych osobowościach.
Czy jako dziecko był pan takim „geekiem”?
O tak! Dorastając, miałem obsesję na punkcie technologii. Nawet jeśli chodziło o proste rzeczy, takie jak toster czy zegarki. Uwielbiałem patrzeć na mechaniczne i elektryczne rzeczy, próbując dojść, jak to wszystko działa. Moja mama lubi powtarzać historyjkę o tym, jak jako mały chłopiec rozebrałem zegarek taty na części. W zasadzie to właśnie tym zajmują się inżynierowie. I pewnie „maniacy technologii” też (śmiech).
Jak się rozpoczęła pańska kariera w NASA?
W NASA pracuje całe mnóstwo bardzo inteligentnych ludzi, geniuszy. To może onieśmielać. Czy ja gram w tej samej lidze? Czy zasługuję, żeby tu być? Różnie bywało u mnie z ocenami na szkolnych świadectwach. Żaden ze mnie megageniusz, który wie dosłownie wszystko o wszystkim. A kiedy byłem na studiach, zgłosiłem się na staż w NASA. Sam nie wiem, dlaczego wybrali mnie, a nie któregoś z innych kandydatów. Ale kiedy zacząłem tam pracować, byłem pełen entuzjazmu i pracowałem z naprawdę świetnymi ludźmi. Dzięki temu mogłem przyjąć zadanie, a dzięki ciężkiej pracy – osiągnąć sukces. Obecnie pracuję z absolutnie wyjątkowymi megageniuszami. Mieć kogoś takiego w zespole – to niesamowita sprawa. Ale dobrze też mieć ludzi, którzy twardo stąpają po ziemi i są bardziej wszechstronni. Wnoszą nowe spojrzenie. Niezależnie od organizacji, w której się pracuje, zawsze dobrze mieć wszechstronny zespół. Gdyby w NASA pracowali sami supergeniusze, to daleko byśmy nie zaszli. Żeby dobrze razem pracować i osiągnąć cel, potrzeba najróżniejszych ludzi, całej galerii pracowników o różnych osobowościach i uzdolnieniach.
„Jesteśmy odkrywcami!” – to była myśl przewodnia pańskiej prezentacji na konferencji DevDay 2016. Jak pan to rozumie?
Kiedy dobrze wykonujesz swoją pracę, niezależnie od tego, czym się zajmujesz, robisz coś znaczącego. Jeśli spojrzysz na to z pewnej perspektywy, w ogólnym kontekście, zapewne zrozumiesz, że to, co robisz, jest czymś większym, niż ci się wydawało i ma większe konsekwencje. Niektórzy z uczestników konferencji DevDay pracują nad nowym oprogramowaniem, a inni tworzą nowe interfejsy użytkownika – całkowicie inne od tych, do których przywykliśmy. Chciałem zmotywować ich do dalszej ciężkiej pracy i do bycia kreatywnymi. Prezentacja „Jesteśmy odkrywcami!” pokazuje słuchaczom, czym się zajmuje NASA, co planuje i co aktualnie bada.
Zgodzi się pan z opinią, że celem DevDay jest dostarczanie inspiracji, zachęcanie ludzi do działania?
To prawda. Kiedy się na chwilę opuści biuro i weźmie udział w takim wydarzeniu, człowiek otwiera się na nowe idee. Nawet jeśli ktoś uważa się za eksperta, może się nauczyć czegoś zupełnie nowego. To świetna sprawa, że ABB sponsoruje taką kameralną, ale bardzo prestiżową konferencję. Jej rozmiar sprzyja nawiązywaniu kontaktów i budowaniu znajomości. Takie wydarzenia są źródłem inspiracji i pomagają myśleć nieszablonowo.
Źródło: Materiały prasowe
