Kategoria: Artikkeli

Pelaajan toimijuus videopelien tarinankerronnan kontekstissa

Interaktiivisessa tarinankerronnassa vaikuttavat pitkälti samat säännöt, kuin tarinoissa yleensä. Pelaajan toimijuus on kuitenkin yksi sellainen kiinnostava käsite, jolla on erityisesti videopelien maailmassa merkittävä vaikutus. Tässä artikkelissa pureudun pelaajan toimijuus -käsitteeseen videopelien näkökulmasta ja pyrin avaamaan sen merkitystä niiden tarinankerronnassa. Tavoitteena on lisätä ymmärrystä interaktiivisen tarinankerronnan uniikeista tulokulmista verrattuna perinteiseen tarinankerrontaan.

Kokijan toimijuus

Englannin kielellä pelitutkimuksessa käytetään termiä “player agency”, joka on käännetty suomen kielellä pelaajan toimijuudeksi. Kyseessä on siis suora käännös ja joissakin yhteyksissä termi onkin suomennettu myös muotoon “pelaajan toimivalta”. Toimivalta tavallaan avaa termiä paremmin ja kuvaa nimenomaan pelaajan “valtaa” pelin tapahtumiin, mutta toimijuus on kuitenkin vaikiintuneempi termi ja yleisessä käytössä pelitutkimuksessa. Käytän kuitenkin molempia suomennoksia tässä artikkelissa.

Perinteisissä tarinankerronnan välineissä, kuten kirjoissa ja elokuvissa toimijuudella viitataan usein siihen, kuinka tarinan seuraaja muodostaa juonesta omia hypoteesejaan, jotka lopulta toteutuvat tai jäävät toteutumatta riippuen siitä, millainen teos on kyseessä (Eichner 2014, 164). Usein tämä kulminoituu viimeistään, kun tarinan loppuratkaisuna rakastavaiset saavat toisensa, ja tarinan seuraaja huudahtaa esimerkiksi “minä arvasin!”. Tällöin katsojalla on ollut jonkinlainen kokemus siitä, että hän osallistuu tarinan kulkuun aktiivisesti. Hypoteeseja saattaa syntyä esimerkiksi elokuvan aikana useita eri kohdissa tarinaa ja katsoja oppii hiljalleen mitä hänen tulee odottaa elokuvalta. Videopeleissä toimijuus menee kuitenkin syvemmälle ja ottaa huomattavasti aktiivisemman roolin, sillä pelaaja – toisin kuin katsoja tai lukija – harvoin on pelkkä sivusta seuraaja. 

Pelaajan toimijuudella pyritään kuvaamaan pelaajan tai interaktiivisen median käyttäjän kykyä tehdä merkittäviä päätöksiä ja nähdä näiden päätösten sekä valintojen seuraukset (Murray 2017, 126). Pelien kontekstissa tämä siis tarkoittaa sitä, että pelaaja tekee päätöksen pelin kontekstissa ja hän olettaa, että päätöksellä on jotakin väliä ja osaa arvioida, mitä siitä seuraa. Toisinaan peli saattaa tarkoituksella johtaa pelaajaa myös harhaan ja päätöksellä voi olla myös yllättäviä seurauksia. Toimijuudessa on kuitenkin kyse siitä millainen kontrollin tunne pelaajalla on pelin tapahtumiin, olivat ne sitten odotettuja tai odottamattomia (Bryant & Giglio 2015, 140). Peleissä pelaajalla on usein mahdollisuus tehdä tarinan kulkuun vaikuttavia päätöksiä ja toimijuus on terminä kehitetty kuvaamaan tätä kykyä ja siitä juontuvaa kontrollin tunnetta. Pelaaja kokee, että hänen valinnoillaan on väliä. 

Pelaaja asetetaan vaikeaan tilanteeseen.

Toimijuus on kuitenkin aina liitännäinen pelaajan ymmärrykseen pelistä. Näinollen, jotta pelaajalle syntyy tunne toimijuudesta, niin päätösten ei todellisuudessa tarvitse olla edes merkittäviä. Oikeastaan pelaajan tulee vain uskoa, että hänellä on kyky vaikuttaa tapahtumien kulkuun (Heussner 2015, 106). Tärkeää ei siis välttämättä ole se millä tavalla peli on interaktiivinen vaan, että pelaajalla on tunne interaktiivisuudesta (Eichner 2014, 61). Pelaajan toimijuus esiintyy peleissä hyvin eri tavoin ja yksinkertaisimmillaan kyse on siitä, että pelaaja onnistuu pelin aikaisemmassa tehtävässä ja sen vuoksi seuraavassa tehtävässä tapahtuu tai on tapahtunut jotain. 

Yksinkertaisimmillaan pelaajan toimijuus näkyy tarinamaisina syy-seuraussuhteina. Jos tehtävässä A. pelaaja onnistuu tuhota pahan terroristiorganisaation tukikohta, niin tällöin tehtävässä B. organisaatio on kostoksi kidnapannut siviilejä, jotka pelaajan on nyt vapautettava. Tästä syntyy tunne, että pelaajan aikaisemmilla teoilla on suora merkitys pelin myöhemmissä vaiheissa. Tässä yksinkertaisessa esimerkissä pelaaja tekee vain sen, mitä peli ohjaa hänet tekemään, mutta siitä huolimatta hänestä tuntuu, että pelimaailma muuttuu hänen tekojensa seurauksena. 

Toisinaan pelaajalla voi siis olla hyvin paljon suoraa valtaa pelin tapahtumiin, toisinaan valta on vain tunne kontrollista. Tunne on kuitenkin erittäin olennainen osa toimijuutta. Varsinkin monimutkaisemmissa peleissä pelaaja tekee enemmän päätöksiä, jotka kehittäjän tulee ottaa huomioon, jos hän haluaa ylläpitää toimijuuden tunnetta (Heussner 2015, 106). Jos pelaaja kokee, että hänen päätöksillään ei ole väliä, niin toimijuus katoaa ja usein immersio peliin heikkenee. Hyvänä esimerkkinä toimijuuden mahdollistamisesta voidaan pitää esimerkiksi interaktiivista tarinavetoista peliä “Detroit: Become Human” (Quantic Dream 2018). Peli sijoittuu tulevaisuuden Detroittiin (kaupunki Michiganissa, Yhdysvalloissa), jossa kehittyneet androidit ovat yleisesti osa yhteiskuntaa. Pelaaja ohjaa kolmea androidia: Connoria, Markusta ja Karaa, joilla jokaisella on oma uniikki tarinansa, johon pelaajan valinnat ja päätökset suoraan vaikuttavat. Pelaaja siis pelaa näillä kolmella hahmolla ratkaisten erilaisia pulmia, tehden dialogivalintoja sekä tutkimalla ympäristöä ja näin omien päätöstensä kautta ohjaa heidän tarinoidensa kulkua. Tarinasta sen enempää paljastamatta voidaan kertoa, että pelissä leikitellään ajatuksella itsetietoisesta tekoälystä. Detroit: Become Humanissa pelaajan päätökset määrittävät lopulta koko tarinan kulun ja tarina haarautuu päätösten mukaan useisiin mahdollisiin lopputuloksiin. 

Detroit: Become Human:in alkuvalikossa pelaajaa avustaa androidi, jonka suhtautuminen pelaajaan muuttuu pelin aikana.

Tarinan monet muodot

Videopelien tarinat on usein jaoteltu kolmeen kategoriaan: lineaarisiin (linear), haarautuviin (branching) ja avoimiin (open) narratiiveihin (Heussner 2015, 107). Lineaarisissa kertomuksissa tarina etenee yleensä kohtuullisen suoraa eeteenpäin ja olennaista tällaisessa tarinassa on se, että juonen käänteet ovat samat jokaiselle pelaajalle, eivätkä pelaajan päätökset suoranaisesti vaikuta tarinan kulkuun. Haarautuvissa kertomuksissa pelaaja tekee päätöksiä, joilla on suora vaikutus tarinaan. Pelaajan tekemät päätökset vaikuttavat seuraavaan tarinan vaiheeseen ja tässä seuraavassa vaiheessa pelaaja tekee taas uusia päätöksiä. Pelin tarina siis ikään kuin haarautuu sitä mukaan, kun uusia päätöskohtia tulee, mutta yleensä tarinan kulku myös palaa jossakin kohtaa takaisin määritetylle raiteelle. Viimeisenä ovat avoimet kertomukset, joissa tarina on ripoteltu maailmaan pelaajan vapaavalintaisessa järjestyksessä nautittavaksi. Pelaaja siis päättää mitä hän tekee missäkin järjestyksessä ja päättääkö jättää jotkin tehtävät kokonaan tekemättä. Pelaajan toimijuuden näkökulmasta kaikki kategoriat ovat erilaisia ja niissä toimijuus esiintyy hyvin monin tavoin. Tietynlainen toimijuus kuitenkin kuuluu kaikkiin tarinankerronan muotoihin, mutta sen esiintymistapa vaihtelee aina kategoriasta riippuen. Käyn seuraavassa läpi nämä kategoriat vielä pelaajan toimijuuden näkökulmasta.

Lineaariset narratiivit tarjoavat pelaajalleen usein kaikkein vähiten toimivaltaa, sillä tapahtumat ovat aina etukäteen määriteltyjä. Lineaarisuus ei siis viittaa tarinaan ajallisesta näkökulmasta vaan puhtaasti rakenteellisesti. Lineaarinen narratiivi etenee tarinankerronnallisesta näkökulmasta ennalta määrättyä polkua. Toimijuuden vähyys ei kuitenkaan tarkoita sitä, etteikö pelaajalle pitäisi kuitenkin mahdollistaa tunne toimijuudesta (Heussner 2015, 109). Lineaariset narratiivit hyötyvät erityisesti aikaisemman esimerkin “tehtävä A johtaa tehtävään B” -tyylisestä toimijuudesta, jonka ansiosta pelaajasta tuntuu siltä, että hänen toiminnallaan on tarinan kannalta väliä. Tämän kaltainen toimijuus on lähellä perinteisen tarinankerronnan syy-seuraussuhdeajattelua, joka toimii hyvän tarinankerronnan selkärankana. Vaikka pelaaja ei siis varsinaisesti teekään pelin kannalta merkittäviä päätöksiä, niin ainakin hän kokee olevansa niiden toteuttaja ja täten vastuussa tekojensa seurauksista. Tunnettuja lineaarista narratiivia edustavia videopelejä ovat esimerkiksi Last of Us, Bioshock -pelisarjan pelit, Half-Life 2 ja What Remains of Edith Finch. 

Lineaariset narratiivit ovat tuttuja pääasiassa elokuvista sekä kaunokirjallisuudesta ja yleensä videopelien tarinat saavatkin osakseen kiitosta silloin, kun kyse on haarautuvista narratiiveistä. Haarautuvat narratiivit ovat kategorisesti sellaisia, joissa pelaajan pääsee tekemään tarinan kannalta valintoja ja näillä valinnoilla on väliä. Tälläisissä peleissä pelaajan toimijuus näkyy vahvana. Haarautuvissa kertomuksissa on pääasiassa kyse nimenomaan pelaajan päätöksistä ja pelin suhteesta niihin. Parhaimmillaan peli kunnioittaa pelaajan tekemiä päätöksiä ja tehty päätös johtaa hänet erilaiseen tilanteeseen, kuin toisenlainen päätös samassa tilanteessa olisi johtanut (Heussner 2015, 113). Monimutkaisimmillaan aikaisemmin tehty päätös johtaa sitten puolestaan uusiin päätöksiin ja lopulta kudottu päätösten verkko vie lopputulemaan, joka on jokaiselle pelaajalle uniikki. Äärimmäisen hyvä esimerkki haarautuvan kertomuksen suhteesta pelaajan toimivaltaan on aikaisemmin mainittu Detroit: Become Human -videopeli, johon pureudun vielä enemmän artikkelin lopuksi. Muita tunnettuja haarautuvaa narratiivia edustavia pelejä ovat esimerkiksi Mass Effect -pelisarjan pelit, The Stanley Parable, The Walking Dead -pelisarja sekä Firewatch. 

What Remains of Edith Finchissä pelaaja ei tee päätöksiä, mutta toteuttaa niitä.

Tarinassa on aina oltava jonkinlainen rakenne – alku, keskikohta ja loppu – mutta rakenteen sisällä olevat osaset on mahdollista järjestellä monin tavoin. Avoimissa narratiiveissa pyritään juuri siihen, että pelaaja saa valita osien järjestyksen itse (Heussner 2015, 121).  Avoimissa narratiiveissa tarinankerronta etenee sitä mukaa, kun pelaaja päättää sitä seurata, eikä peli itsessään pakota pelaajaa varsinaisesti tekemään yhtään mitään (Bryant & Giglio 2015, 111). Pelaajalla on siis suuri valta päättää miten hän tarinan kokee, tai ainakin missä järjestyksessä. Toisinaan tämä johtaa siihen, että itse kertomus saattaa kärsiä, mutta se kuuluu avoimen narratiivin luonteeseen. 

Avoimet kertomukset ovat usein eräänlaisia avoimen maailman (open world) pelejä, joissa pelaaja seikkailee omaan tahtiinsa ja omien mieltymystensä mukaisesti. Tällaisissa peleissä on usein eräänlainen lineaarinen tai haarautuva päätarina, jota pelaajan odotetaan seuraavan, mutta pelin pelaaminen ei sitä vaadi. Toisinaan pelaajan toimijuus on tällaisissa peleissä niin vahvaa, että koko pelin maailma muuttuu pelaajan valintojen seurauksena. Esimerkiksi aikaisemmin pelaajalle ystävälliset sivuhahmot voivat kuulla tämän toisaalla tekemistä hirveyksistä ja muuttaa suhtautumistaan pelaajaan. Hyviä esimerkkejä avoimen kertomuksen peleistä ovat esimerkiksi Elder Scrolls -pelisarjan pelit, Grand Theft Auto -pelisarjan pelit, The Legend of Zeld: Breath of the Wild ja No Man’s Sky.

Pelaajan toimijuus vahvana

Hyvässä pelattavuudessa on usein kyse siitä, että pelaaja pääsee ratkaisemaan ongelmia tekemällä päätöksiä ja mitä enemmän pelaaja näitä päätöksiä pääsee tekemään, sitä houkuttelevampaa pelin pelaaminen lopulta on (Dille & Platten 2008, 87). Detroit: Become Humanissa on kyse nimenomaan pelaajan valinnoista. Pelatessaan pelaaja kohtaa useita monimutkaisia sosiaalisia ja eettisiä dilemmoja, joita hänen on ratkaistava päästäkseen etenemään pelin tarinassa. Ongelmia sisältävät tilanteet ovat luonteeltaan sellaisia, että niihin ei varsinaisesti ole oikeita ratkaisuja, on vain pelaajan tekemiä päätöksiä sekä niiden seurauksia. Pelaaja immersoituu tarinaan, joka tuntuu elävän hänen toimintansa mukaan: yhdessä kohtaa pelaajan päätös voi johtaa ystävän kuolemaan, toisessa hetkessä nopea päätös pelastaa hengen. Päätösten tekemisen ansiosta pelaajalla on vahva yhteyden tunne pelin tapahtumiin ja sen hahmoihin. Kyse ei enää ole siitä, että pelaaja tahtoo tietää miten pelin tarina etenee, vaan miten minun tarinani etenee ja mihin omat päätökseni johtavat.

Seuraavassa käytän Detroit: Become Humania esimerkkinä pelaajan toimijuudesta videopeleissä. Tarkemmin sanottuna käytän yhtä lyhyttä kohtausta osoittaakseni pelaajan toimijuuden merkityksen ja se toimii kiinnostavana esimerkkinä siitä, miten pelaaja saadaan toimijuuden avulla immersoitua peliin. Detroit: Become Human on arvostettu esimerkki hyvin toteutetusta haarautuvasta narratiivista ja pelaajan toimijuudesta sen sisällä: jokainen pelaajan päätös on merkityksellinen, jopa toisinaan monella tapaa.  Pelissä on tarinasta liikaa paljastamatta seuraavanlainen tilanne: 

  1. Juokset  ystäviesi kanssa käytävää pitkin, kun teidät yllätetään ja…
  2. alkaa tulitaistelu, jonka aikana pelaajan on suoritettava joukko nopeita liikkeitä (sarja reaktiopohjaisia painalluksia peliohjaimella), jotta hän ei jää itse kiinni, mutta sitten…
  3. yksi ystävistäsi kaatuu ja pelaajan on päätettävä pelastaako hän tämän.

Tässä tilanteessa pelaaja on massiivisen päätöksen edessä: pelastaako hän ystävänsä vaiko pakenee itse? Ystävän pelastaminen kuulostaa sankarilliselta, mutta toisaalta pelaaja haluaa itse selvitä tilanteesta ehjin nahoin. Tässä tilanteessa pelaajan toimijuus on vahvaa: hän on päätynyt tähän tilanteeseen aikaisempien valintojensa seurauksena ja nyt hänen on tehtävä kriittinen päätös, joka vaikuttaa peliin tulevaisuudessa. Jos pelaaja jättää ystävänsä, niin tämä voi kuolla tai jäädä vangiksi. Saako pelaaja mahdollisuuden pelastaa ystävänsä myöhemmin vai palaako tämä kenties vihollisena pelin myöhemmissä vaiheissa? 

Panokset aikaisemmin kuvatussa tilanteessa ovat kovat, sillä peli on tehnyt selväksi pelaajalleen, että tämän päätöksillä todellakin on seurauksensa. Aikaisemmissa vaiheissa pelaaja on tehnyt useita valintoja, jotka ovat johdattaneet hänet tähän käytävään juuri tässä hetkessä ja tismalleen näiden henkilöiden kanssa. Hänen valintansa on juuri aikaisemmin johtanut siihen, että tulitaistelu on alkanut. Pelaaja ei tietenkään tiedä olisivatko jotkin toisenlaiset valinnat voineet tuoda hänet tähän samaan tilanteeseen, mutta pelin immersion kannalta sillä ei ole mitään väliä. Pelaajalle on muodostunut vahva tunne siitä, että hän on aktiivinen toimija ja päätösten tekijä. 

Tämä osoittaa hyvin sen, miten pelit eroavat muista tarinankerronnan välineistä: pelaaja tekevät aina valintoja (Bryant & Giglio 2015, 145). Valinnat voivat olla ihan pieniä, kuten “kävele tähän suuntaan” tai järistyttävän suuria koko pelin maailmaa muokkaavia päätöksiä, mutta olennaista on se, että mitä enemmän pelaaja pääsee valintoja tekemään, sitä koukuttavampaa pelaaminen on (Dille & Platten 2008, 87). Detroit: Become Humanin maailmassa pelaajalle on annettu valta tehdä kaikki pelihahmon valinnat ja hän on elänyt pelin tarinaa tämän hahmon läpi. Käytävää pitkin kuolemaa pakenevasta hahmosta on muodostunut pelaajalle tärkeä ja hän välittää tämän hyvinvoinnista. Kun pelaajan on aika valita, päätös ei ole vain irrallinen napin painallus. 

Jokaisen pelaajan kokemus tästä käytäväkohtauksesta on täysin uniikki ja siksi myös mieleenpainuva. Jollekkin pelaajalle tämä kohtaus on käytännössä yhdentekevä: apua tarvitseva ystävä ei ole hänelle tärkeä, pelaaja päättää paeta. Joku toinen pelaaja ei välttämättä edes päädy tähän tilanteeseen: hän on välttänyt käytävän juoksemisen menemällä toista reittiä. Mutta sitten jollekkin pelaajalle tämä on koko pelin ja sen tarinan kannalta merkittävin päätös: kaatunut ystävä ei olekaan kuka tahansa, hän on pelaajan pelaaman hahmon rakastettu. Kohtaus on hyvin erilainen eri pelaajien näkökulmasta ja se johtuu täysin siitä, että on immersoinut itsenstä täysin pelin maailmaan tekemiensä päätösten vuoksi. Miksi minä välitän?

Pelaajan toimijuuden merkitys

Videopelit kertovat tarinoita tavoilla, joihin muut tarinankerronnan tavat eivät pysty, sillä pelit antavat vallan pelaajalle. Tai ainakin kokemuksen vallasta. Katsoja iloitsee siitä, kun rakastavaiset saavat toisensa elokuvan lopussa. Hän oli arvannut, että näin tulee käymään. Elokuvan katsoja ei voi vaikuttaa tarinaan, hän voi ainoastaan toivoa, että hahmot tekevät oikeat valinnat ja pelätä, että he eivät (Bryant & Giglio 2015, 144) Pelaaja sen sijaan saattaa henkäistä helpotuksesta videopelin lopputekstien rullatessa: hänkin on toivonut ja pelännyt. Toivonut, että hän tekee oikeat valinnat ja pelännyt, että ei. Tämä on videopelien olennainen ero, pelaajan toimijuuden ero. 

Videopelikehittäjän näkökulmasta on siis hyvä ymmärtää, että kaikissa tilanteissa pelaajan toimijuutta on kannattavaa kunnioitaa. Peliä kirjoitettaessa tärkeintä on ensin nähdä tarina pelaajan näkökulmasta, (Dille & Platten 2008, 87), oli peli sitten kertomuksena lineaarinen, haarautuva tai avoin, niin pelaajalle on syytä muodostaa jonkinlainen kontrollin tunne.  Me voimme immersoitua tarinaan ilman kokemusta toimijuudesta – ihmiset ovat tehneet sitä jo vuosituhansia – mutta vasta nyt meidän on mahdollista kokea niitä samaan tapaan, kuin koemme elämämme: aktiivisina toimijoina.

Lähteet

Bryant, R. D. & Giglio, K. (2015). Slay the Dragon: Writing Great Video Games. California: Michael Wiese Productions.

Dille, F & Platten J. Z. (2008). The Ultimate Guide to Video Game Writing and Design. New York: Lone Eagle Publishing Company.

Heussner, T., Finley, T. K., Hepler, J. B. & Lemay, A. (2015). The Game Narrative Toolbox. Boca Raton, Florida: CRC Press.

Eichner, S. (2014). Agency and Media Reception: Experiencing Video Games, Film, and Television. Wiesbaden: Springer VS

Murray, J. H. (2017). Hamlet on the Holodeck, updated edition: The Future of Narrative in Cyberspace. Cambridge: MIT Press.

—— 21.06.2023 ——

Artikkelin ovat arvioineet FrostBitin julkaisutoimikunta, johon kuuluu Heikki Konttaniemi, Toni Westerlund, Jarkko Piippo, Tuomas Valtanen, Pertti Rauhala ja Tuuli Nivala. Artikkelijulkaisut löytyvät FrostBitin julkaisublogista.

JAA MEDIASSA

Samuli Valkama, Asiantuntija

Samuli Valkama työskentelee asiantuntijana FrostBit ohjelmistolaboratoriossa Lapin AMK:ssa. Työtehtävien painopiste on hanke- ja pelisuunnittelussa, mutta erityisesti videotuotantojen määrän lisääntyminen on ohjannut yhä enemmän audiovisuaalisen alan asiantuntijatehtäviin.

—— Taiteen maisteri (Media), Lapin Yliopisto

Koneoppimisen soveltaminen

Syksyllä 2022 tuhansia marjakuvia arkistoitiin suurten kuvametatietojen kanssa, viimeisteltiin koneoppimismalli ja pidettiin projektin loppuseminaari. Marjamasiina-projekti oli päättynyt ja se oli kiehtova matka käytännön koneoppimiseen.

Marjakone-hanketta rahoitti Interreg Nord, mukana olivat Luonnonvarakeskus (LUKE) ja Norjan biotalouden tutkimuslaitos (NIBIO), kehittäjänä toimi Frostbit Software Lab Lapin ammattikorkeakoulusta. Hankkeen tavoitteena oli tutkia, onko mahdollista koneoppimisen avulla tehdä nykyisestä marjasadon arvioinnin mittausprosessista vähemmän riippuvainen manuaalisesta työstä, jolloin kenttämittauksia voidaan tehdä huomattavasti enemmän ja avata uusia tapoja marjasadon arviointiin.

Nykyinen marjasadon arvioinnin mittaus tehdään laskemalla manuaalisesti jokainen yksittäinen marja eri materiaaleista luodun kehikon sisällä (Kilpeläinen 2016). Kehys muodostaa tarkalleen yhden m²:n alueen. Metsässä on viisi kehikkoa, jotka on asennettu maalajiltaan vaihteleviin paikkoihin (marjahavainnot.fi 2022). Kaiken tämän manuaalisen työn jälkeen aineisto ei ole vielä tarpeeksi kattava tarkempien tutkimusten tekemiseen, sillä prosessi on sekä kallis että työläs (Bohlin 2021).

Marjamasiina-hankkeessa tutkittiin tapaa, miten syväoppimista voitaisiin käyttää apuna marjojen laskennassa ja siten tehdä prosessista huomattavasti kevyempi. Suunnitelmana oli käyttää syväoppimista hyödyntävää tietokonenäköä marjojen havaitsemiseen ja luoda toimiva mobiilisovellusprototyyppi, taustajärjestelmineen. Alkuperäiseksi kohdelajiksi haluttiin vain mustikka (Vaccinium Myrtillus), mutta mukaan otettiin myös puolukka (Vaccinium Vitis-idea), jotta saataisiin kattavampi kuva siitä, miten tekniikka toimisi eri lajeissa. Molemmat marjat laskettiin kasvuvaiheissa ”kukka”, ”raaka” ja ”kypsä”.

Syväoppimisen tekniikat

Tärkeimmät vaiheet Marjamasiina-hankkeen tehtävän täyttämiseksi olivat tietokoneen syväoppimisen mallin kouluttaminen marjojen tunnistamiseksi kuvista ja tämän tietokonenäön avulla laskea marjat kuvista sekä verrata havaittua marjojen lukumäärää kenttämittauksella laskettuun marjojen määrään.

Kuva 1. Keinotekoinen neuroverkko (ANN).

Perinteinen keinotekoinen neuroverkko (Artificial Neural Network, ANN) muodostuu tuloneuroneista, piilokerroksista ja lähtökerroksesta (Kuva 1). Kuvien luokittelussa sisääntulokerroksen arvoiksi lisätään kuvan pikselien arvot (Gogul 2017). Weight- ja bias -arvot neuroneissa ja yhteyksissä johdetaan koulutusprosessissa. Weight ja bias -arvoja käytetään tulosarvojen laskemiseen sisääntuloarvoista, kun kaikki alkuperäiset pikseliarvot etenevät vasemmalta oikealle saapuen lopulta lopulliseen ulostulokerrokseen, joka edustaa tulosta numeerisessa muodossa.

Kuva 2. Konvolutionaalinen neuroverkko.

ANN:iin verrattuna kuvien luokittelutulokset paranevat merkittävästi, kun siirrytään läpimurtoteknologiaan, konvoluutineuroverkkoon (Convolutional Neural Network, CNN) (Marmanis 2016). CNN-arkkitehtuuri parantaa ANN-arkkitehtuuria lisäämällä konvoluutio- ja pooling-kerroksia. Uudet kerrokset yksinkertaistavat ja poimivat kuvan piirteitä säilyttäen samalla piirteiden sijainnin alkuperäiseen kuvaan nähden (kuva 2). Pooling-kerrokset skaalaavat alkuperäisen kuvan pienemmäksi ja konvoluutiokerrokset havaitsevat kuvasta enemmän korkeamman asteen piirteitä. CNN-arkkitehtuurin avulla tietokonenäkö kykenee ihmisen tasoiseen tai korkeampaan tarkkuuteen (Galanty 2021).

CNN-arkkitehtuuri luokittelee vain yhden kuvan yhtenä kokonaisuutena. Projektin tavoitteena oli tietokonenäön avulla havaita yhdestä kuvasta useita eri kasvuvaiheessa olevia marjoja. Siksi tarvitaan objektin havaitsemisarkkitehtuuria kuvanluokitteluarkkitehtuurin sijaan, sillä objektin havaitsemisella pyritään myös paikantamaan instanssit niiden luonnollisesta taustasta (Liu 2018).

Kuva 3. YOLO (You Only Look Once) -objektien havaitseminen.

Projektissa käytettiin objektin havaitsemisarkkitehtuurina YOLO-algoritmia (You Only Look Once). YOLO on suunniteltu nopeaksi, yksinkertaiseksi ja tarkaksi (Redmon 2015). YOLO-prosessi jakaa kuvan ruudukkoon ja havaitsee kohteet kussakin ruudukossa ja tunnistaa kohteiden ulottuvuudet (Bounding Box). Bounding box -tulokset yhdistetään kunkin ruudukon luokittelutodennäköisyyteen tarkempien tulosten suodattamiseksi (Redmon 2015).  YOLO-prosessi on visualisoitu kuvassa 3. Hankkeessa käytettiin YOLO:n versiota 5, koska se on rakennettu PyTorch-kehitysalustan avulla (Solawetz 2020), mikä helpotti sen käyttöönottoa. Lisäksi YOLOv5 mahdollistaa datan augmentoimisen koulutusprosessissa (Benjumea 2021).

Datasta prototyypiksi

Syväoppimisen koulutusaineisto muodostettiin ottamalla tuhansia marjakuvia. Noin 10 000 kuvaa kerättiin pääasiassa kuluttajatason matkapuhelimilla. Yksi alkuperäisen projektisuunnitelman ideoista oli päästä lähemmäs marjasadon mittausten joukkoistamista helppokäyttöisen mobiilisovelluksen avulla. Tämän vuoksi koulutus oli tarkoitus tehdä pääosin yleisesti saatavilla olevilla puhelimilla.

Kuva 4. Esimerkki kuudesta luokassa annotoidussa aineistosta.

Aineiston keräämisen jälkeen ja sen aikana aloitettiin annotointiprosessi. Annotointiprosessi oli hyvin työläs, eikä kaikkia kuvia saatu annotoitua resurssien rajallisuuden vuoksi. Annotaatioprosessi on yksinkertaisuudessaan oikean marjaluokan manuaalinen piirtäminen kuvan päälle. Merkittävä vaikeus oli se, että marjat ovat pieniä ja varsinkin raakamarjat piiloutuvat hyvin taustaa vasten. Kun annotoitujen kuvien pääaineisto oli valmis, aloitettiin lisäannotointiprosessit aineiston tasapainottamiseksi. Tasapainoinen aineisto on koulutusaineisto, jossa on suunnilleen yhtä monta annotointia kustakin luokasta. Lopullinen aineisto muodostui kuudesta luokasta, jotka ovat esitetty esimerkkien avulla kuvassa 4.

Kuva 5. Annotoitu laskentakehys.

Tiheyden kaava on instanssien lukumäärä jaettuna pinta-alalla. Tietokonenäköä käytettiin marjojen lukumäärän arviointiin, mutta koko kuvan pinta-ala-tietoa ei ollut saatavilla laskennan tukena. Tämän vuoksi myös kenttämittauksen laskentakehykset annotoitiin tiheyden arviointia varten kuvan 5 mukaisesti. Kehyksen monikulmiota käytettiin syväoppimisella havaittujen marjojen rajaamiseen, ja näin kaikki kuvaan jääneet marjat olivat sisällä yhden m²:n tai 0,25 m²:n alueelta. Kahta erikokoista laskentakehystä käytettiin, jotta olisi mahdollista verrata korrelaatioeroja lähempänä ja kauempana maasta otetuissa kuvissa.

Kuva 6. Marjamasiina-hankkeen tehtävät.

Marjamasiina-hankkeen tehtävät havainnollistettiin kuvassa 6. Merkittävä määrä työtä käytettiin koulutustulosten analysointiin ja iteratiiviseen parantamiseen. Koulutustulosten parantaminen tarkoitti sitä, että lisättiin annotaatiota, koska aineisto ei joskus ollut tarpeeksi tasapainossa. Tietokone ei ollut ainoa, jolla oli vaikeuksia marjojen havaitsemisessa. Myös ihmisille annotointi oli vaikeaa, koska kuvissa oli paljon vaikeasti erottuvia marjoja. On todennäköistä, että jos ihmiset ohjeistettaisiin annotoimaan samoja marjakuvia päällekkäin, tulokset vaihtelisivat.

Tärkein aineiston käsittely ennen koulutusta oli kuvan jakaminen pienempiin osiin. Hankkeessa käytetyn YOLOv5-mallin natiiviresoluutio oli 640×640 pikseliä. Suuremman kuvan suoraan käyttäminen tarkoitti sen kutistamista natiiviresoluutioon. Koska kuvat otettiin esimerkiksi 4032×3024-resoluutiolla, yksityiskohtia hävisi merkittävästi kuvaa pienennettäessä, mikä on haitallista marjojen kaltaisten pienten objektien havaitsemisessa. Tämän vuoksi kaikki annotoidut kuvat, jotka olivat annotoitu alkuperäisessä resoluutiossaan, ja kaikki kuvat, joista etsittiin koneellisesti marjoja, jaettiin pienempiin kuviin ennen tunnistamista sekä koulutusta. Aluksi käytettiin monimutkaista kuvanjakoalgoritmia, jossa oli päällekkäisiä zoomaustasoja, mutta jakoprosessi palautettiin yksinkertaisempaan prosessiin yhdellä zoomaustasolla. Yksinkertaisemman prosessin tuomat selkeyden edut olivat suuremmat kuin monimutkaisemman menetelmien käyttö. Jälleen kerran yksinkertaisuus voittaa.

Koulutusiteraatiot eivät sinänsä olleet liian työläitä, mutta syväoppimista parannettiin muokkaamalla aineistoa ja aineiston esikäsittelyä, mikä oli aikaa vievää. Projektiaikaa kului myös jälkikäsittelyyn, sillä koulutustulokset edellyttivät analyysiä ja koulutetun mallin laadun tarkistamista joissakin tapauksissa vertailuaineiston avulla.

Kuva 7. Aineiston annotointien määrä luokittain.

Lopullinen koulutukseen käytetty 640×640 pikseliin normalisoitujen kuvapalojen koulutustietokanta oli 41 101 kuvaa, joissa oli 95 065 annotoitua marjaa. Aineistoa täydennettiin synteettisellä datalla, joka luotiin lisäämällä satunnaisia leikattuja marjakuvia läpinäkyvillä taustoilla erilaisten taustakuvien päälle. Taustakuvat olivat enimmäkseen kampuksen ympäristössä otettuja kuvia ja valkoisia taustakuvia. Kuvassa 7 esitetään lopullisen aineiston tasapaino. Tasapainoa pidettiin kuvaajan perusteella riittävänä.

Kuva 8. Prototyypin backend-arkkitehtuuri.

Kuten kuvassa 8 on esitetty, projektin backend-arkkitehtuuri muodostettiin neljästä erillisestä palvelusta. Protoyypin rajapinta (Prototype backend) oli prototyyppimobiilisovelluksen käyttämä rajapinta. Protoyypin rajapinnan päätehtäviä olivat kirjautumisominaisuuden lisääminen, kuvavarastona toimiminen ladattaville kuville sekä sijaintitiedon ja tulosten tallentaminen. Aineiston tunnistusprosessin (Dataset inference process) -palvelun tehtävänä oli suorittaa tunnistamisprosessi eräajona tuhansille kuville ja tallentaa tulokset data-analyysia varten. Tuloksena havaittuja marjoja käytettiin tiheydenarviointitutkimuksessa. kuvanjakorajapinnan (Pipeline backend) päätehtävänä oli jakaa kuva paloihin ja pyytää koneoppimisrajapintaa (inference backend) etsimään marjoja jokaisesta kuvapalasta. Kun kaikki kuvapalat oli suoritettu koneoppimisrajapinnassa, havaittujen marjojen sijainti kuvapalassa muunnettiin alkuperäisen pääkuvan koordinaatistoon. Lopuksi kaikki tulokset lähetettiin alkuperäisessä pyynnössä määriteltyyn osoitteeseen. Viimeinen rajapinta oli aikaisemmin jo osittain kuvattu koneoppimisrajapinta, joka suoritti koneoppimismallin tunnistaen marjat kuvasta.

Prototyyppisovelluksen kehittäminen aloitettiin heti sen jälkeen, kun ensimmäinen käyttökelpoinen malli oli koulutettu. Tärkein arkkitehtuurinen päätös prototyyppisovelluksen taustapalvelun osalta oli rakentaa varsinainen koneoppimisrajapinta erilliseksi palveluksi. Päätös tehtiin, jotta rajapinta voitaisiin tarvittaessa ottaa käyttöön erillisessä grafiikkaprosessoriyksiköllä (Graphical Processing Unit, GPU) varustetulla palvelimella. Kuvanjakorajapinta kehitettiin erilliseksi palveluksi, jotta prototyyppisovelluksen käyttämää rajapinta voitiin säilyttää mahdollisimman yleisrajapintana. Näin prototyypin rajapinta voitiin helpoiten toteuttaa valmiilla headless API-ohjelman avulla. Kuvanjakorajapinnan erillisyys mahdollisti kuvanjakorajapinnan käytön prototyypin rajapinnan ohi kuvassa 8 esitetyllä tavalla. Modulaarinen arkkitehtuuri erottaa huolenaiheet luotettavammin toisistaan, mutta käytännössä huomattiin, että kehitettäessä useiden palvelujen päivitys hidasti kehitysprosessia merkittävästi ja lisäsi ylläpidon monimutkaisuutta.

Kuva 9. Prototyyppikäyttöliittymä.

Prototyyppisovellus kehitettiin käyttäen Flutter-monialustakehitysympäristöä, joka mahdollistaa sekä IOS-, web- että Android-kehityksen samalla koodipohjalla (GitHub.com 2022). Ollessaan fyysisellä mittauspaikalla, käyttäjä loi uuden paikan prototyypin käyttöliittymästä. Paikan näkymä on kuvassa 9. Paikkanäkymässä näytettiin muun muassa arvioitu marjatiheys. Kohdemarjojen vaihe ja laji määriteltiin useista kuvista havaitun näkyvimmän marjan perusteella. Tiheys arvioitiin kaikkien kuvien keskiarvona ja korjattiin korrelaatioanalyysistä johdetulla lineaarisella regressiokaavalla. Kuvan pinta-alan arviointia testattiin kahdella eri menetelmällä. Ensimmäinen menetelmä oli pinta-alan arviointi marjojen keskikoon perusteella. Toinen menetelmä oli arvioida pinta-ala käyttämällä lisätyn todellisuuden (AR, Augmented Reality) kirjastoa. AR toteutettiin vain Applen IOS-laitteissa.

Tulokset

Hankkeessa saatiin useita erilaisia tuloksia: Syväoppimisen havaintomallin tulokset ja tiheyden arvioinnin tulokset. Tunnistustuloksia käsitellään ensin. Tulokset ovat viimeisestä koulutusiteraatiosta.

Kuva 10. . YOLOv5:n sekoitusmatriisi.

YOLOv5-syväoppimisprosessissa annotoitujen kuvapalojen aineisto jaettiin kolmeen osaan: Koulutus- testi- ja validointiaineisto. Koulutusaineistoa käytettiin mallin kouluttamiseen, testiaineistoa käytettiin mallin edistymisen seuraamiseen koulutuksen aikana ja validointiaineistoa käytettiin lopulliseen testaukseen koulutuksen päätyttyä. Validointiaineiston tulosten mukaan havaitsemisaste oli 83-93 prosenttia luokasta riippuen. Tulokset esitetään kuvassa 10 olevan sekaannusmatriisin avulla. Sekaannusmatriisi kuvaa todellisia arvoja vastaavien ennustettujen havaintojen prosenttiosuuksia. Havaittujen kypsän mustikan kohdalla sekaannusmatriisista on luettavissa, että 1 % oli annotoitu raaoiksi mustikoiksi, 91 % oli oikein ja 17 % havaituista kypsistä mustikoista oli osa taustaa. Sekaannusmatriisin mukaan kypsät puolukat olivat parhaiten tunnistettu luokka, kun taas raaka mustikka oli selkeästi huonoin. Kaiken kaikkiaan tuloksia pidettiin hyväksyttävinä.

Kuva 11. . Havaitut marjat rajattu kehyksellä.

Koneoppimismallia käytettiin tiheyden arviointitutkimusta varten etsimään marjoja lähes 5000 kuvasta, joissa oli yhden m²:n ja 0,25 m²:n kehykset. Tämän jälkeen kuvista havaittuja marjoja rajattiin kehysten avulla siten, että vain sisimmät marjat säilytettiin (kuva 11).

arvioitu tiheys = (oikean tyyppisten havaittujen marjojen lukumäärä kehikon sisällä) / (kehikon pinta-ala)

Yhtälö 1. Arvioidun marjatiheyden laskenta.

Tiheyden laskemista varten pinta-ala toimi kuvassa olevan kehyksen pinta-ala ja marjojen lukumäärä oli kuvasta syväoppimisen avulla havaittujen saman luokan marjojen arvo rajattuna kehikolla. Jokaisessa kuvatiedoston kansiopolussa määritettiin kohdemarjalaji, kasvuvaihe ja sijainti. Tätä metatietoa käytettiin suodattamaan vain kohdelajit tiheysarvioon. Tiheysarvionti laskettiin kullekin kuvalle yhtälön 1 avulla.

Arvioitu tiheys ei ollut prototyypissä käytetty lopullinen tulos. Oletuksena oli, että kuvassa ei näy kaikkia maassa olevia marjoja, mutta marjojen havaitseminen kuvassa korreloi kenttämittausten kanssa. Lineaarinen regressiokaava johdettiin korrelaation avulla. Prototyypissä oli jokaiselle kuudelle luokalle erillinen regressiokaava.

Kuva 12. Kuvissa havaittujen marjojen hajontakuviot verrattuna kenttämittausarvoihin. Väritys sijainnin mukaan.

Arvioitu tiheys ja maastolaskennan tulos kuvattuun hajontakuvioon kunkin luokan osalta erikseen (kuva 12). Hajontakuvioiden otsikoissa on kunkin luokan Pearsonin korrelaatio. Hajontakuvio väritettiin sijainnin mukaan, jotta voitiin tutkia, miten sijainti mahdollisesti vaikuttaa havaittujen marjojen ja maastolaskennan väliseen suhteeseen. Hajontadiagrammista on havaittavissa useita asioita:

  • Kypsällä puolukalla on vähiten aineistoa ja kaikki kypsät puolukkakuvat ovat vain vuoden 2021 kuvista. Homogeenisempi kypsien puolukoiden aineisto viittaa siihen, että tarvitaan monipuolisempaa aineistoa, sillä homogeeniset aineistot voivat johtaa ennenaikaisiin johtopäätöksiin.
  • Jotta korrelaatiota voitaisiin käytännössä käyttää esimerkiksi lineaarisen regression avulla tiheyden arvioimiseksi kuvasta, enemmän muuttujia on otettava huomioon. Sijainnin värittäminen antaa ajatuksia lisäkeinosta parantaa korrelaatiota ottamalla huomioon kasvupaikka.
  • Mustikan ja puolukan käyttäytyminen oli erilaista. Mustikan kohdalla mahdollisia kohinan syitä voi olla rehevämpi aluskasvillisuus kuin puolukalla, joka estää marjojen näkymistä kameralle.
  • Puolukka havaittiin ryppäänä, mutta kenttämittauksessa puolukat laskettiin yksittäisinä marjoina. Ero marja- ja rypäslaskennan välillä todennäköisesti kasvaa sadon kasvaessa. Puolukka saattaa marjasadon parantuessa kasvattaa enemmän marjoja yksittäisessä ryppäässä.
Kuva 13. Hajontakuviot havaituista marjoista rajatuissa kuvissa. Vain suurin marjojen lukumäärän sisältämä kuva on valittu useasta kuvasta samasta kehyksestä. Väritys sijainnin mukaan.

Yksi tapa parantaa korrelaatiotuloksia oli etsiä kaikki samasta kehyksestä otetut kuvat ja käyttää vain sitä kuvaa, jossa on eniten havaittuja marjoja. Teoriassa siis käytetään vain sitä kuvaa, jonka kuvakulma ja laatu on paras koska siinä kuvassa on havaittu eniten marjoja. Tämä tekniikka vaatii useiden kuvien ottamista yhdestä kehyksestä. Käytännön haasteita, miksi kuvissa on eroja kuvanlaadussa, olivat auringon sijainti kameraan (marjat ylivalottuvat tai liian tummia varjoja), kameran tärähtely ja kuvakulma, jossa maakasvillisuus oli enemmän tiellä. Eniten marjoja sisältävän kuvan käyttäminen oli perusteltua, ja maksimiarvokuvasta saatiinkin parempi korrelaatio kuin useiden kuvien keskiarvolla. Maksimiarvokuvan avulla korrelaatio kenttämittausarvon kanssa parani (kuva 13).

Päätelmät

Eri kasvuvaiheissa olevien marjojen havaitseminen kuluttajatason kameroiden ja syväoppimisen avulla tuotti onnistuneita tuloksia. Objektien havaitsemisen koneoppiminen oli erittäin käyttökelpoinen menetelmä vaikeiden tapausten havaitsemiseen luonnollisesta taustasta. Arvokasta tietoa saatiin käytännön koneoppimisprosesseista erityisesti datan esi- ja jälkikäsittelyn osalta. Hankkeessa luotiin suuri ja arvokas koulutusaineisto maastokuvauksilla, annotoinnilla ja synteettisellä aineistolla.

Kuva 14. Rehevä mustikkakasvu piilottaa suurimman osan marjoista.

Tiheyden arvioniti ei ollut yksinkertaista kuten monet asiat luonnossa yleensä eivät ole. Hyvä esimerkki haasteista oli kuvassa 14 esitetty mustikka. Korkeatuottoiseen mustikkasatoon liittyy rehevä pohjakasvillisuus. Tämä käänteisesti vähentää havaittujen marjojen määrää kuvassa.

Hankkeessa saatiin syvällisempi näkemys siitä, millä tavoin tiheyttä voidaan arvioida ja miten ongelmaa voidaan lähestyä. Tiheyden arvioinnin suurimmat haasteet olivat marjojen havaitseminen, pinta-alan arviointi ja tiheyden arviointi kerätyn tiedon avulla. Marjojen havaitsemisessa onnistuttiin, mutta tiheyden sekä pinta-alan arvioinnit vaativat lisätutkimuksia.

Pinta-alan arviointia testattiin prototyypissä kahdella eri menetelmällä. Havaittujen marjojen käyttäminen perusmittana kuvan alan arvioinnissa ja käyttöjärjestelmän lisätyn todellisuuden (AR) käytöllä. AR katsottiin pitkällä aikavälillä suositeltavammaksi menetelmäksi. Hankkeen prototyyppi osoitti, että AR:ää voidaan käyttää maapeitteen pinta-alan mittaamiseen, mutta se vaatii huomattavan määrän ohjelmistokehitystä ollakseen riittävän toimintavarma. Haasteita ovat muun muassa tasaisen pinnan havaitseminen käytännössä epätasaisella pinnalla ja jatkuvasti liikkuvan kameran aiheuttaman kohinan käsittely AR-mittauksessa sekä AR:n toteuttaminen yhtä aikaa molemmissa yleisimmissä puhelinten käyttöjärjestelmissä.

Mitä tulee tiheyden arviointiin pinta-alan ja marjojen havaitsemisen tulosten avulla, tarvitaan lisätutkimusta. Korrelaatio on olemassa, mutta se on liian heikko ollakseen käytännöllinen. Käyttäjien ohjaaminen ottamaan useita kuvia ja käyttämään kuvia, joissa on eniten marjoja, on yksi varteenotettava vaihtoehto korrelaation parantamiseksi, mutta enemmän ulottuvuuksia tarvitaan. Marjojen kasvupaikka on lupaava yksi huomioon otettava ulottuvuus.

Kuva 15. . Vain pieni osa todellisista koneoppimisen järjestelmistä koostuu koneoppimisen koodista, kuten keskellä oleva pieni musta laatikko osoittaa. Tarvittava ympäröivä infrastruktuuri on laajaa ja monimutkaista (Sculley 2015).

Hankkeen aikana kerättiin huomattava määrä kokemusta syväoppimisprosessista. Saadut käytännön kokemukset ovat yhteneväiset artikkelissa ”Hidden Technical Debt in Machine Learning Systems” esitetyn väitteen kanssa, jonka mukaan koneoppimisjärjestelmillä on erityinen kyky aiheuttaa teknistä velkaa (Sculley 2015).  Artikkelissa todetaan myös, että vain pieni osa koneoppimisen järjestelmän koodista on varsinaista kouluttamista tai tunnistamista varten (kuva 15). Marjamasiinaprojektin koodipohja tuki tätä väitettä. Suuri määrä koodia tarvittiin aineiston jälkikäsittelyssä. koneoppimistaustajärjestelmän käyttöönotto modulaarisella rakenteella, versiotarkistusrajapinnat sekä geneeristen ja pyyntö- ja vastausmuotojen käyttö lisäsivät myös koodipohjaa huomattavasti. Viimeinen ja usein unohdettu osa oli analyysiprosessin koodipohja, joiden avulla voitiin tehdä johtopäätöksiä ja ohjata iteratiivista koulutusprosessia oikeaan suuntaan.

Kuten Sculley 2015 totesi, geneeristen pakettien käyttäminen siinä toivossa, että se vähentää tarvittavan ohjelmoinnin määrää, johtaa usein liimakoodiin, jolla geneeriset paketit liitetään yhteen. Liimakoodiongelma johti siihen, että hankkeessa kehitettiin omia kirjastoja hankkeen tarkoituksiin. Versiohallinta oli yksi vaikea näkökohta, sillä koneoppimisjärjestelmää parannettiin muokkaamalla suurta koulutusaineistoa, jota ei hallinnoitu versionhallintajärjestelmällä. Näin ollen on vaikea toistaa tietyn version tuloksia ilman oikeaa, sitä vastaavaa aineistoa.

Koneoppimisjärjestelmän toteuttaminen voi olla haastavaa. Järjestelmään tarvitaan suuri määrä ympäröivää infrastruktuuria. Infrastruktuuri ei ole sinänsä negatiivinen asia, mutta arvokas opetus on ottaa tämä vaatimus huomioon koneoppimisjärjestelmää toteutettaessa. Koneoppimisjärjestelmän toteuttamisen haasteet eroavat tavallisesta ohjelmistoprojektista. Ennen prosessia ja sen aikana kehittäjien on oltava erityisen varovaisia, ettei päädytä täyttämään järjestelmää liimakoodin, kanavaviidakoiden (pipeline) ja abstraktiovelkojen kaltaisilla ”ei-toivotuilla” rakenteilla (anti-pattern) (Sculley 2015).

Kokonaisuudessaan Marjamasiina-projekti oli korvaamaton kokemus täynnä toivoa ja innostusta. Hanke synnytti lukuisia harjoittelupaikkoja ja aloitti kahden kandidaatin ja yhden maisterin opinnäytetyöprosessin. Hankkeessa opittiin koneoppimisjärjestelmän käytännön kehittämisestä. Toivottavasti näemme tulevaisuudessa enemmän koneoppimisen käyttöä, sillä potentiaali on käsin kosketeltava.

Tämä artikkeli perustuu osittain kirjoittajan opinnäytetyöhön ”Berry Density Estimation With Deep Learning: estimating Density of Bilberry and Lingonberry Harvest with Object Detection”, joka on saatavilla osoitteessa https://urn.fi/URN:NBN:fi:amk-2022120927665

Kirjallisuus

Benjumea, Aduen, Izzedin Teeti, Fabio Cuzzolin, and Andrew Bradley. YOLO-Z: Improving small object detection in YOLOv5 for autonomous vehicles. arXiv preprint arXiv:2112.11798, 2021.

Bohlin, Inka. Maltamo, Matti. Hedenås, Henrik. Lämås, Tomas. Dahlgren, Jonas. Mehtätalo, Lauri. ”Predicting bilberry and cowberry yields using airborne laser scanning and other auxiliary data combined with National Forest Inventory field plot data.” Forest Ecology and Management, Volume 502. ISSN 0378-1127, 2021.

Galanty, Agnieszka . Tomasz Danel, Michał We˛grzyn, Irma Podolak. ”Deep convolutional neural network for preliminary in-field classification of lichen species.” 2021.

GitHub.com. Flutter SDK. 2022. https://github.com/flutter/flutter (retrieved 7. 12 2022).

Gogul, I. and Kumar, Sathiesh. ”Flower species recognition system using convolution neural networks and transfer learning.” 2017.

Kilpeläinen, Harri. Miina, Jari. Store, Ron. Salo, Kauko Salo. Kurttila, Mikko. ”Evaluation of bilberry and cowberry yield models by comparing model predictions with field measurements from North Karelia, Finland.” Forest Ecology and Management, Volume 363. ISSN 0378-1127, 2016. 120-129.

Liu, Li & Ouyang, Wanli. Wang, Xiaogang. Fieguth, Paul. Chen, Jie. Liu, Xinwang. Pietikäinen, Matti. ”Deep Learning for Generic Object Detection: A Survey.” International Journal of Computer Vision. 2018.

marjahavainnot.fi. ”Luonnonmarjojen satohavainnot.” 2022. https://marjahavainnot.fi/assets/info/Havaintometsan_perustaminen_v2.pdf (retrieved 25. 4 2022).

Marmanis, Dimitris and Wegner, Jermaine and Galliani, Silvano and Schindler, Konrad and Datcu, Mihai and Stilla, Uwe. ”SEMANTIC SEGMENTATION OF AERIAL IMAGES WITH AN ENSEMBLE OF CNNS.” ISPRS Annals of Photogrammetry, Remote Sensing and Spatial Information Sciences. 2016. 473-480.

Redmon, Joseph. Divvala, Santosh Kumar. Girshick, Ross B. Farhadi, Ali. ”You Only Look Once: Unified, Real-Time Object Detection.” CoRR abs/1506.02640. 2015.

Sculley, D. and Holt, Gary and Golovin, Daniel and Davydov, Eugene and Phillips, Todd and Ebner, Dietmar and Chaudhary, Vinay and Young, Michael and Crespo, Jean-François and Dennison, Dan. ”Hidden Technical Debt in Machine Learning Systems.” Advances in Neural Information Processing Systems. 2015.

Solawetz, Jacob. YOLOv5 New Version – Improvements And Evaluation. 29. 6 2020. https://blog.roboflow.com/yolov5-improvements-and-evaluation/ (retrieved 25. 4 2022).

Artikkelin ovat arvioineet FrostBitin julkaisutoimikunta, johon kuuluu Heikki Konttaniemi, Toni Westerlund, Jarkko Piippo, Tuomas Valtanen, Pertti Rauhala ja Tuuli Nivala. Artikkelijulkaisut löytyvät FrostBitin julkaisublogista.

—— 17.12.2022 ——

JAA MEDIASSA

Mikko Pajula, Asiantuntija

Mikko on koodaaja ja osa-aikainen opettaja. Hänen ohjelmointitehtävät ovat pääosin full stack devausta, lisänä asiantuntemus GIS:stä ja syväoppimisesta (deep learning).

—— Insinööri, AMK

Marjojen tunnistaminen syväoppimisen avulla

Marjamasiina (eng. BerryMachine) on Interreg Nordin rahoittama hanke, jonka osapuolina toimivat Lapin ammattikorkeakoulu, FrostBit Software Lab, Luonnonvarakeskus (LUKE) sekä NIBIO (Norja). Hankkeen tarkoituksena on tutkia tekoälyn hyödyntämisen mahdollisuutta marjasadon määrän sekä laadun arvioimisessa älypuhelimella otetun valokuvan perusteella. Hankkeen tekoälyjärjestelmän prototypoinnista ja toteutuksesta vastaa FrostBit ohjelmistolaboratorio.

Perinteisesti marjasatohavaintoja tuotetaan maastossa käsin laskemalla yhden neliömetrin alueelta kerrallaan. Näistä havainnoista tuotetaan marjasadon yleistilanne tiettyjen laskelmien pohjalta.  Tämän menetelmän on todettu vievän paljon aikaa erityisesti marjojen laskentavaiheessa, minkä vuoksi tekoälyn valjastaminen laskentatyöhön on potentiaalisesti resursseja säästävä mahdollisuus, jonka avulla olisi helppoa osallistaa muitakin laskentatyöhön perehtymättömiä henkilöitä mukaan toiminnan tehostamiseksi. Projektin tekoälyjärjestelmän toteuttamisen eri vaiheet koostuvat aineiston keräämisen suunnittelusta ja toteuttamisesta, aineiston esikäsittelystä sekä soveltuvien kuvan- ja objektintunnistustekniikoiden selvittämisestä, testaamisesta ja implementoinnista projektin kuva-aineiston pohjalta yhteen kokonaiseen järjestelmään. Tekoälyjärjestelmän kehittäminen on luonnostaan iteratiivinen prosessi, mikä tarkoittaa sitä, että aiempiin työvaiheisiin palataan tarvittaessa montakin kertaa projektin aikana aineiston keräämistä lukuun ottamatta.

Tekninen esiselvitys, Case Marjamasiina

Moderni tekoäly on erittäin laaja käsite, joka voidaan ohjelmistoarkkitehtuurin näkökulmasta jakaa karkealla tasolla kolmeen pääkategoriaan. Näitä kategorioita ovat perinteinen koneoppiminen, syväoppiminen sekä vahvistettu oppiminen (Krishnan 2019). Koska Marjamasiina-hanke keskittyy kuvien ja objektien tunnistamiseen valokuvasta, luonnollisin lähestymistapa ongelmaan on hyödyntää syväoppimista.

Figure 1. Neuroverkko, havainnekuva

Syväoppimisen avulla tekoäly oppii kuva-aineistosta itsenäisesti tärkeitä ominaisuuksia, joista yksittäinen valokuva koostuu. Näitä ominaisuuksia voivat olla esimerkiksi tunnistettavan objektin muoto, väri tai vaikka jokin toinen objekti, johon tunnistettava objekti on tyypillisesti kiinnitetty (esimerkiksi auton rengas, joka on usein kiinni autossa). Kuvan- ja objektintunnistuksen ytimenä toimii neuroverkko, joka on käytännössä monimutkainen ja -tasoinen tiedon prosessointimenetelmä, joka muistuttaa suuresti tapaa, jolla myös ihmiset oppivat asioita. Käytännössä yksittäinen neuroverkon taso tutkii valokuvasta aina yhtä ominaisuutta kerrallaan, esimerkiksi jonkin asian muotoa, kun taas toinen taso voisi tutkia esimerkiksi väriä. (Bonner 2019; Patel 2020; Géron 2019, 448.) Neuroverkkoja on olemassa useita eri tyyppejä (CNN, ANN, RNN), mutta tässä artikkelissa viittaamme aina CNN-neuroverkkoon, eli konvolutionaaliseen neuroverkkoon (Pai 2020).

Neuroverkkojen teoria juontaa juurensa vuoteen 1943 (McCulloch & Pitts 1943), mutta vasta viime vuosikymmenten aikana tietokoneiden teho on saatu sellaiselle tasolle, jotta neuroverkkoja voidaan realististesti hyödyntää erilaisissa tietotekniikan sovelluksissa.

Kuvantunnistuksessa sen sijaan on pääsääntöisesti kaksi eri lähestymistapaa, joita ovat kuvien luokittelu (image classification) sekä objektien tunnistaminen (object detection) (Browniee 2021; Sharma 2019). Molempien lähestymistapojen toteuttamiseen on lukuisia eri vaihtoehtoja, joista yksikään ei ole ylitse muiden, vaan sopivin valinta on aina tapauskohtainen. Lähestymistapa ja vaihtoehto, jotka sopivat käyttötarkoitukseen ja aineistoon, selviää parhaiten usein vain rohkeasti kokeilemalla. (Leo 2020; Dwivedi 2020.) Tämän vuoksi kuvantunnistusjärjestelmien luominen vie usein huomattavasti kehitysaikaa, minkä vuoksi tekoälyprojektissa tulee olla joustava rakenne mahdollisimman hyvän lopputuloksen saavuttamiseksi.

Kuvanluokittelun ja objektintunnistuksen käyttötarkoitus on usein hyvin samankaltainen, mutta ne eroavat kuitenkin lopputuloksen sekä toteutustavan näkökulmasta. Lopputuloksen näkökulmasta kuvanluokittelu pyrkii analysoimaan kuvaa kokonaisuutena sekä löytämään tiedon siitä, mitä kuva esittää kokonaisuudessaan. Objektintunnistus taas pyrkii löytämään jokaisen etsittävän asian kuvassa, ja näyttämään niiden tarkan sijainnin kuvan sisällä. Toisin sanoen, kuvanluokittelu tunnistaa, että valokuvassa näkyy kukkia, mutta objektintunnistus voi myös näyttää missä kohdin kuvaa kaikki kuvan kukat sijaitsevat.

Figure 2. Kuvanluokittelun ja objektintunnistuksen välinen ero.

Yleisiä teknologioita, neuroverkkomalleja ja algoritmejä, joita voidaan hyödyntää kuvanluokittelussa, ovat mm. VGG16/19, ResNet, MobileNet, Inception ja Exception. Lukuisia muitakin varteenotettavia vaihtoehtoja on. Objektintunnistuksessa yleisiä teknologioita sen sijaan ovat EfficientDet, YOLO sekä R-CNN. Mitä koneoppimisen tekniikkaa kannattaa käyttää missäkin tilanteessa, riippuu usein ohjelmistoarkkitehtuurin käytännöllisyydestä, tunnistustarkkuuden ja -tehokkuuden välisestä kompromissista sekä soveltuvuudesta itse projektin käyttötarkoitukseen.

Ohjelmistoarkkitehtuurin käytännöllisyydellä tarkoitetaan sitä, että tietty teknologia tai algoritmi ei välttämättä toimi kuin juuri tietyillä sovellusalustoilla ja -versioilla, mikä saattaa tehdä kehitystyöstä todella hidasta ja vaikeaa mikäli yhteensopivuusongelmia on liikaa. Tarkkuuden ja tehokkuuden välisellä kompromissilla tarkoitetaan sitä, että tekoälyn toteutusta varten pyritään valitsemaan sellainen teknologia taustalle, joka on mahdollisimman tarkka tunnistamaan asioita, mutta sitä silti voidaan realistisesti käyttää siinä kontekstissa mihin se on suunniteltu. Esimerkiksi kaikkein raskaimpia ja tarkimpia tekniikoita ei välttämättä voida käyttää mobiililaitteissa, jos tekoälyn vaatima laskenta suoritetaan itse mobiililaitteessa. Marjamasiina-hankkeessa kaikki raskas laskenta suoritetaan palvelimilla, jolloin voimme käyttää myös raskaampia teknologioita. Soveltuvuudella käyttötarkoitukseen tarkoitetaan sitä, että kuinka hyvin valittu teknologia toimii annetulla aineistolla. Esimerkiksi jokin esikoulutettu konenäkömalli (VGG19, ResNet jne.) voi soveltua paremmin vaikkapa ajoneuvojen tunnistamiseen kuin jokin toinen. (Github 2021; Hofesmann 2021; Lendave 2021; Özgenel & Sorguç 2018.)

Marjakuva-aineiston tuottaminen ja esikäsittely

Marjamasiina-hankkeen tekninen toteutus alkoi aineiston keräämisen suunnittelulla keväällä 2021. Kuvantunnistuksen näkökulmasta aineistoa pitää olla runsaasti, ja eräs klassinen määritelmä onkin, että jokaista tunnistettavaa asiaa eli kategoriaa kohden pitää olla vähintään 1000 eri valokuvaa aineistossa. Toisaalta osa taas on sitä mieltä, että vähempikin riittää ja tarvittava kuvien määrä on tapauskohtainen. Myös kuva-aineiston monipuolisuus on erittäin tärkeää, jotta tekoäly oppii tunnistamaan haluttuja asioita myös erilaisia taustoja vasten. (Warden 2017; Huellmann 2021.)  Päätimme kuitenkin Marjamasiina –hankkeessa kerätä mahdollisimman suuren ja monipuolisen aineiston, jotta kuvamateriaalia on varmasti käytettävissä tarpeeksi, oli tilanne mikä tahansa.

Figure 3. Marjamasiinan marjakuva-aineistoa.


Marjamasiina-hankkeessa kerättiin kesän ja alkusyksyn 2021 aikana yli 10000 valokuvaa eri marjaruudukoista. Yksittäinen marjaruudukko tässä tapauksessa on neliömetrin kokoinen alumiinikehikko, jonka sisältä marjojen lukumäärä lasketaan. Jotta kuva-aineisto saatiin tekoälylle käyttökelpoiseen muotoon objektintunnistusta varten, piti se ensin annotoida. Annotointi tarkoittaa tunnistettavien objektien merkitsemistä käsin kuva-aineistoon siten, että tekoäly kykenee kouluttamaan itsensä tunnistamaan sovittuja objekteja uusista valokuvista. Tässä tapauksessa tunnistettavia objekteja ovat raa’at ja kypsät marjat sekä marjojen kukat. Varsinaisista marjoista aineistossa ovat edustettuna mustikka ja puolukka.

Aineiston annotoinnissa hyödynnettiin Label Studio –ohjelmistoa, joka tukee monen henkilön työskentelyä saman kuva-aineiston parissa tehokkaasti sekä tarjoaa useita eri annotointidataformaatteja tekoälyn kouluttamista varten.  Label Studio tukee myös viimeisimmän itse koulutetun konenäkömallin käyttämistä automaattiannotoinnissa. Tällöin tekoäly etsii potentiaaliset marjat ja käyttäjälle jää tehtäväksi tarkistaa ja korjata annotaatiot.

Figure 4. Label Studion annotointinäkymä sekä automaattiannotoinnin tulosten hyväksyntä.

Tavanomaisessa kuvanluokittelussa ei sen sijaan tarvita annotointia, vaan kuvat voidaan syöttää kansioittain tekoälylle, jolloin jokainen tunnistettava asia (kategoria) syötetään tekoälylle omassa alikansiossaan.  Koska keskityimme Marjamasiinan ensimmäisessä versiossa objektintunnistukseen kuvanluokittelun sijaan, keskityimme tässä vaiheessa vain aineiston annotointiin.


Kun yksittäinen valokuva syötetään tekoälyn neuroverkon prosessoitavaksi, pitää se muuttaa tiettyyn kokoon sekä muotoon. Kuvanluokittelussa tyypillinen kuvakoko on 224 x 224, jolla taataan se, ettei prosessointi muutu kuvien koon vuoksi liian raskaaksi. Koska objektintunnistuksessa prosessoidaan lähinnä annotointidataa, voidaan käyttää suurempaa kuvakokoa. Esim. Marjamasiinan tekoälyjärjestelmän ensimmäisessä versiossa käytössä oleva YOLOv5l-objektintunnistusmalli tukee 640 x 640 ja 1280 x 1280 –pikselin kokoisia kuvia. Marjamasiina-hankkeen kuva-aineiston kuvat ovat usein tätä suurempia, esim. 2024 x 4032 pikseliä, mikä tuo tiettyjä haasteita toteutukseen, koska se ei täsmää tuettuihin kuvakokoihin. Suurempaa kuvakokoa hyödyntävä neuroverkko myös tekee tekoälyn koulutusvaiheesta raskaamman.

Lopulta kuva muutetaan tensorimuotoon (moniulotteinen matriisi) eli numeroiksi, jotta neuroverkko kykenee prosessoimaan dataa. Neuroverkot eivät itsessään ymmärrä kuvia, vaan ainoastaan numeerista dataa, minkä vuoksi tämä datamuunnos on välttämätön. Tensorissa oleva numeerinen data usein myös normalisoidaan, jotta jokainen arvo saadaan esitettyä välillä -1 ja 1, mikä on optimaalisin datamuoto neuroverkon kouluttamisen näkökulmasta.

Ensimmäinen tekninen prototyyppi

Kun kuva-aineisto oli sopivassa muodossa, siirrettiin se tekoälyn hyödynnettäväksi. Käytännössä tällöin puhutaan tekoälyn kouluttamisesta, jonka lopputuloksena syntyy tekoälymalli, joka kykenee tunnistamaan valokuvista niitä asioita, joita se on koulutettu tunnistamaan. Marjamasiinan tapauksessa tekoäly koulutetaan tunnistamaan valokuvista kypsiä ja raakoja marjoja sekä niiden kukkia.

Jotta tekoälyn kouluttamiseen saadaan kuvista myös pienimmät yksityiskohdat mukaan, kuvien pilkkominen osiin oli Marjamasiinan kuva-aineiston osalta tarpeen. Pilkkomista varten ei ollut suoraan mitään valmista automaattista työkalua, joten sellainen piti toteuttaa itse. Kuvien pilkkomisessa tuli nopeasti vastaan ongelmia, kuten vaikkapa marjat, jotka olivat leikkauskohtien keskellä tai lähikuvat marjoista, jotka ulottuivat useamman leikatun kuvan alueelle päällekkäisyydestä huolimatta. Samalla kun kuva-aineistoa pilkottiin koneellisesti, pilkottiin samalla myös jokaiseen kuvaan liitetty annotointidata, jotta aineisto pysyi synkronisoituna tekoälyn kouluttamista varten.

Figure 5. Kuva-aineiston pilkkomisessa hyödynnettäviä leikkaustekniikoita.

Kun kuva-aineisto oli pilkottu ja tekoälyn koulutusohjelmisto ohjelmoitu, asennettiin hankkeessa tuotettu tekoälyn koulutusohjelmisto kuva-aineistoineen CSC:n Mahti-supertietokoneelle, joka avattiin korkeakoulujen käytettäväksi vuonna 2020.  (ks. CSC 2020 ja Docs CSC 2021.)

Tekoälyn kouluttaminen vie usein runsaasti aikaa, ja mitä monimutkaisempi neuroverkko ja laajempi aineisto on koulutettavana, sen enemmän aikaa koulutus vie ja sitä enemmän koulutusprosessi vaatii laskentatehoa. Tämän vuoksi tekoälyn kouluttamisessa käytetään tyypillisesti tavanomaisen tietokoneen suorittimen (CPU) sijaan näytönohjaimen suoritinta (GPU). Tämä johtuu siitä, että näytönohjaimen prosessoriarkkitehtuuri soveltuu tavanomaista prosessoria tehokkaammin erikoisempien laskutoimitusten suorittamiseen samanaikaisesti, mikä taas palvelee erityisen hyvin tekoälyn koulutusta silloin, kun käytössä on neuroverkko (Sharabok 2020).

Marjamasiinan tekoälyjärjestelmän ensimmäisessä versiossa valittiin käytettäväksi YOLOv5l –objektintunnistustekniikka. YOLOv5l valikoitui hankkeen objektintunnistustekniikaksi lähinnä käytettävyyden sekä tunnistustehokkuuden vuoksi. YOLOv5l:ää voidaan käyttää suositun PyTorch –moduulin (Python) avulla, mikä tekee toteutusvaiheesta helpomman. YOLOv5l on erittäin kilpailukykyinen vaihtoehto myös tunnistustarkkuuden näkökulmasta verrattuna muihin yleisiin objektintunnistustekniikoihin.

Tekoälyn koulutuksessa myös näytönohjaimen muistikoko vaikuttaa oleellisesti tehokkuuteen. CSC:n Mahti-supertietokoneella on kaikkiaan käytössään 40Gb eri näytönohjainmuisteja. Huomasimme Marjamasiinan tekoälyn koulutuksen aikana jopa tämän muistimäärän ongelmallisuudet, sillä jos kokeilimme tehdä koulutusta suuremmalla 1280 x 1280 –pikselin kuvakoolla, loppui yksittäisen näytönohjaimen muisti kesken. Yksi tapa vaikuttaa tähän on käyttää 640 x 640 –pikselin kokoluokkaa koulutuksessa, mutta se vaatii pitemmän koulutusajan koska aineisto pitää pilkkoa pienempiin osiin, jotta samaan tarkkuuteen voidaan päästä.

Loppujen lopuksi Marjamasiinan tekoälyjärjestelmän viimeisimmän version kouluttaminen vei Mahti-supertietokoneelta kaiken kaikkiaan n. 30 tuntia. Tekoälyn kouluttamisen jälkeen vuorossa oli koulutusprosessin sekä tulosten arviointi.

Ensimmäisten tulosten arviointi sekä suunnitelmat tulevaisuuden varalle

Marjamasiinan tekoälyjärjestelmän ensimmäinen versio pyrkii tunnistamaan annetusta valokuvasta seuraavia kategorioita:

  • mustikka (kukka, raaka, kypsä)
  • puolukka (kukka, raaka, kypsä)
  • puolukkaterttu (kukka, raaka, kypsä)

Päädyimme luomaan puolukkatertuille oman kategorian, koska kokemuksemme mukaan vaikutti siltä, että tekoälyn on helpompi tunnistaa kokonainen puolukkaterttu kuin kaikki tertun puolukat erikseen. Tämä johtuu lähinnä siitä, millä tavalla puolukat ylipäätänsä kasvavat verrattuna vaikkapa mustikkaan.

Figure 6. Puolukat ja marjantunnistus.

Koulutetun tekoälyjärjestelmän tunnistustuloksia käytännössä eri kuvilla:

Figure 7. Koulutettu tekoäly tunnistaa marjoja kuvasta. Desimaaliluku kategorian nimen perässä tarkoittaa prosentuaalista tunnistuksen varmuutta (esim. 0.7 = 70% varmuus tunnistuksen oikeellisuudesta).

Kuvan- ja objektintunnistuksen mallin arvioinnissa käytetään useita eri työkaluja, joista yksi yleisimmistä on ns. sekaannusmatriisi, josta näkee nopeasti, kuinka tekoälymalli tunnistaa objekteja oikein ja väärin prosentuaalisesti. Ensimmäisen version tuottama tekoälymalli tuotti seuraavanlaisen sekaannusmatriisin:

Figure 8. Marjamasiinan tekoälyjärjestelmän ensimmäisen version tuottama sekaannusmatriisi. Kulmittain olevan vihreän laatikon sisällä olevat luvut ovat oikein tunnistetut tapaukset testiaineistosta, kaikki muut ovat vääriä tunnistuksia. Luvut ovat desimaalimuodossa olevia prosentteja (esim. 0.72 = 72%).

Ylläolevasta kuvasta näkee puolukoiden tunnistamisessa esiintyvät haasteet. Myös kuvien tausta aiheuttaa ongelmia erityisesti puolukoiden osalta.  Vaikka tarkkuudessa on kauttaaltaan vielä parannettavaa, erityisesti puolukat ovat tällä hetkellä ongelmallinen marjalajike tunnistuksen näkökulmasta.
Seuraava kysymys onkin: mistä kaikki tämä johtuu ja miten voimme kehittää tekoälymallia entisestään? Ensimmäinen vaihe on tutkia itse aineistoa:


Kuvio 9. Kuva-aineiston jakaantuminen marjoittain.

Figure 10. Kuva-aineiston jakaantuminen marjoittain sekä kypsyysasteittain.

Figure 11. Kuva-aineisto kasvuvaiheittain.

Figure 12. Kuva-aineisto kasvuvaiheittain ja marjoittain, sisältää myös puolukkatertut.

Ylläolevista kuvista voidaan huomata kuva-aineistossa esiintyviä epätasapainoja. Aluksi vaikuttaa siltä, että mustikoiden kuvia on liian vähän, mutta erityisesti annotointien näkökulmasta suurin vaje on raakojen puolukoiden kuvissa. Yksi lähestymistapa on täydentää aineistoa juuri tällä kategorialla, ja kokeilla kouluttaa tekoälymalli uudestaan.

Lisäksi voidaan todeta seuraavaa:

  • Puolukoita on annotoitu kokonaisuutena enemmän kuin mustikoita
  • Kypsyysasteittain annotointien määrä on tasapainossa kaikkien kuvien osalta
  • Kasvuvaiheittain annotointien määrä on tasapainossa suhteessa kyseisen marjan annotointien kanssa
  • Erityisesti raakojen puolukoiden ja varsinkin raakojen puolukkaterttujen määrä annotoidussa aineistossa on huomattavan paljon pienempi verrattuna muihin kategorioihin. Tämä korreloi puolukan tunnistamisen ongelmien kanssa (ks. aiempi sekaannusmatriisi), mutta tuskin selittää kokonaisuudessaan puolukoiden tunnistamisen ongelmia

Aineiston täydentämisen lisäksi voimme harkita myös muita tapoja kehittää tekoälyjärjestelmää. Näitä ovat:

  • Käytettävän objektintunnistusteknologian vaihtaminen kokonaan
  • Raskaamman objektintunnistusmallin hyödyntäminen, kuten YOLOv5x
  • Kehittämällä lisää tekoälyä hyödyntäviä aputyökaluja, jotka voivat jatkojalostaa puolukoiden tunnistamista niissä tapauksissa, joissa tekoäly ei ole täysin varma tunnistuksen oikeellisuudesta
  • Kuvanluokittelutekoälyn hyödyntäminen objektintunnistuksen tukena

Kokonaisuutena vaikuttaa suuresti siltä, että pelkkä objektintunnistus ei riitä tarvittavaan tarkkuuteen marjojen tunnistamisessa. Tämän vuoksi FrostBit aikoo seuraavaksi yhdistää objektintunnistuksen tavanomaiseen kuvanluokitteluun, jotta voimme tutkia tarkemmin objektintunnistusjärjestelmän löytämiä ongelmatapauksia.

Vaikka mitään varmoja lukuja emme voi esittää, voimme varovasti arvioida eri teknologioiden tyypillisiä tunnistamistarkkuuksia. Omien kokemustemme mukaan objektintunnistamisessa tyypillinen keskimääräinen tunnistustarkkuus liikkuu 40–70 % välillä, kun taas tavanomaisella kuvanluokittelulla päästään usein 80–95 % tarkkuuteen yksittäisen kuvan osalta. Kuvanluokittelun rajoitus on se, että se analysoi ainoastaan kokonaista kuvaa, eli onko kuvassa esim. raaka puolukka vai kypsä mustikka.

Koska kuvanluokittelu ei voi tunnistaa muuta kuin sen mitä kuva esittää kokonaisuudessaan, se ei yksinään kykene tunnistamaan tehokkaasti useita eri marjoja samasta kuvasta. Tämän vuoksi seuraava Marjamasiina-hankkeen tekoälyjärjestelmän versio tulee hyödyntämään objektintunnistusta ainoastaan marjojen etsimiseen, joista pilkotaan jokainen marja erikseen kuvana, joista jokainen syötetään kuvanluokitustekoälylle jatkokäsittelyyn. Kokonaisarkkitehtuuria voidaan tällöin kuvata seuraavalla tavalla:

Figure 13. Marjamasiinan tekoälyjärjestelmän seuraava versio, arkkitehtuurisuunnitelma.

Tekoälyn kehittämiseen voisi käytännössä käyttää loputtomiin aikaa, sillä vain luovuus ja saatavilla oleva laskentateho ovat rajana. Tämän vuoksi FrostBit pyrkii saamaan tekoälystä mahdollisimman paljon irti annettujen resurssien puitteissa hankkeen aikana. Marjamasiina-hankkeen päätyttyä onkin mielenkiintoista nähdä kuinka pitkälle marjantunnistusteknologian osalta pääsimme, ja mitä sen pohjalta voimme seuraavaksi alkaa rakentamaan. Jokainen iteraatio tuntuu vievän meitä lähemmäs alkuperäistä tavoitetta.

Marjamasiina-hanke on Interreg Nord 2014-2020:n rahoittama hanke, jonka kokonaiskustannukset ovat 144 431 euroa, josta EU-rahoitusosuus on 122 766 euroa. Hankkeen toteutusaika on 1.1.2021 – 30.9.2022.

Kirjallisuus

Bonner, A. 2019. The Complete Beginner’s Guide to Deep Learning: Convolutional Neural Networks and Image Classification. Towards Data Science 2.2.2019. Accessed on 17.12.2021 https://towardsdatascience.com/wtf-is-image-classification-8e78a8235acb

Browniee, J. 2021. A Gentle Introduction to Object Recognition With Deep Learning. Machine Learning Mastery 27.1.2019. Accessed on 17.12.2021 https://machinelearningmastery.com/object-recognition-with-deep-learning/

CSC 2021. Supercomputer Mahti is now available to researchers and students – Finland’s next generation computing and data management environment is complete. CSC 26.8.2020. Accessed on 17.12.2021 https://www.csc.fi/en/-/supercomputer-mahti-is-now-available-to-researchers-and-students

Docs CSC 2021. Technical details about Mahti. Docs CSC 14.4.2021. Accessed on 17.12.2021 https://docs.csc.fi/computing/systems-mahti/

Dwivedi, P. 2020. YOLOv5 compared to Faster RCNN. Who wins?. Towards Data Science 30.1.2020.  Accessed on 17.2.2021 https://towardsdatascience.com/yolov5-compared-to-faster-rcnn-who-wins-a771cd6c9fb4

Géron, A. 2019. Hands-on Machine Learning with Scikit-Learn, Keras, and TensorFlow. 2nd edition. Sebastobol: O’Reilly Media

Github.com 2021. TensorFlow 2 Detection Model Zoo.  Github.com 7.5.2021. Accessed on 17.12.2021 https://github.com/tensorflow/…/tf2_detection_zoo.md

Hofesmann, E. 2021. Guide to Conda for TensorFlow and PyTorch. Towards Data Science 11.1.2021. Accessed on 17.12.2021
https://towardsdatascience.com/guide-to-conda-for-tensorflow-and-pytorch-db69585e32b8

Huellmann, T. 2021. How to build a dataset for image classification. Levity 9.11.2021. Accessed on 17.12.2021 https://levity.ai/blog/create-image-classification-dataset

Krishnan, B. P. 2019. Machine learning Vs Deep learning Vs Reinforcement learning. Medium 18.9.2019. Accessed on 16.12.2021 https://medium.com/analytics-vidhya/machinelearning-deeplearning-reinforcementlearning-ed7b217861c5

Lendave, V. 2021. A Comparison of 4 Popular Transfer Learning Models. Analytics India Magazine 1.9.2021. Accessed on 17.12.2021 https://analyticsindiamag.com/a-comparison-of-4-popular-transfer-learning-models/

Leo, M. S. 2020. How to Choose the Best Keras Pre-Trained Model for Image Classification. Towards Data Science 15.11.2020. Accessed on 17.12.2021 https://towardsdatascience.com/how-to-choose-the-best-keras-pre-trained-model-for-image-classification-b850ca4428d4

McCulloch, W.S. & Pitts, W. 1943. A Logical Calculus of Ideas Immanent in Nervous Activity. Bulletin of Mathematical Biophysics 5, 1943, 115–133. https://doi.org/10.1007/BF02478259

Pai, A. 2020. CNN vs. RNN vs. ANN – Analyzing 3 Types of Neural Networks in Deep Learning. Analytics Vidhya 17.2.2020. Accessed on 17.12.2021 https://www.analyticsvidhya.com/blog/2020/02/cnn-vs-rnn-vs-mlp-analyzing-3-types-of-neural-networks-in-deep-learning/

Patel, K. 2020. Image Feature Extraction: Traditional and Deep Learning Techniques. Towards Data Science 9.9.2020. Accessed on 17.12.2021 https://towardsdatascience.com/image-feature-extraction-traditional-and-deep-learning-techniques-ccc059195d04

Sharabok, G. 2020. Why Deep Learning Uses GPUs? Towards Data Science 26.7.2020. Accessed on 17.12.2021 https://towardsdatascience.com/why-deep-learning-uses-gpus-c61b399e93a0

Sharma, P. 2019. Image Classification vs. Object Detection vs. Image Segmentation. Analytics Vidhya 21.8.2019. Accessed on 17.12.2021 https://medium.com/analytics-vidhya/image-classification-vs-object-detection-vs-image-segmentation-f36db85fe81

Warden, P. 2017. How many images do you need to train a neural network? Pete Warden’s Blog 14.12.2017. Accessed on 17.12.2021 https://petewarden.com/2017/12/14/how-many-images-do-you-need-to-train-a-neural-network/

Özgenel, Ç.F. & Sorguç, A. G. 2018. Performance Comparison of Pretrained Convolutional Neural Networks on Crack Detection in Buildings. Berlin. 35th International Symposium on Automation and Robotics in Construction (ISARC 2018). Accessed on 17.12.2021 https://www.iaarc.org/publications/fulltext/ISARC2018-Paper154.pdf

—— 30.12.2021 ——

Artikkelin ovat arvioineet FrostBitin julkaisutoimikunta, johon kuuluu Heikki Konttaniemi, Toni Westerlund, Jarkko Piippo, Tuomas Valtanen, Pertti Rauhala ja Tuuli Nivala. Artikkelijulkaisut löytyvät FrostBitin julkaisublogista.

JAA MEDIASSA

Tuomas Valtanen, Projektipäällikkö

Tuomas toimii web/mobiilitiimin vetäjänä, ohjelmistosuunnittelijana ja osa-aikaisena opettajana FrostBitillä Lapin ammattikorkeakoulussa. Hänen tehtäviinsä kuuluvat projektinhallinta, projektisuunnittelu ja ohjelmistosuunnittelu sekä verkko-, mobiili- ja tekoälysovellusten asiantuntemus.

—— Insinööri, ylempi AMK

Mikko Pajula, Asiantuntija

Mikko on koodaaja ja osa-aikainen opettaja. Hänen ohjelmointitehtävät ovat pääosin full stack devausta, lisänä asiantuntemus GIS:stä ja syväoppimisesta (deep learning).

—— Insinööri, AMK

VR-ympäristön kehitys digitaaliselle kaksoselle

DUKE on Lapin ammattikorkeakoulun ja REDU:n ammattikoulun yhteistyöhanke. DUKE:n yhtenä tavoitteena on tutkia, miten VR-ratkaisuja voidaan soveltaa opetustarkoituksiin ja hyödyntää uusiutuvaa energiaa. Pääpilottimme on Rovaniemellä sijaitsevan oppilaitoksen digitaalinen kaksonen ja toissijainen pilotti on asiakaslaatuisen lämpöpumpun digitaalinen kaksonen.

Digitaaliset kaksoset mahdollistavat immersiivisen ympäristön visualisoinnin, minkä ansiosta voimme toteuttaa tarkkoja toimintoja eri laitteille ja järjestelmille. Immersio auttaa käyttäjiä alitajuisesti yhdistämään virtuaaliobjektin tosielämän esineeseen, jolloin ”virtuaalivipu” olisi mahdollisimman lähellä todellista vipua; tämän vuoksi virtuaalivivun tulisikin olla interaktiivinen.

DUKE:ssa tuotettu lämpöpumppu on tehty yhteistyössä projektikumppanin kanssa. Kumppanimme halusi sisällyttää VR-ratkaisut käyttöoppaansa rinnalle. Näin käyttäjä voi visualisoida tarkemmin lämpöpumpun perustoimenpiteet ja huoltotyöt. Projektityöskentelyssä DUKE-insinöörit tekivät tiivistä yhteistyötä lämpöpumppuasiantuntijoiden kanssa. Asiantuntijat opettivat meille lämpöpumpun huollon ja me puolestaan käänsimme tämän tiedon VR-simulaatioon. Kehitysprosessi perustui pohjimmiltaan iteratiiviseen työnkulkuun, jossa meillä oli useita arviointi- ja tarkastuskokouksia. Näin varmistimme, että 3D-toteutus oli tarkka ja hyvälaatuinen.

Digitaalisen kaksosen VR-ympäristön toteutus ja kehitys

Digitaalinen kaksonen on virtuaalinen 3D-mallinnus esineestä tai todellisesta ympäristöstä. Määritelmä ”digitaalinen kaksonen” voidaan nähdä ohjeena siitä, kuinka tarkasti tai realistisesti virtuaalinen versio edustaa mallinnuksen kohdetta. Pyrimme Frostbitillä luomaan digitaalisia kaksosia hyvälaatuiseksi ja tarkaksi, jotta se on verrannollinen sen oikean maailman vastineeseen.

Vierekkäinen kuvavertaus renderöidystä 3D-skenaariosta ja käsittelemättömästä 3D-skenaariosta.

Työnkulku ja mahdolliset haasteet riippuvat suurelta osin käyttötapauksesta. VR-simulaatio sisältää sekä fysiikan simulointijärjestelmän että tarkan 3D-visualisoinnin ympäristöstä. Tästä syystä päätimme käyttää Unity pelimoottoria sen kevyen ja mukautuvan luonteen vuoksi reaaliaikaisen VR-simulaation toteuttamisessa. Unityn avulla voimme helposti manipuloida ja optimoida VR-simulaatiota toimimaan kuluttajatason- ja huipputietokoneiden kanssa entistä todenmukaisemman kokemuksen mahdollistamiseksi.

Kehittäjänäkymä Unity pelimoottorin sisällä. Kuvakaappaus on otettu keskeneräisestä kaukolämpölaitoksesta.

Aloitimme visuaalisen toteutusprosessin ottamalla vertailukuvia paikan päällä. Kuvat on otettu useista kulmista, jotta voidaan havainnollistaa kohteen muoto ja ääriviivat. Lisäksi, referenssikuvat ovat erittäin hyödyllisiä selvitettäessä esineen materiaaliominaisuuksia, kuten kuinka kiiltävä se on, minkälaista metallia se on ja millaisia heijastuksia se tuottaa.

Referenssikuva kaukolämpölaitoksesta.

3D-mallinnusprosessi käyttää blueprinttejä yhdessä referenssikuvien kanssa saadakseen tarkat mittaukset yksityiskohtaiseen tuotokseen. Teräväsilmäinen voi silti löytää joitain eroja vertaamalla kuvakaappausta vertailukuvaan. Tämä johtuu osittain uudelleenjärjestelyistä: joitain kaukolämpölaitoksen osia pidettiin epäolennaisina VR-simulaatiossa, joten niitä oli jätettävä pois tai muutettava.

Teksturointiprosessi käyttää erilaisista perspektiiveistä otettuja kuvia selvittääkseen, millainen materiaali olisi tarkin verrattaessa oikean maailman versioon. HDRi-kuvia käytetään luodaksemme realistisen valaistuksen 3D-maailmaan. HDRi-kuvat ovat lähinnä 360° panoraamakuvia, jotka sisältävät paljon valaistukseen hyödynnettävää dataa. Lopputuloksena pystymme luomaan oikean maailman ympäristöjä myötäilemällä todellisia valaistusolosuhteita ja hyödyntämällä fysiikkaan pohjautuvaa renderöintitekniikkaa.

Kuvakaappaus lämpövoimalaitoksen digitaalisesta kaksosesta.

VR-toteutus pelimoottorissa

Kehittäjien yksi ensimmäisistä askelista toteutuksessa on ekosysteemin valinta; toisin sanoen, mitä devaus-pipelineä käytetään. Yhteen pipelineen keskittyminen on välttämätöntä, jotta voidaan varmistaa ominaisuuksien tehokas toteutus. Tässä yhteydessä ekosysteemi koostuu siitä, kenen valmistajien VR-laitteistoja käytetään sekä mitä pelimoottoria ja kehitystyökaluja käytetään. Hankkeen DUKE-insinöörit käyttivät Unity-pelimoottoria kevyen ja mukautuvan luonteen vuoksi.

Testipelaaja kokeilee DUKE:n VR-simulaation pelattavaa demoa.

DUKE-insinöörimme päättivät käyttää SteamVR-ohjelmistokehityspakettia sen laajan VR-laitteistojen tukimahdollisuuden vuoksi. Tämä paketti tarjoaa helppokäyttöisiä blueprint skriptejä, jotka voimme räätälöidä omaan käyttöön. Kyseinen kehityspaketti tarjoaa perustoiminnot esimerkiksi pelaajan ja esineiden vuorovaikutukselle sekä pelaajan liikkumiselle. Tällä tavalla voidaan varata enemmän aikaa kehittyneempien ominaisuuksien hiomiseen, kuten eri objektien dynaamiseen vuorovaikutukseen, samalla kun matemaattinen simulaatio on käynnissä taustalla.

Matemaattinen simulaatio on rakennettu modulaarisuuttaMatemaattinen simulaatio on rakennettu modulaarisuutta ajatellen. Simulaation jokainen osa on jaettu yksittäisiin osiin; tämä antaa meille mahdollisuuden asettaa simulaatioskriptejä 3D-objekteille, jotka loogisesti käsittelevät samaa fysiikkaa kuin todellisessa maailmassa. Esimerkiksi painehävikkiä käsittelevät skriptit määritetään 3D-objekteille, jotka näyttävät venttiileiltä tai putkilta. Huomasimme VR-ratkaisua työstäessämme haastavaksi implementoida oikean elämän standardisoituja mittoja VR-ympäristöön. EU-standardin kokoiset ovet näyttivät liian kapeilta, standardisoidut nupit, pultit ja venttiilit näyttivät liian pieniltä. Lopulta pelitestaajat totesivat, että heidän oli vaikea toimia VR-ympäristössä. Hankkeessa oli tärkeää kehittää sopiva tasapaino, jossa täyttyi digitaalisen kaksosen määritelmä ja ympäristö olisi tarpeeksi helppokäyttöinen käyttäjille.

Nykyinen DUKE -lämpöpumpun versio sisältää neljä skenaariota: ”Tutoriaali”, ”vedensuodatin”, ”paineen säätö” ja ”vesivuoto”. Kukin skenaario sisältää tietoja lämpöpumpun käytöstä ja perushuollosta.

Tutoriaali -skenaario

Tutoriaaliskenaario selittää perusteellisesti kaikki projektissa käytettävissä olevat toiminnot. Tämä skenaario sisältää myös informaatiota, joka kattaa lämmitysjärjestelmän pääosat. Tämä on yleensä ensimmäinen skenaario, jonka pelaajan pitäisi käynnistää, koska se opettaa samalla pelaajalle VR-laitteiston peruskäyttöä.

Vedensuodatin -skenaario

Käyttäjä voi opetella skenaariossa vedensuodattimen puhdistusta.

Paineen säätö -skenaario

Käyttäjä voi oppia säätämään lämpöpumpun oikeaan paineeseen järjestelmässä ja käyttämään turvaventtiiliä paineen poistamiseksi järjestelmästä.

Vesivuoto -skenaario

Vesivuotokenaario tarjoaa kattavan ohjeistuksen lämpöpumppujärjestelmän säilyttämisestä. Näytämme yleisimmät ongelmat, joita tällaisessa tilassa voi kohdata.

Hankkeen kokonaisbudjetti on 761 732 euroa, josta Lapin liitto on myöntänyt Euroopan aluekehitysrahaston (EAKR) ja valtion rahoitusta 609 385 euroa. Projektin toteutusaikataulu on 1.1.2020-31.12.2022.

Artikkelin ovat arvioineet FrostBitin julkaisutoimikunta, johon kuuluu Heikki Konttaniemi, Toni Westerlund, Jarkko Piippo, Tuomas Valtanen, Pertti Rauhala ja Tuuli Nivala. Artikkelijulkaisut löytyvät FrostBitin julkaisublogista.

—— 20.10.2021 ——

JAA MEDIASSA

Onni Li, Asiantuntija

Onni on erikoistunut CG-Grafiikassa FrostBitillä. Suurin osa hänen tehtävistään liittyy 3D-mallien, virtuaaliympäristöjen ja prosessimateriaalien luomiseen teksturointia varten. Onni on pätevä erilaisissa peli- ja renderöintimoottoreissa erityisesti renderöintifysiikan ymmärryksen kautta.

—— Insinööri, alempi AMK

Severi Kangas, Asiantuntija

Severi työskenteli FrostBitillä ohjelmoijana DUKE-hankkeen parissa.

—— Insinööri, AMK

Opetuspelien uusi aikakausi – oppiminen digitaalisia ratkaisuja ja pelillisyyttä hyödyntämällä

Teknologian edistymisen myötä on ollut mahdollista luoda entistä kehittyneempiä opetustarkoitukseen suunnattuja pelejä. Enää ei ole kyse vain 90-luvun lopun lapsille tarkoitetuista “osoita ja klikkaa” -tyylisistä tietokonepeleistä vaan kehitys on antanut meille avaimet monimutkaisemman oppimisen avustamiseen. Villeimmät unelmat virtuaalitodellisuutta hyödyntävistä digitaalisista kaksosista ovat käyneet jo toteen ja niiden rakentamisesta on tullut Frostbit laboratoriossa arkipäivää. Kuluttajalle lasien läpi katseltava virtuaalimaailma on kuitenkin vielä vieras.

Samaan aikaan, kun teknologisen kehityksen keihäänkärki kulkee kaukana kuluttajan edellä, olemme saavuttaneet myös toisenlaisen virstanpylvään opetuspelien maailmassa: jokaisella meistä on käytössään digitaalinen päätelaite, jota hyödyntämällä oppimisen ovet avautuvat yhä monipuolisemmilla tavoilla. Käytännössä siis älypuhelimen tai tietokoneen välityksellä kaikki voivat hyödyntää opetuspelejä päivittäisessä oppimisessa. Pelien laatu ja sisältö on parantunut myös samassa suhteessa ja viime vuosina erilaiset laitevalmistajatkin tuntuvat hiljalleen heränneet digitaalisuuden tuomiin mahdollisuuksiin. Virtuaalinen todellisuus saavuttaa meidät kaikki viimeistään myöhemmin, mutta tässä vaiheessa on jo ainakin unohdettava ne vanhat homehtuneet muropakettipelit.

Virtuaalista oppimista hoitoalalla

Yhteistyössä sosiaali- ja terveysalan opetuspuolen kanssa toteutamme tällä hetkellä osana hoitoalan TKI-toimintaa yksinkertaista projektia, jonka tavoitteena on luoda infuusiopumpun käytön opettava pelillisyyttä hyödyntävä tutoriaali. Kyseinen Braun Infusomat Space on sairaanhoitajalle jokapäiväinen työkalu ja sen käytön opettelu yksi pieni, mutta tärkeä osa sairaanhoitajan opintoja. Perinteisesti infuusiopumppua opetellaan käyttämään luokkahuoneessa ilman potilasta ja teoriassa opiskelijan on mahdollista käydä läpi laitteen toimintaa niin paljon kuin haluaa. Käytännössä kuitenkin opiskelijoita on usein monta, aikaa rajallisesti ja henkilökohtaiset oppimisen vaikeudet voivat asettua oppimisen tielle, eikä perinteinen luokkaopetus näiden vuoksi aina takaa kaikille opiskelijoille mahdollisuutta käyttää laitetta tarpeeksi. Sairaanhoitajaopiskelija lähtökohtaisesti opiskelee hoitamaan nimenomaan potilasta, eikä teknisten laitteiden käyttäminen ole välttämättä hänen ensisijainen vahvuutensa. Infusomat on kohtuullisen arvokas ja vähän pelottavakin laite, jonka käyttämistä harjoitellessaan opiskelija usein opettelee tietyt toimintatavat ja pyrkii välttämään virheitä. Laitteen käyttämisen opetteluun ei siis varsinaisesti liity syväoppimista, vaan lähinnä kykyä toistaa opittu asia. Tällainen opiskeleminen tuottaa toki halutun lopputuloksen, mutta harmillisena sivuvaikutuksena opiskelija ei varsinaisesti opi tuntemaan laitetta vaan pelkästään käyttämään sitä ennalta määrätyissä tilanteissa. Ongelmatilanteissa tai häiriön sattuessa kyky toimia ei ole tällöin parhain, eikä opiskelija välttämättä tunne itseään varmaksi laitetta käyttäessään.

Infuusiopumpun toiminta (alpha)

Pelillistetty oppiminen auttaa opiskelijaa ymmärtämään opittavaa asiaa syvällisemmin. Sen sijaan, että infuusiopumpun käytön opettelu tapahtuisi vain kontrolloidusti luokkahuoneessa, voi opiskelija jatkaa “laitteella leikkimistä” virtuaalisessa maailmassa. Kun koko laitteen toiminta on mallinnettu peliin tarkasti ja käyttöliittymä on sopivan yksinkertainen, pelaajan on mahdollista kokeilla erilaisia toimintoja ja selvittää ongelmatilanteita vailla huolta siitä, että vahingossa rikkoisi pumpun. Peliä hyödyntämällä opiskelija saavuttaa varmuuden laitteen käyttämisessä ja sen jälkeen oikean infuusiopumpun toiminta tuntuu paljon tutummalta sekä helpommalta oppia käytännössä.

Miten Infuusiopumpun toiminta siirretään peliin?

Tärkeintä tämän pelin tekemisessä ovat seuraavat osa-alueet:

  • Käyttöliittymä
  • Laitteen toiminta
  • 3D-mallin vastaavuus
Infuusiopumpun 3D-malli (alpha)

Olennaista on tietenkin se, että kehittäjä paitsi ymmärtää laitteen toiminnan perinpohjin, hän myös mallintaa sen toiminnan kannalta tarvittavalla tarkkuudella. Isona tekijänä on erityisesti käyttäjälähtöisyys: peli voi olla kohderyhmälleen hyödytön, jos kohderyhmä ei kykene käyttämään sitä. Kehittäjän on oletettava, että laitteen käyttäjällä on vain vähän tai ei ollenkaan kokemusta erilaisten pelien pelaamisesta ja tämän vuoksi ymmärrettävä rakentaa toiminnallisuudet niin, etteivät käyttämisen vaikeudet voi estää oppimisprosessia. Se tarkoittaa käytännössä sitä, että monille videopelaajille erittäin tutut ominaisuudet, kuten ensimmäisessä persoonassa hahmon liikuttaminen ja kameran hallinta on jätettävä pois tai tehtävänä niin yksinkertaisiksi, että ne eivät häiritse pelikokemusta. On tarpeetonta pakottaa pelaaja opettelemaan monimutkaiselta tuntuva käyttöliittymä, että hän saa edes mahdollisuuden opetella itse laitteen käyttöä. 

Kehittämisvaiheessa on kaksi osaa: laitteen mallinnus ja pelimekaniikan rakentaminen. Infuusiopumpun mallintamiseen käytetään Blender-3D-ohjelmistoa ja pelin mekaniikka luodaan Unity-pelimoottorilla. Laitteen mallinnuksessa olennaista on mallintaa kaikki ne ulkoiset ominaisuudet joilla on väliä joko pelimekaniikan (nappulat, näytöt, virtajohdot) tai visuaalisen vastaavuuden (luukun pyöreä kaari, kokosuhde) kannalta. Pelimekaniikassa tärkeää on infuusiopumpun toiminnan täsmällinen representaatio. Esimerkiksi laitteen käynnistysnappia painaessa infuusiopumppu päästää pienen merkkiäänen, valot syttyvät ja sen jälkeen näyttöön ilmestyy tekstiä, joka ilmoittaa käynnistymisestä. Kaikki nuo toiminnot ovat olennaisia, jotta pelaajan on helppo siirtää oppimansa digitaalisesta reaalimaailmaan. Olennaista ei kuitenkaan ole se, että sisäisen toimintalogiikan pitäisi olla täsmälleen sama kuin mallinnettavassa laitteessa on.

Oikea infuusiopumppu

Ratkaisevana asiana voidaan pitää lopputulosta: pelin pitää pystyä vakuuttamaan pelaaja siitä, että se toimii samoin, kuin representoitava oikean maailman laite. Pelinkehittämisessä tehtäviä valintoja on siis tarkasteltava opitun reaalimaailmaan siirtämisen näkökulmasta: jos toiminto on tärkeä oikean fyysisen laitteen käyttämisen kannalta, sitten se on toteutettava myös digitaaliseen versioon. Infuusiopumpusta tehdyn pelin ei siis täydy olla täydellinen digitaalinen kaksonen, vaan lähinnä sen toimintaa mahdollisimman tarkasti simuloiva malli.

Projekti on tällä hetkellä vielä kesken, mutta vaikuttaa erittäin lupaavalta. Pelinkehittämisen yhdistäminen oppimistulosten kehittämiseen on kiinnostava ja tärkeä suunta, josta saadaan varmasti kiinnostavaa dataa pelin kehittyessä. Tutoriaalin on määrä valmistua kesäkuussa 2021. Peli tulee toimimaan tavallisella tietokoneella, mobiilipäätelaitteella ja lisäksi myös virtuaalista todellisuutta selvitetään.

’TKI-toiminta digiaikaan’ -hanketta rahoittaa Lapin Liitto EAKR-rahoituksella.

—— 29.04.2021 ——

JAA MEDIASSA

Samuli Valkama, Asiantuntija

Samuli Valkama työskentelee asiantuntijana FrostBit ohjelmistolaboratoriossa Lapin AMK:ssa. Työtehtävien painopiste on hanke- ja pelisuunnittelussa, mutta erityisesti videotuotantojen määrän lisääntyminen on ohjannut yhä enemmän audiovisuaalisen alan asiantuntijatehtäviin.

—— Taiteen kandidaatti (Media), Lapin Yliopisto

Historiallinen tarkkuus vastaan helppo pelattavuus – Struven ketju -mobiilipelin suunnittelu

Minkä tahansa todellisuuteen perustuvan pelin, pelimäisesti toimivan oppimisympäristön tai muun pelaamisen teknologiaa ja mekaniikkoja hyödyntävän sovelluksen kehityksessä joudutaan pohtimaan realismin ja pelattavuuden suhdetta. Todellisen maailman kopioiminen pelimaailmaan tarkalleen kaikkien fysiikan, biologian tai ajan kulumisen asettamien rajoitusten kanssa ei läheskään aina palvele pelin tai sovelluksen perimmäistä tarkoitusta. Sekä viihteellisyys että oppiminen voivat kärsiä sataprosenttisesta uskollisuudesta realismille.

Jos peli keskittyy hyvin rajattuun aiheeseen, kuten esimerkiksi simuloimaan jonkin kulkuvälineen ohjaamista, on erittäin järkevää tai jopa ehdottoman tarpeellista tehdä pelimaailmasta mahdollisimman tarkasti todellista esikuvaansa vastaava. Erilaisten ajoneuvosimulaattoreiden tapauksessa myös fyysisistä ohjaimista tehdään usein todellisuutta vastaavat. Sen sijaan tapauksissa, joissa peli on toiminnoiltaan tai ympäristöltään laajempi, joudutaan aina tekemään päätöksiä siitä, mitkä asiat toistetaan todellisuudelle uskollisesti ja mitä muutetaan esimerkiksi pelattavuuden, viihteellisyyden tai paremman kokonaisuuden hahmottamisen vuoksi. Oman lisänsä tähän pohdintaan tuo pelin alusta ja sen mukana tuleva ohjaamisen tapa: hiiren ja näppäimistön yhdistelmä, tavallinen kaupallinen peliohjain tai älypuhelimen ruutu ovat hyvin geneerisiä ohjaimia, eivätkä siten vastaa tuntumaltaan mitään erikoistuneita esineitä, työkaluja tai hallintalaitteita. Älypuhelinten tapauksessa vastaan tulevat erityisesti laitteiden rajattu suorituskyky ja fyysinen koko, sekä kosketusnäytön sormella käyttämisen epätarkkuus.

Tätä pohdintaa realismin, alustan rajoitusten ja pelin päämäärän suhteesta on tehty ja joudutaan projektin edetessä tekemään paljon myös EU:n Interreg Pohjoinen -ohjelman (EAKR) osarahoittamassa Maailmanperintö Struven ketjun pohjoiset osat -hankkeessa (struvenorth.net) tuotettavan mobiilipelin kehitystyössä.

Pelin taustatarina: Mikä Struven ketju?

Friedrich Georg Wilhelm von Struve (1793-1864) oli tähtitieteilijä, joka tutki urallaan muun muassa maapallon muotoa. Osana tutkimuksiaan hän johti Mustaltamereltä Hammerfestiin ulottuvan kolmiomittausketjun rakentamista. Mittauksen tavoitteena oli saada tarkempaa tietoa maapallon muodosta sen napoja kohti mentäessä. Nykyisin 10 valtion alueen ylitse kulkevassa ketjussa on kaikkiaan 258 peruskolmiota ja 265 peruspistettä, joista 34 on suojeltu. (Maanmittauslaitos.fi)

UNESCO:n maailmanperintökohteiden listalle vuonna 2005 hyväksytty Struven ketju ei kuitenkaan ole tänä päivänä Pohjoismaissa erityisen hyvin tunnettu. Niinpä Maailmanperintö Struven ketjun pohjoiset osat -hankkeessa pyritään tekemään Struven ketjusta tunnetumpi ja parantamaan sen saavutettavuutta. Hankkeessa kehitettävällä mobiilipelillä halutaan viihteellisellä tavalla tavoittaa maailmanperintökohteelle uutta yleisöä.

Pelin tapahtumat ja ympäristö perustuvat todellisiin tapahtumiin 1800-luvulla nykyisen Suomen, Ruotsin ja Norjan, silloisen Venäjän keisarikunnan ja Ruotsi-Norjan alueilla. Tarkoitus ei ole kuitenkaan tehdä opetuspeliä tai pyrkiä toistamaan historiallisia tapahtumia ja olosuhteita mahdollisimman suurella tarkkuudella, vaikka tämä olisi pelimaailmassa periaatteessa mahdollista. Struven ketju -mobiilipelin ote taustatarinansa todellisiin tapahtumiin on tietoisesti suunniteltu kevyeksi ja viihteelliseksi. Syyt tähän valintaan voidaan karkeasti jakaa kolmeen kohtaan: satunnaisemmin pelaavan yleisön tavoitteluun, sujuvampaan tarinankerrontaan ja mobiilialustan mukanaan tuomiin rajoituksiin. Mainitut syyt ja historiallinen tarkkuus eivät sinällään ole toisensa poissulkevia tekijöitä, mutta tässä peliprojektissa valinta on tehty helppouden ja viihteellisyyden hyväksi.

Ajan kuluminen ja tapahtumien järjestys

Kun monisataasivuisesta kirjasta tehdään elokuvasovitus, tarinan tapahtumia tiivistetään ja saatetaan hieman järjestää uudelleen, jotta kaikki olennainen mahtuisi kompaktimpaan formaattiin ja jotta katsojan mielenkiinto saadaan varmasti pidettyä yllä koko elokuvan ajan. Struve-mobiilipelin kehityksessä on päätetty samaan tapaan käsitellä aikaa ja tapahtumajärjestystä joustavasti samoista syistä: pelin kokonaispituutta halutaan rajata ja tapahtumien seuraamisesta halutaan tehdä pelaajalle tarpeeksi helppoa, että pelaajan mielenkiinto säilyisi pelin loppuun saakka.

Koko ketjun mittaukset kestivät todellisuudessa useita vuosikymmeniä ja pelin keskiössä olevan Lapin osuuden mittauskin vei vuosia. Näin pitkän ajan kaikkien tapahtumien tarkka toistaminen pelissä kasvattaisi pelin pituutta riippumatta siitä, millä tavalla aikaa pelin sisällä käsitellään. Mobiilipelejä ei tyypillisesti pelata kovinkaan pitkää aikaa kerrallaan: pelien käytön seurantaan työkaluja myyvän Game Analyticsin vuoden 2019 raportin mukaan mobiilialustalla pelattaville seikkailupeleille yhden pelikerran keskimääräinen pituus on alle 15 minuuttia (GameAnalytics Mobile Gaming Benchmarks Report: H1 2019, s.13). Jos pelin läpi pääsemiseen tarvittava aika mitataan kymmenissä tunneissa, kuten joissakin nykyisissä PC- tai konsolipuolen AAA-julkaisuissa, keskimääräisen pituisia pelikertoja tarvittaisiin pelin läpäisemiseen moninkertainen määrä verrattuna tilanteeseen, jossa pelin kokonaispituus on joitakin tunteja. Struven ketju -pelissä pelaajan halutaan pääsevän ketjun päätepisteelle Hammerfestiin saakka, joten jos pelin kokonaispituus ja siten läpäisemiseen vaadittujen pelikertojen määrä on suuri, on mahdollista, että pelaajat kokevat pelin liian pitkäksi ja jättävät sen kesken jo ennen maaliviivaa. Niinpä on perusteltua luopua tarkkuudesta ajan kulumisen kohdalla pelaajien loppuun asti mukana pitämisen hyväksi.

Todellista tapahtuma-aikaa ei kuitenkaan haluttu poistaa pelistä kokonaan. Pelin kulkua on tämänhetkisessä kehityksen vaiheessa (keväällä 2021) suunniteltu siten, että kalenterivuodet kulkevat pelin oman sisäisen ajan mukana eteenpäin ja pelaajan tavoitteena on päästä mittausketjun loppuun samana vuonna kuin sinne todellisuudessa päästiin. Joillakin paikkakunnilla pysähtymistä tai niiden kautta kulkemista pyritään mahdollisesti myös sijoittamaan oikeiden tapahtumavuosien kohdalle.

Samalla kun pelin aikaa on päätetty käsitellä joustavasti, myös mittauksen kulku on päätetty esittää lineaarisemmin kuin se todellisuudessa tapahtui. Pelin sisällä kuljetaan kolmiomittausketjua mukailevaa reittiä koko ajan yhteen suuntaan, kun taas todellisuudessa mittaukset eivät kulkeneet yhtä reittiä pisteestä A pisteeseen B, vaan joissakin paikoissa pysyttiin kauemmin kuin toisissa ja mittauksia saatettiin tehdä esimerkiksi pistoina tällaisesta pysyvämmästä pysähdyspaikasta käsin. Pelin varhaisessa suunnitteluvaiheessa olisi periaatteessa ollut mahdollista valita peliin etenemisen tapa, joka olisi sujuvasti mahdollistanut todellisten mittausreittien tarkan seuraamisen pelin sisällä. Pelinkehitystiimin oma päätös oli kuitenkin muuttaa pelin sisällä kuljettava reitti yksisuuntaiseksi ja lineaariseksi. Kehitystiimin jäsenet kokivat selkeätä reittiä pitkin etenemisen huomattavasti enemmän pelaajaa motivoivaksi etenemisen tavaksi kuin esimerkiksi pistoina tehtävät mittausmatkat. Omalta osaltaan päätökseen vaikutti myös se, että varhaisessa suunnitteluvaiheessa tiimillä ei ollut käytössään tarkempia tietoja mittausten todellisista reiteistä vaan niitä saatiin vasta myöhemmässä vaiheessa. Puutteellisilla tiedoilla pelin suunnittelu lineaariselle reitille oli helpompaa.

Ajan kulumisen ja tapahtumien järjestyksen joustavassa käsittelyssä joudutaan uhraamaan historiallisesta tarkkuudesta paljon. Perusteluna ja päämääränä tälle on tehdä pelistä helposti lähestyttävä: pelaajalta ei vaadita mitään pohjatietoja tai aiempaa kiinnostusta pelin aihetta kohtaan, eikä peli myöskään väkisin pyri kasvattamaan tai valistamaan pelaajaa. Ajatus on ensisijaisesti tarjota hyvä pelikokemus, sen sivussa kertoa pelaajalle mahdollisesti tuntemattomasta aiheesta ja herättää kiinnostus tutustua aiheeseen myös muilla tavoilla.

Mobiilialustan vaikutus

Mobiililaitteille tehtävissä peleissä joudutaan pelin genrestä ja sisällöstä riippumatta ottamaan huomioon alustan asettamat rajoitukset. Vaikka älypuhelinten näyttöjen fyysinen koko on suurentunut ja resoluutio parantunut, näytöt ovat silti monta kertaa tavanomaista kannettavan tietokoneen tai pöytäkoneen näyttöä pienempiä. Tämä asettaa suoraan rajoituksia sille, kuinka paljon erilaisia pelin hallintaan ja ohjaamiseen tarvittavia valikoita ja muita elementtejä näytölle mahtuu niin, että ne säilyvät vielä luettavina. Lisäksi mobiililaitteita käytetään tyypillisesti sormilla, mikä on huomattavasti hiirtä tai erillistä peliohjainta epätarkempi ohjaamisen tapa ja vaikuttaa edelleen siihen, kuinka pieniä esimerkiksi valikoiden painikkeista on järkevää tehdä.

Mobiililaitteita voidaan parempaa tarkkuutta haluttaessa ohjata osoitinkynällä (engl. stylus) ja kynää ohjaimena käyttäviä pelejä on tehty jonkin verran. Mobiilipelaamista varten myydään myös nimenomaan tätä tarkoitusta varten tehtyjä ohjaimia, jotka muistuttavat konsolien ohjaimia. Sekä kynät että ohjaimet ovat kuitenkin useimmiten erikseen myytäviä lisälaitteita, joten mahdollisimman laajaa yleisöä ja pelin helppoa käyttöönottoa tavoiteltaessa ei ole järkevää edellyttää käyttäjältä minkäänlaisia erikoisempia ohjaimia.

Pelisuunnittelun kannalta näytön koon rajallisuus vaikuttaa muun muassa siihen, ettei pelaajalle voida näyttää kovin suurta määrää informaatiota kerrallaan. Pelaajalle tarpeellisen informaation esittämistä voidaan säädellä esimerkiksi siten, että informaatiosta on näkyvillä vain ne osat, jotka ovat tarpeellisia juuri sillä pelin hetkellä tai tietyssä avoinna olevassa valikossa. Toinen vaihtoehto on tarvittavan tiedon pilkkominen pienempiin osiin ja näyttäminen eri valikoissa tai valikoiden alatasoilla. Molemmissa tavoissa on kuitenkin omat ongelmansa. Jos informaatiota on paljon ja suuri osa siitä on kontekstuaalista eikä sitä näytetä pelaajalle jatkuvasti, työmuistin rajat tulevat vastaan ja pelaajan on vaikea pitää mielessään kaikkia tarpeellisia asioita. Kovin monitasoiset valikot voivat puolestaan olla vaikeita navigoida. Niinpä ratkaisu ei voi olla ainoastaan esitettävän tiedon pilkkominen tai sen esitystavan muuttaminen vaan peli täytyy lähtökohtaisesi suunnitella niin yksinkertaiseksi, että tarvittavan tiedon määrä ei ole erityisen suuri.

Ohjaamisen epätarkkuus puolestaan tarkoittaa sitä, etteivät varsinkaan kaikista useimmin toistuvat toiminnot saa vaatia tarkkoja tai monimutkaisia ohjausliikkeitä. Peliä pitää pystyä voida ohjaamaan muutamilla tärkeimmillä painikkeilla ja yksinkertaisilla eleillä, jotta pelin oppiminen on helppoa ja sen jatkuva käyttäminen vaivatonta.

Historiallisen näkökulman kannalta nämä yksinkertaistamisen vaatimukset johtavat siihen, että todellisuudessa monimutkaisia tai vaativia toimenpiteitä täytyy muuttaa suoraviivaisemmiksi ja helpommiksi. Struven ketju -mobiilipelissä esimerkiksi mittausten tekemisestä pyritään antamaan pelaajalle todenmukaista tietoa, mutta tarkkuutta ja taitoa vaatinutta mittalaitteiden käyttöä ei toisteta pelissä sinällään, vaan korvataan yksinkertaistetulla tai helpotetulla versiolla siitä, tai kokonaan toisella mittaukseen liittyvällä toiminnalla. Kun pelin perusperiaatteet on helppo oppia ja pelaaminen ei vaadi monimutkaisia toimia, myös pelejä vähemmän pelaavat tai niihin kokonaan tottumattomat pysyvät helposti aloittamaan Struven ketju -pelin pelaamisen.

Mitä historiasta tuodaan peliin mukaan?

Vaikka Struven ketju -mobiilipelin kehityksessä toimitaan ensin pelimekaniikan ja -alustan ja vasta toissijaisesti pelin historiallisiin tapahtumiin perustuvan taustatarinan ehdoilla, pelistä ei kuitenkaan haluta tehdä vain geneeristä seikkailupeliä, johon on liimattu päälle historiasta ammentava kosmeettinen kuori. Pelinkehitystiimi on käyttänyt suunnitelmissaan muun hanketiimin keräämiä tietoja, jotka käsittelevät aiheita itse mittausten kulusta tunnettuihin pysähdyspaikkoihin ja 1800-luvun päivittäiseen elämään. Pelaajan ratkaistavaksi tulevia ongelmia etsitään ketjun mittaajien todellisuudessa kohtaamista haasteista. Lapin syrjäinen sijainti ja haastavat sääolot vaikuttivat muun muassa siihen, miten mittalaitteita pystyttiin kuljettamaan ja milloin mittauksia pystyttiin tekemään. Esimerkiksi Suomen Lapin varsinainen tieverkko, poislukien talvitiet, ulottui 1800-luvulla Kittilään, Kolariin ja Sodankylään, niinpä tätä pohjoisempana pelaajalla ei ole enää reittivaihtoehdoissaan maantietä.

Pelaajalle halutaan pelin mittaan välittää ajatus siitä, millainen merkitys mittauksilla oli laajemmin yhteiskunnassa. Struven ketjun tuottaman tiedon myötä kartoista pystyttiin piirtämään entistä tarkempia ja tarkkojen karttojen merkitys esimerkiksi kaupan tekemisen tai sodankäynnin kannalta oli ja on edelleen suuri.

Ajankuvaa välitetään pelissä myös visuaalisesti. Pelin piirrostyyli on sarjakuvamainen, mutta esimerkiksi vaatteiden ja varusteiden, kylien rakennusten ja erilaisten mittausvälineiden mallit ovat 1800-luvun esikuviensa mukaisia. Lähes 200 vuoden takaiset tapahtumat ja elämä halutaan pelissä näyttää elävinä ja kiinnostavina huolimatta siitä, että todellisesta historiallisesta tarkkuudesta on monilta osin päätetty luopua.

Lisää Maailmanperintö Struven ketjun pohjoiset osat -hankkeesta: struvenorth.net

Lisää Struven ketjusta yleisesti: https://www.maanmittauslaitos.fi/struvenketju

Game Analyticsin vuoden 2019 raportti: https://progamedev.net/wp-content/uploads/2019/07/Benchmarks2019.pdf

—— 31.03.2021 ——

JAA MEDIASSA

Sanni Mustonen, Projektipäällikkö

Sanni on graafinen suunnittelija, jota kiinnostaa erityisesti asioiden tekninen puoli. Hänen työhönsä kuuluu kaikkea käyttöliittymäsuunnittelusta visuaalisiin identiteetteihin ja kesäpeliopinnoissa opettamiseen.

—— Tohtoriopiskelija, taiteiden tiedekunta, Lapin Yliopisto

UX & Palvelumuotoilu FrostBit labrassa

Olen Lapin yliopiston palvelumuotoilun tohtoriopiskelija ja harjoittelija FrostBit ohjelmistolaboratoriossa. On ollut suuri kunnia päästä harjoitteluun FrostBitille. Sain mahdollisuuden päästä harjoittelemaan UX ja palvelumuotoilua FrostBitin eri projekteissa, ja haluaisinkin kertoa teille mielelläni kokemuksistani.

Mitä ovat UX ja palvelumuotoilu?

Viime aikoina UX-suunnittelu ja palvelumuotoilu ovat olleet hyvin ajankohtaisia: olet saattanut kuulla monista tuotteista ja ohjelmistoista, joita on sovellettu UX-suunnittelu sekä palvelumuotoiluperiaatteilla. Mitä ne oikeastaan tarkoittavat?

UX tarkoittaa käyttökokemusta, englanniksi ’User Experience’. Normaalisti suunnitteluohjelmistojen osalta UX-suunnittelijat keskittyvät enemmän ohjelmistojen logiikkaan. Hyvän UX-suunnittelun avulla käyttäjät eivät hämmenny ja eksy 2D-maailmaan (sovellukset, verkkosivustot jne.) tai 3D-maailmaan (VR- tai AR-tekniikat). Useimmissa tilanteissa UX-suunnittelu liittyy läheisesti UI-suunnitteluun (käyttöliittymäsuunnittelu).

Toistaiseksi ei ole vielä olemassa yhtä virallista määritelmää palvelusuunnittelulle. Minulle palvelusuunnittelun ydin on ”empatia”, mikä tarkoittaa, että palvelumuotoilijan on ajateltava ”palveluprosessia” kaikkien sidosryhmien näkökulmista. Esimerkiksi, jos kehität B2C-verkkosivustoja, sidosryhmiksi otetaan mukaan verkkosivustoja käyttäneet asiakkaat, henkilökunta sekä jopa jotkut kolmannet osapuolet. Lisäksi palvelumuotoilu käsittää koko prosessin suunnitteluratkaisun mukaan. Esitän esimerkin ravintolasta: Kun näet ensimmäisen kerran ravintolan logon ja kasvot, palvelusuunnittelun prosessi on jo alkanut. Ruokailuympäristö, ruoan maku, henkilökohtainen palvelu ja jopa antamasi palaute – kaikki nämä voivat olla osa palvelusuunnitteluprosesseja.

Minulle palvelumuotoilu muistuttaa enemmän strategista suunnittelua: itse tuotteen lisäksi palvelumuotoilu tarjoaa tehokkaamman ja arvokkaamman suunnitteluprosessin, joka ratkaistaan ”kipupisteiden” kautta. Palvelumuotoilulla on laajempi soveltamisala, joka ei sisällä vain UX-suunnittelua, vaan myös graafisen suunnittelun, tuotesuunnittelun, tietosuunnittelun ja niin edelleen.

Alla näet perustason suunnitteluprosessin, jota seuraan itse aina:

Kuinka päädyin UX- ja palvelumuotoilu-harjoitteluun FrostBit-ohjelmistolaboratoriossa?

FrostBit-ohjelmistolaboratoriossa harjoittelujaksoni aikana olen tehnyt pääasiassa kahta asiaa: ensimmäisenä olen suunnitellut FrostBit-verkkosivustoille uusia ominaisuuksia tai parannusehdotuksia, ja toisena tein sisustussuunnittelua laboratorion toimiston ulkopuoleiselle aulalle. Voit ajatella, että verkkosivujen suunnittelu liittyy UX-suunnitteluun ja palvelumuotoiluun – mikä on totta. Suunnitteluprosessissani toteutin verkkosivustolle animaatioita, jotka kiinnittävät asiakkaiden huomion heti, kun he saapuvat verkkosivustolle, ja tätä kautta huomaamaan tärkeimmät asiat. Lisäksi joihinkin teksteihin yhdistettiin kuvakkeita: tällä tavalla tieto voidaan siirtää lukijoille hyvin lyhyessä ajassa. Vaikka suunnittelijoilla on yleisiä vinkkejä, joita usein sovelletaan web-suunnitteluussa, haluan itse kiinnittää huomiota enemmän ajattelutapaan, eli kuinka lukijat itse ajattelisivat ja kuinka tieto voidaan siirtää heille. Kun suunnittelen tällä tavalla, voin määritellä suunnitteluratkaisun ytimen, tasapainottaa molempien osapuolten vaatimukset ja kiinnittää huomiota aiemmin mainitsemaani ”empatiaan”.

Aulan sisustussuunnittelussa minulla on ollut sama ajatteluprosessi: prosessi määrittelee sekä kohderyhmän että tavoitteen ja päätoiminnot sekä suunnittelun elementit (jokaiselle ryhmälle) aulassa. Kokemukseni perusteella käytin UX- ja palvelumuotoilua aulan ”kokonaiskuvan” suunnitteluun ja käytin sitten sisustussuunnittelua tapana soveltaa ja näyttää ideani ja suunnitteluratkaisut.

Harjoitteluni aikana en vain kehittänyt suunnittelun perustaitojani, vaan myös harjoittelin palvelusuunnittelun avainkohtia FrostBitilla. Määrittelisin kolme tiettyä ydintä, jotka on pidettävä mielessä suunnitteluprosessin aikana:

  • Kuinka kasvattaa asian arvoa
  • Kuinka hyödyntää yhteissuunnittelua (co-design)
  • Mikä on se ”uusi idea” tai ratkaisu

Mitä näkyy FrostBitin UX ja palvelumuotoilun tulevaisuudessa?

Olen ehdottoman varma, että palvelusuunnittelulla ja UX-suunnittelulla on valoisa tulevaisuus FrostBit-ohjelmistolaboratoriossa. Riippumatta siitä, miten maailma muuttuu, jokainen Frostbit-ohjelmiston edistyminen voi muuttaa tai ohjata ihmisten käyttäytymistä. Siksi käytämme palvelumuotoilua nähdäksesi kokonaiskuvan ja antamalla ”oikeat” ohjeet projekteillemme. FrostBitissä emme sovella vain ”todellisia” suunnittelutaitoja, vaan myös ”empatian” ajattelutapaa projekteissamme ja pyrimme jatkuvasti etsimään tapoja luoda tämä. Jos haluat nähdä, kuinka käytämme UX:ää ja palvelumuotoilua projektissamme inspiroivien tulosten luomiseen, pysy ajan tasalla portfoliostamme ja julkaisuista!

—— 10.03.2021 ——

JAA MEDIASSA

Nan Li, Asiantuntija

Nan Li työskentelee asiantuntijana FrostBitillä. Hän on palvelumuotoilun tohtorikandidaatti Lapin yliopistossa. Palvelusuunnittelu ja graafinen suunnittelu ovat hänen päätyöalueitaan.

—— Palvelumuotoilun tohtoriopiskelija, Lapin Yliopisto

Game Dev -tiimin työskentely FrostBitillä

Meitä labrassa työskentelee jo noin 40 palkattua henkilöä sekä tietenkin meidän harjoittelijamme, vaihto-opiskelijat sekä opinnäytteen tekijät. Iso osa tästä työskentelee Game Development (Game Dev / peli) tiimissä eri peliprojekteissa. Henkilöstömäärämme on kasvanut huimasti viime vuosina ja mukaan on tullut paljon eri osaamista. Emme ole enää pelkästään insinöörijoukko, joka koodaa pimeässä laboratoriossa Jolt Colan voimalla. Mukaan on tullut muun muassa mallinnuksen, graafisen suunnittelun, palvelumuotoilun, audiovisuaalisen ja pelipedagogiikan ammattilaisia, sekä jokaisen henkilökohtainen osaaminen. Tiimissämme on todella vahva osaaminen viemään projekteja aivan alkumetreiltä maaliin asti. Teemme todella tiiviisti yhdessä projekteja mobiili ja web tiimin kanssa, sillä lähes jokainen projektimme tarvitsee vähintään web-sivuston tai taustajärjestelmän. Monimutkaisen taustajärjestelmän rakentaminen on labran mobiili ja web tiimin ydinosaamista.

Kaivosprosesseihin tutustumista Mantovaaran louhoksella

Mitä me teemme Game Dev tiimissä? Päätyökalumme ovat eri pelimoottorit, käytämme pääsääntöisesti Unity3D tai Unreal pelimoottoria projektin mukaan. Vaikka tiimimme nimi on Game Dev Team, emme ehkä tee pelejä siinä perinteisessä muodossa. Hyödynnämme peliteknologiaa esimerkiksi visualisointeihin, simulaatioihin, oppimisympäristöihin tai markkinointiin. Tämä tekee työstä todella monipuolista; pääsemme työskentelemään eri substanssialojen kanssa ja olemme tehneet erilaisia peliteknologiaa hyödyntäviä toteutuksia aina hiukkasfysiikasta sairaanhoitoon. Eikä ainoastaan se, että teemme pelkästään yhteistyötä eri substanssialojen kanssa – pääsemme myös tutustumaan ja opiskelemaan millaista työskentely on erilaisilla aloilla, esimerkiksi kaivoksissa. Hyvänä esimerkkinä toimii KaiVi-hanke, jonka aikana hankkeessa työskennelleet ohjelmoijat ja mallintajat lähtivät työharjoitteluun kaivokselle tutustumaan kaivoksen toimintaan. Tällainen toiminta on ensiarvoisen tärkeää, kun halutaan rakentaa ympäristöjä, jotka vastaavat todellisuutta. Tärkeää on myös, että kehitystiimille kasvaa jonkinlainen ymmärrys substanssialasta ja pystyy näin keskustelemaan tehokkaasti ammattilaisten kanssa.

Monialaista osaamista ja oppimista

Peliteknologioiden täysipainoinen hyödyntäminen vaatii usean ammattilaisen yhteistyötä. Jokainen projekti alkaa suunnittelulla ja määrittelyllä johon osallistuu niin substanssiasiantuntijoita, suunnittelijoita, ohjelmoijia kuin artisteja. Tässä vaiheessa myös mietitään pedagogisia ratkaisuja oppimisympäristöihin tai mukaan otetaan palvelumuotoilun työkalut. Varsinaiset toteutukset pitävät sisällään projektista riippuen erilaisia vaiheita, mutta tyypillisesti projekti aloitetaan konseptoinnilla, teknologiatesteillä tai prototyypeillä, josta siirrytään varsinaisen tuotekehitykseen. Projektista riippuen projektille valitaan sopivat työkalut sekä tarvittavat menetelmät projektin läpiviemiseksi. Käytämme useassa projektissa scrum-menetelmää: menetelmä mahdollistaa ketterän kehityksen, sekä toimii erittäin hyvin nykyisessä tilanteessa, jossa työskentely tapahtuu pitkälti etänä.

Uudet teknologiset laitteet ja ratkaisut ovat meillä käytössä useassa projektissa. Pääsemme esimerkiksi toteuttamaan erilaisia virtuaalitodellisuuden ympäristöjä ja etsimään myös uusia ratkaisuja hyödyntää virtuaalitodellisuutta. Virtuaalitodellisuus on vain yksi uusista teknologioista, joita hyödynnämme. Virtuaalitodellisuuden lisäksi pääsemme hyödyntämään projekteissamme muun muassa tekoälyä, koneoppimista, sensoreita, liikealustoja ja ohjaimia. Pyrimme aina löytämään uusia tapoja hyödyntää teknologiaa toiminnassamme parhaan lopputuloksen saamiseksi.

Vaikka meillä labrassa jokaisella on oma roolimme, ei se tarkoita, että ohjelmoijan tarvitsee pelkästään koodata, tai mallintajan mallintaa. Oman osaamisen ja tahtotilan mukaan pääsee monipuolisesti osallistumaan erilaisiin tehtäviin. Tarjolla on hankesuunnittelua, artikkeleita, esittelyjä, kehittämistehtäviä, harjoittelijoiden ohjaamista, teknistä vetovastuuta, työpajoja, webinaareja ja monia muita toiminamme kannalta tärkeitä tehtäviä. Kliseistä, mutta totta; ei yhtään samanlaista työpäivää, ei yhtään samanlaista projektia.

Osa henkilökuntaamme toimii myös tuntiopettajina tieto- ja viestintätekniikan koulutuksessa. On todella palkitsevaa päästä jakamaan osaamistamme tuleville insinööreille ja päästä myös sitä kautta laboratoriona antamaan oman panoksensa alueen kehittymiselle. Tulevana kesänä olemme mukana jälleen kerran rakentamassa kesäpeliopintoja, suunnittelu on hyvässä vauhdissa, parhaat kesäpeliopinnot ovat jälleen luvassa. Muista seurata blogiamme, laitamme varmasti tunnelmia kesäpeliopinnoista kesän aikana.

Käy tutustumassa erilaisiin projekteihimme portfoliossamme

—— 26.02.2021 ——

JAA MEDIASSA

Toni Westerlund, Projektipäällikkö

Ei ole ongelmaa, jota Toni ei ratkaise. Toni on ohjelmistotekniikan ja ohjelmoinnin raaka ammattilainen: ”propellihattu” on varmasti oikea nimitys Tonista. Peliteknologia ja virtuaalitodellisuus ovat erityisesti lähellä Tonin sydäntä. Hän viihtyy myös opettamassa, mikä on hienompaa kuin oman tietämyksen jakaminen ja uusien propellihattujen kasvatus. Toni vetää FrostBitin pelitiimiä ja toimii myös tieto- ja viestintätekniikan alumnivastaavana.

—— Ohjelmistotekniikan insinööri (YAMK)

Pelillisyydellä näkyvyyttä kaivosalalle

Suomessa on jopa 46 kaivosta, joiden henkilöstöä oli vuonna 2018 yli 5000. Erityisesti Pohjois-Suomessa kaivosala on tärkeä työllistäjä ja toimii elinkeinona niillä seuduilla, joissa monipuolinen työllisyys ja hyvinvoinnin kehittäminen voi olla muuten haastavaa (Kaivosteollisuus.fi). Kaivosalalla on myös laaja koulutustarjonta ympäri Suomen, jonka vuoksi tutkintorakenteiden uudistaminen ja modernien oppimiskeinojen kehittäminen on kasvavan kysynnän vuoksi ajankohtaista.

Kuinka kaivosalan koulutusta voitaisiin sitten nykyaikaistaa? Migael-hanke vastaa tähän kysymykseen pelillisyydellä ja moderneilla teknologioilla. Hankkeen tavoitteena on kehittää kaivosalan koulutusta luomalla virtuaalinen oppimisympäristö, jossa on erilaisia skenaariopohjaisia harjoitteita. Vuoden 2021 alkuun mennessä hankkeessa on luotu kolme valmista harjoitusta ja neljäs harjoitus valmistuu helmikuun aikana. Jokainen harjoitus keskittyy erilaisiin “skenaarioihin” avolouhoksessa sekä maanalaisessa kaivoksessa, ja harjoitusten luomisessa on hyödynnetty erilaisia alustoja ja teknologioita:

Panostus / räjäytys
Ensimmäisessä harjoituksessa pystyy harjoittelemaan räjähteiden panostusta 2D-näkymässä, ja tarkastelemaan panostuksen ja räjäytyksen simulointia sekä 3D- että Oculus Guest virtuaalinäkymässä. Harjoituksessa pelaaja pääsee simuloimaan erikokoisia panostuksia ja näkemään miltä niiden räjäytys voisi näyttää kalliossa.

Työturvakortti
Toinen harjoitus luotiin myös Oculus Guestin virtuaalilaseilla pelattavaksi, ja tässä harjoituksessa pelaaja pääsee tekemään työturvakortin tarkastusta maanalaiseen kaivokseen. Pelaaja pystyy liikkumaan maanalaisessa kaivoksessa ja havainnoimaan tarvittavat turvatoimenpiteet sekä täyttämään työturvakortin niiden mukaan.

Ajoonlähtötarkastus
Kolmas harjoitus luotiin sekä Oculus Rift -virtuaalilaseilla että Android-puhelimilla pelattavaksi, ja tässä harjoituksessa käydään läpi kaivoskoneen ajoonlähtötarkastus. Pelaajan tulee tarkastaa työhenkilön turvavarustus ja kaivoskoneen ajo- ja käyttökelpoisuus, ennen kuin sillä voidaan lähteä työskentelemään.

Räjäytystä edeltävät ja sen jälkeiset turvallisuustoimenpiteet
Neljännessä harjoituksessa pelaajan tulee suorittaa louhosräjäytystä edeltävät ja räjäytyksen jälkeiset turvallisuustoimenpiteet. Harjoituksesta tehtiin perinteisempi 3D-desktop hyötypeli, jossa pystytään hyödyntämään tekstillistä opetusmateriaalia enemmän laajan aihepiirin parissa. Pelaaja pääsee havainnoimaan avolouhos-ympäristöstä kohteita, joille tulisi tehdä toimenpiteet alueen turvaamiseksi ennen ja jälkeen räjäytyksen.

Erilaiset tekniset toteutusalustat mahdollistavat erilaisia tapoja esittää tai simuloida opetettavaa aihealuetta. Virtuaalitodellisuudella pystytään viemään pelaaja tai oppija todentuntuiseen oppitilanteeseen, jolla vastataan mahdollisimman paljon oikean elämän tilannetta. Tällä tavoin voidaan esimerkiksi simuloida hyödyllisesti harjoitustilanteita, joiden toteuttaminen olisi vaativaa, kallista ja usein myös vaarallista. Puhelinalustalla toteutettu harjoitus mahdollistaa oppimisen helpommin ajasta ja paikasta riippumatta, ja tällä voidaan tavoittaa laajempi käyttäjäryhmä. Tämän vuoksi esimerkiksi kolmannessa harjoituksessa ajoonlähtötarkastuksen lista toteutettiin sekä VR-laseille että puhelimelle.

Virtuaalilasit luovat kuitenkin oman haasteensa, mikäli opetettava materiaali ja aihealue ovat laajoja ja vaativat enemmän kuin havainnointia ja ”käsinkosketeltavia toimenpiteitä”. Vaikka virtuaalilaseille pystytään tuomaan esimerkiksi ohjeet ”leijuvina teksteinä”, interaktiiviset tekstit liikkumisen ja muun aktiviteetin kanssa voivat luoda tarpeettoman paljon haastetta VR-maailmassa. Migaelin neljäs harjoitus päätettiinkin toteuttaa 3D desktop-pelinä, sillä aihealue vaati paljon tekstiä opetusmateriaalin ja muun informaation muodossa. Tässä harjoituksessa jouduttiin myös suunnittelemaan erityisen tarkasti mitkä toimenpiteet on järkevää pelillistää, sillä turvallisuustoimenpiteitä on räjäytystilanteessa useita. Osa geneerisimmistä ja hankalammin pelillistettävistä toimenpiteistä toteutettiin muun muassa cinematic-välisiirtymien sekä pelin hahmojen opastusten muodossa:

Erilaisilla teknologisilla toteutuksilla voidaan siis mahdollistaa erilaisia oppimiskeinoja ja saavuttaa tiettyjä oppimistavoitteita. Toiset teknologiat mahdollistavan todenmukaisemman harjoitusten simuloinnin, kun taas toisilla voidaan tuoda laajemmin asiasisällöt esille ja tavoittaa suurempi käyttäjäryhmä. Migaelissa tuotetut harjoitukset muodostavat yhdessä pelillisen oppimisympäristökokonaisuuden, jossa pääsee kokemaan monien uusien teknologioiden hyödyt ja oppimaan kaivosalasta innostavasti ja turvallisesti. Hankkeen tavoitteena onkin tehdä kaivosalaa näkyvämmäksi ja kiinnostavammaksi erityisesti opiskelijoille, sekä mahdollistaa tärkeän ja turvallisen harjoittelun ajasta ja paikasta riippumatta.

Neljännen harjoituksen valmistumisen lisäksi, alkuvuosi on hankkeelle tapahtumarikas: hankkeen tiimoilta järjestetään 25.01.2021 Teams-webinaari nimeltä ‘modernien teknologioiden hyödyntäminen kaivosalalla’. Webinaarissa kuullaan puhujia FrostBitin lisäksi VTT:ltä ja Kajaanin ammattikorkeakoulusta, jotka esittelevät muun muassa pelillisyyden, VR/AR-teknologioiden ja uusien sensori-teknologioiden hyödyntämistä kaivosalalla. Webinaariin kutsutaan kuuntelemaan kaivosalan henkilöstöä, projektihenkilöstöä sekä Lapin ammattikorkeakoulun opiskelijoita.

Hankkeen toimenpiteitä päivitetään sen virallisilla sivuilla, joista löytyy muun muassa blogi ja ladattavat harjoitukset: www.migael.fi

Lisäksi projektin tekninen tiivistelmä löytyy FrostBitin portfoliosta: https://www.frostbit.fi/portfolio-fi/migael-fi/

Pohjois-Pohjanmaan elinkeino-, liikenne- ja ympäristökeskus on myöntänyt Euroopan sosiaalirahaston (ESR) ja valtion rahoitusta 337 502€ Migael-hankkeelle. Hankkeen kokonaiskustannukset ovat 450 002€.

Kirjallisuus

www.kaivosteollisuus.fi/fi/kaivosala-suomessa

—— 15.01.2021 ——

JAA MEDIASSA

Tuuli Nivala, Asiantuntija

Tuuli työskentelee Lapin AMK:lla FrostBitin asiantuntijana. Roolissaan hän hyödyntää pelipedagogista osaamistaan pelisuunnittelussa sekä osallistuu projektisuunnitteluun ja jossain määrin 2D-graafiseen suunnitteluun. Hän myös tekee laboratoriolle markkinointia ja AV-mediamateriaalia.

—— Mediakasvatuksen maisteri, Lapin Yliopisto

Alustariippumaton mobiilikehitys, kokemuksia Flutterista

FrostBit ohjelmistolaboratorio on viime vuosina kiinnostuneena seurannut Googlen tuottamaa Flutter-alustaa, sekä ottanut sitä myös aktiivisesti käyttöön mobiilisovellusten toteuttamisen tueksi. Tarve tehokkaalle alustariippumattomalle teknologialle on ollut suuri, sillä kahden erillisen natiivisovelluksen (Android + iOS) tuottaminen erikseen ei ole ollut tarpeeksi kustannustehokasta, oli kyse sitten kehitys- tai ylläpitovaiheesta.

Natiivisovellusten vahvuus on niiden täysi kustomoitavuus sekä mahdollisuus hyödyntää kaikkia puhelimen ominaisuuksia helposti, mutta niiden heikkous on kehitysprosessin tarvitsemassa henkilöstöresurssin määrässä, sekä nopeasti kehittyvän laitekannan tuoman jatkuvan ylläpidon tuomissa haasteissa. FrostBitin väki on aiemmin kokeillut mm. PhoneGap-alustaa alustariippumattomien sovellusten tuottamisessa, mutta sen tuomat rajoitteet todettiin liian haastaviksi FrostBitin teknisiin tarpeisiin nähden.

Vuonna 2017 Google julkaisi ensimmäisen version Flutterista, ja se herätti välittömästi suurta mielenkiintoa FrostBitin väessä. Koska FrostBitin projektikalenterissa oli silloin kaksi suurempaa mobiilisovellusprojektia tiedossa, päätimme rohkeasti kokeilla Flutteria molemmissa projekteissa natiivisovellusten tuomien ongelmien välttämiseksi.

https://en.m.wikipedia.org/wiki/File:Google-flutter-logo.png

Kun kuljemme nyt kohti vuotta 2021, olemme alustavasti erittäin positiivisesti yllättyneitä ja optimististia Flutterin suhteen alustariippumattomien sovellusten tuottamisessa, ja aiomme hyödyntää sitä myös tulevissa hankkeissa mahdollisimman paljon. Mutta koska mikään maailmassa ei ole täydellistä, on myös Flutterissa vahvuuksien lisäksi myös joitain heikkouksia. Olemme tämän vuoksi FrostBitin kesken keränneet kokemuksiamme Flutterin parissa viimeiseltä kahdelta vuodelta, ja tulleet alla olevaan lopputulokseen.

Flutterin hyvät puolet:

  • Kehittäminen on helpompaa verrattuna esimerkiksi PhoneGapiin tai Xamariniin, koska Flutter tarvitsee vähemmän alustakohtaista koodia
  • Flutter on alustariippumaton; sillä on mahdollista kehittää sovelluksia yhtä aikaa Androidille, iOS:lle, Windowsille, Linuxille, MacOS:lle, web ym.
  • Flutterilla sovellusten kehittäminen on nopeaa
  • Flutter mahdollistaa monimutkaisten ja kustomoitujen UI-komponenttien rakentamisen, sillä kaikkeen ulkoasuun liittyvän voi vaikuttaa
  • Flutterissa on hyvä dokumentaatio ja paljon esimerkkejä saatavilla. Myös Flutterin käyttäjäkunta kasvaa nopeasti
  • Flutterin taustalla on erittäin suorituskykyinen 2D-käyttöliittymämoottori (sky_engine), joka toimii hyvin tarvittaessa myös 120Hz –näytöillä
  • Flutterin käyttämä Dart-ohjelmointikieli on helposti opittava olio-ohjelmointikieli
  • Google on suuri organisaatio, jolla on varaa kehittää Flutteria tehokkaasti. Google myös itse käyttää Flutteria omassa toiminnassaan
  • Flutter-koodi kääntyy lopulta natiiviksi sovelluskoodiksi eri laitteilla
  • Flutterille on saatavilla hyvät kehitystyökalut mm. Android Studiolle ja Visual Studio Codelle
  • Flutter kehittyy nopeasti

Flutterin heikkoudet:

  • Monimutkaisten ulkoasujen tekeminen on joskus erittäin työlästä
  • Flutterin nopea kehittyminen tuo paljon muutoksia lyhyessä ajassa itse alustaan, mikä saattaa vaikeuttaa isojen projektien toteuttamista
  • Dart-ohjelmointikieli ja Flutter ovat vielä melko uusia, minkä vuoksi ne tulevat myöskin kehittymään jatkuvasti. Tämä ongelma tosin tasaantuu ajan myötä.
  • Flutterin parhaat ominaisuudet ovat vielä kehitysvaiheessa (null safety, web- ja työpöytäsovellustuki jne.)
  • Jos haluttuun alustakohtaiseen (Android tai iOS) ominaisuuteen ei Flutterissa löydy valmista liitännäistä, vaaditaan silloin alustakohtaista ohjelmointia
  • Flutterin nopeasti kasvanut suosio ja helppo ohjelmoitavuus on tuonut sen, että tarjolla on runsaasti kolmannen osapuolen liitännäisiä, joiden laadussa voi olla puutteita
  • Flutterin nuoren iän vuoksi ns. parhaat käytänteet ja arkkitehtuurit eivät ole vielä muodostuneet

Keskimäärin kuitenkin Flutterissa on huomattavasti enemmän hyviä kuin huonoja puolia, joista suurin osa liittyy lähinnä Flutterin nuoreen ikään tekniikkana.

Jos tarkastelemme lisäksi vielä joitain aiheeseen liittyviä internet-artikkeleita, voimme todeta että kokemuksemme ovat monessa asiassa samoilla linjoilla muiden maailmalla olevien kehittäjien näkökulmien kanssa (ks. Rozwadowski 2020;  Costa 2019; Sannacode 2020;  Powalowski 2019). Artikkeleiden mukaan Flutterin heikkouksia ovat lisäksi suuri mobiilisovelluksen koko, sekä tietyt kompromissit mobiilisovelluksen ulkoasussa, jotka liittyvät Androidin ja iOS:n virallisiin suosituksiin ulkoasusta (esim. material design). Emme kuitenkaan ole FrostBitin toiminnassa kokeneet näitä liian ongelmalliseksi nykyisten mobiiliprojektiemme osalta.

Olemme hyödyntäneet Flutteria kahdessa isossa hankkeessa, joista toinen on Arktori (Arktinen kehittyvä rehtori) ja toinen DWELL. Arktori-hankkeessa olemme tuottamassa mobiilisovellusta, jonka avulla pohjoisen alueen oppilaitosten rehtorit voivat verkostoitua, kehittää osaamistaan sekä mentoroida toisiaan omassa työssään. DWELL-hankkeessa sen sijaan olemme tuottamassa yhteisöllisen asumisen mobiilisovellusta, jonka pilotointikohteena on Rovaniemellä sijaitseva DAS Kelo –opiskelija-asuntola. Molempien projektien osalta olemme olleet tyytyväisiä Flutterin tarjoamiin mahdollisuuksien mobiilisovellusten kehittämisessä.

Alla kuvakaappauksia Arktori- ja DWELL-mobiilisovelluksista.

Arktori-mobiilisovellus (Flutter), kehitysversio joulukuu 2020
Arktori-mobiilisovellus (Flutter), kehitysversio joulukuu 2020
DWELL-mobiilisovellus (Flutter), kehitysversio joulukuu 2020
DWELL-mobiilisovellus (Flutter), kehitysversio joulukuu 2020

Flutter on osoittanut voimansa alustariippumattomien mobiilisovellusten tuottamisessa, mutta tulevaisuudessa jää vielä nähtäväksi, kuinka taipuisa ja tehokas Flutter tulee olemaan web- ja työpöytäsovellusten maailmassa. Jos Flutter tulee olemaan aidosti kilpailukykyinen myös mobiilisovellusten ulkopuolella, on täysin realistinen vaihtoehto keskittyä sovelluskehittäjän näkökulmasta pääsääntöisesti Flutteriin, jota tuetaan muilla tekniikoilla vain niiltä osin, joihin Flutter ei tehokkaasti taitu.

Emme ole vielä FrostBitissä aivan varmoja onko Flutter vielä kaikenkattavan tehokas tekninen alusta kaikenlaisiin tarpeisiin, mutta kukaan ei voi väittää etteikö se sitä tosissaan yrittäisi olla. Joka tapauksessa, tulemme seuraamaan Flutterin kehitystä jatkossakin erityisen suurella mielenkiinnolla ja olemme aina valmiita kokeilemaan Flutteria uusiin käyttötarkoituksiin!

—— 11.12.2020 ——

JAA MEDIASSA

Tuomas Valtanen, Projektipäällikkö

Tuomas toimii web/mobiilitiimin vetäjänä, ohjelmistosuunnittelijana ja osa-aikaisena opettajana FrostBitillä Lapin ammattikorkeakoulussa. Hänen tehtäviinsä kuuluvat projektinhallinta, projektisuunnittelu ja ohjelmistosuunnittelu sekä verkko-, mobiili- ja tekoälysovellusten asiantuntemus.

—— Insinööri, ylempi AMK

Referenssit

Viitatut Flutter-artikkelit:
https://www.futuremind.com/blog/pros-cons-flutter-mobile-development
https://medium.com/flutter-community/pros-and-cons-of-using-flutter-1f5d1269a4b9
https://medium.com/@sannacode/advantages-and-disadvantages-of-using-flutter-543bac7ced76
https://10clouds.com/blog/flutter-business-pros-and-cons

Tietoa Arktori-hankkeesta:
https://www.lapinamk.fi/fi/Yrityksille-ja-yhteisoille/Lapin-AMKin-hankkeet?RepoProject=521710

Tietoa DWELL-hankkeesta:
https://www.lapinamk.fi/fi/Yrityksille-ja-yhteisoille/Lapin-AMKin-hankkeet?RepoProject=521834