RAPORT DE ETAPĂ 2016 Etapa V. Testare si validare

Proiect: Sistem Cooperativ de Asistare a Conducerii Bazat pe Dispozitive Mobile Inteligente şi Unități de Monitorizare a

Drumului (SmartCoDrive) Contract PCCA tip 2, nr 18/2012

Coordonator: Universitatea Tehnica din Cluj-Napoca Partener: Arobs Transilvania Software SRL

Rezumat 1

Integrarea Componentelor 1

Aplicatii de asistare avansata a conducerii 5 2.1. Augmentare Harta Dinamica Locala 5 2.2. Pozitionarea vehiculului relativ la intersectii 8 2.3. Aplicatiile de Asistare a Conducerii 10

2.3.1 Avertizare la parasirea benzii curente (nedorita / nesemnalizata) 10 2.3.2 Avertizari cu privire la conditiile de trafic in intersectie 10 2.3.3 Avertizari la coliziune iminenta din cauza unei frane bruste 11 2.3.4 Avertizari la coliziune cu vehiculul care circula in fata egovehiculului 11 2.3.5 Avertizare la coliziune in intersectie 12 2.3.6 Identificarea implicatiilor semnelor de circulatie 12

3. Plan de evaluare 13

4. Evaluarea si testarea aplicatiilor de asistare a conducerii 13

5. Beneficiile sistemului 18

6. Bibliografie 19

7. Diseminare 20 Rezumat In acest raport sunt prezentate activitatile desfasurate in anul 2016 care constau in:

1. Finalizarea componentelor sistemului 2. Finalizarea modelelor de comunicare intre aceste componente 3. Dezvoltarea de noi aplicatii de asistare a conducerii: 4. Testarea si evaluarea aplicatiilor de asistare a conducerii 5. Diseminare

Toate activitatile prevazute in planul de realizare au fost indeplinite.

1. Integrarea Componentelor Sistemul cooperativ dezvoltat in cadrul acestui proiect este alcatuit din vehicule inteligente, elemente de

infrastructura locala si elemente de infrastructura regionala (figura 1.1). Toate aceste elemente trebuie sa comunice intre ele. Vehiculele (Smart Mobile Platforms - SMP) si unitatile locale de infrastructura (Road Side Unit - RSU), care se afla intr-o locatie fixa, formeaza o retea adhoc si comunica prin intermediul tehnologiei V2X (comunicare intre vehicule - V2V

1

si comunicare intre vehicule si RSU - V2I). Aceasta tehnologie de comunicare se bazeaza pe noul standard wireless 802.11p, care a fost adoptat pentru implementarea conexiunilor wireless in retele vehiculare adhoc. Pentru acest lucru atat vehiculele participante in cadrul retelei adhoc cat si elementele locale de infrastructura sunt dotate cu dispozitve speciale de comunicare care implementeaza standardul 802.11p - in acest proiect dispozitivele folosite sunt platformele NEC Linkbird-MX. Elementele locale de infrastructura (RSU) comunica prin internet cu serverele regionale de trafic (Regional traffic information system - RTIS) prin protocolul HTTP. Infromatiile transmise intre RSU si RTIS sunt incapsulate intr-un raport de trafic, descris in format XML. Raportul de trafic poate fi local, daca este transmis de la RSU la RTIS, sau global daca este transmis de la RTIS la RSU.

Figura 1.1: Arhitectura globala a sistemului cooperativ de asistare a conducerii

Arhitecturile dezvoltate in cadrul vehiculelor si unitatilor locale de infrastructura sunt prezentate in figura 1.2.

Detaliile de implementare au fost prezentate in raportul precedent. O diferenta notabila fata de arhitectura prezentata anterior este folosirea tabletei Microsoft Surface Pro 4 in cadrul SMP. Aplicatiile de asistare a conducerii vor rula pe aceasta tableta.

In cadrul SMP si RSU se utilizeaza un modul de interconectare / tableta (SMP) si calculator industrial (RSU) pentru a putea conecta si integra toti senzorii folositi la nivelul unui vehicul sau la nivelul RSU. Din acest motiv arhitecturile descrise pentru cele doua componente sunt similare (in functie de configuratie se determina automat numarul de senzori folositi si modalitatile de interconectare cu acesti senzori).

O alta modificare a fost adusa formatului de comunicare prin Bluetooth intre modulul de interconectare din cadrul SMP si aceasta tableta. Din cauza faptului ca aplicatiile de asistarea a conducerii au nevoie de informatii precise atat de la nodul curent din reteaua adhoc, cat si de la alte noduri din retea, au fost dezvoltate 2 tipuri de mesaje prin Bluetooth, cu lungimi diferite. Viteza de comunicare prin Bluetooth este 115200 biti pe secunda, ceea ce inseamna ca un byte de date se transfera in aproximativ 86.8 μs. Primul byte din fiecare mesaj Bluetooth contine numarul de bytes al mesajului. Un mesaj de Bluetooth care furnizeaza date despre nodul local (ego vehicul) contine 80 de bytes - durata de trimitere mesaj ~ 7ms, iar un mesaj de Bluetooth care furnizeaza informatii despre un nod din retea contine 61 de bytes - durata de transmitere ~ 5.3 ms. Acest format este mai condensat decat formatul precedent, permitand rate de transfer superioare.

2

Figura 1.2: Arhitectura Software pentru SMP si RSU

Bluetooth Msg Size Data Byte 1 Data Byte 2 Data Byte 3 ….. Data Byte N Tabelul 1.1: Formatul datelor transmise prin Bluetooth

Mesaj despre Ego Vehicul Mesaj despre alt nod Informatie Nr. Bytes Informatie Nr. Bytes Adresa Nod in retea 8 Adresa Nod in retea 8 GPS: Latitudine 8 GPS: Latitudine 8 GPS: Longitudine 8 GPS: Longitudine 8 GPS: Inaltime 8 GPS: Inaltime 8 GPS: Viteza Orizontala 8 GPS: Viteza Orizontala 8 GPS: Viteza Verticala 8 GPS: Viteza Verticala 8 GPS: Directie 8 GPS: Directie 8 CAN: Viteza 8 Tipul Nodului 1 CAN: Rata de giratie 8 Clasa Mesaj 1 CAN: Semnalizare Stanga 1 Subclasa Mesaj 1 CAN: Semnalizare Dreapta 1 Caz de utilizare 1 CAN: Pozitia Pedalei de Frana 1 Tipul Nodului 1 Clasa Mesaj 1 Subclasa Mesaj 1 Caz de utilizare 1 Tabelul 1.2: Informatiile cuprinse in mesajele Bluetooth initiate de modulul de interconectare

Daca mesajul trimis prin Bluetooth are campurile: Clasa mesaj, Subcasa Mesaja si Caz de utilizare egale cu 0, inseamna ca mesajul este unul de prezenta; in caz contrar mesajul este unul de avertizare. Un mesaj de avertizare initiat de modulul de rationare de pe tableta contine aceleasi campuri: dimensiune mesaj, clasa mesaj, subclasa mesaj, caz de utilizare, dar mai poate contine si alte informatii aditionale despre mesajul de avertizare care va fi diseminat in reteaua adhoc.

Structura mesajelor de comunicatie V2X a ramas neschimbata (raport 2014). Se poate observa faptul ca informatiile importante care vor identifica un caz de utilizare / aplicatie de asistenta a conducerii (clasa mesaj, subclasa mesaj, caz de utilizare) sunt generate de catre modulul de rationare si vor fi diseminate in reteaua adhoc prin intermediul echipamentelor de comunicatie V2X.

3

Figura 1.3: Arhitectura RTIS

4

Serverul regional de trafic (Regional traffic information system - RTIS) este responsabil de colectarea datelor relevante de la unitatile locale de infrastructura (RSU). O data la 30 de minute fiecare RSU trimite un raport de trafic local catre RTIS (in format XML). Serverul regional poate furniza informatii de trafic pe o arie mai extinsa fata de unitatile locale de infrastructura. In acest fel participanții la trafic pot fi avertizați din timp dacă pe ruta pe care intenționează să se deplaseze sunt condiții meteorologice nefavorabile, ceata densa, gheața sau polei; daca există un accident pe drum, dacă traficul este congestionat, etc. Cunoscând aceste informații participanții la trafic pot evita cu mult înainte rutele cu probleme. Sistemul RTIS utilizeaza un server cu acces la internet si este alcatuit din urmatoarele nivele conceptuale: recepția datelor, procesarea și stocarea datelor precum și prezentarea informațiilor obținute din trafic (nivel de vizualizare). Arhitectura acestui sistem este prezentata in Figura 1.3. Comunicarea intre un RSU si RTIS se realizeaza prin protocolul HTTP. La cerere serverul RTIS trimite catre un RSU un raport de trafic global. Cererea trebuie sa cuprinda o specificatie in coordonate GPS a ariei pentru care RTIS trebuie sa calculeze raportul global de trafic.

2. Aplicatii de asistare avansata a conducerii

2.1. Augmentare Harta Dinamica Locala

Aplicatiile de asistare avansata a conducerii au nevoie de o cunoastere cat mai buna a contextului in care se afla participantii la trafic. O componenta importanta in perceptia corecta a contextului este corelarea datelor primite de la senzori cu informatiile din harta dinamica locala (bazata pe Open Street Map - OSM). Rationarea geospatiala trebuie sa fie rapida, cu acuratete mare, si sa permita interpretarea unor date in perceptii de nivel inalt, precum numarul benzii pe care se afla un vehicul sau pozitia vehiculului in cadrul unei benzi , la intrare in intersectie, semn de limitare de viteza activ, etc. In figura 2.1 se poate observa o structurare pe niveluri a tranzitiei datelor catre cunostinte; la nivelul datelor consideram harta OSM, date de la senzori (CAN, GPS, Comunicare), dar si un model probabilistic pentru modelarea structurii drumului in termeni de benzi prin date istorice. Pentru o crestere a vitezei si o mai buna pozitionare in intersectii, drumurile sunt interpretate ca secvente de segmente cu orientari fata de Nord (azimut) si secvente de intersectii, calculate offline si stocate in baza de date PostgreSQL. La nivelul de cunostinte, se pot folosi si sisteme dedicate precum sisteme expert sau sisteme bazate pe logica fuzzy.

Figura 2.1: Structura pe niveluri a modului de rationare in prezenta hartii

Interpretare alternativa a drumurilor - secventa de valori azimut si de puncte de intersectie

Un drum descris in OSM prin puncte este considerat in cadrul aplicatiei ca o secventa de puncte descrise n P i de i) pozitia lor in cadrul drumului, reprezentand fractia din lungimea totala a drumului, si ii) de orientarea l(P ) 0, ]l i ∈ [ 1 segmentelor fata de directia nord (azimut). Un drum drept descris in OSM doar prin doua noduri, este descris ,< P i P i+1 > de un singur astfel de punct. Drumul prezentat in figura 2.2 prezinta 45 astfel de puncte, azimutul variind intre si 2.875 0

Reprezentarea drumului prin puncte cu azimut si stocarea acestora in baza de date eficientizeaza determinarea03.99 .1 0 pozitionarii vehicului in special pentru drumuri neliniare si in apropierea intersectiilor. Azimutul fata de nord este stocat pentru toate segmentele pentru deplasarea de la 0 la 1, conform secventei de puncte din OSM. Pentru deplasarea in sens opus, azimutul se recalculeaza online astfel: daca atunci devine altfel .zimut 80a < 1 0 zimut 80 ,a + 1 0 zimut 180 a − 0

Sistemul foloseste de asemena puncte de intersectie. Un punct de intersectie este un nod cu cel putin doua segmente, dintre care unul singur este de tip in, putand fi unul sau mai multe segmente out. In modelul propus, drumul pentru care se defineste punctul de intersectie se numeste drum referinta , in timp ce drumurile care-l intersecteaza se numesc drumuri secundare . Segmentul in apartine drumului referinta, in timp ce cele de tip out apartin drumurilor secundare sau celui referinta - in cazul in care drumul referinta se continua dupa acea intersectie. Segmentele sunt definite de punctele descrise anterior, adica de pozitia si , iar punctele de intersectie sunt definite l(P )l i zimut(P , P )a i i+1 de:

● - valoarea pentru punctul in cadrul drumului referintall ref ll P i

5

● - azimutul segmentului in, adica segmentul situat pe drumul referinta inaintea punctului aref P i ● - valoarea pentru punctul in cadrul drumurilor secundarell sec ll P i ● - azimutul segmentelor out, adica segmentele situate pe drumurile secundare imediat dupa punctul .asec P i

Acestea sunt obtinute din descrierea drumurilor cu puncte cu azimut, si in functie de valoarea componentei from0to1 se inverseaza sau nu.

● - sensul de parcurgere pe drumul secundar in cazul in care un vehicul intra pe acest drum secundar dinrom0to1f intersectia analizata. Acest sens nu are legatura cu sensul legal permis pe acel drum.

Figura 2.2: Date intermediare, respectiv finale pentru puncte de intersectie ce descriu Bvd 1 Decembrie

Structura benzilor reprezentata ca GMM si invatarea parametrilor GMM (Gaussian Mixture Model)

Acuratetea hartilor OSM poate fi imbunatatita folosind informatii de pozitionare a masinilor in timpul deplasarilor [3, 7]. S-au colectat astfel de informatii identificate de receptorul GPS de inalta precizie si s-au folosit in antrenarea unor modele probabilistice pentru predictia cu acuratete mai buna a benzii si a pozitiei in cadrul benzii.

Pe fiecare segment din geometria unui drum definit de noduri OSM s-a construit in baza de date PostgreSQL cate un segment perpendicular la fiecare 0.5 m. Fiecare segment perpendicular este identificat de o valoare din intervalul [0,1] reprezentand fractia din lungimea totala a drumului. Punctele obtinute la intersectia dintre perpendiculare si geometriile trace-urilor se vor aglomera catre centrele benzilor. Presupunem ca punctele sunt distribuite in cadrul unei benzi, pentru fiecare prependiculara in parte, conform unei distributii Gauss-iene datorita fie zgomotului pozitionarii GPS, a pozitionarii dispozitivului GPS pe vehicul, a pozitionarii vehiculului pe banda si in cele din urma datorita schimbarii benzii. Punctele de intersectie a parcurgerii cu perpendicularele sunt caracterizate de distanta pana la geometria drumului.

Figura 2.3: Parcurgeri anterioare definite prin punctele de intersectie cu perpendicularele pe geometria drumului OsM

Pentru drumul din figura 2.2, s-au generat 2746 de perpendiculare. Pentru fiecare dintre aceste perpendiculare

se pastreaza in baza de date distanta la geometria drumului a punctului de intersectie a perpendicularei cu toate parcurgerile implicate. In graficul din figura 2.3 sunt reprezentate distantele punctelor de intersectie cu perpendicularele pentru 7 parcurgeri ale bulevardului 1 Decembrie din Cluj-Napoca, de pe ambele sensuri. Se pot observa zone in care sunt folosite toate cele 4 benzi, precum si zone in care sunt folosite doar benzile apropiate de mijlocul drumului. Punctele tind sa se aglomereze catre mijlocul benzii. Reprezentarea structurii benzilor prin GMM si invatarea parametrilor acestora permit: (i) identificarea pentru fiecare perpendiculara a distantei fata de geometria drumului la care e cel mai probabil sa se afle mijlocul benzii, reprezentata de media distributiei gaussiene, (ii) identificarea numarului de benzi prin identificarea numarului de componente GMM prin Bayesian Information Criterion (BIC).

6

Un model GMM cu k componente are urmatoarea functie de densitate de probabilitate:

, unde(x) j exp(− )p = ∑k

j=1w 1

√2πσj2 2σj

2(x−μ )j 2

- k numarul de componente gaussiane, in acest caz numarul de benzi - - ponderile fiecarei componente, corespunzand volumului de trafic relativ in fiecare banda. Ponderile, w1 ...,wk

trebuie sa fie pozitive si normalizate. - - mediile parcurgerilor pentru fiecare componenta, adica mijlocul benzii pt perpendiculara curenta, ..,μ1 . μk - - varianta pentru fiecare componenta, reprezentand imprastierea punctelor de intersectie a parcurgerilor, .., σσ2

1 . 2k

cu perpendicularele.

Invatarea parametrilor GMM [3] s-a realizat prin algoritmul Expectation Maximization. EM este un proces iterativ care alterneaza doi pasi:

● E-step - calculeaza valoarea asteptata a logaritmului functei de likelihood pentru valorile curente ale parametrilor ● M-step - identificarea parametrilor care maximizeaza log likelihood.

In pasul de E-step se calculeaza probabilitatea fiecarui punct de a fi generat de fiecare componenta din model, in timp ce in pasul al doilea se modifica parametrii modelului in directia maximizarii valorii likelihood. Pentru identificarea numarului de benzi s-a folosit criteriul BIC - Bayesian information criterion. S-a comparat valoarea acestui criteriu pentru GMM cu k=1, respectiv k=2 si s-a ales valoarea k pentru care BIC are valoarea mai mica. Cu modelul GMM antrenat pentru fiecare perpendiculara, determinarea benzii curente pentru o pozitie descrisa de (lat, long) presupune urmatorii pasi:

1. Identificarea celui mai apropiat segment perpendicular pe strada curenta de punctul (lat, long) - closest_ortho 2. Calcularea distantei de la proiectia punctului (lat, long) pe perpendiculara closest_ortho la geometria strazii 3. Identificarea benzii prin predictia clusterului dat de modelul GMM pentru perpendiculara identificata 4. Identificarea pozitiei in cadrul benzii in functie de logaritmul functiei de likelihood pentru valoarea distantei

Validarea modelului s-a realizat prin doua metode. Pentru a valida corectitudinea valorilor care identifica mijlocul

benzii, s-au comparat informatiile de pozitionare pe banda obtinute prin predictii ale modelului GMM antrenat cu informatiile de pozitionare laterala obtinute de la senzorul de stereo-viziune. S-a folosit un sample de parcurgere a intregii strazi 1 Decembrie format din 74 de masuratori succesive ale pozitiei (lat,long), o masuratoare la o secunda; pentru fiecare pozitie s-au considerat in medie 10 frame-uri pentru care s-a calculat deplasarea laterala din stereo-viziune (lateral displacement). Pentru fiecare masuratoare s-a calculat distanta ortogonala , fata de geometria (P , geom)d ortho drumului. Aceasta valoare ajustata cu deplasarea laterala identificata din imagini este comparata cu media modelului GMM pentru fiecare sample, adica cu valoarea la care se considera ca este mijlocul benzii. Media artimetica a diferentelor intre cele doua valori este 0.175m pentru drumul considerat. Consideram aceasta valoare ca o valoare mica, tinand cont de geometria drumului ales (azimutul segmentelor componente variaza puternic), dar si de faptul ca distanta laterala raportata de modulul de stereo-vizune este o medie a valorilor distantelor laterale pentru toate cadrele asociate unei pozitii (lat, long).

rr(μ, mijloculBenzii(distance, lateralDisplacement) μ ( d(P, geom) ateraralDisplacement )| E = ∑

| − − l

rr (μ) L(mijloculBenzii(distance, lateralDisplacement)) E likelihood = ∑

L −

Pentru parcurgerea aleasa pentru validare, se identifica perpendicularele cele mai apropiate de punctele din parcurgere, distantele ortogonale implicate pot fi observate in figura 2.4 La antrenarea modelelor GMM pentru cele 74 de perpendiculare, pentru , respectiv , conform criteriul BIC se identifica prezenta a doua l 0.679, ]l ∈ [ 1 l 0.48, .59)l ∈ [ 0 componente, adica a doua benzi in parcurgerile folosite. Pentru se identifica prezenta unui singur l 0.59, 0.679)l ∈ [ cluster. Folosirea unui criteriu de alegere a numarului de componente (adica a numarului de benzi) permite aplicarea identificarii benzii curente si a pozitiei in cadrul acesteia si pentru drumuri cu mai multe benzi dar pentru care in parcurgerile anterioare folosite nu sunt puncte pentru toate benzile, precum in exemplul descris.

7

Figura 2.4: Distantele ortogonale pe sensul 1-0 pentru setul de validare

A doua metoda de evaluare a modelului GMM consta in evaluarea corectitudinii identificarii pozitionarii pe una

dintre benzi pentru un drum cu doua benzi pe sens. In aceasta evaluare nu sunt folosite informatii de la camera. Pentru scenariul de 74 de puncte descris anterior, banda a fost tot timpul aceeasi, modelul GMM identificand corect acest lucru pentru toate punctele. S-a considerat de asemenea un sample cu doua schimbari de banda, pentru care s-a adnotat manual banda. Din cele 90 de puncte, banda a fost identificata corect pentru 87 de puncte. Descresterea valorii log likelihood pentru apartenenta punctelor la clusteri (benzi) indica manevra de schimbare de banda (figura 2.5).

Figura 2.5 Identificarea benzii folosind GMM

2.2. Pozitionarea vehiculului relativ la intersectii

Orizontul unui vehicul este constituit din urmatorul punct de intersectie, respectiv drumurile care sunt incluse in descrierea punctului de intersectie. Pozitionarea unui vehicul relativ la intersectie influenteaza identificarea drumului curent. Vehiculul poate fi intr-una din 5 stari: departe de prima intersectie , la intrarea sau in interiorul unei intersectii , in interiorul intersectiei cu schimbare de drum , la iesirea din intersectie cu schimbarea de drum , la iesirea din intersectie cu pastrarea drumului. Modelul cu 5 stari este prezentat in Figura 2.6 [13].

8

Figura 2.6: Modelul cu 5 stari pentru pozitionarea vehiculului fata de intersectie

Atat timp cat vehiculul se afla departe de urmatoarea intersectie nu se pune problema schimbarii drumului

curent. O data ce se apropie de intersectie, se poate pastra drumul curent sau schimba cu unul din drumurile incluse in punctul de intersectie. Metodele clasice arc-to-arc de map-matching pentru identificarea drumului curent sunt sensibile la intersectii, insa modelul propus permite identificarea corecta a drumului curent. Mai mult, inca din interiorul intersectiei, se poate identifica drumul catre care se indreapta vehiculul, numit in continuare drum candidat. Tranzitiile dintre stari sunt controlate de valori ale distantei fata de intersectie si variatii ale diferentelor intre azimutul segmentului in si azimutul segmentelor out .

Figura 2.7: Starile relative la intersectie ale vehiculului In figura 2.7 este reprezentata starea identificata de aplicatie prin culori, impreuna cu distanta pana la intersectie

calculata din descrierea punctului de intersectie, diferenta intre headingul masinii si azimutul segmentului curent , Δaref respectiv minimul diferentelor dintre headingul masinii si azimutul segmentelor out . In alegerea acestui minim sunt Δaout considerate segmentele out pentru care ; in acest fel sunt eliminate segmentele out | a eading vehicul||aref −asec > | sec−h care sunt apropiate ca si orientare de orientarea masinii, deci implicit diferenta dintre cele doua orientari este mica, insa catre care nu se indreapta vehiculul. Pentru situatii urbane s-a considerat distanta in m de la care o intersectie 5mδ = 1 situata in directia vehicului devine relevanta. La prima masuratoare, vehiculul este identifcat ca fiind in starea departe de intersectie. La a doua masuratoare, distanta este 14.69m , ceea ce face ca vehicululsa treaca in starea la intrarea sau in interiorul unei intersectii (marcata cu albastru). Diferenta este 1.060, iar este 49.41. Atat timp cat < Δaref Δaout Δaref Δaout starea nu se modifica, ceea ce inseamna ca drumul curent nu se modifica nici el. La masuratoare 5 insa > , insa Δaref Δaout

>10, ceea ce determina ca starea sa fie considerata in intersectie cu schimbare de drum (marcata cu rosu). DrumulΔaout referinta ramane acelasi, insa se identifica drumul candidat. La urmatoarea masuratoare, respecta conditia care Δaout permite trecerea in starea la iesire din intersectie cu schimbare de drum. Drumul candidat devine drumul curent. In toate aceste etape se folosesc datele stocate pentru punctele de intersectie, ceea ce permite un timp de procesare redus comparat cu situatia calcularii azimutului in timpul deplasarii.

2.3. Aplicatiile de Asistare a Conducerii In cadrul acestui proiect a fost dezvoltat un set de aplicatii de asistare a conducerii; atat aplicatii cooperative cat

si aplicatii care ruleaza doar pentru vehiculul propriu. In cadrul aplicatiilor cooperative se trimit mesaje de avertizare in

9

cadrul retelei adhoc, catre alti participanti care ar putea fi afectati de schimbarile din mediul de trafic. Aceste aplicatii sunt descrise in paragrafele urmatoare.

2.3.1 Avertizare la parasirea benzii curente (nedorita / nesemnalizata) Folosind componentele de identificare a pozitionarii in cadrul benzii prin modelul GMM, respectiv prin prelucrarea

imaginii de la camera, se pot identifica situatiile de risc determinat de parasirea benzii curente in absenta intentiei manifestata prin actionarea semnalizarii. Soferul este atentionat in aceasta situatie printr-un semnal sonor, in timp ce celorlalti participanti la trafic aflati in vecinatatea vehiculului le este trimis mesaj de avertizare. Harta locala a fiecarui vehicul pastreaza informatii legate de masina din fata / spate pe aceeasi banda, respectiv masinile de pe banda alaturata. Date folosite De la senzori: CAN - yaw rate, viteza, semnalizare stanga-dreapta, GPS: pozitie

Din LDM: model GMM , drumuri OSM , pozitionarea vehiculelor din proximitate

Trigger In cursul a n=3 ( pt conditii de trafic urban) masuratori succesive: ● semnalizatorul nu este folosit ● descresterea ΔLogLikelihood(d(P, geom) > tlaneChange ● cresterea distantei fata de mijlocul benzii calculata din informatii stereo d> l laneChange

Actiunea Ego vehicul: avertizare vizuala / sonora Alte vehicule: Mesaje de avertizare V2V

○ Clasa - 1, subclasa - 1, use case - 13 (lane change) ○ Restrictii destinatar: masina din spatele ego-vehiculului pe aceeasi banda si

masinile de pe banda catre care se face schimbarea

2.3.2 Avertizari cu privire la conditiile de trafic in intersectie Level of Service este o masura calitativa a traficului in termeni de viteza si densitate. Pentru intersectii este

definit in termeni de intarziere a vehiculelor, iar pentru segmente de drum in termeni de densitate, rata fluxului si ocupare. Exista 6 niveluri [12]:

● (1) free flow ● (2) Steady Traffic ● (3) Steady Traffic but Limited. ● (4) Steady Traffic at High Density. ● (5) Traffic at Saturation ● (6) Congestion

Densitatea pe un segment de drum = numarul de vehicule pe unitate de lungime Rata fluxului = numarul de vehicule pe unitatea de timp Media intarzierii = timp total de intarziere in intersectie / numarul de masini intarziate RSU monitorizeaza continuu valoarea LOS si trimite mesaje de avertizare masinilor care se indreapta catre intersectie. Pentru aceasta se foloseste modelul celor 5 stari de descriere a pozitionarii masinii fata de intersectie. In cazul in care RSU identifica LOS de tip congestie, se vor trimite mesaje de avertizare.

Date folosite De la senzori : GPS: pozitie si viteza - transmise catre RSU de catre vehicule prim mesajele

de prezenta Din LDM: puncte de intersectie , pozitionarea vehiculelor relativa la intersectie

Trigger LOS > 3

Actiunea Mesaje de avertizare V2V ○ Clasa - 2, subclasa - 4, use case - 36 (A),37 (B), 37 (C), 38 (D), 39 (E), 40 (F) ○ Restrictii destinatar: masinile aflate in starea inainte de intersectie pentru

intersectia cu LOS > 3 Mesaj de informare de la RSU la RTIS - daca LOS = 6

2.3.3 Avertizari la coliziune iminenta din cauza unei frane bruste In cazul unei frane bruste a ego vehiculului, reducerea riscului de coliziune se poate realiza prin avertizarea

masinilor din spate de existenta acestui eveniment. Pentru aceasta sunt necesare informatii de variatie a vitezei pentru

10

ego-vehicul, precum si pozitionarea celorlalte masini fata de de ego-vehicul. Modelul GMM impreuna cu modelul punctelor de intersectie sunt folosite pentru a interpreta informatiile de pozitie primite de la alte masini.

Date folosite De la senzori : CAN - yaw rate, viteza, GPS: pozitie Din LDM: model GMM , drumuri OSM , pozitionarea vehiculelor din proximitate

Trigger Δv/Δt > tf ranareBrusca

Actiunea Alte vehicule: Mesaje de avertizare V2V ○ Clasa - 1, subclasa - 1, use case - 5 (emergency electronic brake lights) ○ Restrictii destinatar: masinile din spatele ego-vehiculului pe aceeasi banda aflate

la o distanta mai mica decat tdistantaInSpate

2.3.4 Avertizari la coliziune cu vehiculul care circula in fata egovehiculului Aceasta aplicatie de asistare a conducerii foloseste imaginile provenite de la camerele externe pentru a detecta

din imagini vehiculul din fata propriului vehicul de pe banda curenta [5]. Mai mult, se detecteaza viteza vehicului din fata. Asadar cunoscand si viteza propriei masini aplicatia calculeaza probabilitatea de coliziune cu vehiculul din fata. O probabilitate mai mare de coliziune va determina afisarea unui mesaj de avertizare. Soferul este avertizat din timp astfel incat sa poata actiona pentru a evita un accident. Aplicatia de asistare a conducerii la coliziune cu vehiculul din fata a fost dezvoltata in C++ folosind libraria OpenCV 3.1 si ruleaza pe tableta Microsoft Surface Pro 4. Tableta are un procesor Intel Core i5-6300U cu frecventa 3.0 GHz. In ceea ce priveste timpul de executie, aplicatia ruleaza in timp real iar toti pasii algoritimului de la reconstructia 3D la detectia si urmarirea benzii curente si a obstacolului dureaza aproximativ 45 ms pentru un cadru. Aplicatia ruleaza cu 20-22 cadre/secunda procesand imagini cu dimensiunea 512 x 288 pixeli. In Figura 2.8 se poate vedea sistemul pe care ruleaza aplicatia. Camerele sunt conectate la tableta Microsoft Surface Pro 4 prin intermediul unui adaptor USB 3.0 → 2 x Gigabit Ethernet.

Figura 2.8: Conectarea sistemului de stereoviziune la Tableta Microsoft Surface Pro 4

In primele etape ale acestui proiect, am dezvoltat o aplicatie Android pentru tableta LG Optimus V900 Pad care

are incorporate doua camere. Aplicatia are aceleasi functii de asistare a conducerii. Tabletele cu doua camere sunt greu de gasit, iar cea mai puternica tableta ce poate fi cumparata este LG Optimus V900 Pad avand un procesor Cortex A9, 1.0 GHz aparuta in anul 2011. Aceasta configuratie nu este destul de buna pentru dezvoltarea unor algoritmi de procesare de imagini, astfel ca aplicatia ruleaza cu doar 4 cadre/secunda, ceea ce nu poate fi considerat timp real de executie. Mai mult, aceasta tableta achizitioneaza imagini la o rezolutie foarte mica: 384 x 216, rezultand o calitatea mai slaba a reconstructiei 3D. Dat fiind faptul ca tabletele cu doua camere au configuratii hardware vechi, cu capabilitate de procesare mica comparativ cu tabletele cu o camera, se decalibreaza din cauza vibratiilor provocate de autovehicul, si au o distanta de detectie a obstacolelor foarte mica (sub 15 m) am optat pentru o tableta mai puternica Microsoft Surface Pro 4 si am conectat doua camere externe (JAI BM141 GE). Aplicatia de asistare a conducerii la coliziune cu vehiculul din fata foloseste urmatorii algoritmi de viziune artificiala:

● Reconstructia 3D: ○ datele de intrare sunt cele doua imagini achizitionate simultan de catre cele doua camere externe ○ Pas 1: calibrarea celor doua camere: gasirea parametrilor intrinseci si extrinseci ale celor doua camere ○ Pas 2: rectificarea celor doua imagini folosind parametri de calibrare. Rezulta doua imagini coplanare in

planul imaginii. ○ Pas 3: Gasirea pixelilor corespondenti in imaginea stanga si dreapta ○ Pas 4: Pentru fiecare pixel se calculeaza coordonata 3D in lumea reala a fiecarui pixel din imagine ○ Nota: pentru a reduce costul computational al acestui algoritm, reconstructia 3D a fost aplicata doar pe

imaginea de muchii ● Detectia benzii curente

11

○ Se realizeaza prin gasirea marcajelor benzii curente in imagine ○ Dupa gasirea marcajelor de pe partea stanga si dreapta se foloseste algoritmul de urmarire bazat pe

filtru Kalman pentru a gasi structura 3D a benzii curente: latime, orientare, inclinatie, curbura ● Detectia vehiculului din fata vehiculului propriu

○ Se foloseste o metoda care combina trasaturi din imagine cu puncte 3D ○ Se realizeaza impartirea imagnii in superpixeli (grupari de pixeli cu aproximativ aceeasi culoare) si se

asigneaza fiecarui superpixel o locatie 3D. Superpixelii cu caracteristici similare din punct de vedere a pozitiei 3D si a culorii sunt uniti. Un vehicul din imagine va fi determinat de un superpixel unit. Se alege superpixelul de pe banda curenta avand anumite dimensiuni ca fiind valid.

○ Vehiculul este urmarit folosind filtrul Kalman. In urma acestui algoritm se estimeaza viteza vehiculului. ● Detectia probabilitatii de coliziune

○ Se realizeaza printr-un algoritm cu logica fuzzy care foloseste doua variabile: timpul pana la coliziune si decalajul de timp, calculate pe baza vitezelor celor doua vehicule

Aplicatia de avertizare la coliziune a fost evaluata atat in scenarii de trafic real cat si in simulator.

Date folosite De la senzori : CAN - viteza,unghi-volan, CAMERE - imagini stanga, dreapta

Trigger Probabilitate coliziune > 0.8

Actiunea Informare vizuala ego-vehicul despre posibilitatea unei coliziuni cu vehiculul din fata Alte vehicule: Mesaje de avertizare V2V

○ Clasa - 1, subclasa - 1, use case - 11 (cooperative forward collision warning) ○ Restrictii destinatar: masinile din spatele ego-vehiculului pe aceeasi banda aflate la o

distanta mai mica decat tdistantaInSpate

2.3.5 Avertizare la coliziune in intersectie La nivelul RSU, pe baza pozitionarii masinilor pe benzi si a starilor relative la intersectie, se pot identifica situatii

evidente de risc, in care cel putin doua masini se indreapta catre intersectie cu viteze necorespunzatoare de pe drumuri diferite. Se calculeaza timpul mediu de coliziune intre cele doua, iar in cazul in care acest timp este mai mic decat

RSU trimite mesaj de avertizare catre ambele vehicule. De asemenea, limitari ale comunicarii intretriscColiziuneIntersectie vehicule sunt rezolvate prin forwardarea mesajelor de pozitie de catre RSU in cazul unor vehicule cunoscute aflate la distanta mare.

S-a folosit si o metoda de invatare de predictie a intentiei de oprire in intersectie pe baza seriilor de timp determinate de vitezele vehiculelor care se apropie de intersectie [8], [9]. Pentru generarea seriilor de timp s-a folosit simulatorul SUMO.

Date folosite De la senzori : GPS: pozitie si viteza - transmise catre RSU de catre vehicule prin mesajele de prezenta Din LDM: puncte de intersectie , pozitionarea vehiculelor relativa la intersectie

Trigger d(V1,intersectie)/v1+d(V2,intersectie)/v2 < triscColiziuneIntersectie

Actiunea Mesaje de avertizare RSU2V ○ Clasa - 1 , subclasa - 1, use case - 3 ○ Restrictii destinatar: masinile pentru care conditia de trigger este adevarata

2.3.6 Identificarea implicatiilor semnelor de circulatie Verificarea validitatii unor manevre in functie de contextul perceput este realizata folosind reguli definite in

sistemul expert CLIPS [10, 11]. S-a luat in considerare validitatea manevrelor de depasire, viraj stanga sau dreapta, precum si limitari ale vitezei in prezenta semnelor de circulatie interzis la stanga/dreapta, avertizare trecere de pieton, trecere de pieton, avertizare hazard copii, limitare de viteza. Perceptiile de la nivelul modului CLIPS sunt construite pe baza datelor de la senzori si a interpretarii lor in cadrul LDM, precum pozitia relativa la intersectii sau fata de semne de trafic. Pe baza perceptiilor si a regulilor sunt derivate credinte (beliefs) referitoare la validitatea unor manevre. Un exemplu de regula poate fi observat mai jos; zona interzis la stanga este identificata pe baza perceptiei unui semn de trafic de interdictie. Aceasta credinta va fi anulata in momentul in care s-a perceput iesirea dintr-o intersectie (pe baza modelului cu 5 stari). In figura 2.9 validitatea manevrelor de viraj la dreapta nu e influentata de marcajele identificate pe drum, ci doar de semnele de trafic. (defrule r-no-left-turn-sign

12

(time (value ?t)) (ag_percept (percept_pname road_sign) (percept_pval no-left-sign)) => (assert (ag_bel (bel_type fluent) (bel_pname no-left-turn-zone) (bel_pval yes)))) (defrule r-no-left-turn-zone-end (time (value ?t)) ?f <- (ag_bel (bel_type fluent) (bel_pname no-left-turn-zone) (bel_pval yes)) (ag_percept (percept_pname intersection_end) (percept_pval yes)) => (retract ?f))

Figura 2.9: Scenarii de avertizare vizuala asupa legalitatii manevrei de viraj la dreapta

Date folosite De la senzori : CAN - viteza, GPS: pozitie

Din LDM: model GMM , drumuri OSM , pozitionarea semnelor de trafic

Trigger La fiecare secunda

Actiunea Informare vizuala ego-vehicul despre validitatea unor manevre

3. Plan de evaluare Pentru testarea aplicatiilor de testare a conducerii s-au folosit atat simulatoare si inregistrari efectuate in trafic,

cat si teste in timp real si in diferite conditii de trafic. Principalul scenariu de test pentru evaluarea pozitionarii vehiculului fata de intersectii, a pozitionarii vehiculului in cadrul benzilor de circulatie, identificarea benzii de circulatie si a identificarii implicatiilor semenelor de circulatie a fost bulevardul 1 Decembrie din Cluj-Napoca. Pentru celelalte aplicatii au putut fi folosite si alte scenarii de trafic.

Fiecare modul din cadrul arhitecturilor SMP, RSU si RTIS a fost evaluat individual pentru a ii testa functionalitatea si rata de transfer a datelor intre senzori si modulul de interconectare din cadrul SMP, comunicare Bluetooth intre tableta si modulul de interconectare in cadrul SMP, senzori si calculator industrial la nivel RSU, comunicare V2V, V2I intre vehicule sau intre vehicule si RSU, comunicare intre RSU si RTIS. In paragrafele urmatoare sunt descrise evaluarile efectuate pentru a testa fnctionalitatea diferitelor module din cadrul aplicatiilor de asistarea a conducerii.

4. Evaluarea si testarea aplicatiilor de asistare a conducerii

Pentru testarea aplicatiilor de testare a conducerii s-au folosit atat simulatoare si inregistrari efectuate in trafic, cat si teste in timp real si in diferite conditii de trafic. Principalul scenariu de test pentru evaluarea pozitionarii vehiculului fata de intersectii, a pozitionarii vehiculului in cadrul benzilor de circulatie, identificarea benzii de circulatie si a identificarii implicatiilor semenelor de circulatie a fost bulevardul 1 Decembrie din Cluj-Napoca. Pentru celelalte aplicatii au putut fi folosite si alte scenarii de trafic.

Fiecare modul din cadrul arhitecturilor SMP, RSU si RTIS a fost evaluat individual pentru a ii testa functionalitatea si rata de transfer a datelor intre senzori si modulul de interconectare din cadrul SMP, comunicare Bluetooth intre tableta si modulul de interconectare in cadrul SMP, senzori si calculator industrial la nivel RSU, comunicare V2V, V2I intre vehicule sau intre vehicule si RSU, comunicare intre RSU si RTIS. In paragrafele urmatoare sunt descrise evaluarile efectuate pentru a testa fnctionalitatea diferitelor module din cadrul aplicatiilor de asistarea a conducerii.

13

Evaluarea comunicarii in cadrul SMP si a comunicarii V2X Pentru a evalua comunicarea prin Bluetooth intre modulul de interconectare din cadrul SMP si tableta Microsoft

Surface Pro 4, s-a creat o platfroma de test in laborator cu ajutorul programului HTerm. In cadrul Hterm au fost generate mesaje de prezenta de 80 de bytes, descrise in tabelul 1.2, la fiecare 100 de milisecunde, iar apliatia care ruleaza pe tableta a trimis mesaje catre platforma de test (in Hterm). Testul a rulat aproximativ 3 ore; la aceasta frecventa de trimitere (10 mesaje pe secunda) nu se pierde nici un mesaj. Testul a fost repetat cu succes si invers (HTerm pe tableta) si aplicatia dezvoltata pe modulul de interconectare. Teste similare au fost dezvoltate si pentru comunciarea cu senzorii: CAN, GPS si V2X. Testul complet in laborator consta in conectarea mai multor dispozitive de comunicatie V2X si verificarea primirii mesajelor de prezenta (o data la 1 secunda) de la fiecare dispozitiv de comunicatie pe tableta Microsoft, generarea de mesaje de avertizare la nivelul aplicatiei de pe tableta catre unul (unicast) sau mai multe (broadcast) dispozitive V2X si verificarea primirii acestor mesaje de avertizare. Pe tableta se ruleaza o secventa offline din cadrul scenariului de test Bulevardul 1 Decembrie, Cluj-Napoca. Acelasi test a fost efectuat cu succes si in conditii de trafic, concluzia fiind ca se poate mari frecventa trimiterii de mesaje de prezenta - de la 1 secunda la 500 de ms, dar acest lucru depinde de numarul de noduri care participa in reteaua adhoc. O solutie robusta pentru alegerea frecventei mesajelor de prezenta ar putea include numarul de noduri din retea pentru a evita congestia comunicarii in cadrul retelei adhoc.

Evaluarea algoritmului de detectie si urmarire a benzii curente Algoritmul de detectie si urmarire a benzii curente a fost evaluat vizual pe un set de 5000 de imagini luate in

Cluj-Napoca, care contin o varietate mare de delimitatori. Algoritmul a dovedit ca functioneaza bine in aproape orice fel de scenariu, cu orice configuratie de delimitatori si nu este afectat de umbre. Modelul matematic al benzii curente se bazeaza pe modelul clotoidal, fapt care face posibil detectarea corecta a benzii chiar si in curbe. Banda curenta nu poate fi detectata in intersectii, atunci cand marcajele nu sunt prezente. In cazul in care un marcaj de pe una dintre parti nu este prezent pentru o scurta perioada de timp, algoritmul va detecta corect banda curenta daca in trecutul apropiat s-au detectat marcaje pe ambele parti. O absenta indelungata a unui marcaj pe o parte a benzii va impiedica gasirea corecta a benzii curente. De remarcat este faptul ca algoritmul necesita parametri corecti ai camerei pentru a determina cu precizie structura 3D a benzii.

Acuratetea algoritmului a fost evaluata prin adnotarea manuala a 100 de imagini cu zona benzii curente. Aceasta a fost marcata cu pixeli albi, iar restul imaginii cu pixeli negri. Setul de imagini a fost achizitionat in Cluj-Napoca si contine o varietate de geometrii de drum: drum drept, drum in panta, diferite curburi, diferite latimi de benzi. Marcajele de pe ambele parti sunt prezente in imaginile din setul de test. Un exemplu de astfel de imagine adnotata poate fi vazut in Figura 4.1.

Figura 4.1: Evaluarea modului de detectie si urmarire a benzii folosind imagini adnotate manual

Banda curenta detectata de algoritm a fost comparata cu banda adnotata manual din imagine folosind metrici

precum precizie si recall. Valorile de true positive, false positive, false negative reprezinta numar de pixeli. Modulul de detectie si urmarire a benzii ofera rezultate bune in diferite scenarii urbane avand o precizie de 94.5 % si recall de 98.1%. Tabelul 4.1 prezinta rezultatele evaluarii algoritmului de detectie si urmarire a benzii pe setul de test.

Precizia = TP/(TP + FP) Recall = TP/ (TP + FN)

Tabelul 4.1: Rezultatele evaluarii algoritmului de detectie si urmarire a benzii

Evaluarea algoritmului de detectie a obstacolului din fata

14

In dezvoltarea acestui algoritm am luat in considerare doar obiectele situate pe banda curenta aflate la mai putin de 30 metri distanta. Aceasta distanta permite ca obstacolul sa fie inca vizibil in imagine astfel incat in urma aplicarii detectorului de muchii, reconstructia 3D sa aiba acuratete buna. Evaluarea algoritmului a fost facuta pe 1000 de imagini capturate in Cluj-Napoca, in timpul zilei in conditii bune din punct de vedere meteorologic. Cele 1000 de imagini au fost adnotate manual, astfel ca fiecare obstacol de pe banda curenta a fost incadrat intr-un dreptunghi. Acest algoritm depinde de detectia corecta a benzii curente. Majoritatea imaginilor din setul de test contin un mediu structurat cu marcaje vizibile, insa cateva imagini sunt preluate in intersectie unde marcajele nu sunt prezente. Pe acest set de date, am obtinut precizie de 97.9% si recall de 96%. Instantele fals negative sunt prezente din cauza erorilor in reconstructia 3D sau discriminarea gresita dintre punctele de drum si punctele de obstacol. De remarcat este faptul ca algoritmii de reconstructie 3D sunt intensivi din punct de vedere computational. Astfel ca in procesul de dezvoltare a algoritmului de reconstructie 3D s-a tinut cont de cerintele de rulare in timp real a aplicatiei, asadar a fost nevoie de balansarea acuratetii si a timpului de executie pentru a obtine algoritmul cu cele mai bune rezultate. In tabelul 3.2 se prezinta rezultatele detectiei obstacolului din fata situat la mai putin de 30 metri.

Tabel 4.2: Rezultatele evaluarii algoritmului de detectie a obstacolului din fata

Evaluarea algoritmului de detectie a coliziunii cu vehiculul din fata Acest algoritm a fost testat atat in simulator, cat si in mediu de trafic real [6]. In simulatorul dezvoltat in Matlab,

s-au pozitionat doua vehicule pe un drum si s-au testat mai multe scenarii. Unul dintre scenariile relevante este cel in care vehiculul propriu se deplaseaza cu o viteza mai mare decat vehiculul din fata astfel incat cele doua vor face accident. In graficele de mai jos poate fi observat timpul coliziunii ca fiind secunda 17 din simulare. Parametrii sistemului de coliziune cum ar fi viteza, locatia vehiculelor, timpul pana la coliziune si decalajul de timp sunt schitati in grafice. De notat este faptul ca axa timpului se masoara in secunde. In Figura 4.2 se poate observa momentul cand cele doua vehicule se accidenteaza. In Figura 4.3 putem vedea cum viteza vehiculului propriu creste mai repede decat cea a vehiculului din fata. In urmatorul grafic, valoarea timpului pana la coliziune descreste de la 10 (cat este maxim) pana la 0, momentul cand coliziunea are loc. Mai mult, decalajul de timp descreste de la 16 (maxim) pana la un minim de 0 la momentul accidentului. In ultima figura, se poate vedea variabila de avertizare si valorile acesteia. La inceput, sistemul considera situatia normala fara posibilitate de coliziune, iar in timp aceasta creste si are valoarea maxima cand are loc accidentul.

TTC = distantaEgoVehiculFata/ (vitezaEgo - vitezaVehiculFata) (timpul pana la coliziune) TG = distantaEgoVehiculFata / vitezaEgo (decalaj de timp)

Functia de avertizare se bazeaza pe TTC si TG folosind logica fuzzy.

Figura. 4.2: Locatia celor

doua vehicule

Figura 4.3: Viteza celor doua vehicule

Figura 4.4: Timpul pana la coliziune si decalajul de timp

Figura 4.5: Valorile

semnalului de avertizare in timp

15

Figura 4.6: Rezultate bune cu imagini care contin diverse geometrii a drumului si obstacol la diferite distante. Se remarca dificultatea scenelor prin prezenta umbrei in imagine, diferite tipuri de marcaje, sine de tramvai, treceri de pietoni, curburi

variate. Cu toate acestea banda curenta este bine detectata.

Figura 4.7: Erori in detectie: lipsa marcajelor pe o parte sau pe ambele parti, intersectii fara marcaje

16

Evaluarea aplicatiei de determinare a implicatiilor semnelor de circulatie Pentru evaluarea aplicatiei s-au masurat pozitiile a 6 semne de circulatie: un semn interzis la dreapta, avertizare

trecere de pietoni, 2 semne de limitare de viteza, un semn de avertizare hazard copii, precum si 2 marcaje de trecere de pieton. Pentru a calcula pozitia cu acuratete mare a acestora, s-au colectat intre 40 si 100 de sample-uri GPS pentru fiecare semn; pentru acestea, folosind extensia PostGIS, s-au calculat infasuratoarea concava si convexa, centrele acestor suprafete si ariile lor. Centrul infasuratorii convexe a fost introdus in harta OSM (figura 4.8)

Figura 4.8: Semne de circulatie identificate si introduse in harta OSM, folosite in evaluarea aplicatiei

Pe un sistem cu procesor IntelCore i7 2GHz timpul de procesare alocat operatiilor de tell/ask cu modulul de

reguli variaza intre 3 ms si 9 ms, iar timpul mediu de interpretare a pozitiei (lat, long) in termeni de stare curenta fata de intersectie, drum curent si distanta fata de semne de circulatie este 3.5 ms in situatiile in care vehiculul este departe de intersectie, respectiv 7 ms in intersectie.

Evaluarea Comunicarii intre RSU si RTIS Pentru evaluarea comunicarii dintre RSU si RTIS s-a testat atat transmiterea rapoartelor de trafic local de la RSU

la RTIS si transmiterea rapoartelor de trafic globale de la RTIS la RSU, dar si performanta si scalabilitatea la nivel RTIS cand exista mai multe unitati locale de infrastructura - RSU care trimit rapoarte [4]. Scenariu de test a fost urmatorul: timp de 10 minute au fost lansati 15 clienti RSU, fiecare client trimitand un raport de trafic local la fiecare secunda.

Figura 4.9: Timpi de raspuns RTIS pentru 15 RSU pornite simultan

Time to first byte reprezinta timpul intre primul octet al cererii RSU si primul octet al raspunsului serverului, in

timp ce Time to last byte reprezinta timpul intre primul octet al cererii RSU si ultimul octet al raspunsului serverului. Se observa ca acesti timpi sunt mai mici decat 5 s in medie, respectiv 14 s in cel mai rau caz. Dupa optimizari ale accesului

17

la baza de date, maximum de timp a scazut la 6 s. Viteza transferului de date la cerere, respectiv la raspuns se imbuntataeste de asemenea, reducandu-se bottleneck-urile din comunicare.

Figura 4.10: Timpi de raspuns RTIS pentru 15 RSU pornite simultan dupa optimizarea accesului la baza de date

5. Beneficiile sistemului

Proiectul SmartCoDrive uneste trei concepte cheie (functii avansate de asistare a conducerii, sisteme cooperative si dispozitive mobile inteligente) prin intermediul carora ofera o solutie unica de asistare a conducerii. Un avantaj al acestui sistem complex il reprezinta posibilitatea imediata de aplicabilitate si penetrare a pietei. Utilizarea dispozitivelor mobile inteligente creste exponential de la an la an iar din punct de vedere tehnic hardware-ul devine mai performant, permitand dezvoltarea unor algoritmi complecsi de viziune artificiala. Prin aplicatiile de asistare a conducerii pentru telefonul mobil, aceasta solutie le ofera soferilor o alternativa accesibila din punct de vedere financiar la sistemele de asistare a conducerii deja existente pe anumite vehicule de ultima generatie.

Impactul general este puternic dependent de rata de penetrare a dispozitivelor mobile, a capacitatii de procesare, de corectitudinea hartilor, dar mai ales de rata de acceptare a dispozitivelor de comunicare V2V, respectiv V2I. Beneficiile platformei mobile de asistare a conducerii (SMP) sunt atat de natura arhitecturala cat si functionala. In cadrul platformei mobile s-au propus, implementat si analizat metode de integrare a datelor de la diversi senzori proprii ai vehiculului (date furnizate prin intermediul magistralei CAN), date de pozitionare (GPS), date despre contextul imediat furnizate de senzorul de stereo-viziune si de alte vehicule sau elemente de infrastructura (V2X), date despre contextul global de trafic furnizat de serverul regional de trafic RTIS. Toate aceste date permit construirea unei harti locale dinamice relevante pentru o multitudine de aplicatii de asistare a conducerii.

La nivelul modulelor Road Side Unit, contributia principala este construirea si folosirea unei harti locale dinamice proprii relevanta pentru situatii de intersectie sau zone cu risc ridicat, precum treceri de pietoni. Prin mesajele initiate de RSU, evenimente de risc mare pot fi cel putin diseminate, scopul final fiind insa preintampinarea acestora. De asemenea, eficientizarea traficului se doreste a fi obtinuta prin comunicarea intre nodurile RSU. Cresterea sigurantei prin utilizarea RSU este dependenta de o multime de factori precum existenta echipamentelor de comunicare V2I sau de reactia rapida a soferilor in momentul primirii mesajelor.

La nivelul serverelor regionale de trafic, arhitectura propusa si interfata de comunicare cu unitatile locale de infrastructura (RSU) permit diseminarea informatiilor la nivelul unei regiuni extinse.

Modulul de comunicatii adreseaza problema standardizarii mesajelor de asistenta a conducerii. Solutiile propuse asigura comunicarea in timp suficient de mic a mesajelor pentru a permite construirea hartii locale in timp util, precum si pentru eficienta mesajelor de avertizare. Este de asteptat ca aceasta tehnologie de comunicare bazata pe standardul

18

802.11p sa fie implementata si in dispozitivele mobile inteligente de noua generatie, astfel incat un telefon mobil inteligent sa poata fi utilizat direct in cadrul vehiculelor atat ca platforma de procesare cat si ca platforma de comunicare.

Aplicatiile dezvoltate in cadrul proiectului evidentiaza posibilitatea utilizarii platformei mobile, a RSU, a RTIS pentru diverse situatii bine definite din trafic. Acestea vizeaza atat siguranta soferului ego-vehiculului, precum si cea a celorlalti participanti la trafic, dar si eficienta traficului. Aplicatiile au caracter atat informativ cat si preventiv.

Incepand cu anul 2020 este asteptata o rata tot mai mare de penetrare a vehiculelor inteligente, echipate si cu sisteme de comunicatie V2V si V2I, astfel dezvoltandu-se o noua clasa de algoritmi avansati de asistenta a conducerii. Vehiculele autonome vor avea nevoie atat de algoritmi robusti de perceptie a mediului din jurul vehiculului, dar si de informatii distribuite de alti participanti la trafic prin comunicatie V2X, sau alte informatii importante - informatii meteorologice, informatii cu privire la starea carosabilului, etc. Asadar vehiculele nu vor putea exista fara dispozitive de comunicatie; ele vor conta din ce in ce mai mult pe calitatea informatiilor primite din mediul in care ruleaza, astfel incat algoritmii de decizie asupra directiei de mers, evaluarea posibilelor impacte, etc. vor fi unii cooperativi. Problema care ramane de rezolvat este echiparea autovehiculelor mai vechi cu echipamente si dispozitive de comunicatie astfel incat algoritmii cooperativi de asistare a conducerii sa poata fi adaptati si pentru aceste autovehicule. Poriectul de fata furnizeaza o solutie complexa in acesta directie.

Datorita acestor algoritmi cooperativi de asistenta a conducerii, impactul imediat asteptat este o crestere a numarului utilizatorilor de sisteme de asistare a conducerii, o crestere a numarului aplicatiilor care exploateaza comunicarea V2X si in consecinta o imbunatatire a sigurantei pe sosele, reducerea numarului de accidente, optimizarea fluxurilor de trafic, reducerea emisiilor poluante. In prezent se investigheaza extinderea acestor tipuri de aplicatii nu doar in domeniul transportului rutier, dar si spre alte domenii de transport: Car2XUrban, Car2XHighway, Rail2X, Ship2X si Airplane2X [1]. Tehnologia de comunicatie V2X va putea fi folosita intr-o gama larga de noi aplicatii, cum ar fi [2]:

● Siguranta in trafic: asistenta la coliziune, asistenta la coliziune iminenta, locatii primejdioase, etc. ● Eficienta traficului: asistenta in diverse conditii de trafic, asistenta la depasire, semne de circulatie si viteza

optima pentru unda verde, etc. ● Diverse informatii sau acces la internet: informatii despre puncte de interes, locuri de parcare disponibile intr-o

zona, acces automat in parcare, servicii comunitare, etc.

6. Bibliografie [1] Future of Infrastructure: Vehicle-to-X (V2X) Communication Technology, Siemens AG https://www.mobility.siemens.com/mobility/global/SiteCollectionDocuments/en/road-solutions/urban/trends/siemens-vehicle-to-x-communication-technology-infographic.pdf [2] ETSI TS 102 636-4-1: "Intelligent Transport System (ITS); Vehicular communications; GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 1: Media independent functionalities" [3] Y. Chen and J. Krumm, “Probabilistic modeling of traffic lanes from GPS traces,” in Proceedings of the 18th SIGSPATIAL International Conference on Advances in Geographic Information Systems, ser. GIS ’10. New York, NY, USA: ACM, 2010, pp. 81–88 [4] D. Munteanu, “Regional Traffic Information System”, lucrare de disertate, 2016 [5] A. Petrovai, “A Stereovision based Rear-End Collision Warning System on Mobile Devices”, lucrare de disertatie, UTCN, 2016 [6] A. Petrovai, R. G. Danescu, M. Negru, C. C. Vancea, S. Nedevschi, ”A Stereovision based Rear-End Collision Warning System on Mobile Devices”, 2016 IEEE International Conference on Intelligent Computer Communication and Processing (ICCP) , 8-10 Sept. 2016, pp. 285-292. [7] L. Zhang, F. Thiemann, and M. Sester, “Integration of GPS traces with road map,” in Proceedings of the Second International Workshop on Computational Transportation Science, ser. IWCTS ’10. New York, NY, USA: ACM, 2010, pp. 17–22. [8] A. Pirvu, “Deducerea intentiei soferilor si prevenirea situatiilor periculoase pe baza intentiei la nivel de Road Side Unit”, lucrare de licenta, 2016 [9] S. Lefevre, C. Laugier, and J. Ibanez-Guzman, “Exploiting map information for driver intention estimation at road intersections,” in Intelligent Vehicles Symposium (IV), 2011 IEEE, June 2011, pp. 583–588. [10] J. C. Giarratano and G. D. Riley, Expert Systems: Principles and Programming. Pacific Grove, CA, USA: Brooks/Cole Publishing Co., 2005 [11] K. Kaplan and H. L. Akin, “Expert system design for an autonomous driver evaluation system,” in Intelligent Vehicles Symposium (IV), 2011 IEEE, June 2011, pp. 314–319 [12] Transportation Research Board. (2000). Highway Capacity Manual 2000. National Research Council, Washington, DC [13] A. Marginean, A. Petrovai, R. R. Slavescu, M. Negru and S. Nedevschi, “Enhancing Digital Maps to Support Reasoning on Traffic Sign Compliance”, 2016 IEEE International Conference on Intelligent Computer Communication and Processing (ICCP) , 8-10 Sept. 2016, pp. 277-284

19

7. Diseminare Jurnale ISI 1. R. Danescu, R. Itu, and A. Petrovai, "Generic Dynamic Environment Perception Using Smart Mobile Devices," Sensors, vol. 16, p. 1721, 2016. Conferinte Internationale 1. C. C. Vancea, V. C. Miclea and S. Nedevschi, "Improving stereo reconstruction by sub-pixel correction using histogram matching," 2016 IEEE Intelligent Vehicles Symposium (IV) , Gothenburg, 2016, pp. 335-341. 2. A. D. Costea and S. Nedevschi, "Fast traffic scene segmentation using multi-range features from multi-resolution filtered and spatial context channels," 2016 IEEE Intelligent Vehicles Symposium (IV) , Gothenburg, 2016, pp. 328-334. 3. A. D. Costea, S. Nedevschi, “Semantic Channels for Fast Pedestrian Detection” 2016 IEEE Conference on Computer Vision and Pattern Recognition, 2016, pp. 2360-2368. 4. A. Marginean, A.Petrovai, R. R. Slavescu, M. Negru and S. Nedevschi, “Enhancing Digital Maps to Support Reasoning on Traffic Sign Compliance”, 2016 IEEE International Conference on Intelligent Computer Communication and Processing (ICCP) , 8-10 Sept. 2016, pp. 277-284. 5. A. Petrovai, R. G. Danescu, M. Negru, C. C. Vancea, S. Nedevschi, ”A Stereovision based Rear-End Collision Warning System on Mobile Devices”, 2016 IEEE International Conference on Intelligent Computer Communication and Processing (ICCP) , 8-10 Sept. 2016, pp. 285-292. 6. B. Coseriu, M. Negru, S. Nedevschi, “Contrast Restoration of Foggy Images on the ZYNQ Embedded Platform”, 2016 IEEE International Conference on Intelligent Computer Communication and Processing (ICCP) , 8-10 Sept. 2016, pp. 207-214.

Teze 1. D. Munteanu, “Regional Traffic Information System”, lucrare de disertatie, 2016 2. A. Petrovai, “A Stereovision based Rear-End Collision Warning System on Mobile Devices”, lucrare de disertatie, UTCN, 2016 3. A. Pirvu, “Deducerea intentiei soferilor si prevenirea situatiilor periculoase pe baza intentiei la nivel de Road Side Unit”, lucrare de licenta, 2016 Organizarea de sesiuni stiintifice pentru diseminarea rezultatelor: 1. Organizarea conferintei 2016 IEEE Intelligent Computer Communication and Processing cu sesiuni specializate pe tematica proiectului: “Computer vision 1-4”, “Cooperative Driving”. 2. Organizarea in cadrul conferintei 2016 IEEE Intelligent Computer Communication and Processing a unui workshop cu tema “Vision-based Driving Assistance”.

Cluj-Napoca Coordonator proiect 05.12.2016 prof. dr. ing. Sergiu Nedevschi

20