Realizarea Unui Sistem De Infotainment (11) [612117]

Universitatea Politehnica Bucure¸ sti
Facultatea de Automatic ˘a si Calculatoare
Departamentul de Automatic ˘a ¸ si Ingineria Sistemelor
LUCRARE DE LICEN¸ T ˘A
Realizarea unui sistem de infotainment
Absolvent: [anonimizat]¸ sti, 2020

Cuprins
List˘ a de figuri iii
1. Introducere 1
1.1. Prezentare general ˘a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Contribut ,ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Rezumatul lucr ˘arii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Arhitectura sistemului 3
2.1. Arhitectura hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Arhitectura software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Descrierea Aplicat ,iei 8
3.1. Designul aplicat ,iei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Prezentarea si evolutia sistemelor infotainment 11
4.1. Ce este un sistem infotainment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Ce reprezint ˘a sistemul de infotainment . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Istorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Originea sistemului infotainment . . . . . . . . . . . . . . . . . . . . . . . 11
5. Prezentarea aplicat ,iei 13
5.1. Prezentarea mediilor de progamare folosite . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. Kivy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Prezentarea arhitecturii aplicat ,iei în ansamblu . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.2. Core providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.3. Grafic ˘a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.4. Intr ˘ari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.5. Widgets Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.6. Events and Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.7. Lib ˘arii auxiliare folosite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Descrierea fiecarui submeniu al app . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. Înc ˘arcarea aplicat ,iei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.2. Meniul principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.3. Muzic ˘a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.4. Set ˘ari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.5. Notit ,e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.6. Hart ˘a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Proiectarea aplicat ,iei 23
6.1. Dificult ˘at,i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2. Imbun ˘at˘at,iri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7. Concluzii 35
Anexe 37
ii

Cuprins
A. Nota¸ tii 37
B. Cod 38
Bibliografie 46
iii

List˘ a de figuri
2.1. Diagrama hardware a placut ,ei Raspberry Pi 4 . . . . . . . . . . . . . . . . . . . . 3
2.2. LCD-ul care ofer ˘a utilizatorului interact ,iunea cu sistemul . . . . . . . . . . . . . 4
2.3. CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. St ˘arile aplicat ,iei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Structura arhitecturii conform libr ˘ariei Kivy Kivy architecture 2014 . . . . . . . . 14
5.2. Specificarea atributelor vertecsilor (Chenaru 2020) . . . . . . . . . . . . . . . . . 15
5.3. Thread ( Events and Properties 2014) . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. St ˘arile aplicat ,iei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5. Meniul principal al aplicat ,iei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.6. Ecranul de muzic ˘a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.7. Ecranul de set ˘ari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.8. Ecranul de notit ,e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.9. Creare/Editare notit ,˘a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.10. Harta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Codul pentru înc ˘arcarea aplicat ,iei . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. Codul pentru înc ˘arcarea aplicat ,iei . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. Fragment din cod pentru a exemplifica un Layout cont ,inând mai multe obiecte
de tip Button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4. Exemplu fis ,ier.inipentru memorarea set ˘arilor . . . . . . . . . . . . . . . . . . . 27
6.5. Funct ,ia care prea din fis ,ierul .ini informat ,iile salvate din set ˘ari . . . . . . . . . . 29
6.6. Funct ,ia care prea din dintr-un fis ,ier .ini traducerile pentru fiecare text . . . . . . 30
6.7. Fis ,ierul .ini cu traducerile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.8. Exemplificare clase RecycleView , utilizarea s ,i implementarea acesteia pentru
tema prezentat ˘a. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.9. Diagram ˘a care descriere interact ,iunea cu modelul Model-view-controller ( MVC
Process (2020)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.10. Apelarea a dou ˘a funct ,ii definite în clasa principal ˘a . . . . . . . . . . . . . . . . . 33
6.11. Codul pentru funct ,ia set_note_content() . . . . . . . . . . . . . . . . . . . . . . 33
iv

1. Introducere
1.1. Prezentare general˘ a
Înc˘a de la începerea product ,iei în mas ˘a a autovehiculelor în 1908, industria auto a ocupat un
sector împortant de piat ,˘a, aducând de asemenea cu ea o serie de inovat ,ii care au fost pe urm ˘a
adoptate s ,i în alte domenii de activitate. Aici putem ment ,iona tehnicile de product ,ie ce sunt
folosite pentru producerea unui automobil, plecând de la brat ,ele robotice pneumatice utilizate
la sudura caroseriei pân ˘a la managementul fabricii prin organizarea product ,iei într-o manier ˘a
în care totul se afl ˘a intr-o continua mis ,care. Mai explicit, fiecare mas ,in˘a se afl ˘a pe o band ˘a
convoioare astfel încât doar personalul fabricii poate lucra la autovehicul în timp ce aceasta
parcurge traseul de product ,ie.
La începutul aparit ,iei primului autovehicul produs în mas ˘a, Ford Model T in 1908, in-
dustria auto avea ca scop s ˘a ofere fiecarei persoane un autovehicul care s ˘a te duc ˘a din punctul
A în punctul B la un pret ,decent. În ultimele 2 decenii, acest obiectiv devine insuficient, iar
produc ˘atorii sunt nevoit ,i s˘a vin˘a cu solut ,ii noi pentru a atrage cumpar ˘atorii. Astfel, progresul
tehnologic este impus de c ˘atre consumator s ,i noi tehnologii sunt dezvoltate pentru a le satisface.
În aceast ˘a perioad ˘a apar sisteme de tract ,iuni din ce în ce mai performante si complexe, cutii de
viteze automate care pot obt ,ine atât performant ,e bune la schimbarea vitezelor cât s ,i un consum
de combustibil redus sau reducerea emisiilor motorului. Pe lâng ˘a cele ment ,ionate, mult ,i pro-
duc˘atori au început s ˘a pun ˘a accentul pe interfat ,area utilizatorului cu mas ,ina prin dezvoltarea
sistemelor de infotainment, cât s ,i a IPC-urilor (instruments control clustere) complet digitale
sau a hibridelor (analog s ,i digital).
Un sistem de infotainment are rolul de a pune la dispozit ,ie utilizatorului o interfat ,˘a gra-
fic˘a cu care acesta poate iteract ,iona cu componentele autovehicului doar prin atingerea unui
ecran tactil, utilizarea unor butoane sau potent ,iometre dedicate, comand ˘a vocala sau chiar prin
utilizarea gesturilor. Datorit ˘a diversit ˘at,ii modurilor prin care se poate utiliza un sistem de info-
tainment cât s ,i diversitatea funct ,ionalit ˘at,ilor pe care le poate avea unul, obt ,inem o gam ˘a vast ˘a
de produse ce se reg ˘asesc ast ˘azi pe autovehicule. Din punct de vedere a evolut ,iei tehnologice,
sistemele de infotainment la începutul anului 2000 aveau un numar mic de funct ,ionalit ˘at,i, prin-
tre care putem aminti radioul FM s ,i interfat ,area cu senzorii de parcare. În momentul actual,
sistemele de infotainment au progresat atât de mult încât majoritatea funct ,iilor mas ,ini sunt
disponibile doar la o simpl ˘a atingere. De exemplu, exist ˘a posibilitatea regl ˘arii înalt ,imii suspen-
siei, verificarea nivelului de ulei, controlul sistemului de climatizare automat ˘a sau chiar reglarea
alunec ˘arii diferent ,ialului. Interfat ,area cu restul ECU-urilor din autovehicul se realizeaz ˘a prin
intermediului CAN (controller area network), un protocol utilizat preponderend în industria
auto datorit ˘a robustet ,ei acestuia cât s ,i a reducerei costului de fabricare a autovehiculului. În
acest protocol, informat ,ia este trimis ˘a în mod diferent ,ial sub form ˘a de broadcast, pe urm ˘a fi-
ind procesat ˘a de c ˘atre fiecare ECU doar dac ˘a ID-ul mesajului este de int ,eres pentru ECU-ul
respectiv.
În aceast ˘a lucrare, voi dezvolta un sistem de infotainment bazat pe un Raspberry Pi 4
s,i un ecran tactil de 7 inchi cu capacitatea de a reda fis ,ierele audio mp3, utilizarea navigat ,iei,
personalizarea aplicat ,iei cât s ,i posibilitatea de a lua notit ,e.
1

Capitolul 1. Introducere
1.2. Contribut ,ii
Pentru realizarea acestei lucr ˘arii a fost necesar ˘a utilizarea limbajului Python ca limbaj principal
de programare. Pe lâng ˘a acesta, s-a folosit frameworkul Kivy pentru a facilita dezvoltarea
interfetei grafice, cât s ,i pentru a permite gestionarea eficient ˘a a intr ˘arilor utilizatorului. De
asemenea, prin utilizarea acestui framework, se foloses ,te implicit OpenGL 2.0 ES, o versiune de
OpenGL dedicat ˘a platformelor mobile datorit ˘a consumului redus de resurse cât s ,i o amprent ˘a
redus˘a a memoriei necesare pentru execut ,ie.
1.3. Rezumatul lucr˘ arii
Lucrarea de fat ,˘a prezint ˘a un sistem infotainment modern s ,i us ,or de folosit de c ˘atre conduc ˘atorul
autovehiculului. În cadrul acestui sistem, utilizatorul dispune de anumite funct ,ionalit ˘at,i. Mai
jos voi vorbi pe scurt despre funct ,ionalit ˘at,ile sistemului, urmând ca în capitolul 5.3 s ˘a descriu
modul în care utilizatorul se poate plimba printre ferestre s ,i ce poate face. Voi explica modul
lui de funct ,ionare, us ,urint ,a cu care poate fi utilizat de c ˘atre s ,ofer. Dup ˘a aceea, în capitolul 6
voi descrie în detaliu fiecare funct ,ionalitate a sistemului, cum se apeleaz ˘a funct ,iile între ele, de
ce am ales anumite clase, cum am construit fis ,ierele kivy.
1. redarea de melodii audio – aproape toate mas ,inile înscrise în circulat ,ie dispun de unitate
radio si CD care permite redarea de melodii de la radio sau pe baza unui CD/DVD;
Cu ajutorul sistemului pe care îl pun la dispozit ,ie, utilizatorul va dispune de o interfat ,˘a
modern ˘a care il va ajuta sa îs ,i aleag ˘a us ,or melodia dorit ˘a dintr-o list ˘a de melodii far ˘a s˘a
mai fie necesar ˘a trecerea prin ele.
2. navigat ,ie – partea de navigat ,ie va permite utilizatorului s ˘a obt ,in˘a informat ,ii despre traseul
pe care dores ,te s˘a îl parcurg ˘a.
3. notit ,e – dac ˘a utilizatorul este stat ,ionat s ,i dores ,te s˘a noteze o anumit ˘a informat ,ie rapid,
sistemul îi ofer ˘a ca opt ,iune o sect ,iune de notit ,e unde acesta poate nota f ˘ar˘a s˘a le piard ˘a.
4. set ˘arile sistemului – set ˘arile îi vor permite utilizatorului s ˘a modifice afis ,ajul aplicat ,iei,
f˘acând fonturile mai mari de exemplu, sau schimbând limba, setarea unui nume.
2

2. Arhitectura sistemului
2.1. Arhitectura hardware
Înainte de a prezenta alegerea f ˘acut˘a pentru hardware-ul sistemului, trebuie s ˘a definim obiec-
tivele pe care dorim s ˘a le atingem, cât s ,i s˘a evalu ˘am disponibilitatea componentelor pe piat ,˘a,
dar s ,i pret ,ul acestora. Pentru început, va fi nevoie de un microprocesor suficient de puternic
pentru a executa instruct ,iunile într-un timp suficient de mic, astfel încât utilizator s ˘a nu poat ˘a
observa eventualele întârzieri de procesare. Astfel, luând în considerare necesit ˘at,ile date de
natura aplicat ,iei, impreun ˘a cu necesitatea de a ocupa un spat ,iu fizic cât mai redus, am decis
de a opta pentru un microprocesor din familia ARM, datorit ˘a performant ,elor bune raportate
la dimensiunea s ,i consumul acestuia. Având în vedere faptul c ˘a sistemele de infotainment lu-
creaz˘a cu un num ˘ar relativ ridicat de imagini/texturi, vom utiliza o memorie volatil ˘a de tip
LPDDR4-3200 SDRAM pentru a gestiona aceste resurse. De asemenea, ne intereseaz ˘a s ,i partea
de conectivitate cu sistemul de infotainment, astfel suntem nevoit ,i de a g ˘asi o solut ,ie hardware
care s˘a ne dea posibilitatea de a ne conecta prin bluetooth sau prin wireless cu sistemul nostru.
în cele din urm ˘a, va fi necesar un ecran tactil (2.2) fie capacitiv, fie rezistiv pentru a capta
intr˘arile utilizatorului.
Având cerint ,ele fixate, putem g ˘asi solut ,ii hardware deja existente pe piat ,˘a, care ne satisfac
nevoile. O solut ,ie popular ˘a s ,i utilizat ˘a în aceast ˘a lucrare este Raspberry Pi 4. Un sistem complet
integrat pe un singur PCB, care are în componenta sa urmatoarele componente:
Figura 2.1.: Diagrama hardware a placut ,ei Raspberry Pi 4
• Broadcom BCM2711, Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz
• 4GB
• 5.0 GHz IEEE 802.11ac wireless, Bluetooth 5.0, BLE
• Port Ethernet
3

Capitolul 2. Arhitectura sistemului
• 2 porturi USB 3.0; 2 porturi USB 2.0
• Raspberry Pi standard 40 pini
• 2 micro-HDMI
• port MIPI DSI pentru display
• port MIPI CSI pentru camera
• port audio stereo s ,i video
• H.265 (4kp60 decode), H264 (1080p60 decode, 1080p30 encode)
• grafic ˘a OpenGL ES 3.0
• slot card Micro-SD card slot
• 5V DC via USB-C (minim 3A*)
• 5V DC via GPIO (minim 3A*)
(Hattersley 28 May 2020; Upton 28 May 2020)
Figura 2.2.: LCD-ul care ofer ˘a utilizatorului interact ,iunea cu sistemul
Faptul c ˘a Raspberry Pi 4 are în component ,a sa un port disponibil de PoE cât s ,i un num ˘ar
ridicat de porturi intrare-ies ,ire, ne ofer ˘a nenum ˘arate posibilit ˘at,i de îmbun ˘at˘at,ire a sistemului de
infotainment, plecând de la instalarea unei camere de mans ,alier cu afis ,ajul pe sistemul nostru
pân˘a la monitorizarea a mai multor parametrii ai mas ,inii cât s ,i controlul acestora. De asemenea,
pinii GPIO ne pot fi folositori pentru utilizarea ecranului tactil. Din acest punct de vedere, dorim
s˘a folosim un ecran tactil de 3.5" (2.2) de tip LCD TFT cu o rezolut ,ie de 320480 pentru a asigura
minimul de detalii necesare pentru a demonstra conceptul. Principalul avantaj al acestui tip
de ecran tactil rezistiv este c ˘a din punct de vedere a comunicat ,iei utilizeaz ˘a o interfat ˘a SPI
care poate fi usor de folosit împreun ˘a cu Raspberry Pi-ul. Pe lâng ˘a cele ment ,ionate, specific c ˘a
alimentarea ecranului tactil se face utilizând o surs ˘a coborâtoare de tensiune bazat ˘a pe circuitul
integrat LM2596 pentru a obt ,ine o tensiune de la 12V la 5V. De asemenea t ,in s˘a ment ,ionez
c˘a puterea necesar ˘a ansamblului de componente poate s ˘a ajung ˘a pân ˘a la valoarea de 20W, o
valoare relativ mic ˘a pentru un autovehicul.
4

Capitolul 2. Arhitectura sistemului
Figura 2.3.: CAN
În continuare, considerând ca o îmbun ˘at˘at,ire a sistemului, fat ˘a de obiectivele impuse,
putem folosi un circuit MCP2515 (2.3) cu rolul de a permite unei pl ˘acut ,e de dezvoltare precum
Raspberry Pi 4, s ˘a utilizeze ca metod ˘a de comunicare protocolul CAN. Pe scurt, acest lucru îi va
da posibilitatea de a putea comunica în mod direct cu celalalte ECU-uri ale autovehicului prin
intermediul mesajelor de tip broadcast. Am preferat s ˘a pastrez acaest lucru ca îmbun ˘at˘at,ire
datorit ˘a costurile ridicate impuse etapei de dezvoltare, mai exact costul softului de simulare
a ECU-urilor autovehicului pentru a putea confirma primirea si procesarea corespunz ˘atoare a
mesajelor.
2.2. Arhitectura software
Alegerile pentru arhitectura hardware au fost f ˘acute luând în considerare s ,i natura software a
sistemului. S-a urm ˘arit cu atent ,ie deosebit ˘a compatibilitatea procesorului grafic cu OpenGl ES
2.0 fiind principala limitare din punct de vedere software. Astfel, putem observa c ˘a micropro-
cesorul ARM ales ofer ˘a suport pentru OpenGL ES 3.0, implicit pentru versiunea 2.0 putând fi
folosit mai departe pentru dezvoltarea aplicat ,iei. Dup ˘a cum am mentionat s ,i in subcapitolul 1.3,
limbajul principal de programare ales este Python 3.0. Am f ˘acut aceast ˘a alegere deoarece unul
dintre principalele avantaje ale acestui limbaj este compatibilitatea cu o gam ˘a larg˘a de sisteme de
operare. În cazul acesta, folosim o distribut ,ie de Debian numit ˘a Raspbian, dedicat ˘a sistemelor
bazate pe Raspberry Pi. Mai exact, Raspbian-ul pe care îl utiliz ˘am este bazat pe versiunea 10 de
Debian având la baz ˘a versiunea 4.19 de Linux Kernel. Un lucru important la aceast ˘a versiune
este c ˘a se poate înlocui Kernelul cu unul Real-Time pentru a asigura c ˘a evenimentele critice
din punct de vedere a timpului sunt procesate cât mai eficient. Acest lucru poate fi considerat
ca îmbun ˘at˘at,ire în momentul în care se opteaz ˘a pentru cres ,terea complexit ˘at,ii sistemului prin
ad˘augarea unor funct ,ionalit ˘at,i dependente de restul de ECU-uri ale autovehicului.
Dup˘a cum am ment ,ionat s ,i în 1.3 dorim s ˘a folosim un framework, numit Kivy, pentru
a ne facilita scrierea interfet ,ei grafice a sistemului. Acest beneficiu este atins de c ˘atre Kivy
deoarece acesta punem la dispozit ,ie un API simplist care intermediaz ˘a apelurile c ˘atre OpenGL.
5

Capitolul 2. Arhitectura sistemului
De asemenea, prin intermediul acestui framework se pot procesa mult mai us ,or intr ˘arile de la
utilizator prin intermediul unui Event Dispacher. Mai exact, în momentul în care utilizatorul
atinge ecranul tactil, se va genera o întrerupere de sistem, care va fi procesat ˘a de c ˘atre Kivy
pentru a determina tipul de intrare (scroll, swipe, rotat ,ie). Dup ˘a ce intrarea a fost analizat ˘a,
aceasta va fi preluat ˘a de c ˘atre event dispacher pentru a realiza act ,iunea corespondent ˘a tipului
de act ,iune. Astfel, aproape toat ˘a operat ,ia de prelucrare a intr ˘arilor utilizatorului este preluata
de catre Kivy s ,i tratat ˘a într-o maniera eficient ˘a.
Pe lâng ˘a avantajele date de compatibilitatea microprocesorului cu libr ˘ariile ment ,ionate
anterior, as ,dori s ˘a prezint în cele care urmeaz ˘a beneficiile aduse de utilizarea unui sistem de
operare bazat pe un kernel de Linux în cadrul acestui proiect. Luând în considerare faptul c ˘a
aplicat ,ia noastr ˘a necesit ˘a interact ,iunea utilizatorului cu sistemul prin intermediul unui ecran
tactil, ne punem problema necesit ˘atii unor drivere dedicate sistemului de operare pentru con-
trolul s ,i achizit ,ia datelor ale ecranului tactil. Am optat pentru utilizarea unui ecran tactil de
3.5" LCD (2.2 ) comandat cu ajutorul SPI-ului. Astfel, a fost posibil ˘a utilizarea unor drivere
dedicate disponibile pe github.com/goodtft/LCD-show.git dedicate pentru Raspbian. De aseme-
nea ecranul pe care l-am ales cont ,ine un header pentru pini compatibili cu pinii de GPIO de la
Raspberry Pi 4, astfel conexiunile necesare sunt us ,or de f ˘acut doar printr-o simpl ˘a inserare a
LCD-ului în aces ,ti pini. Instalarea driverelor, de asemenea se face cu us ,urint ,˘a doar prin apelul
scriptului cuprins în repository-ul ment ,ionat anterior.
În cele care urmeaz ˘a, v˘a voi prezenta câteva beneficii pe care le aduce limbajul Python
acestei lucr ˘ari s ,i de ce am optat pentru aceasta în dezavantajul altor limbaje de programare.
Pentru început, limbajul Python are ca scop punerea la dispozit ,ie dezvoltatorului software
un limbaj "curat", cu alte cuvinte limbajul urm ˘ares ,te simplitatea codului t ,inând seama mai mult
de ideea care urmeaz ˘a a fi implementat ˘a decât de implementarea în sine. Acest lucru a permis
dezvoltatorilor de software scrierea a unor programe complexe într-un timp scurt s ,i întret ,inerea
codului cu un minim de efort. Acest avantaj, din p ˘acate, vine cu un dezavantaj la fel de
mare. Limbajul Python nu este un limbaj compilat, ci unul interpretat astfel, obt ,inându-se
nis ,te performant ,e comparativ mai reduse fat ,˘a de restul limbajelor moderne.
Un alt beneficiu al Python-unului este compatibilitatea cu mai multe sisteme de operare.
Acest lucru a crescut popularitatea limbajului, deoarece a oferit posibilitatea de a utiliza limbajul
în domenii precum: backend sau mai bine spus partea de servere, aplicat ,ii de machine learning
sau data science, procese de automatizare a mediului casnic, cât s ,i aplicat ,ii de statistic ˘a sau
bot ,i în domeniul financiar.
De asemenea, un alt factor important ce a dus la cres ,terea limbajului l-a jucat comunitatea
open-scource. Astfel, prin colaborarea mai multor dezvoltatori software s-a ajuns la crearea
unor librarii complexe din domenii diversificate cu un suport de lunga durat ˘a, accesibil oric ˘arui
utilizator doar printr-o simpla comand ˘a din linia de comand ˘a. Acest lucru a atras atât de mult ,i
utilizatori încât a pozit ,ionat Python-ul ca cel mai preferat limbaj de programare în ultimii ani,
al˘aturi de JavaScript.
Totodata, acest limbaj de programare nu este perfect. Precum am ment ,ionat anterior,
acest limbaj de programare nu este unul rapid în comparat ,ie cu limbaje compilate precum C,
C++ unde diferent ,a de performant ,˘a poate fi chiar de doua sau de mai multe ori mai mare.
Totodat ˘a, diversitatea pe care o ofer ˘a din punct de vedere a libr ˘ariilor disponibile, poate fi de
asemenea s ,i un dezavantaj. Cu cât cres ,te complexitatea programului s ,i cu cât sunt folosite mai
multe libr ˘arii, cres ,te s ,ansa aparit ,iei problemelor de incompatibilitate între libr ˘ariile utilizate.
Acest lucru se întampl ˘a deoarece aceste libr ˘arii dezvoltate de c ˘atre comunitate pot avea la
rândul lor, la baz ˘a alte dependent ,e c˘atre alte libr ˘arii, de asemenea dezvoltate de comunitate.
6

Capitolul 2. Arhitectura sistemului
Acest dezavantaj poate face chiar inutilizabil ˘a aplicat ,ia în momentul în care se produce o astfel
de incopatibilitate.
În cadrul sistemului nostru am încercat s ˘a ment ,inem o dependent ,˘a minimal ˘a fat ,˘a de
libr˘ariile auxiliare date de comunitate. Cu alte cuvinte ne-am limitat la libr ˘ariile necesare exe-
cutate în mod corect de c ˘atre frameworkului Kivy, cât s ,i la libr ˘ariile necesare utiliz ˘arii sistemului
de navigat ,ie.
De asemenea, în urma test ˘arii aplicat ,iei, nu se simte vreo limitare c ˘atre utilizator a tim-
pului în care sistemul de infotainment prea s ,i prelucreaz ˘a un anumit eveniment.
7

3. Descrierea Aplicat ,iei
3.1. Designul aplicat ,iei
Din punct de vedere al designului aplicat ,iei, mai precis a cursivit ˘at,ii acesteia, voi încerca s ˘a
construiesc un automat finit de st ˘ari cât mai fidel modului de funct ,ionare. Pentru inceput, este
necesar sa definim ceea ce inseamna un automat finit de st ˘ari.
„Un automat finit (AF) sau o "mas ,in˘a cu un num ˘ar finit de st ˘ari" este un model de
comportament compus din st ˘ari, tranzit ,ii s ,i act ,iuni. O stare stocheaz ˘a informat ,ii
despre trecut, adic ˘a reflect ˘a schimb ˘arile intr ˘arii de la init ,ializarea sistemului pân ˘a
în momentul de fat ,˘a. O tranzit ,ie indic ˘a o schimbare de stare s ,i este descris ˘a de o
condit ,ie care este nevoie s ˘a fie îndeplinit ˘a pentru a declans ,a tranzit ,ia. O act ,iune este
o descriere a unei activit ˘at,i ce urmeaz ˘a a fi executat ˘a la un anumit moment.”
(Kam 1997; Villa 1997)
Astfel, vom nota fiecare meniu al aplicat ,iei drept o stare s ,i vom nota fiecare act ,iune a
utilizatorului drept o tranzit ,ie. De asemenea, fiecare act ,iune din interiorul unui ecran reprizint ˘a
s,i ea o stare noua (e.g selectarea unei melodii). În Figura 3.1 de mai jos, este reprezentat
automatul finit determinist.
Automatul pleac ˘a din starea init ,ial˘a când se apas ˘a butonul de START/STOP al mas ,inii.
Din acel punct, se intr ˘a în starea de "welcome" în care se st ˘a aproximativ 5 secunde, pân ˘a când
aplicat ,ia se încarc ˘a la 90%. Din acel moment, aplicat ,ia trece în starea nou ˘a de "Meniu principal".
De aici, utilizatorul poate s ˘a treac ˘a în mai multe st ˘ari (Harta, Muzica, Setari, Notite).
H˘ art ,i
utilizatorul poate ajunge în aceast ˘a stare dac ˘a apas ˘a din meniu butonul pentru H ˘art ,i. Din
noul ecran, se poate întoarce înapoi în vechia stare, "Meniul Principal" dac ˘a apas ˘a butonul
pentru "Acasa".
Muzic˘ a
la fel ca în restul de ecrane, pentru a ajunge în starea de "Muzic ˘a", utilizatorul trebuie
s˘a apase din meniul principal butonul de muzic ˘a. Ajuns în noua stare, acesta poate s ˘a se
întoarc ˘a înapoi în meniul principal. Din starea de "Muzic ˘a", daca se apas ˘a pe o melodie,
aceasta începe s ˘a cânte. Implicit se trece la o stare nou ˘a "Melodia cânt ˘a". Pentru a ne
întoarce înapoi la starea de "Muzic ˘a", utilizatorul trebuie s ˘a opreasc ˘a melodia curent ˘a.
Dac˘a apas ˘a o nou ˘a melodie, el r ˘amâne tot în starea de "Melodia cânt ˘a". Pentru aceast ˘a
stare, se poate seta volumul – mai încet sau mai tare – s ,i acest lucru conduce la alte dou ˘a
st˘ari: "Cânt ˘a mai tare" s ,i "Cânt ˘a mai încet".
Set˘ ari
înainte de a intra în set ˘arile sistemului, ca o protect ,ie pentru a nu intra în meniul de set ˘ari
din gres ,eal˘a – s ,i implicit s ˘a se modifice ceva, aplicat ,ia dispune de o fereastr ˘a intermediar ˘a
în care utilizatorul este îns ,tiint ,at. Astfel, dac ˘a se apas ˘a pe butonul de set ˘ari, automatul
trece de la starea de "Meniu principal" la "Avertizment" iar la înc ˘a un click, automatul
finit trece în starea de "Set ˘ari". Din meniul cu set ˘ari, atunci când alegem o setare s ˘a o
schimb ˘am se trece la o stare nou ˘a, special ˘a pentru aceast ˘a setare. Dupa ce s-a finalizat
setarea programul se întoarce în starea de "Set ˘ari". Fontul afis ,at, dimensiunea fontului,
8

Capitolul 3. Descrierea Aplicat ,iei
Figura 3.1.: St ˘arile aplicat ,iei
limba, proprietarul, sunt set ˘ari care se pot modifica s ,i care permit trecerea automatului
prin diferite st ˘ari s ,i înapoi in starea de "Setari".
Notit ,e
la fel ca s ,i la restul de set ˘ari, pentru a ajunge în starea aceasta trebuie ap ˘asat butonul
potrivit. În starea nou ˘a de "Notit ,e" sunt afis ,ate o list ˘a cu notit ,e salvate. Atunci când se
apasâ butonul pentru crearea unei noi notit ,e, automatul trece in starea de "Notit ,˘a nou˘a".
Daca se renunt ,˘a la notit ,˘a s ,i nu se salveaz ˘a, programul se întoarce înapoi în starea de notit ,e
afis ,ate. Dac ˘a se salveaz ˘a, acesta trece intr-o stare rapida nesemnificativa ochiului uman
unde se salveaza notita intr-un json cu toate notit ,ele. Totodat ˘a, din starea de "Notit ,e" se
poate selecta o notit ,˘a existent ˘a pentru a fi editat ˘a. Se intr ˘a astfel în starea de "Editare
notit ,˘a". La fel ca s ,i la salvarea unei notit ,e, dac ˘a aceasta se salveaz ˘a, se trece într-o stare
în care se salveaz ˘a notit ,a într-un json, altfel se întoarce la starea de "Notite".
Astfel, se poate observa c ˘a aplicat ,ia trece o singur ˘a dat˘a prin starea int ,ial˘a de "Welcome".
De asemenea, se poate observa c ˘a din orice sub-meniu se poate întoarce in starea "Meniu princi-
9

Capitolul 3. Descrierea Aplicat ,iei
pal". Din ecrane cu act ,iune specifice sub-meniului (e.g crearea/editarea unei notit ,e) nu se poate
întoarce direct în meniul principal. Pentru oprirea dispozitivului trebuie ca motorul s ˘a fie oprit
s,i el. Am urm ˘arit aceast ˘a grupare deoarece putem atinge funct ,ionalitate completa cu un num ˘ar
minim de evenimente.
10

4. Prezentarea si evolutia sistemelor
infotainment
4.1. Ce este un sistem infotainment
Infotainment este un termen care acoper ˘a o gam ˘a complet ˘a de tehnologie auto. Cuvântul „in-
fotainment” este o combinatie a „informat ,iei” s ,i „divertismentului”, care extrim ˘a cu exactitate
scopul unui sistem de infotainment. Pur s ,i simplu, un sistem de infotainment este un sistem de
bord conceput atât pentru a informa s ,i distra s ,oferul, cât s ,i pasagerii.
„De la „sistemele de navigat ,ie prin satelit” la sistemele avansate de asistent ,˘a a con-
duc˘atorilor auto, tehnologiile moderne asigur ˘a deja înregistrarea tuturor informat ,iilor
importante din autovehicul, furnizarea acestora c ˘atre conduc ˘atorul auto s ,i asocierea
lor cu serviciile de internet. Pentru conduc ˘atorul auto, acest lucru înseamn ˘a confort,
eficient ,˘a s ,i control sporit asupra mediului autovehiculului. Continental duce acest
lucru mai departe – prin conectivitatea sporit ˘a a componentelor individuale.”
Gapper (2015)
4.2. Ce reprezint˘ a sistemul de infotainment
„Sistemele moderne de gestionare de infotainment asigur ˘a mult mai multe decât simpla afis ,are
a informat ,iilor relevante despre autovehicul. Un dialog holistic dintre om s ,i mas ,in˘a asigur ˘a
un schimb simplu de informat ,ii între s ,ofer, autovehicul s ,i mediul exterior. Într-un univers
din ce în ce mai complex, gestionarea informat ,iilor în autovehicul este astfel simplificat ˘a s ,i
creeaz ˘a posibilit ˘at,i pentru noile funct ,ii ale autovehiculului, precum conducerea automatizat ˘a s ,i
integrarea optim ˘a a dispozitivelor mobile.” Gapper (2015)
4.3. Istorie
Un sistem infotainment îmbina partea software cu cea hardware pentru a furniza pasagerilor
atât informat ,ii despre mas ,in˘a (de exemplu: num ˘arul de km pân ˘a la urm ˘atorul schimb de ulei)
cât s ,i divertizment. ( The evolution of car infotainment systems 2020) În general, aceste sisteme
sunt interfet ,e audio s ,i video, au ecrane tactile s ,i tastaturi. Acest domeniu variaz ˘a foarte mult s ,i
difer˘a în funct ,ie de divers ,i factori, cum ar fi anul în care s-a produs, firma care produce mas ,ina,
modelul mas ,inii s ,i desigur echiparea acesteia. Prin urmare, sistemul ofer ˘a o gam ˘a variat ˘a de
funct ,ionalit ˘at,i utile care îmbun ˘at˘at,esc experient ,a pasagerilor in autovehicul.
4.3.1. Originea sistemului infotainment
Istoria sistemelor infotainment poate fi urm ˘arit˘a înc˘a din anii 1930 odata cu lansarea primului
raiou AM pentru mas ,ini. Radioul va devenii astfel sursa principal ˘a de divertizment în mas ,in˘a
pentru urm ˘atoarele dou ˘a decade. ( The evolution of car infotainment systems 2020)
11

Capitolul 4. Prezentarea si evolutia sistemelor infotainment
În anii 1940 radioul primes ,te o nou ˘a echipare care include butoane.
În anii 50, o companie din germania ofer ˘a primul radio AM/FM. Cu toate acestea, va mai
fi nevoie de înc ˘a cativa ani pentru a se putea face trecerea interpret ˘arii semnalului din modulat ,ie
în amplitudine la interpretarea semnalului prin modulat ,ia în frecvent ,a.
În anii 1960 a fost inclus modul stereo care utilizeaz ˘a doua canale radio în loc de una.
în 1970 au fost înlocuite cu casete compacte. Din acest punct al istoriei, sistemele de sunet au
început s ˘a prind ˘a popularitate s ,i s˘a fie dorite de c ˘atre conducatori.
În 1981 apare primul sistem de navigat ,ie care a fost introdus pe un model de Toyota. Zece
ani mai târziu apar CD-urile ca modalitate de redare a melodiilor mp3. Sfârs ,itul secolului a
adus majore schimb ˘ari. Mas ,inile cu sisteme infotainment au lovit puternic piat ,a. La începutul
anului 2000 apar ecranele touch screen cu GPS, muzic ˘a, posibilitatea de a te conecta bluetooth.
In 2007 apare controlul vocal, pentru prima dat ˘a pe Ford. Începând cu 2010, apare posibilitatea
de a te conecta la sistem prin intermediul WiFi-ului, compatibilitate cu Google, Apple, Android
Play s ,i interfat ,a sistemului devine din ce în ce mai modern ˘a si mai complex ˘a.
12

5. Prezentarea aplicat ,iei
5.1. Prezentarea mediilor de progamare folosite
În aceast ˘a sect ,iune vor fi prezentate limbajul de programare Python în care a fost scris ˘a aplicat ,ia
si libr ˘aria Kivy care a fost folosit ˘a pentru a facilita interfat ,a grafic ˘a a aplicat ,iei. Am ales s ˘a
folosesc acest limbaj de programare pentru c ˘a:
• este un limbaj independent de sistemul de operare
• acesta ofer ˘a o multitudine de pachete s ,i astfel pot folosi Kivy, care este o libr ˘arie Python
us,or de folosit, prietenoas ˘a s ,i de asemenea independent ˘a de sistemul de operare
• Kivy este constuit cu o grafic ˘a care are la baz ˘a OpenGL ES 2, utilizând o grafic ˘a rapid ˘a
si modern ˘a
5.1.1. Python
Am ales s ˘a scriu aplicat ,ia în limbajul de programare Python, care este un limbaj dinamic.
Motivul pentru care am ales acest program de programare este capabilitatea lui de a rula us ,or
indiferent de sistemul de operare. Cu ajutorul lui aplicat ,ia reus ,este s˘a se plimbe printre ferestre
s,i s˘a îs ,i indeplineasc ˘a sarcinile cu succes.
5.1.2. Kivy
În proiectarea aplicat ,iei am folosit libr ˘aria Kivy (Phillips (2014)) pentru a-mi facilita interfat ,a
grafic˘a de care avea nevoie aplicat ,ia. La fel ca si Python s ,i Kivy ruleaz ˘a independent de platforma
folosit ˘a, fiind foarte us ,or ca aplicat ,ia s˘a ruleze pe orice sistem de operare (e.g. Windows, Linux,
iOS, Raspberry Pi).
5.2. Prezentarea arhitecturii aplicat ,iei în ansamblu
În acest subcapitol voi explica cum este structurata aplicatia din punct de vedere software
bazat˘a pe libr ˘aria Kivy. În acest subcapitol vom întelege cum funct ,ioneaz ˘a totul împreun ˘a.
Acest˘a sect ,iune explic ˘a în detaliu modul de împlementare.
Libr˘aria Kivy este format ˘a din mai multe grup ˘ari de blocuri dup ˘a cum se poate observa
în figura Figura 5.1
Aplicat ,ia este format ˘a din cinci componente principale:
• Widget-uri si Layout-uri
• Limbajul kivy
• "Core providers"
• Grafic ˘a
• Intr ˘ari
13

Capitolul 5. Prezentarea aplicat ,iei
Figura 5.1.: Structura arhitecturii conform libr ˘ariei Kivy Kivy architecture 2014
5.2.1. Core
Acest pachet cont ,ine cele mai utilizate funct ,ii. Astfel câteva dintre funct ,ionalit ˘at,ile din core pe
care aplicat ,ia le foloseste sunt:
• Clock: funct ,ionalitatea de ceas este utilizat ˘a în cadrul aplicat ,iei pentru a contoriza ora
curent ˘a s ,i a o afis ,a în aplicat ,ie.
• Cache-ul: este utilizat la fel ca în cadrul unui aplicat ,ii web pentru a stoca anumite
informat ,ii, cum ar fi numele utilizatorului.
• Limbajul Kivy: este utilizat pentru a descrie interfat ,a us ,or s ,i eficient. În cadrul aplicat ,iei,
fiecare fis ,ier python va avea asociat un fis ,ier kivy pentru a-i oferi grafic ˘a.
• Window
5.2.2. Core providers
Framework-ul vine în ajutorul utilizatorului s ,i aduce o serie de libr ˘arii, încercând s ˘a us ,ureze
munca programatorului. La acest nivel se g ˘asesc afis ,area de imagini s ,i text, redarea video
s,i audio. Aceste fuct ,ionalit ˘at,i devin utile aplicat ,iei pentru interfat ,a de redare a melodiilor
audio/video s ,i radio.
5.2.3. Grafic˘ a
Deoarece libr ˘aria este una cross-platform, compatibil ˘a cu orice sistem de operare, la baz ˘a, pentru
a putea avea o grafic ˘a modern ˘a, Kivy utilizeaz ˘a OpenGL 2.0 ES care la rândul lui este un limbaj
14

Capitolul 5. Prezentarea aplicat ,iei
independent de sistemul de operare. Acesta devine util deoarece proiectul are nevoie de grafic ˘a.
Conduc ˘atorul auto are nevoie de o interfat ,˘a prietenoas ˘a, us ,or de înt ,eles si de înv ˘at,at.
•Vertex Buffer : Un VBO cont ,ine date efective despre un obiect: pozit ,ie, culoare, normal ˘a
– s,i transmite un pachet mai mare de date c ˘atre placa grafica; în timp ce un VAO defines ,te
ce atribute au vertecs ,ii utilizati s ,i totodat ˘a permite interpretarea mai multor obiecte VBO
în acelas ,i timp. În figura Figura 5.2 sunt evident ,iate atributele vertecs ,ilor. În exemplul
acesta, primul VBO este pentru pozit ,ie iar al doilea pentru culoare.
•Texturi : O textura reprezint ˘a o imagine 2D utilizat ˘a pentru a ad ˘auga detalii unui obiect.
Ne putem imagina c ˘a o textur ˘a reprezint ˘a un ambalaj care vine s ,i îmbrac ˘a perfect un
cadou.
•Shader : sunt programe simple care descriu anumite tr ˘as˘aturi pentru vertecs ,i sau pixeli.
Un vertex shader descrie anumite caracteristici ale unui vertex (e.g culoare, pozit ,ie, textur ˘a
etc.) În principiu, un shader este un program care transform ˘a o intrare într-o ies ,ire.
Shaderele nu pot comunica între ele decât prin intr ˘arile s ,i ies ,irele lor.
•GLEW : este o libr ˘arie scris ˘a in C++ independent ˘a de sistemul de operare, care ajut ˘a
la înc˘arcarea extensiilor de OpenGL. Libr ˘aria GLEW determin ˘a într-un timp eficient ce
extensii de OpenGL sunt acceptate de sistemul de operare pe care ruleaz ˘a.
Figura 5.2.: Specificarea atributelor vertecsilor (Chenaru 2020)
5.2.4. Intr˘ ari
Acelas ,i concept s-a urm ˘arit s ,i pentru interact ,iunea utilizatorului cu dispozitivul. În aceasta
categorie intr ˘a de exemplu gesturile conduc ˘atorului auto pe care le face pe ecranul dispozitivului.
Glisarea meniului de la stânga la dreapta s ,i de la dreapta la stânga sau apasarea pe un meniu
sunt act ,iuni care intr ˘a în categoria aceasta s ,i pentru care libr ˘aria ofer ˘a suport.
Astfel, o act ,iune de intrare, în spate practic este o bucat ˘a de cod care ofer ˘a suport pentru
o specific ˘a act ,iune. De exemplu, ap ˘asarea unui buton de c ˘atre conduc ˘atorul automobilului. De
altfel, framework-ul ofer ˘a accesibilitate pentru suprascrierea acestor clase sau ad ˘augarea unor
noi tipuri de intr ˘ari.
15

Capitolul 5. Prezentarea aplicat ,iei
5.2.5. Widgets Layouts
Modulul UIX cont ,ine cele mai comune s ,i utilizate widget-uri si layout-uri care permite utilizarea
s,i crearea rapid ˘a de interfet ,e interactive s ,i atractive pentru utilizator.
• Widgets: sunt elemente de interfat ,˘a care se pot ad ˘auga în program oferind astfel funct ,ionalitate.
Astea se pot folosi în cod impreun ˘a cu implement ˘arile din python sau separat într-un fis ,ier
scris special în limbajul kivy. Widget-urile îmi sunt folositoare pentru ad ˘augarea butoa-
nelor de navigare, de ies ,ire sau cele de interact ,ionare cu conduc ˘atorul autovehiculului s ,i
pasagerii.
• Layouts: sunt folosite pentru a aranja widget-urile. Acestea pot fi privite ca un array care
primes ,te în coad ˘a câte un nou widget. Devine util pentru stocarea s ,i gruparea butoanelor
pentru submeniuri.
De preferat, aceste componente sunt ad ˘augate separat într-un fis ,ier .kv.
5.2.6. Events and Properties
Figura 5.3 ilustreaz ˘a cum evenimentele din cadrul aplicat ,iei sunt gestionate de c ˘atre framework-
ul în care am ales s ˘a lucrez.
Figura 5.3.: Thread ( Events and Properties 2014)
5.2.7. Lib˘ arii auxiliare folosite
În cadrul proiectului am folosit câteva libr ˘arii auxiliare care mi-au permis realizarea proiectului.
pip este o comanda cu ajutorul c ˘areia se pot instala pachete în Python de aceea este necesar ˘a
cea mai noua versiune de pip
wheel
creaz˘a o arhiv ˘a pentru proiectul s ,i dependent ,ele acestuia. Ofer ˘a avantajul de a nu mai
compila software-ul la fiecare instalare.
16

Capitolul 5. Prezentarea aplicat ,iei
setuptools
este o libr ˘arie care ofer ˘a posibilitatea de a împacheta proiectul. Pachetul include detalii
despre platform ˘a, suport pentru Python 3, teste si modulele proiectului.
virtualenv
este o libr ˘arie care creaz ˘a un mediu izolat care îmi permite s ˘a rulez aplicat ,ia. Instalarea
acestuia se face cu comanda
python -m virtualenv kivy_venv
rulat˘a în r˘adacina proiectului. De fiecare dat ˘a când dorim s ˘a rul˘am aplicat ,ia trebuie mai
întâi s ˘a pornim environmentul cu comanda de Windows
kivy_venv\Scripts\activate
sau pentru linux:
source kivy_venv/Scripts/activate
pygments
este o libr ˘are care ofer ˘a posibilitatea de introducere s ,i evident ,ia cod surs ˘a sau alte formate
(e.g text îngros ,at sau înclinat) în aplicat ,ie
kivy_deps
libr˘arie din care am instalat modulele necesare pentru partea grafic ˘a:
• kivy-deps.angle
• kivy-deps.glew
• kivy-deps.gstreamer
• kivy-deps.sdl2
Kivygarden
este libr ˘arie care centralizeaz ˘a libr˘arii create de utilizatorii Kivy.
mapview
este un modul creat de dezvolvatorii de aplicat ,ii Kivy, face parte din libr ˘aria Kivy-Garden
s,i este utilzat pentru crearea de h ˘art ,i. Aceast ˘a libr˘arie vine ca un înlocuitor pentru Google
Maps.
5.3. Descrierea fiecarui submeniu al app
În aceast ˘a sect ,iune voi trece prin fiecare meniu al aplicat ,iei s ,i voi descrie pe scurt cum poate
utilizatorul s ˘a se mis ,te printre ferestre, ce poate face în ecranul respectiv s ,i cum îi este util.
5.3.1. Înc˘ arcarea aplicat ,iei
Atunci c ˘and conduc ˘atorul autovehicului pornes ,te mas ,ina, sistemul pornes ,te automat s ,i el. În
faza int ,ial˘a, sistemul are nevoie de câteva secunde de înc ˘arcare. În figura Figura 5.4 se poate
observa cum aplicat ,ia se încarc ˘a, iar când ajunge la un procent de 90% se deschide meniul
principal. Am optat pentru un ecran de înc ˘arcare deoarece toate sistemele de infotainment sau
toate aplicat ,iile pe android create pentru a înlocui un sistem învechit sau inexistent au o scurt ˘a
durat˘a de înc ˘arcare a sistemului. De asemenea am considerat c ˘a trecerea de la start la meniul
principal ar fi prea brusc ˘a.
17

Capitolul 5. Prezentarea aplicat ,iei
Figura 5.4.: St ˘arile aplicat ,iei
5.3.2. Meniul principal
Dup˘a ce s-a simulat înc ˘arcarea aplicat ,iei, pagina de înc ˘arcare redirect ,ioneaz ˘a c˘atre meniul prin-
cipal unde sunt listate submeniurile sistemului.
În figura Figura 5.5 se poate observa meniul afis ,at în limba Român ˘a. Din meniul principal,
Figura 5.5.: Meniul principal al aplicat ,iei
utilizatorul se poate plimba prin diverse submeniuri:
• H˘art ,i
• Muzic ˘a: poate reda fis ,iere media. Se poate seta un volumn mai încet sau mai tare în
funct ,ie de preferint ,˘a. Se poate opri melodia activ ˘a daca acesta nu mai doreste s ˘a asculte
muzic ˘a.
• Set ˘ari: se poate selecta limba dorit ˘a în aplicat ,ie: Româna/Englez ˘a; se poate modifica
numele utilizatorului care det ,ine autovehiculul; dimensiunea fontului cu care sunt afis ,ate
meniurile.
18

Capitolul 5. Prezentarea aplicat ,iei
• Notit ,e: exist ˘a posibilitatea de a crea o noua notit ,˘a; de a edita una daca dorim s ˘a ii
modific ˘am titlul sau cont ,inutul; de a s ,terge notit ,ele pe care nu le mai dorim.
Meniul se poate glisa la stânga sau la dreapta cu un efect de scroll pe orizontal ˘a. Pentru a
ajunge în alt meniu, acesta trebuie doar sa selecteze unul dintre ele. I se va deschide o fereastr ˘a
noua iar dac ˘a dores ,te s˘a revin ˘a înapoi în meniul principal, trebuie doar s ˘a apese butonul pentru
"Acasa".
Mai jos voi vorbi pe scurt despre fiecare meniu în parte s ,i vor explica cum poate un
utilizator s ˘a se plimbe prin meniuri s ,i ce poate face util în ele, urmând ca în capitolul 6 s ˘a
descriu detaliat modul în care au fost implementate toate aceste ferestre.
5.3.3. Muzic˘ a
Figura 5.6.: Ecranul de muzic ˘a
La fel ca orice sistem de infotainment, aplicat ,ia are un meniu pentru muzic ˘a. De aici,
utilizatorul îs ,i poate alege melodiile pe care dores ,te s˘a le asculte în timpul condusului. Ecranul
simuleaz ˘a înc˘arcarea melodiilor de pe un stick USB/CD/DVD. La pornirea melodiei, aceasta
are un volum prestabilit îns ˘a conduc ˘atorul is ,i poate seta volumul dup ˘a bunul plac. Setarea
volumului a fost pus ˘a în partea stâng ˘a pentru a fi aproape de conduc ˘ator s ,i astfel s ˘a nu îi fure
prea mult atent ,ia de la trafic.
Melodia selectat ˘a pornes ,te la o simpl ˘a ap˘asare pe aceasta. Dac ˘a o melodie era deja
pornit ˘a, aceasta se va opri s ,i abia dup ˘a va porni noua melodie. Butonul de Stop are ca scop
oprirea melodiei care este activ ˘a, far˘a a mai activa alta melodie.
5.3.4. Set˘ ari
Figura Figura 5.7 afis ,eaz˘a lista de set ˘ari pus ˘a la dispozit ,ie de c ˘atre aplicat ,ie. În starea init ,ial˘a,
set˘arile au valori predefinite (e.g aplicat ,ia este salvat ˘a s˘a afis ,eze meniurile s ,i stringurile în limba
Român ˘a, însa aceasta poate fi schimbat ˘a din set ˘ari în limba Englez ˘a daca dores ,te utilizatorul).
19

Capitolul 5. Prezentarea aplicat ,iei
Figura 5.7.: Ecranul de set ˘ari
Numele proprietarului de asemenea poate fi modificat dintr-un nume standard într-un nume
personalizat.
Scopul acestor set ˘ari este de a oferi utilizatorului posibilitatea de a modifica aspectul
interfet ,ei dup ˘a bunul plac. Modul cum aceste set ˘ari modific ˘a aplicat ,ia o voi explica în capitolul
5. Pe scurt, frameworul are set ˘arile lui predefinite s ,i cu ajutorul lor îmi va permite s ˘a creez
o clasa care s ˘a mos ,teneasc ˘a acele set ˘ari. Pe modelul în care au fost construite acele set ˘ari am
construit s ,i eu propriile set ˘ari. Totul se salveaz ˘a într-un fis ,ier .ini care se actualizeaz ˘a de fiecare
dat˘a cand se va modifica setarea respectiv ˘a. Acest fis ,ier are la baz ˘a un format JSON care
permite o c ˘autare rapid ˘a s ,i eficient ˘a dupa anumite criterii.
5.3.5. Notit ,e
Figura Figura 5.8 ilustreaz ˘a ecranul unde sunt afis ,ate toate notit ,ele. Utilizatorul poate crea/edita
o notit ,˘a as ,a cum se poate observa s ,i în figura Figura 5.9. Dac ˘a se apas ˘a pe butonul ’X’ notit ,a
va fi s ,tears˘a dac˘a era deja salvat ˘a, respectiv nu se va salva dac ˘a aceasta este nou ˘a.
Figura 5.8.: Ecranul de notit ,e
În figura Figura 5.8 se poate observa doar o notit ,˘a salvat ˘a dar, datorit ˘a modului în care
a fost implementat algoritmul s ,i mos ,tenirea adecvat ˘a a unor clase de baz ˘a ne va permite s ˘a
20

Capitolul 5. Prezentarea aplicat ,iei
afis ,˘am s ,i s˘a stoc ˘am un volum foarte mare de date. Aceste notit ,e sunt memorate într-un JSON
s,i de unde sunt extrase foarte us ,or dupa id-ul lor unic. Mai multe informat ,ii despre modul de
implementare a acestor ferestre vor fi explicate în capitorul 6.
Figura 5.9.: Creare/Editare notit ,˘a
5.3.6. Hart˘ a
Pe sistemele de infotainment actuale exist ˘a navigat ,ie care ît ,i permite s ˘a alegi un punct unde
vrei s˘a ajungi s ,i s˘a it ,i calculeze cel mai optim traseu. În aceast ˘a lucrare am încercat s ˘a integrez
s,i un ecran pentru navigat ,ie. Aceasta urmeaz ˘a a fi impun ˘at˘at,it,˘a. Voi vorbi despre acest aspect
în subcapitolul 6.2
21

Capitolul 5. Prezentarea aplicat ,iei
Figura 5.10.: Harta
22

6. Proiectarea aplicat ,iei
Acest capitol va cuprinde informat ,ii despre cum a fost proiectat ˘a aplicat ,ia al˘aturi de mici
buc˘at,i de cod. Voi explica pe rând fiecare submeniu, leg ˘aturile dintre acestea s ,i modul în
care interact ,ioneaz ˘a un ecran cu cel ˘alalt.
Figura 6.1.: Codul pentru înc ˘arcarea aplicat ,iei
Welcome
Fereastra este una simpl ˘a, scopul el fiind doar de a încânta vizual participant ,ii mas ,inii cât
timp sistemul se înc ˘arca. Astfel, pagina a fost realizat ˘a cu us ,urint ,˘a doar cu un fis ,ier scris
în limbajul Kivy.
As ,a cum am specificat s ,i în capitolul precedent, widget-urile sunt elemente de interfat ,˘a s ,i
pot fi folosite atât într-un fis ,ier scris în Python cât s ,i direct într-un fisier Kivy. Astfel,
pentru aceast ˘a fereastr ˘a am optat doar pentru folosirea unui fis ,ier Kivy în care am realizat
o interfat ,˘a pl˘acut˘a pentru utilizator.
23

Capitolul 6. Proiectarea aplicat ,iei
Am utilizat modului:
import Window kivy.core.window.Window
care este o clas ˘a din Core s ,i care este utilizat ˘a pentru a crea o fereastr ˘a nou ˘a in Kivy.
Kivy suport ˘a doar o singur ˘a fereastr ˘a pentru aplicat ,ie astfel încât am ales s ˘a o folosesc in
fereastra de deschidere.
În Figura 6.2 am încercat s ˘a ilustrez modul în care fac înc ˘arcarea ecranului procentual în
funct ,ie de timp, iar atunci când trece de pragul de 90% s ˘a treac ˘a la ecranul cu meniul
principal.
Figura 6.2.: Codul pentru înc ˘arcarea aplicat ,iei
Meniul principal
As ,a cum am precizat în sect ,iunea precedent ˘a, în sub-capitolul 5.2.5, widget-urile sunt
folosite pentru interfat ,˘a, oferind funct ,ionalitate programului. Deoarece am un meniu cu
mai multe iteme, fiecare reprezentând câte un obiect de tip Widget, am nevoie ca ele s ˘a fie
grupate împreun ˘a. Astfel, am folosit opt ,iunea de Layout pentru a le grupa într-un obiect
p˘arinte.
Obiectele de tip Widget/Layout se pot instant ,ia în fis ,iere python la fel ca orice tip de
obiect creat pe baza unei clase proprii. Mai jos se poate observa un exemplu de obiect de
tip Button care ar putea fi instant ,iat în codul surs ˘a.
button = Button(text=’Hello world’, font_size=14)
Deoarece framework-ul vine cu propriul lui limbaj, am ales ca tot ce t ,ine de interfat ,˘a s˘a fie
introdus în fisiere .ky deoarece astfel aplicat ,ia este mult mai ordonat ˘a, curat ˘a s ,i respect ˘a
condit ,ii standard.
Submeniurile sunt memorate într-un list ˘a. Aceast ˘a list˘a cu submeniuri devine util ˘a atunci
când dorim s ˘a trecem rapid din meniul curant în urm ˘atorul. De asemenea aceast ˘a list˘a
este folosit ˘a la apelarea functiei
load_screen(self, index)
Aceast ˘a funct ,ie primes ,te ca parametrii selfcare este o referint ,˘a c˘atre obiectul curent, iar
index reprezint ˘a id-ul ecranului. Scopul funct ,iei ei este acela de a înc ˘arca fis ,ierul kivy
aferent ecranului s ,i o voi folosi doar în interiorul funct ,iei
24

Capitolul 6. Proiectarea aplicat ,iei
Figura 6.3.: Fragment din cod pentru a exemplifica un Layout cont ,inând mai multe obiecte de
tip Button
go_screen(self, idx)
Ca s ,i exemplu de utilizare a aceste funct ,ii, ne putem imagina ca în cadrul automatului
finit determinist din Figura 3.1 utilizatorul se afl ˘a în starea "Meniu principal" s ,i dores ,te
s˘a treac ˘a în starea "Audio". Astfel, funct ,iago_screen() realizeaz ˘a aceast ˘a trecere.
Funct ,iaswitch_to(screen, **options) apelat ˘a în cadrul funct ,ieigo_screen() face ca
glisarea între ecrane s ˘a se realizeze cu o anumit ˘a orientare (e.g la stânga).
Muzic˘ a
Din folderul data/audio sunt preluate toate fis ,ierele audio în format .mp3 s ,i ad˘augate într-
un obiect de tip AudioButton . Fiecare obiect de acest tip se adaug ˘a într-un obiect p ˘arinte
de tip Button despre care am vorbit în capitolul 5.2.5. Clasa AudioButton primes ,te ca
parametrou un obiect de tip Button . Aceast ˘a clas˘a are trei funct ,ii:
• on_press(self)
• release_audio(self)
• set_volume(self, volume)
Prima funct ,ie se apeleaz ˘a în momentul în care utilizatorul apas ˘a pe o melodie. Aceast ˘a
funct ,ie va primi ca si parametru un obiectul selfcare are un obiect sound de tipul Sound-
Loader . SoundLoader va înc ˘arca melodia pe baza unui string cu numele melodiei, preluat
din calea /data/audio . Variabila sound.statul stocheaz ˘a starea curent ˘a a melodiei, adic ˘a,
dac˘a aceasta nu are valoarea stop, înseamn ˘a c˘a melodia selectat ˘a era activ ˘a s ,i cânta. În
momentul respectiv o va reporni.
Funct ,iarelease_audio(self) are ca scop oprirea melodiei curente s ,i eliberarea memoriei.
ClasaAudioBackground(BoxLayout) este o clas ˘a goal ˘a utilizat ˘a doar pentru a modela
aspectul grafic din fis ,ierul .kv.
25

Capitolul 6. Proiectarea aplicat ,iei
Clasa principal ˘aAudioApp are s ,i ea 4 funct ,ii importante:
• build(self)
• release_audio(self)
• set_volume(self, value)
• get_settings(self)
Funct ,iabuild care este prezent ˘a în orice clas ˘a creaz ˘a o variabil ˘arootcare o instant ,iaz˘a
de tipul AudioBackground . AudioBackground, as ,a cum am specificat, este o clas ˘a f˘ar˘a
variabile sau funct ,ii definite. Scopul ei este de a oferi un stylind adecvat ecranului. Cu
ajutorul comezii
glob(join(dirname(__file__), ’data’, ’audio’, ’format_fisier’)
voi prelua de pe ruta /data/audio toate fisiere cu un anumit format, le voi crea de tipul
claseiAudioButton s,i le voi memora într-o list ˘a cu butoane.
As ,a cum se poate observa în Figura 5.6, utilizatorul are posibilitatea modific ˘arii volumului.
În faza init ,ial˘a, volumul este setat pe maxim. Ultima funct ,ie,set_volume(self, volume)
primes ,te la al doilea parametru o variabil ˘a de tipul NumericProperty . NumericProperty
primes ,te o variabil ˘a de tip float. Valorile acceptate se afl ˘a în intervalul [0, 1.0], unde 1
reprezint ˘a valoarea maxim ˘a a sunetului. Primul parametru primit de funct ,ie este obiectul
self. Variabila lui self.sound va primi noua valoare a volumului.
Funct ,iileset_volume(self, value) s,iget_settings(self) nu fac decât s ˘a caute melodia
s,i s˘a apeleze funct ,iile cu aceeas ,i declarat ,ie din clasa AudioButton .
Ultima funct ,ie,get_settings(self) este folosit ˘a pentru actualizarea aplicat ,iei în funct ,ie
de set ˘arile salvate. Aceast ˘a funct ,ie va fi explicat ˘a mai jos la descrierea ecranului de set ˘ari.
Pentru partea de interfat ,˘a, am creat un fis ,ier Kivy în care am stilizat clasele AudioBac-
kground s,iAudioButton . Mai jos se poate observa codul pentut clasa AudioButton:
size_hint: None,0.333
width: self.height
text_size: self.size
font_size: ’18sp’
valign: ’middle’
font_name: ’data/fonts/merge_light.otf’
background_color: (0.1, 0.3, 0.4, 0.5)
on_press: app.release_audio()
Aici, de exemplu, am pus dimensiunile de lungime si adâncime pentru chenarul în care se
afis ,eaz˘a melodia. Am stabilit un font, o m ˘arime a textului, culoarea de fundal a chenarului.
Comanda on_press: app.release audio()apeleaz ˘afunct,iarelease_audio() careafostexplicat ˘amaisus.
Tot în acest fis ,ier am ad ˘augat s ,i butoanele de "Stop" s ,i "Acasa" din dorint ,a de a simplifica
codul python. Practic, în fis ,ierul Python am introdus doar implementarea funct ,iilor.
Pentru clasa AudioBackground am ad ˘augat un BoxLayout as,ezat în partea de sus a
ecranului s ,i în care am ad ˘augat bara specific ˘a care afis ,eaz˘a numele proprietarului, logoul
mas ,inii s ,i butonul care redirect ,ioneaz ˘a c˘atre meniul principal. Tot la acelas ,i nivel cu
BoxLayout am ad ˘augat s ,i unLabel care afis ,eaz˘a titlul paginii s ,i un buton pentru oprirea
melodiei active. Pentru realizarea sliderului de volum, am chemat un bloc de tip Slider
care la modificarea cursorului întoarce o valoare între 0 s ,i 1.
26

Capitolul 6. Proiectarea aplicat ,iei
Set˘ ari
Pentru a sporii interact ,iunea sistemului cu utilizatorul, pagina de set ˘ari ofer ˘a posibilitatea
conduc ˘atorului de a-s ,i personaliza aplicat ,ia. În mod implicit, aplicat ,ia vine cu set ˘ari
prestabilite care sunt salvate într-un fis ,ier.ini.
În figura Figura 6.4 am ilustrat structura fis ,ierului în care sunt salvate set ˘arile. Acest fis ,ier
este citit de c ˘atre program s ,i în funct ,ie de acestea încarc ˘a de exemplu programul în limba
salvat ˘a. De asemenea, acest fis ,ier, în funct ,ie de setarea pe care dores ,te utilizatorul s ˘a o
modifice, suprascrie valoarea id-ului corespunz ˘ator.
În figura Figura 5.7 se poate observa lista cu opt ,iunile pe care utilizatorul le poate modifica.
Figura 6.4.: Exemplu fis ,ier.inipentru memorarea set ˘arilor
Pentru început, funct ,iile create pentru clasa de set ˘ari sunt urm ˘atoarele:
• __init__(self, **kwargs)
• build_config(self, config)
• build_settings(self, settings)
• on_config_change(self, config, section, key, value)
• close_settings(self, settings=None)
• get_settings(self)
Totodat ˘a, pentru a putea crea un fis ,ier cu set ˘ari, am creat s ,i clasa
MySettingsWithTabbedPanel(SettingsWithTabbedPanel)
care a chemat implicit s ,i set˘arile framework-ului. În proiect, nu voi avea nevoie de set ˘arile
predefinite din trei motive: utilizatorul nu are nevoie de ele, pot fi confuze s ,i se pot modifica
set˘ari importante care se doresc a r ˘amâne nemodificate. Pentru a ascunde set ˘arile init ,iale,
am introdus linia urm ˘atoare în cod:
self.settings_cls = MySettingsWithTabbedPanel
Clasa principal ˘a,MySettings apeleaz ˘a în prim ˘a instant ,˘a funct ,ia
27

Capitolul 6. Proiectarea aplicat ,iei
__init__(self, **kwargs):
super(MySettings, self).__init__(**kwargs)
Cuvântul cheie super este utilizat în general într-o metod ˘a dintr-o subclas ˘a pentru a chema
metoda definit ˘a în clasa super. Cu alte cuvinte, acest cuvânt cheie chem ˘a în metoda mea,
metoda "mam ˘a" din clasa init ,ial˘a pentru set ˘ari. Tot în aceast ˘a funct ,ie am introdus si
comanda care dezactiveaz ˘a afis ,area set ˘arilor init ,iale.
În acest moment, obiectul selfprimes ,te toate variabilele si funct ,iile din clasa p ˘arinte. În
funct ,iabuild va apela funct ,iaget_settings() care îi va returna set ˘arile aferente.
Întâi de toate trebuie specificat modul în care am construit propriile set ˘ari. Într-un fis ,ier
.jsonam introdus set ˘arile într-un format ca cel de mai jos:
"tip": "string/numerit/options",
"titlu": "",
"descriere": "",
"sectiune": "",
"id": ""
Cu ajutorul unei funct ,iiget(sectiune, id) am preluat din json datele în funct ,ie de id-ul
acestora s ,i sectiunea din care face parte.
Funct ,iabuild_config(self, config) se apleaz ˘a o singur ˘a dat˘a, la instalarea aplicat ,iei s ,i
creaz˘a un fis ,ier cu valori predefinite. Valorile se salveaz ˘a prin aplerea funct ,ieisetdefa-
ults(sectiune, id) .
Urm˘atoarea metod ˘a folosit ˘a:
build_settings(self, settings)
este chemat ˘a când utilizatorul vrea s ˘a vad˘a set˘arile alicat ,iei. În Figura 5.7 este descris ˘a
aceast ˘a fereastr ˘a. Cu ajutorul aceste funct ,ii am ad ˘augat propiriul meu tab cu set ˘ari. Acest
tab în mod normal apare lâng ˘a tabul cu set ˘arile framework-ului. As ,a cum am precizat
s,i mai sus, set ˘arile predefinite vor fi ascunse din motivele precizate. Comanda de mai jos
adaug ˘a tabul cu titlul "Background settings" s ,i fis ,ierul json creat:
settings.add_json_panel(’Background settings’,
self.config, data=json)
Metoda on_config_change(self, config, section, key, value) , care este o suprascriere
a funct ,iei din clasa super, are rolul de a actualiza configurat ,ia atunci când a fost modificat ˘a
de c˘atre utilizator. Variabila keyreprezint ˘a id-ul unic introdus în JSON, cu ajutorul acestei
valori se caut ˘a valoarea ce vrea a fi modificat ˘a s ,i se va suprascrie valoarea potrivit ˘a din
selfcu parametroul value.
Ultima funct ,ie,close_settings(self, settings=None) are ca s ,i scop închiderea panoului
de set ˘ari. Panoul se închide prin apelarea funct ,ieiclose_settings() din clasa super pe
care o chem cu indicatorul super:
super(MySettings, self).close_settings(settings)
28

Capitolul 6. Proiectarea aplicat ,iei
Dar, pe acelas ,i principiu funct ,ioneaz ˘a s ,i deschiderea ecranului de set ˘ari. Deoarece obiectul
nostru selfa primit de la clasa parinte toate metodele, pentru deschiderea ferestrei este
suficient s ˘a chem ˘am în kivy metoda open_settings() .
Orice modificare f ˘acut˘a în panou este automat salvat ˘a într-un fisierul configurabil. Tre-
buie ment ,ionat c ˘a înainte de a se deschide lista cu set ˘arile care pot modifica aplicat ,ia,
utilizatorul este îns ,tiint ,at s ,i avertizat c ˘a dac˘a continu ˘a, motific ˘arile pe care le va face se
vor putea observa în toat ˘a aplicat ,ia.
Pentru partea de design, am introdus un BoxLayout care randeaz ˘a widget-uri pe orizon-
tal˘a sau vertical ˘a. BoxLayout-ul principal randeaz ˘a cont ,inutul pe vertical ˘a s ,i cont ,ine un
buton care la ap ˘asare deschide fereastra cu set ˘ari cu ajutorul comenzii app.open_settings() .
Acesta mai cont ,ine înc ˘a grupare de Layout-uri care afis ,eaz˘a bara în care se afl ˘a sigla, nu-
mele utilizatorului s ,i butonul care te întoarce înapoi în meniul principal.
Mai jos voi încerca s ˘a explic cum restul programului interact ,ioneaz ˘a cu aceste set ˘ari.
Figura 6.5 ilustreaz ˘a funct ,ia cu ajutorul careia sunt preluate modific ˘arile.
Figura 6.5.: Funct ,ia care prea din fis ,ierul .ini informat ,iile salvate din set ˘ari
As ,a cum am precizat mai sus, la fiecare setare modificat ˘a (e.g limba sistemului) fis ,ierul .ini
se actualizeaz ˘a pentru setarea potrivit ˘a. De exemplu, dac ˘a ne uit ˘am în figura Figura 6.4
s,i ne imagin ˘am c˘a am modificat limba din Englez ˘a în Român ˘a, singura linie care se va
modifica va fi a 7-a. La actualizarea fis ,ierului, programul caut ˘a dupa categoria în care se
afl˘a setarea (e.g Language) s ,i apoi dup ˘a id-ul set ˘arii care este unic pe categorie.
Revenind la funct ,ia noastr ˘aget_settings(self) , în prim ˘a instant ,˘a se va realiza comanda
read_config = configparser.ConfigParser()
read_config.read("mysettings.ini")
Cu ajutorul primei linii se creaz ˘a un obiect de tip ConfigParser care va putea c ˘auta
fis,ierulmysettings.ini s,i din care va putea prelua informat ,iile. Acesta s ,tie s˘a citeasc ˘a
fis,iere în format .ini s ,i ne va permite s ˘a cautam informat ,ii în fis ,ier direct dup ˘a gruparea
din care face parte s ,i id-ul set ˘arii. Dup ˘a ce am preluat informat ,iile de care am nevoie, le
voi memora într-o variabila settings care face parte din instant ,aself. Aceste variabile vor
putea fi apelate apoi în fis ,ierele .kv ale ecranelor.
Pentru traducerea cont ,inutului, am creat funct ,iaget_translations(self, language) care
as,a cum este ilustrat s ,i în Figura 6.6, verific ˘a init ,ial care este limba g ˘asit˘a în fis ,ierul
mySettings.ini . Init ,ial vectorul este memorat în Limba Român ˘a. Daca noua limb ˘a
selectat ˘a este Engleza, se vor extrage traducerile din fis ,ier în aceeasi manier ˘a ca s ,i la
cel˘alalt fis ,ier. Structura fis ,ierului cu traduceri se poate observa în Figura 6.7. Se poate
observa cum s-a p ˘astrat aceeasi structur ˘a ca la fis ,ierulmySettings.ini
29

Capitolul 6. Proiectarea aplicat ,iei
Figura 6.6.: Funct ,ia care prea din dintr-un fis ,ier .ini traducerile pentru fiecare text
Figura 6.7.: Fis ,ierul .ini cu traducerile
Notit ,e
As ,a cum am ilustrat în Figura 5.8 s ,i în Figura 5.9, pagina de notit ,e devine util ˘a atunci
când conduc ˘atorul sau pasagerii autovehicului doresc s ˘a salveze o informat ,ie important ˘a
care le va fi util ˘a în viitor.
La apelul funct ,iei principale NoteApp , în metoda build() se apeleaz ˘a clasa Notes care
returneaz ˘a trei valori:
• note_index – care reprezint ˘a id-ul notit ,ei cu ajutorul c ˘aruia va putea fi recunoscut
• note_content – reprezint ˘a cont ,inutul notit ,ei ce urmeaz ˘a a fi chemat ˘a
• note_title – reprezint ˘a titlul notit ,ei
Clasa principala – NoteApp – are urm ˘atoarele metode:
• get_settings(self) – aceast ˘a fuct ,ie va fi prezentat ˘a în sect ,iunea în care vorbesc despre
set˘ari
• load_notes(self)
• save_notes(self)
• del_note(self, note_index)
• edit_note(self, note_index)
• add_note(self)
• set_note_content(self, note_index, note_content)
• set_note_title(self, note_index, note_title)
• refresh_notes(self)
• go_notes(self)
• notes_fn(self)
Dup˘a ce am înc ˘arcat toate notit ,ele deja existente în sistem, în variabile notes din ca-
drul obiectului self, am apelat funct ,iaload_notes() . Aici, întâi de toate, se va apela
proprietarea:
notes_fn(self)
30

Capitolul 6. Proiectarea aplicat ,iei
care va cauta în directorul potrivit dac ˘a exist ˘a JSON-ul cu notit ,e. Codul de mai jos
ilustreaz ˘a cele spuse:
join(self.user_data_dir, ’notes.json’)
Dac˘a fis ,ierul exist ˘a, se vor înc ˘arca notit ,ele cu ajutorul funct ,iilor existente pentru fis ,ierele
de tip JSON.
Trebuie t ,inut minte c ˘a trebuie importat ˘a aceast ˘a librarie cu ajutorul liniei:
import json
care va pune la dispozit ,ie funct ,iaload(fis ,ier). Toate notit ,ele vor fi memorate în variabila
self.notes.data .
În fis ,ierul .kv, pentru clasa Notes am ad ˘augat anumite clase predefinite din kivy cum ar
fi:BoxLayout ,Image ,Label ,Button . Am început cu dou ˘a clase BoxLayout, o clas ˘a
care o include pe cealalt ˘a. Prima clas ˘a va avea o orientare pe vertical ˘a în timp ce a doua
clasa de BoxLayout va avea o orientare orizontal ˘a. BoxLayout-ul cu orientare orizontal ˘a va
fi copilul primei clase, împreuna cu clasa RecycleView . Aceast ˘a clas˘a un model flexibil
de afis ,are a informat ,iilor. De asemenea accept ˘a un volum mare de date din care se poate
face select ,ia.
Un alt scop al clasei este de a preveni pierderea informat ,iei care poate ap ˘area dac ˘a sunt
oferite spre afis ,are un num ˘ar foarte mare de notit ,e. Aceast ˘a clas˘a se bazeaz ˘a pe modelul
MCV(Model-view-controller).
Figura 6.8.: Exemplificare clase RecycleView , utilizarea s ,i implementarea acesteia pentru tema
prezentat ˘a.
Model-View-Controller este un model de proiectare software. Acesta este folosit pentru
dezvoltarea de interfet ,e utile utilizatorului. Logica modelului este împ ˘art ,it˘a în 3 compo-
nente care sunt interconectate între ele. Astfel, se încearc ˘a separarea funct ,iilor interne
ale programului de partea din fat ,˘a, adic ˘a imaginea s ,i funct ,ionalitatea care este oferit ˘a
utilizatorului. (Burbeck (1992))
În Figura 6.9 se pot observa cele trei componente ale modelului care într-un final ofer ˘a
informat ,ii us ,or de prezentat utilizatorului.
31

Capitolul 6. Proiectarea aplicat ,iei
Figura 6.9.: Diagram ˘a care descriere interact ,iunea cu modelul Model-view-controller ( MVC Pro-
cess(2020))
1. Model: Este componenta central ˘a a modelului. Este o structur ˘a dinamic ˘a a aplicat ,iei.
Scopul ei este de a gestiona corect toate datele, logica s ,i regulile aplicat ,iei.
2. View: Aici intr ˘a reprezentarea informat ,iei, în cazul nostru fiind notit ,ele. Permite
mai multe vizualiz ˘ari ale aceleas ,i informat ,ii, de exemplu prezentarea notit ,ei intr-un
format în care se prezint ˘a doar titlul s ,i anumite butoane s ,i un format în care se
prezint ˘a s ,i informat ,ia din cadrul notit ,ei.
3. Controller: Determin ˘a interact ,iunea logic ˘a s ,i este implementat cu ajutorul clasei
RecycleViewBehavior . (RecycleViewBehavior 2020)
Aceast ˘a clas ˘a ofer ˘a un model pe baza caruia este construit s ,i clasa RecycleView
folosit ˘a de noi. Împreun ˘a reus ,esc eficient s ˘a produc ˘a un mod flexibil de vizualizare a
volumului mare de date.
Întorcându-ne la structura fis ,ierului, gruparea care se aranjeaz ˘a pe orizontal ˘a va cuprinde
structuri vizibile în toat ˘a aplicat ,ia s ,i anume:
• Numele det ,in˘atorului
• Un mesaj de întâmpinare împreun ˘a cu sigla
• Numele ecranului
32

Capitolul 6. Proiectarea aplicat ,iei
• Butonul pentru ad ˘augarea unei noi notit ,e
• Buton care redirect ,ioneaz ˘a înapoi în meniul principal.
Atunci când dorim s ˘a ad˘aug˘am o nou ˘a notit ,˘a vom apela funct ,iaedit_note() . Aceast ˘a
funct ,ie se apeleaz ˘a când ap ˘asam butonul pentru o nou ˘a notit ,˘a. Butonul cheam ˘a apelul
funct ,iei prin comanda on_release .
Clasa NoteView care primes ,te un obiect de tip Screen , are ca viabile titlul, id-ul s ,i
informat ,ia stocat ˘a în notit ,˘a. Atunci când se apas ˘a butonul pentru crearea unei noi
notit ,e, în funct ,ia care adaug ˘a o notit ,a, explicat ˘a mai sus, cheam ˘a clasa edit_note(self,
note_index) . Trebuie precizat c ˘a acest ˘a metod ˘a este chemat ˘a s ,i de funct ,iea care creaz ˘a
o notit ,˘a noua, dar s ,i de butonul care editeaz ˘a una deja existent ˘a.
Aceast ˘a clas ˘a încearc ˘a s˘a preia notit ,a în funct ,ie de id-ul primit. Dac ˘a notit ,a exist ˘a,
deschide un ecran cu ajutorul funct ,ieiget_screen(name) . În schimb, daca notit ,a abia
se creaz ˘a, se apeleaz ˘a clasa NoteView care întoarce într-o variabil ˘a informat ,ii despre
notit ,˘a: nume, index, titlu s ,i cont ,inut. Numele reprezint ˘a o concatenare dinte cuvântul
cheie ’note’ s ,î id-ul primit.
În fis ,ierul .kv, la definirea clasei se g ˘asesc doua funct ,ii:
Figura 6.10.: Apelarea a dou ˘a funct ,ii definite în clasa principal ˘a
Cele doua funct ,ii sunt definite în clasa principala – NoteApp s,i au ca s ,i scop actualizarea
titlului s ,i al cont ,inutului.
În Figura 6.11 se poate observa codul pentru aceast ˘a funct ,ie, aproape identic si pentru
funct ,iaset_note_title(self, note_index, note_title)
Figura 6.11.: Codul pentru funct ,ia set_note_content()
Aceste funct ,ii primesc informat ,ia transmis ˘a de c ˘atre variabilele clasei NoteView s ,i le ac-
tualizeaz ˘a în obiectul principal self. Dup ˘a ce se face memorarea în obiect, se apeleaz ˘a
funct ,iasave_notes() pentru a actualiza cont ,inutul.
ClasaNoteListItem are aceeas ,i structur ˘a ca s ,i clasa NoteView . Aceast ˘a clas˘a este utili-
zat˘a în fis ,ierul .kv s ,i cu ajutorul c ˘areia se grupeaz ˘a fiecare notit ,˘a. Acesta are ca s ,i structur ˘a
unBoxLayout care are la rândul lui copii unui Label pentru afis ,area titlului s ,i unBut-
toncare face posibil ˘a editarea. Deoarece clasa primes ,te aceias ,i parametrii ca si NoteView,
afis ,area textului se face usor prin apelarea obiectului root.note_title . Pentru edidate, se
apas˘a butonul s ,i în acel moment se va apela funct ,iaedit_note(root.note_index)
33

Capitolul 6. Proiectarea aplicat ,iei
Hart˘ a
Pentru început, trebuie precizat c ˘a am avut nevoie de o libr ˘arie special ˘a care m-a ajutat
s˘a lucrez cu h ˘art ,ile:
from kivy.garden.mapview import MapView, MapMarker
MapView este un modul care permite interact ,iunea cu h ˘art ,ile. Din cadrul acestui modul
am utilizat MapView s,iMapMarker . MapView primeste trei argumente, zoom prezint ˘a
cât de departe se poate vedea din hart ˘a,lats,ilonreprezint ˘a latitudinea s ,i longitudinea.
Mai jos s-au pus latitudinea s ,i longitudinea pentru Bucures ,ti.
MapView(zoom=11, lat=44.4268, lon=26.1025)
6.1. Dificult˘ at ,i
Una dintre dificult ˘at,ile întâmpinate a fost crearea navigat ,iei care este destul de complex ˘a s ,i
necesit ˘a multe funct ,ii. Aceasta ar trebuie s ˘a prea locat ,ia curent ˘a s ,i pe baza locat ,iei introduse de
c˘atre utilizator s ˘a ii genereze cel mai scurt traseu. În momentul actual, ecranul pentru navigat ,ie
ofer˘a doar o imagine de ansamblu a h ˘art ,ii, urmând ca pe viitor s ˘a implementez restul navigatiei.
6.2. Imbun˘ at˘ at ,iri
Pe viitor, doresc s ˘a îmbun ˘at˘at,esc structura h ˘art ,ii, astfel încât utilizatorul s ˘a poat ˘a avea o hart ˘a
performant ˘a s ,i la standardele actuale. De asemenea doresc s ˘a adaug si conectivitate cu telefonul.
La conectarea telefonului, sistemul s ˘a îi ofere posibilitate s ,oferului de a avea apeluri vocale f ˘ar˘a
s˘a utilizeze telefonul. Acesta îs ,i va memora contactele pe care dores ,t,e s˘a le apeleze cel mai des
iar la conectarea prin bluetooth s ˘a poat ˘a suna direct de pe sistemul infotainment. Radioul este
o alt˘a îmbun ˘at˘at,ire pe care doresc s ˘a o aduc. S ˘a poat ˘a selecta us ,or orice canal radio. S ,i într-un
final, as ,dorii s ˘a adaug comenzi vocale de tipul "Porneste muzica", "Du-m ˘a acas ˘a".
34

7. Concluzii
Prin realizarea acestei lucr ˘ari am dorit s ˘a prezint un sistem infotainment modern s ,i us ,or de
adaptat la orice cerint ,˘a care ar ap ˘area. Funct ,ionalit ˘at,ile de care dispune ne permite s ˘a avem
un sistem infotainment de baz ˘a usor de folosit. Împreun ˘a cu funct ,iile pe care doresc s ˘a le mai
adaug în viitor, va rezulta un sistem infotainment care s ˘a se plieze cu toate cerint ,ele actuale.
Microprocesorul pe care îl are aplicat ,ia este suficient de puternic cât s ˘a execute instruct ,iunile
într-un timp suficient de mic iar utilizatorul s ˘a nu observe eventualele întârzieri.
Distribut ,ia de Debian folosit ˘a, creat ˘a special pentru pl ˘acut ,ele Raspberry Pi, permite în-
locuirea Kernelului cu unul Real-Time. Astfel, se va asigura c ˘a evenimentele critice din punct
de vedere al timpului vor fi procesate eficient.
Framework-ul pe care l-am ales are ca s ,i beneficiu API-ul simplist pe care îl ofer ˘a. Intr ˘arile
primite de la utilizator (selectarea unui buton, glisarea meniului stânga-dreapta) se vor procesa
mult mai us ,or.
În concluzie, aplicat ,ia creat ˘a ofer˘a funct ,ionalit ˘at,i utile pentru conducatorul automobilului
s,i pasagerii acestuia, într-un mod simplit, modern s ,i care are un timp de execut ,ie rapid.
35

Anexe
36

A. Nota¸ tii
GLEW
OpenGL Extension Wrangler Library
VAO
Vertex Array Object
VBO
Vertex Buffer Object
37

B. Cod
38

Capitolul B. Cod
39

Capitolul B. Cod
40

Capitolul B. Cod
41

Capitolul B. Cod
42

Capitolul B. Cod
43

Capitolul B. Cod
44

Capitolul B. Cod
45

Bibliografie
Burbeck, Steve (1992). Applications Programming in Smalltalk-80:How to use Model–Vi-
ew–Controller (MVC) .
Chenaru, Oana (2020). Curs grafic˘ a avansat˘ a .
Events and Properties (2014). https://kivy.org/doc/stable/guide/events.html .
Gapper, John (2015). Software is steering auto industry .
Hattersley, Lucy (28 May 2020). Raspberry Pi 4, 3A+, Zero W – specs, benchmarks thermal
test.
Kam, Timothy (1997). Kluwer Academic Publishers: Synthesis of Finite State Machines:
Functional Optimization .
Kivy architecture (2014). https://kivy.org/doc/stable/guide/architecture.html/ .
Accessed: 2010-09-30.
MVC Process (2020). https://en.wikipedia.org/wiki/File:MVC- Process.svg/ .
Accessed: 2010-09-30.
Phillips, Dusty (2014). Creating Apps in Kivy .
RecycleViewBehavior (2020). https://kivy.org/doc/stable/api-kivy.uix.recycleview.
html#kivy.uix.recycleview.RecycleViewBehavior .
The evolution of car infotainment systems (2020). https://www.motorists.org/blog/
the-evolution-of-car-infotainment-systems-infographic/ . Accessed: 2010-09-30.
Upton, Eben (28 May 2020). 8GB Raspberry Pi 4 on sale now at $75 .
Villa, Tiziano (1997). Synthesis of Finite State Machines: Logic Optimization .
46