Što su nas Gideonovi inženjeri naučili o razvoju robota? Da kao u životu, rijetko kad stvari idu prema nacrtu

Vrlo rijetko se može doživjeti situacija da robotski sustav, odnosno sastavljeni robot pogonjen baterijama i softverom za autonomni rad, iz prve radi – bez greške. Sve te greške rezultat su nepredvidljivosti samog procesa zbog čega je razvoj robota skup, dugotrajan i rizičan pothvat.

Edin Kočo, direktor odjela za robotiku u Gideonu i Tomislav Haus, direktor autonomnih aplikacija u istom poduzeću, ispričali su nam s kakvim su se sve greškama suočavali tijekom razvoja komercijalnih robota.

U razvoju robota vrijedi “nemoguće je spriječiti – bitno je dobro zaliječiti”

U ovoj zagrebačko-osječkoj tvrtki odavno su navikli da je greška sasvim prirodna pojava u ciklusu razvoja robota, pojašnjava Edin:

Greške su sastavni dio našeg posla, iako se trudimo da ih minimiziramo, prihvaćamo ih kao normalni korak u razvojnom ciklusu naših sustava. U slučaju Gideona i specifičnosti posla koje radimo, smatram da je bitnije imati brzi “feedback loop” unutar kompanije koji će osigurati da se greška brzo detektira i ispravi, nego da se u startu ne napravi.

Roboti u Gideonu prolaze kroz tri faze testiranja, opisuje Edin, a testovi se rade i u simulacijskom i u stvarnom okruženju. 

Edin pojašnjava da im simulator omogućava testiranje prije nego je robot fizički gotov ili omogućuje stvaranje scenarija koje je teško ili gotovo nemoguće reproducirati u stvarnosti. Primjerice, velik broj robota koji rade u kooperaciji ili rade u zahtjevnim, dosad neviđenim okruženjima. Za stvaranje simulacijskog okruženja, sučelja, okruženja u kojima roboti rade, gibajućih i 3D modela koriste open source alate Gazebo, Stage, ROS i Blender.

Nekada je potrebno na robote bacati i kutije

Ipak, Edin ističe da simulator ima određena ograničenja koja nije moguće efikasno adresirati, a primarno su vezani uz simulaciju kompleksnijih senzora ili fizikalnih pojava, pa se roboti moraju testirati fizički – u hali i u raznim okruženjima kod korisnika.

Za testiranje u stvarnom okruženju Edin navodi da na raspolaganju imaju dvije hale – proizvodnu i testnu – veličine oko 750 m². Proizvodna hala se koristi za serijsko testiranje u tijeku proizvodnje, a testna prvenstveno za development testiranja novih proizvoda ili softverskih funkcionalnosti.

Prepreke koje koriste u testiranju spadaju u standardnu statičku infrastrukturu (regali), dinamičke prepreke (ljudi testeri, drugi roboti ili viličari) ili kartonske kutije, koje nerijetko bacaju na robote kako bi testirali brzinu zaustavljanja.

Postoje greške na koje se možete pripremiti…

Tomislav Haus, direktor autonomnih aplikacija u Gideonu navodi kako su najčešće očekivane greške vezane uz sučelja između pojedinih modula, a otkrivaju se integracijskim testovima. Svaki softverski modul (primjerice, računalni vid) i hardverska komponenta (kamera, Wi-Fi antena i sl.) često će raditi bez problema sama za sebe, ali kad dođe do faze integracije svih tih modula i komponenti u kompletni robotski sustav, ako se promijenio samo jedan parametar u sučelju samo jednog modula, može se dogoditi da – zajedno ne radi ništa.

Prema Tomislavu, relativno su se navikli i na greške kod softverskih komponenti koje rješavaju neke od najtežih problema u mobilnoj robotici, poput lokalizacije u 3D prostoru temeljenoj isključivo na vizualnoj percepciji ili navigaciji robota u okruženju drugih dinamičkih objekata.

Edin upozorava da se greške događaju i u proizvodnji, gdje su mahom vezane uz kvalitetu ožičenja i montaže komponenti ili pak kalibracije različitih senzora na robotu. One se detektiraju tek u proizvodnoj kontroli kvalitete ili kad dospiju do QA testiranja. Edin objašnjava da je intenzitet ovakvih grešaka veći prilikom proizvodnje novih, ne još duboko testiranih, proizvoda.

… ali i one koje je nemoguće predvidjeti

S druge strane, Edin kaže kako se neočekivani problemi uglavnom pojavljuju tek kasnije u razvojnom procesu, stoga su i najbolniji, jer je manevarskog prostora za popravak malo:

Primjer jedne takve greške je problem s komponentama koje se kupuju od drugih proizvođača kao komercijalno spremno rješenje, za koje se kroz naša interna testiranja detektiraju mnogi problemi. U tom trenutku potrebno je reklamirati takav proizvod te raditi s proizvođačem te komponente na rješavanju bugova.

Taj proces je poprilično bolan iz više razloga, navodi Edin:

• “Zato jer niste očekivali da kupljena komponenta od renomirane kompanije može imati grešku te vjerujete da bi sve trebalo raditi onako kako piše u specifikaciji;

• jer vas čeka objašnjavanje i uvjeravanje proizvođača da ste napravili sve što ste mogli prema uputama te da je problem s njihove strane;

• zato što ste u neizvjesnosti hoće li proizvođač popraviti problem u najkraćem mogućem roku i hoćete li uspjeti isporučiti proizvod na vrijeme;
• te konačno, zato što niste u potpunosti pod kontrolom nad problemom koji vas je zadesio.”

Tomislav objašnjava da neočekivane greške ponekad dolaze iz interakcije robotskih sustava s okolinom u kojoj se testiraju ili rade, a ponekad iz nesavršenosti senzora. Drugi dio grešaka dolazi iz nepredvidljivosti dinamičkih okruženja u kojem se roboti gibaju.

Primjerice, navodi Tomislav, može se dogoditi da određeno gibanje drugih dinamičkih objekata, poput viličara, može stvoriti uvjete u kojima se otkriju neočekivani nedostaci. Takve greške se najčešće otkriju tek kod testova u stvarnom okruženju jer je teško precizno modelirati uvjete koji bi ih razotkrili u simulatoru.

Manja ili teža, svaka greška se plaća

Edin napominje da su najčešće i najjednostavnije greške one softverskog/firmverskog karaktera jer, osim vremenskog troška, ne uzrokuju značajne materijalne troškove. No što je greška bliža fizičkom djelu robota to je teža i bolnija za ispraviti, pogotovo ako je već značajan broj jedinica proizveden. 

Prema Edinu, neke od jednostavnijih grešaka u ovom pogledu su nesavršenosti u izradi komponenti koje naručuju od proizvođača prema njihovim nacrtima, a koje uzrokuju probleme u sastavljanju robotskih sustava. Srećom, takve greške se najčešće poprave na licu mjesta od strane tima za montažu te nisu visokorizičnog i dugotrajnog karaktera. 

Primjer teže greške, smatra Edin, bio bi odabir ključnih komponenata (primjerice, senzora ili upravljača) na kojem se sustav bazira te naknadno detektiranje razloga zašto je tu komponentu potrebno zamijeniti.

Tomislav misli da teže greške često proizlaze iz nedovoljno dobro napisanih zahtjeva za pojedine module koji onda uzrokuju da arhitektura pojedinog rješenja ne podržava na dovoljno jednostavan i smislen način ispravljanje takvih grešaka. U tim slučajevima potreban je značajniji zahvat u programski kod koji može potrajati od nekoliko tjedana do nekoliko mjeseci, a u rijetkim slučajevima i promjenu cijele arhitekture rješenja.

Manje greške su lako ili relativno lako ispravljive, a u najboljem slučaju zahtijevaju samo promjenu konfiguracije robota, kaže Tomislav i otkriva nam primjer jedne manje neočekivane greške s kojom su se susreli:

Na jednom od naših prvih Proof-of-Concept (PoC) projekata pokazalo se da je zbog specifičnog tereta koji robot prevozi potrebno okrenuti smjer vožnje gibanja robota. Iako se u početku potreba za promjenom smjera gibanja činila kao značajna promjena koja obuhvaća više modula, pokazalo se da se u većini komponenti svela na promjenu parametara, što smo mogli zahvaliti dobrom dizajnu pojedinih komponenti i cijelog sustava.

Što kad korisnik otkrije grešku?

Edin napominje da se greške također događaju prilikom puštanja robota u rad. Greške u toj fazi su češće kod PoC deploymenta novih proizvoda u izazovna okruženja, dok su rjeđe kod stabilnih proizvoda. 

Najskuplje je ispravljati greške u produkciji, ističe Tomislav. Greške u produkciji ne narušavaju samo reputaciju firme, već i zahtijevaju popriličan angažman inženjera koji, za posljedicu, gube fokus za stvari kojima su se u to vrijeme trebali baviti, a nekad i samopouzdanje. 

Edin dodaje da je u takvim situacijama iznimno važno biti transparentan i iskren prema kupcu te što prije angažirati inženjering i customer success tim sa svrhom rješavanja problema. U svim slučajevima Gideon uvijek osigurava prisutnost svojih timova na lokaciji kupca dok se ne uvjere da je korisnik u potpunosti sposoban preuzeti rad s robotima.

Prema Tomislavu, ključ smanjenja rizika pojave grešaka u produkciji leži u dobro strukturiranom i dugotrajnom QA procesu. Budući da je kvalitetan QA proces ponekad u konfliktu s planovima kompanije za raniji izlazak proizvoda na tržište, potrebno je pronaći odgovarajući balans.

Ključno je znati nositi se s greškama

Greške na koje inženjeri Gideona nailaze i koje su možda propustili tijekom razvoja robota ne predstavljaju samo intrigantne tehničke izazove, nego i sa sobom nose određen pritisak i stres.

Edin priznaje da se radi o poprilično psihički izazovnom poslu: 

Osim osjećaja velike odgovornosti prema korisnicima čiji procesi ovise o našim robotima tu je i pritisak koji nastaje zbog opasnosti koje robot može prouzročiti ako nije dovoljno dobro testiran. Roboti prevoze teške terete te rade u blizini ljudi te bilo kakve incidentne situacije su posebno opasne. To zahtijeva veliku pozornost u razvoju, provjeri kvalitete i proizvodnji kako bi se osigurala velika pouzdanost kod krajnjih korisnika što je posljedično vrlo psihički izazovno za sve.

Tomislav navodi kako razvojni inženjeri, a posebice oni najiskusniji, često donose odluke oko odabira algoritama za koje ne mogu sa sigurnošću tvrditi da će riješiti sve izazove s kojima se roboti susreću. Međutim, ističe da su u Gideonu s vremenom stekli povjerenje u svoje robote i tehnologiju koja ih pogoni te da im je stečeno iskustvo temelj za upravljanje i svladavanje psihičkih pritisaka s kojima se suočavaju.

Ako se želite priključiti timu vizionara, u jednoj od rijetkih robotskih tvrtki u Hrvatskoj, svakako provjerite njihove stranice karijera.