Roveksen ja Kapernaumin teollisuusalueella (jatkossa pelkkä Roves) on jatkuvaa pientä logistiikkaa ja tavaraliikennettä siellä sijaitsevien yritysten välillä. Lastin suuruus vaihtelee merkittävästi, mutta pienimmillään se on EURO-lavan päälle kasattuja tarvikkeita ja suurimmillaan kymmenien tonnien edestä raskasta rahtia. Tällä hetkellä rahti kulkee yritysten oman työvoiman, pakettiautojen ja isompien kuorma-autojen avulla. Tähän pieneen logistiikkaan kuluu huomattava määrä henkilötyövuosia ja polttoainetta. Tehottomuus hidastaa teollisuusalueen toiminnan kasvua ja vaikuttaa kielteisesti sen kilpailukykyyn. Hankkeen tarve on noussut puhtaasti yritysten kiinnostuksesta ja innostuksesta lähteä kehittämään alueelle autonomista tai lähes autonomista logistiikkaratkaisua, joka voisi suurelta osin hoitaa ei-akuutin tai aikakriittisen tavaraliikenteen Roveksen teollisuusalueen sisällä.

• Hankkeen nimi: RovesUGV
• Hankenumero: A81318
• Hankkeen rahoitus: Kestävän kaupunkikehittämisen haku – Seinäjoen ekosysteemisopimus 20.5. – 28.6.2024
• Hankkeen toteutusaika: 1.4.2025–30.7.2026

Avoimen lähdekoodin ROS2 järjestelmän hyödyntäminen teollisuuden aluelogistiikan autonomisoimisessa

Hankkeen tarpeen taustalla on Roveksen ja Kapernaumin teollisuusalueiden yritysten välinen jatkuva logistiikka ja tavaraliikenne, jossa lastin suuruus vaihtelee huomattavasti. Nykyisin rahti kulkee yritysten oman työvoiman, pakettiautojen ja isompien kuorma-autojen avulla, mikä kuluttaa huomattavan määrän henkilötyövuosia ja polttoainetta. Tämä tehottomuus hidastaa teollisuusalueen toiminnan kasvua ja vaikuttaa kielteisesti sen kilpailukykyyn. Autonominen logistiikka tarjoaa ratkaisun näihin haasteisiin, ja sen käyttöönotto on välttämätöntä Roveksen teollisuusalueen toiminnan kehittämiseksi ja kilpailukyvyn parantamiseksi.Hankkeen tavoitteisiin kuuluu luoda Roveksen yritysten kanssa yhteinen käsitys siitä, miten autonomiset logistiikkareitit voisivat toimia alueella. Lisäksi tavoitteena on selkeyttää autonomisten kuljetusajoneuvojen käyttöön liittyvät lupa-asiat ja lainsäädännölliset haasteet, yhteiskehittää ja toteuttaa Proof-of-Concept (PoC) -demo.

Työpaketit

TP1: Hallinto, viestintä, hankkeen johto ja vaikuttaminen

TP2: Roveksen alueen kartoittaminen ja optimaalisten reittien etsiminen

TP3: PoC-demonstraatio SeAMKin Husarion UGV-alustaa käyttäen

Hankkeen tavoitteet

1. Hankkeen päätavoitteena on kehittää ja demonstroida autonomisia logistiikkaratkaisuja Roveksen teollisuusalueella.
2. Parantaa alueen sisäistä logistiikkaa, tehostaa toimintaa ja tuo merkittävää brändiarvoa alueelle.

Toimenpiteet

Hankkeen toimenpiteet jakautuvat kolmeen työpakettiin:

Työpaketti 1:

• Hankkeen hallinto
• Hankkeen julkaisut SeAMK:n kanavissa

Työpaketti 2:

• Roveksen alueen kartoitus
• Logistiikkatarvekartoitus Roveksen yrityksiltä
• Reittisuunnittelu ja optimointi
• Lupien ja lainsäädännön selvitys
• Roveksen saavutettavuuskartan työstäminen

Työpaketti 3:

• Proof-of-concept (PoC) demon yhteiskehittäminen ja toteuttaminen SeAMK:n Panther mobiilirobotilla

Hankkeen kohderyhmä

Hankkeen kohderyhmänä ovat Roveksen teollisuusalueen yritykset. Välillisesti kohderyhmään kuuluvat korkeakoulut ja Seinäjoen kaupunki sekä yleisesti logistiikka-alan yritykset.

Hankkeen tulokset

Hankkeen toiminnan tuloksena syntyy

• 5 artikkelia SeAMK:n kanaviin
• Roveksen alueen kartoitus, joka sisältää teiden, risteysten ja rakennusten sijainnit ja ominaisuudet
• Optimaalisten reittien suunnittelu autonomisille kuljetuksille, sekä virtuaaliteiden mahdolliset sijainnit, perustuen kartoitukseen ja tarvekartoitukseen.
• Visualisoitu saavutettavuuskartta.
• Lupa- ja lainsäädäntöselvitys, missä on kartoitettu vaadittavat luvat ja autonomista logistiikkaa koskeva lainsäädännöstä.
• Yksityiskohtainen suunnitelma PoC-demonstraatiosta, joka sisältää reitin, testauksen ja toteutuksen todellisessa ympäristössä.
• Toteutettu autonominen PoC-demonstraatio kahden yrityksen välillä Roveksessa ja sen perusteellinen raportointi.

Hankkeessa kehitettyä UGV-prototyyppiä algoritmeineen tullaan käyttämään myös tulevissa TKI-hankkeissa ja opetuksessa. Yritykset voivat käyttää tätä tutkimusalustaa myös omissa kehityshankkeissaan. Prototyyppiä voidaan hyödyntää myös IXFactory – ja Sähköiset voimalinjat -hankkeissa syntyvien TKI- ja opetuskokonaisuuksien yhteydessä.

Hankkeessa tehdään proof-of-concept kokeiluja, joiden myötä pystytään todentamaan avointen järjestelmien hyödynnettävyys työkoneiden ja niiden osien automatisoinnissa.
Hankkeessa syntyvä yritys-korkeakouluyhteistyöverkosto jatkaa työskentelyä esiin tulevien tarpeiden ja jatkokehitysnäkymien pohjalta uusissa EAKR hankkeissa.

Hanke etsii potentiaalisia yrityksiä esiselvityshaastatteluiden ja alueen elinkeinotoimien avustuksella ja järjestää työpajatapahtuman/-ia yhteistyössä elinkeinotoimien kanssa. Alueen yrityksistä työpajoihin ja demoihin osallistuvien henkilöiden osaaminen kehittyy suoraan ja SeAMK:n opetushenkilökunnan osaamisen päivittymisen kautta myös
uudet valmistuvat insinöörit saavat parempaa osaamista autonomisten työkoneiden teemassa.

Hankkeen työpajoista yritykset saavat uusia ideoita sekä tuotekehitykseen että teknologian hyödyntämismahdollisuuksiin, mikä mahdollistaa Etelä-Pohjanmaan elinkeinorakenteen uudistumista ja monipuolistumista. Pitkällä aikavälillä työkoneiden autonomisoituminen tukee resurssiviisasta toimintaa, mikä
on osaltaan merkittävä syy yrityksille panostaa tämän teeman osaamisen hankkimiseen.

RovesUGV Tietosuojaseloste(Opens in a new window)

 

KOODIJULKAISU 1: Python-asiakasohjelma Fixposition Vision-RTK 2 -laitteen API:lle

Hankkeessa kirjoitettiin Python-ohjelmointikielellä API-rajapinta (Application Programming Interface = rajapinta, jonka kautta kaksi ohjelmaa tai järjestelmää voivat kommunikoida keskenään), jonka avulla RovesUGV-hankkeessa käytettävä Panther-mobiilirobotti voi kommunikoida Fixposition Vision-RTK 2 -paikannusmoduulin kanssa. Tuon moduulin avulla saadaan mobiilirobotin tarkka paikka selville satelliittinavigaation ja sen korjaussignaalin (GNSS+RTK), inertiamittausyksikön (IMU), visuaalisen odometrian (paikoitus videosyötteen avulla) ja näiden syötteiden avulla muodostetun sensorifuusion avulla. Eli lyhyesti sanottuna tämän asiakasohjelman avulla mobiilirobotti (Panther) pystyy kommunikoimaan paikoitusyksikön (Vision-RTK 2) kanssa.

Laitteen konfigurointi tapahtuu pääasiassa verkkoselaimella, mutta sen voi vaihtoehtoisesti tehdä myös laitteen API:n eli ohjelmointirajapinnan kautta. Koska Fixposition API:lle ei ollut saatavilla valmista asiakasohjelmaa, se päätettiin kehittää itse käyttämällä Python-ohjelmointikieltä.

Asiakasohjelma tukee seuraavia toiminnallisuuksia:

• laitteen konfiguroinnin varmuuskopion luominen ja palautus
• kameran kalibroinnin hallinta ja videokuvan striimaus
• CAN (Controller Area Network) -väylän asetusten hallinta
• järjestelmän palveluiden hallinta
• sensorifuusion hallinta
• RTK (Real Time Kinematic) -korjausdatan striimausparametrien hallinta
• laitteen lokitietojen hallinta
• ulkoisten karttapalvelujen valtuutusten (engl. token) hallinta
• käyttäjädatan hallinta
• verkkoasetusten hallinta
• käyttäjän omien konfiguraatioiden hallinta
• laitteen järjestelmätietojen lukeminen
• salasanan asetus ja nollaus

 

Linkki koodijulkaisuun GitHub-verkkopalvelussa:

https://github.com/SeAMKedu/rovesugv-fixposition-api-client

 

Fixposition API-dokumentaatio:

Fixposition-laitteen ohjelmointirajapinnan dokumentaatio on saatavilla osoitteessa https://docs.fixposition.com/fd/api-documentation.

 

Ohjelmistoriippuvuudet:

Asiakasohjelma käyttää alla listattuja Python-paketteja:

• requests
• pillow
• pydantic

 

Tekijätiedot:

Hannu Hakalahti, Asiantuntija, TKI, Seinäjoen ammattikorkeakoulu (SEAMK).

 

KOODIJULKAISU 2: ROS2 -paketti nelipyöräisen mobiilirobotin GPS-navigoinnin simulointiin.

Mobiilirobotin GPS-navigoinnin kehitys on monimutkainen kokonaisuus, mikä edellyttää lukuisia eri ohjelmia ja niiden vuorovaikutusta keskenään. Monimutkaisuuden seurauksena ohjelmien asetusten testaus edellyttää suurta osuutta GPS-navigoinnin kehitysprosessin kokonaisajasta. Testausta voidaan onneksi nopeuttaa ja helpottaa simuloinnin avulla.

RovesUGV-hankkeessa kehitettiin ROS 2 -paketti nelipyöräisen mobiilirobotin GPS-navigoinnin simulointia varten. Paketti kehitettiin hyödyntämällä ROS 2 (Robotic Operating System 2) -sovelluskehyksen tarjoamia valmiita työkaluja ja kirjastoja. ROS 2 -paketti on käytännössä projektikansio, joka sisältää käynnistettävien robottisovellusten lähdekoodin ja konfigurointi- ja käynnistystiedostot. Paketissa on myös itse paketin metatietoja, kuten paketin kuvaus sekä tekijä- ja lisenssitiedot. Hankkeessa kehitetyssä ROS 2 -paketissa on lisäksi mobiilirobotin ja simulointiympäristön 3D-mallit, mobiilirobotin URDF (Unified Robot Description Format) -tiedosto robotin kuvailuun, ja simulointiympäristön SDF (Simulation Description Format) -tiedosto simulointiympäristön kuvailuun. ROS 2 -paketti helpottaa robottisovellusten hallintaa ja jakamista toisten kanssa.

ROS 2 -paketti voi sisältää useita robottisovelluksia, joista ROS 2 -ekosysteemissä käytetään nimitystä ROS 2 -solmu (engl. node). ROS 2 -solmut voivat viestittää keskenään aiheiden (engl. topic), palveluiden (engl. service), ja toimintojen (engl. action) välityksellä. ROS 2 -paketissa voidaan käynnistää samaan aikaan useita eri ROS 2 -solmuja vaaditun toiminnallisuuden saavuttamiseksi.

Alla on listattu ohjelmat ja ROS 2 -solmut, jotka käynnistetään mobiilirobotin simulointiin tarkoitetussa ROS 2 -paketissa:

• Gazebo: ohjelma 3D-simulointiin
• RViz2: ohjelma robotteihin liittyvän datan visualisointiin
• Mapviz: ohjelma 2D-karttadatan visualisointi ja reittipisteiden antamiseen
• Nav2: kirjasto mobiilirobottien navigointiin
• ros_gz_bridge: mahdollistaa Gazebon ja ROS 2:n välisen tiedonsiirron
• robot_state_publisher: julkaisee robotin rakenteen ja asennon
• ekf_filter: laajennettu Kalman suodin robotin sijaintiarvion tuottamiseen
• navsat_transform: GPS-datan muunnos Nav2-kirjaston käyttämään formaattiin
• swri_transform: koordinaatiston hallinta ja muunnokset
• static_transform: tarvittavan staattisen koordinaatistomuunnoksen julkaisu
• gazebo_ros_image_bridge: videokuvan lähetys Gazebosta ROS 2:seen

 

Termien/nimien selitykset:

ROS2 = (Robot Operating System) on ns. väliohjelmisto, joka toimii kahden (tai useamman) järjestelmän välissä ja hoitaa niiden välisen viestinnän.

Gazebo = Robotiikan simulaattoriohjelmisto, jota käytetään erityisesti yhdessä ROS2:n kanssa robottien testaamiseen ilman fyysistä laitteistoa.

LiDAR = (Light Detection and Ranging) on etäisyysmittaustekniikka, joka käyttää laseria ympäristön mittaamiseen.

RViz2 = Visualisointityökalu ROS2:lle, jolla nähdään mitä robotti “näkee” ja tekee reaaliajassa

MapViz = ROS2-ympäristössä käytettävä karttapohjainen visualisointityökalu, joka keskittyy erityisesti GPS- ja karttadataan.

 

Linkki koodijulkaisuun GitHub-verkkopalvelussa:

https://github.com/SeAMKedu/rovesugv_navsim

 

Ohjelmistoriippuvuudet

• ROS2 Humble (asennus)
• Ignition Gazebo Fortress (asennus)
• Joukko ROS2 -paketteja (paketit lueteltu GitHub-palvelussa)
• customtkinter GUI-sovellusta varten (GUI = Graphic User Interface = graafinen käyttöliittymä)
• Docker
• ROS Offline Google Maps for MapViz (asennus)

 

Simulaation ajaminen (tarkemmat käskyt GitHubissa):

1. Käynnistä MapProxy-palvelin (Huomautus: tämä tarvitsee tehdä ainoastaan kerran tietokoneen käynnistämisen jälkeen).
2. Avaa terminaali ja mene omaan ROS2 workspace -kansioosi
3. Lataa ympäristömuuttujat
4. Käynnistä simulaatio
5. Avaa uusi terminaali ROS2 workspace -kansiossa ja lataa tarvittavat ympäristömuuttujat. Käynnistä sitten ROS2-solmu, joka vastaanottaa MapViz-kartassa klikatun pisteen GPS-koordinaatit ja navigoi mobiilirobotin kyseiseen pisteeseen.
6. Vaihtoehtoisesti voit käynnistää uudessa terminaalissa GUI-sovelluksen, jolla voi ohjata mobiilirobottia määrättyihin GPS-koordinaatteihin.

Simulaation voi sulkea painamalla Ctrl+c.

 

Gazebo-simulaattori

Mobiilirobotin ja sen antureiden simulointi. Simulointiympäristöön voidaan lisätä kohteita (esim. kuutio tai sylinteri) vasemman yläkulman valikosta.

 

RViz2-visualisointiohjelmisto

Anturidatan (esim. lidar) visualisointi.

 

MapViz

MapViz-sovellus näyttää mobiilirobotin sijainnin karttapohjalla. Jos ”gps_waypoint_commander”-solmu on käynnissä, kartalla voi klikata pistettä, johon haluaa mobiilirobotin liikkuvan.

 

 

GUI-sovellus

Python-sovellus, jolla voi ajaa mobiilirobottia joko manuaalisesti yläosassa olevilla painikkeilla tai pitkin ennalta määritettyjä GPS-reittipisteitä. Reittipisteet on tallennettu ”config”-kansiossa olevaan ”gps_waypoints.yaml”-tiedostoon.

 

 

Tekijätiedot:

Hannu Hakalahti, Asiantuntija, TKI, Seinäjoen ammattikorkeakoulu (SEAMK).

SENSORIFUUSIO PANTHER-MOBIILIROBOTIN OHJAUKSESSA

Husarion Panther -mobiilirobotin paikannus perustuu Fixposition Vision-RTK 2 -laitteen kiihtyvyysanturin, kameran (visuaalisen odometrian) ja kahden satelliittivastaanottimen sensorifuusioon. Sensorifuusion ansiosta laitteen paikannustarkkuus säilyy hyvänä myös lähellä korkeita rakennuksia tai puita, jotka häiritsevät paikannussatelliiteista saatavia signaaleja.

Vision-RTK 2 pystyy vastaanottamaan ulkoisen RTK-tukiaseman lähettämää korjausdataa (paikannussatelliittien radat, kellot ja virheet), minkä ansiosta laitteen paikannustarkkuus on parhaimmillaan noin 2–4 cm. Kahden satelliittivastaanottimensa ansiosta Vision-RTK 2 kykenee määrittämään reaaliaikaisesti oman suuntansa myös silloin, kun mobiilirobotti on paikallaan.

Fixposition Vision-RTK 2:n sensorifuusio otetaan käyttöön siten, että aluksi laitteen web-käyttöliittymästä määritetään RTK-tukiasema, jonka korjausdataa halutaan käyttää. Seuraava askel on ajaa mobiilirobotti avoimelle ulkoalueelle ja odottaa kunnes laitteen molemmat satelliittivastaanottimet ovat saavuttaneet tarkimman RTK Fixed -tilan, mikä vastaa senttimetriluokan paikannustarkkuutta. Seuraavaksi kalibroidaan laitteen sisäinen kiihtyvyysanturi ajamalla mobiilirobottia pitkin venytettyä kahdeksikkoa muistuttavaa rataa. Kun kaikki edellä mainitut toimenpiteet on tehty, sensorifuusio käynnistetään laitteen web-käyttöliittymän kautta.

Sensorifuusion toiminta edellyttää lisäksi Vision-RTK 2:n ROS 2 -ajurien ajamista. Ajurien konfigurointitiedostossa määritetään muun muassa Nav2-toimintatila eli käytetäänkö Vision-RTK 2:sta yhdessä Nav2-kirjaston kanssa. Mikäli näin tehdään, laitteen valmistaja suosittelee, että Vision-RTK 2 on järjestelmän ainoa paikannusanturi. Tällöin laajennettu Kalman suodin (Extended Kalman Filter, EKF) ei ole käytössä, sillä muuten se aiheuttaisi konflikteja TF-puuhun eli muunnospuuhun.

TF-puu on järjestelmä, joka kuvaa robotin eri koordinaatistojen välisiä sijaintisuhteita. Kun sensorifuusio on toiminnassa, Vision-RTK 2:n ajurit muodostavat TF-puun laitteen koordinaatistoista. Robotin paikannuksen kannalta oleellisin koordinaatistomuunnos on FP_ECEF à FP_ENU0 à map à odom à vrtk_link.

FP_ECEF (Earth-Centered Earth-Fixed) vastaa maapallon keskipistettä, FP_ENU0 vastaa sijaintia ENU (East North Up) -koordinaateissa, map on globaali koordinaattikehys, joka on sidottu todelliseen ympäristöön, kun taas odom on lokaali koordinaattikehys, joka kuvaa robotin sijaintia suhteessa sen lähtöpisteeseen käyttäen jatkuvaa paikallista odometriaa. vrtk_link puolestaan vastaa Vision-RTK 2:n kuoressa olevan logon keskipistettä.

Mobiilirobotin GPS-navigointia varten Vision RTK 2:n ja Pantherin TF-puut täytyy yhdistää. Tämä tehdään osana Pantherin ohjausta varten kehitetyssä ROS 2 -paketissa, jossa yksi paketin käynnistämistä ROS 2 -solmuista julkaisee staattisen koordinaatistomuunnoksen Vision-RTK 2:n ja Pantherin juurikehyksen välillä: vrtk_link à panther/base_link.

Nav2-kirjasto, joka käytännössä vastaa Pantherin navigoinnista, käyttää navigoinnin reittisuunnittelussa apuna Vision-RTK 2:lta saatavia odometria-viestejä. Lisäksi kyseinen kirjasto käyttää valotutkalta saatavaa pistepilveä laskeakseen uuden reitin mahdollisten esteiden väistämiseksi.

Kuviossa 1 esitetään eri ohjelmat ja ROS 2 -paketit, joita vaaditaan Panther-mobiilirobotin ohjaukseen ja GPS-navigointiin.

Kuva 1. Ohjelmat mobiilirobotin navigointiin ja ohjaukseen.

 

Linux-tietokoneella ajetaan rovesugv_gps_nav ROS 2 -pakettia, joka kehitettiin hankkeen aikana Pantherin ulkotilanavigointia varten. Tietokoneella ajetaan myös Docker-konttia, joka toimii välityspalvelimena ROS 2 -paketin käynnistämän Mapviz-ohjelman karttalle. Hankkeen aikana kehitettiin myös toinen ROS 2 -paketti, rovesugv_web_teleop, joka on mobiilirobotin etäohjaukseen käytettävä verkkosovellus.

Husarion Panther sisältää kaksi minitietokonetta: Raspberry Pi 4 ja Nvidia Jetson Orin. Raspberry:llä ajetaan Husarionin omaa Pantherille kehitettyä ROS 2 -pakettia panther_ros ja niin ikään Husarionin kehittämää ROS 2 -pakettia, joy2twist, joka mahdollista Pantherin manuaalisen ajamisen peliohjaimen avulla. Nvidia Jetson:illa ajetaan Velodyne-valotutkan Docker-konttia ja Fixposition Vision-RTK 2:n ROS 2 -ajuria.

 

Tekijätiedot:

Hannu Hakalahti, Asiantuntija, TKI, Seinäjoen ammattikorkeakoulu (SEAMK).

From Satellite Imagery to Full Stack Outdoor Navigation

Abstract

This study documents the development of an outdoor autonomous navigation stack for the SEAMK unmanned ground vehicle (UGV). The core idea is for the UGV to travel around 250 metres from one point selected in a satellite image to another, staying on the road, stopping for people, and avoiding obstacles. The work progressed through five stages: (i) establishing a simulation environment for testing; (ii) extracting a drivable road network from satellite and open–map data; (iii) converting GPS coordinates to the robot’s local frame so that Nav2 can follow the route; (iv) adding a forward–facing camera road–segmentation module so the robot can perceive drivable ground locally; and (v) fusing the global GPS route with the local camera perception into a single command stream, together with a human–detection safety stop. This document describes each idea, exploring the options that succeeded and some that failed

 

1 INTRODUCTION

The core objective of the SEAMK project was to give the UGV the ability to navigate autonomously through an outdoor campus/urban environment to a given point. To save local memory and stay flexible in unknown areas, this project did not use premade maps like those common in indoor settings. The initial strategy was to use satellite imagery and OpenStreetMap [1] to build a coarse road network, plan a route on it, and then rely on the robot’s own camera to keep it centered on the road during execution. The development followed a chronological workflow, grouped into the following themes:

1. Remote connection and simulation setup (Sec. 2).
2. Road extraction from satellite / aerial data — what was tried, what failed, what succeeded (Sec. 3).
3. Route planning from map clicks (Sec. 4).
4. GPS-to-map conversion and hand–off to Nav2 (Sec. 5).
5. Camera–based road segmentation (Sec. 6).
6. Fusion of GPS route and camera perception (Sec. 7).

Each section states the idea being tested, the outcome, and the lessons carried into the next stage.

1.1 Platform

The vehicle is a Husarion Panther V1.2, a ∼55 kg skid-steer UGV capable of carrying up to 80 kg. It can be equipped with RGB-D cameras, 3D LiDARs, RTK GNSS receivers and ultrasonic sonars. For this project it carries a StereoLabs ZED X stereo camera on a StereoLabs (Orin NX 16 GB) compute module, with integrated GNSS and IMU. The reference mission is a preliminary route from the door of the robotics laboratory (A) to the door of the automotive and work machine laboratory (B) and back — about 250 m.

 

2 SIMULATION SETUP

Development began by exercising the basic functionality in simulation, so that navigation logic could be validated without the physical platform. A peer-to-peer VPN (Husarnet) was used to join the operator computer, the local development machine and the Panther_unit into one whitelist, giving full remote access to the ROS 2 [2] graph running on the vehicle.

For simulation, the digital twin of the deployment site was imported into Gazebo/Ignition [3] and the rover model was spawned onto it (Fig. 1). A set_pose service was used to “teleport” the robot to arbitrary start locations on the map, which made it easy to test navigation from many different positions (Fig. 2). This simulation became the workbench for every later stage.

Figure 1: Digital twin of the deployment site imported into Gazebo (top), aligned with the corresponding aerial view (bottom). The rover is spawned on the terrain tile.

 

Figure 2: Teleporting the rover to an arbitrary pose on the map via the set_pose service, used to test navigation from many start points

 

3 ROAD EXTRACTION FROM SATELLITE IMAGERY

The first technical problem in the project was to obtain a drivable road mask of the environment from overhead imagery. Several ideas were tested.

3.1 Idea 1 – Self–supervised feature / PCA maps

The first attempt was to feed satellite tiles to a selfsupervised vision backbone [4] and visualize the per-pixel features with a principal component analysis (PCA) projection (Fig. 3). The idea was that roads, water and buildings would fall into separable feature clusters. The features did in fact separate the major structures (the river is clearly distinct from roads, for example), but the road surface itself was not cleanly isolated: roads and open ground shared similar embeddings. This approach was informative but did not, on its own, yield a usable binary road mask.

Figure 3: Satellite tile (left) and its PCA feature map (right). Major structures such as the river separate well, but the road surface is not cleanly isolated — a partial result

 

3.2 Idea 2 – Promptable segmentation (Segment Anything Model)

A SAM model [5] was applied to the satellite tiles (Fig. 4) with the keyword “roads” to separate the road surface. This segmented large, coherent regions – most reliably the river – but it captured only the most salient (information-rich) areas rather than the road network specifically, so it could not be used directly as a road extractor.

 

Figure 4: Promptable segmentation of a satellite tile. Coherent regions (notably the river) are captured, but the output is not road-specific.

 

3.3 Idea 3 – OSM + parameter–tuned road extraction (success)

The approach that succeeded combined open-map information with tuned image processing. Starting from an OpenStreetMap raster of the same area, the road layer was isolated and cleaned by parameter optimization until a connected road skeleton emerged (Fig. 5 and Fig. 6). Unlike the learned-feature attempts, this produced a clean, connected binary road network suitable for graph search. This mask became the basis for all route planning.

Figure 5: Parameter optimization for road extraction: OSM raster (left), intermediate feature response (centre) and the extracted road response (right).

Figure 6: The tuned pipeline yields a connected road network (b) from the overhead feature response (a).

 

4 ROUTE PLANNING FROM MAP CLICKS

4.1 Early prototype: pixel search on the road mask

The first route–planning prototype operated directly on the extracted binary road mask (Sec. 3). Given a start and end point on the map, an A* search [6] returned the shortest path constrained to the white road pixels (Fig. 7). However, since the map-to-reality scale was incorrect, the path could not be handed to the robot directly. It was superseded by the OSM–graph planner below.

Figure 7: Early prototype: interactive shortest–path search on the extracted road mask. Left–click sets start then goal; the search is constrained to road pixels. Three queries are shown. This validated the network but planned in pixels, not GPS.

 

4.2 Deployed planner: clicked GPS points on the OSM graph

The deployed route planner removes the failed pixelbased step entirely and plans on OpenStreetMap’s own road graph. The start/goal interaction works as follows:

1. The node subscribes to /clicked_point (geometry_msgs/PointStamped) published by Mapviz, and requires the click frame to be wgs84. Each click is therefore a geographic coordinate, with x = longitude and y = latitude.
2. A small state machine interprets the clicks: the first click sets the START, the second click sets the GOAL and triggers planning, and a third click resets to a new START.
3. On the goal click, the planner uses OSMnx [7] to download the road graph around the midpoint of the two clicks (graph_from_point, ∼1200 m radius), snaps the start and goal to the nearest graph nodes, and runs a networkx [8] shortest path weighted by edge length. The route stays on real roads because the search is on the road graph itself. Edge geometries are read back as a latitude/longitude polyline.

This is the mechanism behind the Route Planner block of the full pipeline (Fig. 16). Coordinate conversion and Nav2 hand-off are described next (Sec. 5).

 

5 GPS–TO–MAP CONVERSION AND NAV2 HAND–OFF

The route from Sec. 4.2 is a latitude/longitude polyline, which must be expressed in the robot’s local coordinate frame before the Nav2 navigation stack [9] can drive it. The node supports two conversion modes:

1. Anchor mode (default). Each lon/lat vertex is projected to the local UTM zone and expressed relative to the first vertex, then anchored at the robot’s current pose in the map frame (obtained from the map →base_link TF). This method needs no georeferenced map, only the current robot pose.
2. FromLL mode. Each lon/lat vertex is converted through the robot_localization [10] /fromLL service, which returns the corresponding point directly in the map frame using the navsat transform.

The resulting polyline is then densified to a fixed spacing (default ∼10 m) and the goal poses are sent one at a time to Nav2’s NavigateToPose action: the node waits for each goal’s result before sending the next, and sets each goal’s yaw toward the following waypoint (Fig. 8). Nav2 returns the velocities and local path between successive waypoints.

Figure 8: Route hand–off: clicked GPS start/goal → OSMnx on–road route (lon/lat) →UTM–anchor or /fromLL conversion to the map frame →densified waypoints →sequential NavigateToPose goals →Nav2 velocities and local path.

This pipeline was validated in simulation. Feeding the full GPS waypoint list to Nav2 produced a coherent global route that the robot tracked across the map (Fig. 9), while the Nav2 controller generated the smooth local trajectory between successive goals, including avoidance of inserted obstacles (Fig. 10).

Figure 9: Global path: the complete GPS waypoint route (blue) and the robot’s trail as it follows the goals in Gazebo

 

Figure 10: Local path: the Nav2 controller producing the local trajectory between goals, with obstacles present in the scene.

 

6 CAMERA-BASED ROAD SEGMENTATION

The GPS route keeps the robot roughly on the right streets, but GPS alone is not precise enough to keep the vehicle within a specific path. To perceive the drivable surface locally, a forward-facing camera segmentation module was developed: it takes RGB frames from the ZED camera, produces a road mask, and reduces that mask to a target point indicating the drivable direction ahead. Road detection was approached as three methods of increasing complexity, described below in order.

6.1 Classical method

The simplest approach used classical colour and edge [11] heuristics to separate the road from its surroundings and derive a steering target. It is the cheapest option computationally, but on the SEAMK route the gravel/rubble surface and the weak visual distinction between road and vegetation made it unreliable, so it was not pursued further.

6.2 FastSAM (general segmentation)

The second approach used FastSAM [12], a lighter variant of the Segment Anything Model [5] chosen for realtime use. It produces many class-agnostic masks per frame, from which a scoring heuristic selects the most road-like one; the mask is cleaned with morphology and connected-component seeding, and its centroid is taken as a steering cue (Fig. 11, Fig. 12).

Figure 11: FastSAM road–perception pipeline: ZED camera →RGB image →class–agnostic segmentation (FastSAM) → road–mask selection →centre–point detection.

 

Figure 12: Road segmentation with the extracted drivable region (green) and its detected centre point (red).

In favourable conditions — clear ground, good contrast — this was reliable and the centre point sat firmly on the path (Fig. 13). In harder scenes, with ambiguous ground/grass boundaries, the mask over- or undersegmented and the centre point drifted (Fig. 14). Because FastSAM is not road-aware and these results were unreliable, it remained an experiment and motivated moving to a trained semantic model.

 

Figure 13: Examples of good segmentation: the drivable surface is captured cleanly and the centre point lies on the path.

 

Figure 14: Examples of poor segmentation: ambiguous lighting/ground causes the mask to spread and the centre point to drift.

 

6.3 PPLiteSeg (semantic segmentation)

The final and adopted approach used PPLiteSeg [13], a trained semantic-segmentation network that labels road, vegetation, people, cars, sky, and more directly. It is heavier (initial tests on CPU, better on GPU) but gives the most consistent road class, and as a bonus provides the person class used for the safety stop. The production node runs a Cityscapes-pretrained [14] PPLiteSeg and keeps the road class (trainId 0). Instead of a single centroid, it extracts the road centre with a scan-line method: over a set of rows in the lower part of the frame (between 0.62 and 0.90 of the image height) it finds the left and right road edges per row, takes the mid-point, and computes a weighted average biased toward the rows nearest the robot. From this target it publishes a RoadObservation message on /road_observation carrying a valid flag, the normalised lateral error from the image centre, the heading error, a confidence score (combining valid-row count, road width, road area and temporal stability), and the raw target pixel and road width. This message, not a raw image, is what the fusion stage consumes.

6.4 Comparison

Fig. 15 places the three methods side by side. The classical method breaks down on the ambiguous ground; FastSAM segments a plausible region but not a specific road class; PPLiteSeg gives the cleanest, most stable drivable surface and was therefore adopted as the production perception front-end.

Figure 15: Comparison of road–segmentation methods: classical heuristic (left), FastSAM general segmentation (centre) and PPLiteSeg semantic segmentation (right).

 

6.5 Emergency stop for humans

A safety behaviour is layered on the same PPLiteSeg output. The person class (Cityscapes class 11) is isolated, cleaned with morphology, and its largest connected component is measured. If that blob exceeds a pixel-area threshold (human_stop_pixel_threshold, ≈1500 px — i.e. a person close enough to matter) the robot stops. The logic is simply: human detected →largest blob above the pixel threshold? →stop, overriding the forward command.

7 FUSION OF GPS ROUTE AND CAMERA PERCEPTION

The final stage combines the two information sources so that each covers the other’s weakness: the GPS route provides the global direction of travel, while the camera provides a local correction to stay centred on the visible road. The intended pipeline is shown in Fig. 16: the GPS/Nav2 branch produces a baseline command /cmd_vel_nav, the camera branch publishes /road_observation, and a fusion node blends them into the final /cmd_vel.

In the additive design (road_nav_fusion_node.py), the fusion node starts from the latest Nav2 command and adds a confidence-scaled steering correction from the road observation,

ωfused = ωnav + α c, c = − (︁ klatelat + kheadehead )︁ ,

where the blend weight α grows with vision confidence and is reduced on sharp upcoming turns, so the route — not the camera — decides direction at intersections, and the system falls back to pure Nav2 when the road mask is weak. Two other arbitration strategies were also prototyped: camera-only driving, and a twist_mux that switches by priority between the Nav2 and vision commands.

Because of the time constraints of the project, this fusion stage could not be fully completed and validated. The individual components — GPS route planning, Nav2 control, road perception and the human stop — each work on their own, but their end-to-end integration and testing on the real vehicle remain to be finished.

 

8 DISCUSSION: WHAT WORKED AND WHAT DID NOT

Partial. Separated water/structures but not a clean road mask. Promptable segmentation (SAM) on satellite

Partial. Segmented salient regions (river), not roads specifically. OSM + tuned road extraction Success. Clean, connected binary road network. Pixel search on road mask Prototype. Validated the network but planned in pixels, not GPS. OSMnx graph planning from clicked GPS points

Classical camera segmentation Works but lighting/texture sensitive. FastSAM camera segmentation Experiment. Flexible but not road–specific; visualisation only. PPLiteSeg semantic segmentation Best of the three; deployed, publishes RoadObservation. GPS + camera fusion Success. Global route with local road correction.

Idea	Outcome
Self–supervised / PCA feature maps of satellite tiles	Partial. Separated water/structures but not a clean road mask.
Promptable segmentation (SAM) on satellite	Partial. Segmented salient regions (river), not roads specifically.
OSM + tuned road extraction	Success. Clean, connected binary road network.
Pixel search on road mask	Prototype. Validated the network but planned in pixels, not GPS.
OSMnx graph planning from clicked GPS points	Success. On–road shortest path; deployed planner.
GPS → map (UTM–anchor / /fromLL) → Nav2	Success in sim; needed frame/transform debugging.
Classical camera segmentation	Works but lighting/texture sensitive.
FastSAM camera segmentation	Experiment. Flexible but not road–specific; visualisation only.
PPLiteSeg semantic segmentation	Best of the three; deployed, publishes RoadObservation.
GPS + camera fusion	Success. Global route with local road correction.

Table 1: Summary of the ideas tested and their outcomes.

 

8.1 Sim–to–real deployment challenges

The stack that ran cleanly in simulation exposed several gaps on the physical robot, most of them rooted in the difference between the “textbook” simulated TF/topic setup and the real one:

• Frames and namespaces. Simulation uses a clean map→odom→base_link tree, whereas the robot mixes panther/base_link, vrtk_link and Fixposition frames. A stray panther namespace on the Jetson (absent on the laptop) and static 180◦TF flips were recurring sources of wrong headings and local– costmap mismatches.
• Latency. A navsat_transform delay: 3.0 that simulation tolerated made the map→odom transform lag on hardware, so Nav2 kept correcting for where the robot was, not where it is.
• Open–area obstacle detection. In open spaces most LiDAR rays return inf, which does not populate the costmap; enlarging obstacle_range, lengthening voxel / observation persistence, and disabling inf_is_valid (so inf rays stop clearing the costmap) helped.

Figure 16: Intended navigation pipeline. The GPS branch turns a clicked route into Nav2 /cmd_vel_nav; the camera branch turns images into a /road_observation; the Road_Nav_Fusion node combines them into the final /cmd_vel.

 

9 FUTURE WORK

The following directions were identified during development:

• Localization. The current IMU+GPS fusion is adequate but could be improved with ZED visual odometry or wheel odometry; a low–resolution global costmap could also help keep the robot on roads.
• Status reporting. A Socket.IO status topic publishing events such as “waypoint completed”, “human detected — stopping” and “path obstructed”.
• Deployment robustness. Test the fusion model over long sessions.

 

10 CONCLUSION

Starting from overhead imagery, this project built the main building blocks of an outdoor navigation stack for the SEAMK/Panther UGV. The key insight was that learned satellite segmentation alone (PCA features, SAM) did not reliably isolate roads, whereas combining OpenStreetMap with tuned extraction produced a clean, plannable road network. On top of that network, a GPS waypoint pipeline drives Nav2, and a camera road– segmentation module (best served by PPLiteSeg) provides a local heading correction, together with a human– detection safety stop. Each of these components was

validated on its own in simulation; fusing them into a single end-to-end system could not be completed within the project’s time frame and is the immediate next step.

 

REFERENCES

[1] OpenStreetMap contributors, “OpenStreetMap.” https://www.openstreetmap.org, 2017.

[2] S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, “Robot operating system 2: Design, architecture, and uses in the wild,” Science Robotics, vol. 7, no. 66, p. eabm6074, 2022.

[3] N. Koenig and A. Howard, “Design and use paradigms for Gazebo, an open-source multi-robot simulator,” in 2004 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), vol. 3, pp. 2149–2154, 2004.

[4] M. Oquab, T. Darcet, T. Moutakanni, H. Vo, M. Szafraniec, V. Khalidov, et al., “DINOv2: Learning robust visual features without supervision,” Transactions on Machine Learning Research (TMLR), 2024.

[5] A. Kirillov, E. Mintun, N. Ravi, H. Mao, C. Rolland, L. Gustafson, T. Xiao, S. Whitehead, A. C. Berg, W.-Y. Lo, P. Dollár, and R. Girshick, “Segment anything,” in Proceedings of the IEEE/CVF International Conference on Computer Vision (ICCV), pp. 4015–4026, 2023.

[6] P. E. Hart, N. J. Nilsson, and B. Raphael, “A formal basis for the heuristic determination of minimum

cost paths,” IEEE Transactions on Systems Science and Cybernetics, vol. 4, no. 2, pp. 100–107, 1968.

[7] G. Boeing, “OSMnx: New methods for acquiring, constructing, analyzing, and visualizing complex street networks,” Computers, Environment and Urban Systems, vol. 65, pp. 126–139, 2017.

[8] A. A. Hagberg, D. A. Schult, and P. J. Swart, “Exploring network structure, dynamics, and function using NetworkX,” in Proceedings of the 7th Python in Science Conference (SciPy2008), pp. 11–15, 2008.

[9] S. Macenski, F. Martín, R. White, and J. G. Clavero, “The marathon 2: A navigation system,” in 2020 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pp. 2718–2725, 2020.

[10] T. Moore and D. Stouch, “A generalized extended Kalman filter implementation for the Robot Operating System,” in Proceedings of the 13th International Conference on Intelligent Autonomous Systems (IAS-13), pp. 335–348, Springer, 2014.

[11] J. Canny, “A computational approach to edge detection,” IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. PAMI-8, no. 6, pp. 679– 698, 1986.

[12] X. Zhao, W. Ding, Y. An, Y. Du, T. Yu, M. Li, M. Tang, and J. Wang, “Fast segment anything,” arXiv preprint arXiv:2306.12156, 2023.

[13] J. Peng, Y. Liu, S. Tang, Y. Hao, L. Chu, G. Chen, Z. Wu, Z. Chen, Z. Yu, Y. Du, Q. Chen, Q. Dang, and Y. Ma, “PP-LiteSeg: A superior realtime semantic segmentation model,” arXiv preprint arXiv:2204.02681, 2022.

[14] M. Cordts, M. Omran, S. Ramos, T. Rehfeld, M. Enzweiler, R. Benenson, U. Franke, S. Roth, and B. Schiele, “The Cityscapes dataset for semantic urban scene understanding,” in Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (CVPR), pp. 3213–3223, 2016.

 

The Author:

Pejman Habibiroudkenar, M.Sc. (Tech.), Doctoral Student in Mechanical Engineering, Aalto University

UGV navigoi autonomisesti SEAMK:n ympäristössä

 

Riskianalyysi osana RovesUGV-hankkeen koeajojen valmistelua

Autonomisen mobiilirobotin siirtäminen kehitysympäristöstä teollisuusalueen liikenteeseen edellyttää teknisen toimivuuden lisäksi turvallisuuden järjestelmällistä tarkastelua. RovesUGV-hankkeessa riskianalyysin laatiminen liittyi Roveksen alueella suunniteltuun testaukseen ja yritysten välisen materiaalikuljetuksen käytännön demonstraatioon. Se oli osa Husarion Panther-mobiilirobotin koelupahakemuksen valmistelua.

Riskianalyysin tarkoituksena on tehdä näkyväksi, missä tilanteissa suunniteltu toiminta voi aiheuttaa vaaraa ja miten riskejä voidaan pienentää. Mobiilirobotin tapauksessa tarkastelu yhdistää laitteen, ohjelmiston, käyttäjän ja toimintaympäristön. Pelkkä onnistunut koeajo ei vielä osoita, miten järjestelmä käyttäytyy poikkeavassa tilanteessa. Siksi analyysin tekemisessä olennaista on tarkastella myös toiminnan rajoja, mahdollisia häiriöitä ja ihmisen mahdollisuuksia puuttua robotin toimintaan. Näin turvallisuutta voidaan arvioida suhteessa juuri siihen käyttöön, jota varten kokeilua valmistellaan.

 

 

Mobiilirobotiikka ja tieliikennelainsäädäntö

Autonomisen logistiikan kehittäminen edellyttää toimivan tekniikan lisäksi liikennettä koskevan lainsäädännön huomioimista. SEAMKin RovesUGV-hankkeessa tavoitteena on kehittää ja demonstroida yritysten välisiä autonomisia kuljetuksia Seinäjoen Roveksen teollisuusalueella. Hankesuunnitelmassa lupa-asioiden ja lainsäädännöllisten haasteiden selvittäminen on nostettu omaksi tehtäväkseen reittisuunnittelun ja teknisen kehittämisen rinnalle.

Suomen lainsäädäntö mahdollistaa liikenteen automaatiokokeilut. Liikenne- ja viestintävirasto Traficomin (2026b) mukaan automaattiautojen testaaminen liikenteessä edellyttää virastolta haettavaa koenumerotodistusta. Virasto auttaa myös kuljettajan määrittämiseen, tekniseen hyväksyntään ja rekisteröintiin liittyvissä kysymyksissä. Keskeinen lähtökohta on käyttöympäristö. Tieliikennelain tarkoittama tie käsittää maanteiden ja katujen lisäksi yksityiset tiet sekä muut yleiselle liikenteelle tarkoitetut tai yleisesti liikenteeseen käytetyt alueet (Tieliikennelaki 729/2018, 1–2 §). Siksi yrityksen piha-aluekaan ei automaattisesti jää lain soveltamisalan ulkopuolelle. Roveksessa reitin oikeudellista asemaa on arvioitava sekä katuosuuksilla että yritysten pihoilla. Pelkkä maanomistajan suostumus ei ratkaise ajoneuvon liikennekelpoisuutta.

Toinen olennainen kysymys on ajoneuvoluokitus. Suomessa pienille kuljetusroboteille on oma luokkansa, kevyt automaattinen tavarankuljetin. Näiden sähköisten, etähallittujen ajoneuvojen vaatimukset koskevat muun muassa mittoja, massoja, valoja, havaittavuutta ja jarruja (Liikenne- ja viestintävirasto Traficom, 2023). Hankkeen Husarion Panther-alustan noin 55 kilogramman massa ja 7,2 kilometrin tuntinopeus eivät yksin osoita luokkaan kuulumista. Myös varustelu, kuormaus ja muut tekniset ominaisuudet on huomioitava. Valmistajan ilmoittama kantavuus ei sellaisenaan tarkoita vastaavan kuorman sallittavuutta tieliikenteessä.

Liikenteessä automaation luotettava toiminta on ensiarvoista. Tieliikennelaki edellyttää huolellisuutta, muiden tienkäyttäjien toiminnan ennakointia ja olosuhteisiin sovitettua nopeutta. Ajoneuvo on pystyttävä hallitsemaan ja pysäyttämään ennakoitavissa tilanteissa (Tieliikennelaki 729/2018, 3–5 §). RovesUGV:n kehitystyössä näiden periaatteiden käytännön vastineita ovat esimerkiksi esteiden tunnistaminen, turvallinen pysähtyminen sekä paikannuksen ja tietoliikenneyhteyden häiriöihin varautuminen. Riskianalyysillä voidaan yhdistää liikenneympäristön vaarat konkreettisiin teknisiin ja toiminnallisiin hallintakeinoihin.

Myös kokeilutoiminnan ja jatkuvan kuljetuspalvelun (tai muun liiketoiminnan) ero on tärkeä. Koenumerotodistuksen käyttötarkoituksiin kuuluu ajoneuvon tai sen laitteiden tutkimus ja tuotekehitys, ja hakeminen edellyttää voimassa olevaa koenumerovakuutusta (Liikenne- ja viestintävirasto Traficom, 2026a). Onnistuneesta demonstraatiosta ei siksi voi suoraan päätellä, että sama järjestelmä olisi hyväksytty jatkuvaan kaupalliseen liikenteeseen.

RovesUGV-hankkeen kannalta lainsäädäntö vaikuttaa suoraan reittivalintoihin, robotin varusteluun sekä kokeiden toteutukseen. Teknisen kehittämisen rinnalla tarvitaan dokumentoitua tietoa siitä, missä olosuhteissa järjestelmä toimii turvallisesti, miten toimintaa valvotaan ja miten poikkeamiin reagoidaan. Näin kokeiluista syntyy teknisten tulosten lisäksi tietopohjaa autonomisten kuljetusten myöhempää käyttöönottoa varten.

 

Lähteet

Liikenne- ja viestintävirasto Traficom. (2023, 8. joulukuuta). Pienet kuljetusrobotit saivat tarkemmat tekniset vaatimukset. https://www.traficom.fi/fi/uutiset/pienet-kuljetusrobotit-saivat-tarkemmat-tekniset-vaatimukset

Liikenne- ja viestintävirasto Traficom. (2026a, 9. syyskuuta). Hae ajoneuvolle koenumerotodistusta. https://www.traficom.fi/fi/autoilijat/hae-ajoneuvolle-koenumerotodistusta

Liikenne- ja viestintävirasto Traficom. (2026b, 12. huhtikuuta). Tieliikenteen automaatiokokeilut. https://www.traficom.fi/fi/liikennejarjestelma/verkottunut-ja-automatisoitunut-liikenne/tieliikenteen-automaatiokokeilut

Tieliikennelaki 729/2018. (2018). Finlex. https://www.finlex.fi/fi/lainsaadanto/2018/729