Automatizare Pentru Plasarea I Recuperarea Autovehiculelor Dintr O Parcare Supraetajată

Universitatea „Politehnica” din Timișoara

Facultatea de Automatică și Calculatoare

Programul de Licență: Calculatoare și tehnologia informației

Automatizare pentru plasarea și recuperarea autovehiculelor dintr-o parcare supraetajată

Proiect de diplomă

Pavel DERLEAN

Conducător științific:

Conf. Dr. Ing. Lucian PRODAN

Timișoara,

<anul elaborării>

Lista abrevierilor

PWM – Pulse Width Modulation

SUA – Statele Unite ale Americii

Lista figurilor

Fig1. Parcarea hotelului La Salle

Fig2. Parcarea Rue de Ponthieu din Paris

Fig3. Sistem de parcare automatizat

Fig4. Schema hardware bloc a sistemului de automatizare pentru parcare

Fig5.

Fig6.

Fig7.

Fig8.

Fig9.

Fig10.

Fig11.

Fig12.

Fig13.

Fig14.

Fig15.

1 Introducere

Începând cu anii 1900, pe măsură ce tot mai multe persoane aveau autovehicule, nevoia existenței unor locuri de parcare a devenit din ce în ce mai mare. Astfel, parcarea a devenit o problemă iar oamenii căutau o soluție pentru a parca cât mai multe mașini pe un spațiu cât mai restrâns.

Primele autovehicule nu erau atât de rezistente la condițiile meteorologice precum sunt mașinile de astăzi. Majoritatea erau fără acoperiș, aveau scaunele din piele și erau foarte sensibile. Din acest motiv , ele trebuiau să fie parcate într-un loc închis , unde să fie protejate de frig , de ploaie și de alte precipitații.

Parcări

Parcarea reprezină un loc special amenajat, delimitat prin marcaje și indicatoare, destinat staționării autovehiculelor.

Primele parcări arătau ca oricare alte clădiri obișnuite unde oamenii depozitau lucruri. O mașină era considerată de majoritatea persoanelor ca fiind doar o mașinărie și nimic mai mult,

în contrast cu ideea de astăzi despre ce reprezintă o mașină. Parcările se contopeau în peisaj cu celelalte clădiri și nu puteai să știi că erau locuri destinate stocării autovehiculelor.

Prima parcare supraetajată cunoscută a fost construită în anul 1918 pentru hotelul La Salle. Parcarea se afla la câteva blocuri de hotel și a fost dezvoltată de Holabird și Roche. De asemena punea la dispoziție 350 de locuri de parcare dar și un ”doctor” pentru mașinile din parcare. Pentru a evita aglomerația exista și un lift pentru a aduce mașinile înapoi. Partea din nord si sud avea geamuri de sticla și exista un angajat permanent ce se ocupa doar cu ștersul geamurilor. Era pentru prima oară când o societate comercială punea la dispoziție clienților un loc sigur unde își pot lăsa autovehiculele.

Fig1. Parcarea hotelului La Salle [1]

În acea perioadă erau două idei diferite despre autovehicule: una se referea la faptul că sunt doar mașinării iar cealaltă la sentimentul de libertate asociat cu conducerea mașinii. Aceste două concepte diferite au dus la apariția a două tipuri de parcări: parcările mecanizate și cele cu rampă .

Parcări mecanizate

Parcările mecanizate sunt considerate ca fiind predecesorii parcărilor automatizate din ziua de azi. Nu conduceai în interiorul unor astfel de parcări și nici până la locul de parcare ci doar până la intrare, unde predai mașina unei persoane care se ocupa de parcarea autovehiculelor. Mașina era plasată pe o platformă și cu ajutorul unor cabluri era mutată în locul de parcare liber. În 1920 erau diferite mecanisme de parcare ce difereau de la o locație la alta. Unul dintre mecanisme era numit ”Dublu Helix” pentru că avea două rampe în formă de spirală pentru a muta mașinile în structură. Acest tip de parcare nu avea însă un singur lucru: libertatea de a-ți parca singur mașina și de a intra și a ieși din parcare atunci când dorești.

Cel mai vechi sistem de parcare mecanizat cunoscut a fost ”Garajul Rue de Ponthieu ” aflat în Paris și dezvoltat de către arhitectul August Perret. Sistemul a fost construit în anul 1905 și transporta vehiculele la primul sau la al doilea etaj, unde o persoană se ocupa de parcarea acestora. Acest sistem a fost practic un sistem semi-automat, această metodă fiind destul de des întâlnită în sistemele moderne de parcare.

Fig2. Parcarea Rue de Ponthieu din Paris [2]

În 1920 s-au construit primele sisteme de parcare în Statele Unite ale Americii în orașe ca New York, Chicago si Los Angeles.

Adevărata explozie a parcărilor mecanizate a avut loc în perioad anilor 1950 când s-au construit peste 70 de sisteme de parcare în SUA, majoritatea fiind de tipul ”cușcă de porumbel”. Acestea aveau un lift situat în centru , iar un operator efectua parcarea autovehiculelor pe ambele părți de-alungul unui coridor. De asemenea se ofereau și numeroase servicii ca : verificarea uleiului, verificarea presiunii pneurilor, sau posibilitatea de a alimenta. Câteva sisteme sunt încă funcționale și astăzi.

1.3 Parcări cu rampă

Sistemele de parcare cu rampă pentru a trece de la un etaj la altul oferă posibilitatea de a-ți parca singur mașina. Construirea rampelor a fost o adevărată provocare deoarece nu puteau să fie nici prea lungi, deoarece se pierdea astfel spațiu de parcare, și nici prea scurte deoarece mașinile nu puteau urca la un alt etaj. În cadrul unor astfel de parcări numărul locurilor de parcare disponibile era mai mic decât într-o parcare mecanizată. Acest lucru înseamnă că dimensiunea clădirilor a crescut pentru a avea suficientă capacitate.

Parcările supraetajate cu rampă au fost și sunt o alternativă pentru sistemele de parcare automatizate. Chiar dacă au mai multe dezavantaje, posibilitatea de a-ți parca singur autovehiculul a fost mai importantă pentru unele persoane. Faptul că trebuia să îți predai mașina unui operator iar apoi să fii nevoit să aștepți la finalul zilei pentru ca mașina ta să apară era considerat un mare inconvenient.

Parcări automatizate

Într-o parcare automatizată complet nicio persoană nu este implicată pe parcursul

desfășurării operațiunii de parcare.

Un sistem de parcare automatizat este un sistem mecanizat, coordonat de un computer care transportă autovehiculele și le stochează într-un mod similar depozitelor de stocare a mărfurilor. De asemena această metodă de transport și stocare este prezentă în industria constructoare de mașini unde componentele grele sunt stocate și transportate în mod automat cu ajutorul unor dispozitive.

Procedura de efectuare a parcării este una relativ simplă: clientul lasă autovehiculul într-o zonă specială, poate fi o cameră sau pur și simplu o platformă delimitată, iar apoi sistemul se ocupă de întreaga operațiune fără a mai fi nevoie de intervenția clientului.

Sistemul este format din zona de așteptare, sistemul de transport al autovehiculului ce asigură deplasarea acestuia de-alungul zonelor de parcare, liftul sau sistemul care asigură legatură dintre etajele parcării, locul propriu-zis de parcare și un computer care funcționarea optimă a întregului sistem.

Fig3. Sistem de parcare automatizat

2 Analiza stadiului actual în domeniul problemei

2.1 Contextul problemei

Într-o lume a inovației în care maximizarea confortului operatorului uman, minimizarea efortului depus de acesta, precum și scăderea timpului irosit dar și a costurilor reprezintă un obiectiv esențial al tehnologiei , problema locurilor de parcare și a timpului petrecut în cadrul unei parcări a devenit un element de actualitate.

De exemplu, conform unei analize recente, numărul locurilor de parcare din Timișoara este de aproximativ 55 000 , raportat la un număr de peste 127 000 mașini înregistrate [1], fără a ține cont de numărul mașinilor care tranzitează zilinic orașul sau de mașinile studenților , rezultând un raport de aproximativ 2,30 mașini / loc de parcare .

2.2 Motivația

2.3 Soluția propusă și prezentarea succintă a sistemului

Proiectul propus spre implementare reprezintă un sistem de automatizare compus din elemente atât hardware, software, cât și mecanice , care împreuna alcătuiesc un sistem de parcare inteligentă , capabil să îndeplinească toate funcțiile și operațiile necesare pentru efectuarea unei operații de parcare dar și de returnare a mașinii.

Modul de funcționare al acestui sistem este următorul : clientul alege operațiunea pe care dorește sa o facă , introducând cu ajutorul unei mini-tastaturi codul corespunzător:

Parcare autovehicul ;

Ridicare autovehicul ;

În cazul primei variante, clientul apasă tasta “1”, lasă mașina pe platformă în dreptul căreia sunt așezați senzori de detecție, iar în momentul în care mașina a fost detectată este generat automat un cod pe ecran, codul necesar ulterior clientului pentru ridicarea mașinii. In cazul implementării reale al acestui sistem acest cod va fi tipărit pe hârtie, alături de dată și oră. În continuare se va desfășura întreaga operațiune de parcare : mașina aflată pe platformă va fi transportată în primul loc de parcare liber. Principiul alegerii locului de parcare este cel

al stivei , parcarea se va ocupa începând de la primul loc de la etajul inferior și până la ultimul loc al ultimului etaj.

În cazul variantei secunde, clientul apasă tasta “2”, iar apoi introduce codul rezultat în urma operației anterioare de parcare. Daca acest cod introdus este corect , va începe operația de returnare a mașinii: sistemul va știi pe baza codului introdus, locația exacta unde este parcat autovehiculul, și îl va transporta cu ajutorul platformei la locul de ridicare. În cazul în care codul introdus este greșit, clientul va avea posibilitatea să îl reintroducă de maxim 3 ori. În cazul în care a introdus codul greșit de 3 ori, se va afișa un număr de contact pentru rezolvarea problemei.

Ilustrație a machetei proiectului

3 Structura hardware a sistemului

3.1 Schema hardware bloc a sistemului

Schema hardware bloc descrie într-un mod sumar întregul sistem , elementele componente , precum și modul de interconectare al acestora.

Fig1. Schema hardware bloc a sistemului de automatizare pentru parcare

3.2 Elemente hardware folosite

După cum am menționat, sistemul de lumini ambientale este compus atât din elemente hardware cât și din elemente software.

Sistemul hardware de control al luminilor ambientale, este compus din:

– 1 placă de dezvoltare Arduino Mega 2560 cu microcontroler ATmega2560;

– 1 modul de bluetooth TTL serial;

– 2 module driver ULN 2803A;

– 4 comutatoare rotative cu 6 poziții fiecare;

– 7 benzi cu leduri RGB în fiecare cameră din cele 4;

– 1 sursă de tensiune de tip PC (Personal Computer);

– 1 sau mai multe dispozitive mobile cu Android;

Placa de dezvoltare Arduino Mega 2560 este bazată pe microcontrolerul ATmega2560. Printre caracteristicile microcontrolerului se enumeră: dimensiunea magistralei de 8 biti, frecvența maximă de clock 16MHz, 256K Bytes memorie Flash proprie, 4K Bytes memorie EEPROM, 8K Bytes memorie interna SRAM, convertor analog numeric (CAN) cu rezoluție de 10 biți.

Caracteristici ale plăcii de dezvoltare din punctul de vedere al interfațării cu mediul exterior: 54 de pini digitali (dintre care 15 pot fi configurati cu PWM) cu posibilitatea de setare ca pini de intrare sau de ieșire, 16 pini analogici de intrare, 4 pini dedicați comunicației UART [2].

În cadrul acestui proiect am folosit placa de dezvoltare Arduino Mega pentru a îndeplini următoarele sarcini:

– achiziția de date de la cele 4 comutatoare montate câte unul în fiecare cameră;

– achiziția de date de la modulul de bluetooth;

– procesarea datelor citite de la comutatoare și de la modulul de bluetooth;

– trimiterea către drivere a comenzii ledurilor, în funcție de datele achiziționate și procesate.

Modulul de bluetooth TTL serial este un modul de bluetooth care poate fi atât master cât și slave, putând chiar să fie cel care inițiază o conexiune de tip bluetooth. Prin urmare poate fi folosit în aplicații Client-Server atât ca și client (cand acest modul inițiază cererea de conectare către server), cât și ca și server (caz în care nu el este cel ce inițiază conexiunea).

Acest modul de bluetooth funcționează pe baza protocolulului v2.1 + EDR (Enhanced Data Rate) la o frecvență de 2.4GHz. Tensiunea de alimentare recomandată de producator este de 3.3 V iar curentul de intrare de 50mA [3].

În cadrul acestui proiect am utilizat modulul de bluetooth TTL serial pentru a interfața comunicația fără fir între aplicația mobilă si placa de dezvoltare Arduino Mega. Modulul are funcția de server în cadrul comunicației stabilite cu modulul bluetooth aflat pe dispozitivul mobil, acesta din urmă avand rol de client.

Modulul bluetooth a fost conectat în următorul mod: pinul de VCC al modulului a fost conectat la pinul de 3.3V al plăcii de dezvoltare, pinul GND al modulului a fost conectat la masa comună a echipamentelor, pinul de Rx al modulului la cel de Tx al plăcii de dezvoltare, iar pinul de Tx al modulului la pinul de Rx al plăcii de dezvoltare.

Modulul driver ULN 2803A este un dispozitiv amplificator de curent, ce constă in 8 perechi de tranzistoare NPN Darlington. Fiecare ieșire care reprezintă de fapt colectorul tranzistorului, poate să furnizeze un curent de până la 500mA, dar ieșirile legate în paralel pot furniza chiar și curenți mai mari. Tensiunea maximă la ieșiri este de 50V. Acest modul poate fi folosit cu succes în aplicații ce presupun conducere de motoare sau conducere de led-uri de înaltă putere [4].

Am utilizat acest modul driver pentru a face posibilă aprinderea ledurilor la parametrii nominali, amplificând comanda primită de la placa cu microcontroler. În caz contrar, dacă nu se folosea un astfel de modul de amplificare, porturile de ieșire ale plăcii de dezvoltare nu ar fi fost capbile să conducă o sarcină așa mare precum cea a ledurilor, ledurile ar fi cerut o cantitate mare de curent de la placă și prin urmare portul de ieșire se deteriora sau ardea și de ce nu, poate aceleași reacții negative le putea suporta chiar microcontrolerul.

Comutatoarele rotative sunt produse de către Marquardt și au câte 10 posibile poziții pe care pot fi setate. În cadrul proiectului de față, am limitat mecanic comutatoarele la doar 6 poziții pentru a se mula pe cerințele și necesitățile de dezvoltare. Pe lângă pinii corespunzători fiecărei poziții, comutatoarele mai prezintă și un pin la care se conectează tensiunea ce se va permuta pe pinii de poziție.

Aceste comutatoare au fost folosite în cadrul proiectului ca o măsură de rezervă în cazul în care utilizatorul nu mai dorește sau nu mai poate să folosească aplicația mobilă din diverse motive.

Benzile cu leduri RGB reprezintă benzi cu contacte situate din trei in trei leduri. Contactele prezente la această distanță sunt patru la număr și anume:

– unul pentru a comanda culoarea roșu, contact notat cu R (de la red);

– unul pentru a comanda culoarea verde, contact notat cu G (de la green);

– unul pentru a comanda culoarea albastru, contact notat cu B (de la blue);

– unul pentru borna pozitivă de alimentare, contact notat cu 12V deoarece tensiunea nominală de alimentare a benzii de leduri este de 12 volți.

În fiecare led aflat pe bandă, se află trei leduri extrem de apropiate care pot fi comandate prin intermediul contactelor menționate mai sus. Astfel ochiul uman va percepe o singură nuanță chiar dacă aceasta este compusă din cele trei culori fundamentale roșu, verde și albastru comandate prin cele trei contacte ale benzii.

Aceste benzi cu leduri au fost folosite ca și elemente de execuție în cadrul proiectului. Alegerea s-a datorat și faptului că benzile RGB sunt capabile să reproducă orice nuanță sau culoare.

Sursa de tensiune de tip PC este o sursă capabilă să furnizeze tensiune pe cele trei nivele des întalnite și utilizate în automatică: 3.3V, 5V și 12V.

Pinul de 12V împreună cu pinul de GND al sursei au fost folosiți în cadrul proiectului pentru a alimenta benzile de leduri prin contactele de 12V și contactul aferent culorii și pentru a alimenta cele două module driver prin pinii de COM și GND ale capsulelor modulelor driver.

Pinul de 5V împreună cu pinul de GND al sursei au fost folosiți pentru alimentarea plăcii de dezvoltare Arduino Mega.

Pinul de 3.3V al sursei nu a fost folosit deoarece pentru alimentarea modulului de bluetooth TTL serial s-a folosit pinul de 3.3V oferit de placa de dezvoltare.

Dispozitivul mobil cu Android poate fi un smartphone, o tabletă sau un notebook ce rulează cu un astfel de sistem de operare.

În cadrul acestui proiect dispozitivul mobil are rol de platformă hardware pentru rularea optimă a aplicației mobile de control al sistemului de lumini ambientale.

3.3 Schema hardware în detaliu a sistemului

Schema hardware detaliată, descrie în profunzime comunicația ce se realizează intre modulele hardware componente. Raportată la Figura 1, schema din Figura 2 preia fiecare modul hardware și îi detaliază parțile de interfațare cu modulele conectate.

Figura 2 exemplifică schema hardware corespunzătoare a două camere, pentru a nu încărca schema și pentru a fi mai ușor de înțeles. Prin analogie, același principiu de interconectare se aplică si la celelalte două camere.

Figura 2 Schema hardware detaliată a sistemului

Se observă că în figură avem două comutatoare rotative cu 6 poziții fiecare și două benzi cu leduri RGB.

Pe macheta hardware a proiectului sunt montate câte șapte benzi cu leduri RGB și câte un comutator în fiecare cameră, așadar schema din Figura 2 nu reflectă întru totul montajul din două camere ale machetei. Diferența constă în faptul că o bandă de leduri RGB din Figura 2 simbolizează cele șapte benzi de leduri înseriate aflate într-o cameră a machetei. Aceste șapte benzi prezente în fiecare cameră sunt comandate identic, dar fiecare cameră poate fi comandată diferit.

Se pot observa în cadrul schemei din Figura 2 elementele hardware componente:

– sursa de tensiune de tip Personal Computer;

– placa de dezvoltare Arduino Mega 2560;

– două benzi cu leduri RGB;

– modulul driver ULN 2803A;

– modulul bluetooth TTL serial;

– două comutatare rotative cu 6 poziții.

4 Structura software a sistemului

Software-ul sistemului este compus din două mari componente: modulul software embedded al cărui comportament este implementat de codul scris în memoria flash a plăcii de dezvoltare Arduino Mega și modulul software reprezentat de aplicația mobilă ce rulează în dispozitivul mobil cu Android.

4.1 Schema software bloc a sistemului

Schema software bloc prezintă tipurile de comenzi ce se transmit între cele doua componente sofware folosite: aplicația mobilă și aplicația în bucla infinită pe microcontroler.

Figura 3 Schema software bloc a sistemului de lumini ambientale

Comenzile de setare culoare și luminozitate au ca și structură următorul model: “denumire cameră”+ “denumire culoare”+ “intensitate luminoasă” . Aceste trei câmpuri concatenate alcătuiesc comanda.

Comenzile de stingere lumini în toată casa au un format fix, alcătuit doar din șirul de caractere “StingeTot”.

Comenzile de stingere lumini într-o anumită cameră nu au un format fix, structura comenzii depinzând de denumirea camerei. Acest tip de comandă poate lua patru forme: “StingeSts”, “StingeStj”, “StingeDrs”, “StingeDrj”, unde “Sts” provine de la stânga sus, “Stj” de la stânga jos, “Drs” de la dreapta sus iar “Drj” de la dreapta jos.

Comenzile de cedare sau acordare prioritate comutatoarelor nu au un format fix, depinzând și ele de denumirea camerei. Tipul acesta de comandă poate lua opt forme: “SliderSts”, “ComutatorSts”, “SliderStj”, “ComutatorStj”, “SliderDrs”, “ComutatorDrs”, “SliderDrj”, “ComutatorDrj”.

Comanda de forma “SliderX” dă prioritate sliderului camerei X din ecranul de luminozitate inhibând acțiunea comutatorului fizic din camera X. Comanda de forma “ComutatorX” dă prioritate comutatorului fizic aflat în camera X.

Detalierea algoritmului referitor transmiterea acestor patru tipuri de comenzi se află la capitorul 3.5 .

4.2 Schema software detaliată

Am ales ilustrarea unei scheme software în detaliu referitoare la o singură cameră, deoarece același algoritm s-a aplicat pentru fiecare cameră din cele patru existente.

În figura ce urmează este descris firul algoritmului software, pornind de la elementele de achiziție, până la elementele de execuție.

Figura 4 Schema software detaliată a sistemului de lumini ambientale

4.3 Prezentarea generală a utilitarului software App Inventor 2

App Inventor 2 a fost dezvoltat la fel ca și fratele său mai mare App Inventor, de către compania Google și intreținut apoi de către Massachusetts Institute of Technology. Ca și caracteristici principale se enumeră faptul că este un mediu de programare vizual, cu o interfață grafică prietenoasă, menit să faciliteze dezvoltarea aplicațiilor pentru dispozitive cu sistem de operare Android. Mediul de dezvoltare este oferit online de către MIT prin simpla autentificare cu contul de Google.

Una din principalele trăsături distinctive ale limbajului App Inventor 2 este că a facut posibilă dezvoltarea aplicațiilor multi-ecran, spre deosebire de App Inventor care ducea lipsă de așa ceva. Datorită faptului că nu se pot construi aplicații prea complexe dar și simplu de utilizat folosind doar un ecran în cadrul unei aplicații, am ales utilitarul App Inventor 2, nu App Inventor.

App Inventor 2 este un utilitar axat pe evenimente specifice fiecărui tip de componentă grafică prezentă pe ecran, dar și pe evenimente specifice ecranului.

Pentru elementul grafic buton (button) de exemplu, mediul dispune de evenimente de tipul “When Click”, “When TouchUp”, “When TouchDown” etc.

Pentru elementul grafic ecran (screen), mediul de dezvoltare dispune de o largă varietate de evenimente care sunt foarte utile dezvoltatorului, evenimente precum: “When screen initialized”, “When screen back pressed”, “When screen other screen closed”, etc.

Mediul de dezvoltare are doua secțiuni principale:

– Designer, este o secțiune în care dezvoltatorul își aduce și își aranjează elementele grafice ce vor apărea pe ecranul dispozitivului;

– Blocks, este o secțiune în care dezvoltatorul își asamblează algoritmul sau modul de interconectare și interacționare al elementelor plasate în secțiunea “Designer”.

Așadar, în secțiunea “Designer” se definește grafica aplicației, iar în secțiunea “Blocks” se definește algoritmul aplicației.

4.4 Prezentarea interfeței grafice dezvoltată în App Inventor 2

Interfața grafică cu utilizatorul (GUI) este compusă din șase ecrane:

ecranul numărul 1 – reprezintă ecranul principal din care se va face trecerea către toate celelalte ecrane;

ecranul numărul 2 – este cel pentru setarea luminozității pentru oricare din cele patru camere;

ecranele 3, 4, 5 și 6 – sunt identice din punct de vedere grafic și sunt utile pentru setarea culorii luminii ambientale (aplicația are câte un astfel de ecran pentru fiecare cameră din cele patru existente).

4.4.1 Ecranul principal

Acest ecran face posibilă tranziționarea către oricare ecran din celelalte cinci. Prin urmare, nu se poate face trecerea dintr-un ecran de setare al culorii în camera unu într-un ecran de setare al culorii în oricare din camerele 2, 3 sau 4, fără să trecem prin ecranul principal. Relaționarea ecranelor este descrisă de figura de mai jos:

Figura 5 Relaționarea ecranelor

Săgețile portocalii de la ecranul principal la ecranele secundare ilustrează o relație de tipul “lansează în execuție pe” (vezi Figura 5).

Figura 6 Elementele grafice evidențiate ale ecranului principal

Elementele grafice vizibile ale ecranului principal:

– buton cu funcție de activare bluetooth pe dispozitivul mobil (elementul grafic 1);

– buton cu funcție de ieșire din aplicație (elemntul grafic 2);

– etichetă indicatoare de stare a modulului bluetooth de pe dispozitivul mobil (Oprit/Pornit) (elemntul grafic 3);

– etichetă indicatoare de stare a conexiunii între cele două dispozitive bluetooth (Oprit/Pornit) (elementul grafic 4);

– buton cu funcție de listare a adreselor și a numelor tuturor modulelor bluetooth aflate în apropierea dispozitivului mobil (elementul grafic 5);

– buton cu funcție de deconectare de la dispozitivul bluetooth conectat în momentul curent (elementul grafic 6);

– buton cu funcție de tranziționare în ecranul de setare a culorii în camera 1 (elementul grafic 7);

– buton cu funcție de tranziționare în ecranul de setare a culorii în camera 2 (elementul grafic 8);

– buton cu funcție de tranziționare în ecranul de setare a culorii în camera 3 (elementul grafic 9);

– buton cu funcție de tranziționare în ecranul de setare a culorii în camera 4 (elementul grafic 10);

– buton cu funcție de tranziționare în ecranul de setare al luminozității în oricare din cele patru camere (elementul grafic 11);

– buton cu funcție de stingere totală a luminilor ambientale în toată casa (elementul grafic 13);

– etichetă de confirmare a stingerii luminilor în toată casa (elementul grafic 12);

– notificator de confirmare a activării bluetooth-ului pe dispozitivul mobil fie că este vorba de activare automată la intrarea în aplicație, fie că se cere activare prin apăsarea butonului de activare (butonul marcat cu 1 în Figura 6). Numai în aceste două cazuri devine vizibil;

– notificator de confirmare a deconectării bluetooth-ului de pe dispozitivul mobil de la bluetooth-ul cu care a fost împerecheat. Acest notificator este o componentă care acționează la apăsarea butonului de deconectare și doar atunci devine vizibil;

– notificator de avertizare în cazul în care utilizatorul dorește să treacă într-un ecran de setare al culorii într-o cameră, fără să fi activat bluetooth-ul pe dispozitiv. Acest tip de notificator acționează la apăsarea oricărui buton de tranziționare în alt ecran și la apăsarea butonului de alegere a dispozitivului. Așadar doar în aceste cazuri devine vizibil;

– notificator de avertizare în cazul în care utilizatorul dorește să treacă într-un ecran de setare al culorii într-o cameră, fără să se fi conectat cu bluetooth-ul din casă dar având bluetooth-ul activ. Acest tip de notificator acționează la apăsarea oricărui buton de tranziționare în alt ecran și la apăsarea butonului de alegere a dispozitivului. Așadar doar în aceste cazuri devine vizibil;

– notificator ce avertizează utilizatorul că bluetooth-ul este deja pornit pe dispozitiv. Acest notificator devine vizibil când se apasă butonul de activare bluetooth, el fiind deja activ;

– notificator de confirmare a ieșirii din aplicație. Acesta apare doar în situația în care utilizatorul apasă butonul de ieșire din aplicație (butonul marcat cu 2 în Figura 6);

Elementele invizibile ale ecranului principal, dar de o importanță deosebită:

– componenta Clock care se trezește din 1.5 secunde în 1.5 secunde și verifică dacă bluetooth-ul este activ pe dispozitiv și dacă este conectat la bluetooth-ul din casă. După acțiunea de verificare, setează corespunzător cele doua etichete de stare (vezi Figura 6 elementele 3 și 4);

– componenta TinyDB care stochează o mulțime de informații foarte importante ce se impartășesc între ecrane. Pentru a exemplifica importanța acestei componente trebuie menționat că fară ea, păstrarea conexiunii bluetooh după tranziționarea în alt ecran ar fi fost imposibilă deoarece adresa MAC a dispozitivului pereche din ecranul principal s-ar fi pierdut la trecerea în oricare alt ecran;

– componenta BluetoothClient fără de care aplicația mobilă nu ar fi putut comunica cu aplicația de pe microcontroler. Am ales componenta aceasta pentru că aplicația mobilă se comportă ca un client ce inițiază comenzi către bluetooth-ul legat la placa cu microcontroler;

– componenta ActivityStarter folosită pentru a iniția o cerere de activare către modulul bluetooth de pe smartphone atunci cand se intră în aplicație cu bluetooth-ul oprit sau când se apasă butonul de activare bluetooth și el este oprit.

4.4.2 Ecranul de setare a culorii

Acest tip de ecran se regăsește în patru exemplare în aplicație, deoarece am decis că trebuie oferite aceleași opțiuni de configurare a culorii luminii ambientale în oricare cameră din cele patru existente. Diferența din punct de vedere grafic între aceste ecrane este doar mesajul de “Bine ati venit in camera numarul x”, unde x este numărul camerei.

Interfața grafică oferită utilizatorului în ecranul de setare a culorii este ilustrată în figura următoare:

Figura 7 Elemente grafice evidențiate ale ecranului secundar de setare al culorii

Ecranul de setare a culorii cuprinde următoarele elemente grafice vizibile:

– buton cu funcție de mers înapoi către ecranul principal (elementul grafic 1 din Figura 7), util pentru situațiile în care utilizatorul vrea să schimbe camera în care iși va configura lumina ambientală sau vrea să schimbe luminozitatea într-una din cele patru camere;

– buton cu funcție de ieșire din aplicație (elementul grafic 2 din Figura 7);

– etichetă cu mesaj static care întotdeauna afișează mesajul: “Alegeți culoarea dorită:” (elementul grafic 3 din Figura 7);

-15 butoane de setare a culorii luminii ambientale pe 15 culori diferite (un astfel de buton este elemenul grafic 4 din Figura 7);

– etichetă de confirmare a setării cu secces a culorii în cameră (elementul grafic 5 din Figura 7);

– buton cu funcție de stingere a luminilor ambientale doar în camera corespunzătoare ecranului pe care utilizatorul l-a accesat (elementul grafic 6 din Figura 7);;

– buton cu funcție de aprindere implicită a luminii ambientale pe culoare albastru (pentru situația în care se intră pentru prima dată în aplicație și nu a fost setată nici o culoare până în momentul curent) și cu funcție de aprindere pe ultima culoare setată înainte de stingere pentru cazul în care s-a setat cel puțin o dată culoarea de când a fost instalată aplicația și până în momentul curent (elementul grafic 7 din Figura 7);

– notificator de confirmare a ieșirii din aplicație. Acesta apare doar în situația în care utilizatorul apasă butonul de ieșire din aplicație (butonul marcat cu 2 în Figura 6);

– notificator ce avertizează utilizatorul în cazul în care apasă orice buton de pe interfața ecranului (exluzând cel de mers înapoi și cel de îeșire din aplicație) cât timp bluetooth-ul nu este conectat cu nicun dispozitiv sau este chiar dezactivat. Notificatorul devine vizibil doar în asemenea situații.

Elemente invizibile ale ecranului de setare a culorii, dar fără de care funcționarea ar fi fost compromisă, sunt:

– componenta Clock care se trezește din 1.5 secunde în 1.5 secunde și verifică dacă bluetooth-ul este activ pe dispozitiv și dacă este conectat la bluetooth-ul din casă. După acțiunea de verificare, dacă această componentă a identificat că bluetooth-ul este inactiv sau nu este conectat cu niciun alt dispozitiv, va dezactiva toate butoanele de pe ecran cu excepția celor de mers înapoi și de ieșire din aplicație și va notifica utilizatorul cu privire la situație.

– componenta TinyDB care stochează o mulțime de informații foarte importante ce se impartășesc între ecrane. Importanța componentei a fost exemplificată anterior la ecranul principal. De menționat este faptul că această componentă este comună tuturor ecranelor.

– componenta BluetoothClient fără de care aplicația mobilă nu ar fi putut comunica cu aplicația de pe microcontroler. Rolul componentei a fost descris anterior la ecranul principal.

De menționat este faptul că această componentă este comună tuturor ecranelor.

4.4.3 Ecranul de setare a luminozității

Ecranul de setare a luminozității oferă utilizatorului posibilitatea să schimbe luminozitatea în oricare cameră din cele patru. Acest ecran capătă diferite aspecte în funcție de numărul camerei introdus în caseta de text ce apare de fiecare dată la intrarea în ecran.

De fiecare dată când utilizatorul intră în ecranul de setare a luminozității, va apărea o notificare pentru alegerea camerei, așa cum se vede în figura de mai jos:

Figura 8 Notificare pentru alegere cameră în ecranul de setare a luminozității

Am adoptat această abordare pentru ecranul de setare a luminozității deoarece am considerat-o mai practică și evită utilizarea mai multor ecrane pentru setarea luminozității. Astfel, avem doar un singur ecran care poate avea diferite aspecte, minimizând dimensiunea aplicației.

Așadar, alegerea pe care utilizatorul o va face aici, va determina aspectul ecranului de setare a luminozității, activându-se doar elementele grafice corespunzătoare camerei cu numarul introdus. Cu alte cuvinte, dacă în caseta de text din Figura 8 se introduce cifra 1 și a fost luminozitatea a fost setată înainte la 48%, atunci ecranul de luminozitate va căpăta un aspect ca cel din stânga din figura ce urmează:

Figura 9 Ecranul de setare a luminozității cu sliderul pentru camera 1 activ (partea stângă) și sliderul pentru camera 2 activ (partea dreaptă)

Dacă în caseta de text din Figura 8 se introduce cifra 2 și înainte s-au stins luminile în camera 2 sau nu s-au aprins luminile niciodată până în momentul curent în camera 2, ecranul de luminozitate va căpăta un aspect ca cel din partea dreaptă Figura 9.

Prin analogie, daca se introduce 3 în caseta de text și înainte s-au stins luminile în camera 3 sau nu s-au aprins luminile niciodată până în momentul curent în camera 3, aspectul ecranului de setare a luminozității va fi cel din partea stângă Figura 10.

Daca s-a introdus 4 în caseta de text si aceleași condiții sunt îndeplinite pentru camera 4 (nu s-au aprins luminile niciodată până în momentul curent în camera 4 sau au fost stinse înainte), atunci ecranul de setare a luminozității va arăta cel din partea dreaptă Figura 10.

Figura 10 Ecranul de setare a luminozității cu sliderul pentru camera 3 activ (partea stângă) și sliderul pentru camera 4 activ (partea dreaptă)

Elemente grafice vizibile care alcătuiesc ecranul de setare a luminozității:

– buton cu funcție de mers înapoi către ecranul principal (elementul grafic 3 din Figura 10), util pentru situațiile în care utilizatorul vrea să schimbe camera în care iși va configura lumina ambientală sau vrea să schimbe luminozitatea într-una din cele patru camere;

– buton cu funcție de ieșire din aplicație (elementul grafic 4 din Figura 10);

– patru etichete cu mesaj static care întotdeauna afișează mesajul “Alegeți luminozitatea în camera x”, unde x este 1, 2, 3 sau 4 (un exemplu este elementul grafic 5 din Figura 10);

– patru etichete cu mesaj static care întotdeauna afișează mesajul “Întunecat” (vezi elementul grafic 7 din Figura 10);

– patru etichete cu mesaj static care întotdeauna afișează mesajul “Luminos” (vezi elementul grafic 8 din Figura 10);

– patru slidere pentru setarea luminozității, câte unul pentru fiecare cameră (vezi elementele grafice 1 și 2 din Figura 9 și elementele grafice 1 și 2 din Figura 10);

– etichetă de confirmare a setării luminozității la poziția corespunzătoare sliderului în camera corespunzătoare acestuia (vezi elementul grafic 6 din Figura 10);

– notificator pentru alegerea camerei care apare de fiecare dată când se intră în ecranul de setare a luminozității (vezi elementul grafic 1 din Figura 8);

– notificator de confirmare a ieșirii din aplicație. Acesta apare doar în situația în care utilizatorul apasă butonul de ieșire din aplicație (butonul marcat cu 4 în Figura 10);

– notificator de avertizare pentru utilizator în cazul în care acesta introduce în caseta de text din Figura 8 orice altceva în afară de 1, 2, 3 sau 4 (variantele valide). Acest notificator devine vizibil doar în această situație și resetează caseta de text pentru o nouă introducere;

– notificator ce avertizează utilizatorul dacă bluetooth-ul s-a dezactivat pe dispozitiv sau dacă s-a întrerupt conexiunea. Acest notificator, pe langă faptul ca afișează un mesaj pentru utilizator va și dezactiva sliderele de pe ecran;

Elemente invizibile ale ecranului de setare a luminozității, dar esențiale în funcționarea aplicației, sunt:

– componenta Clock care se trezește din 1.5 secunde în 1.5 secunde și verifică dacă bluetooth-ul este activ pe dispozitiv și dacă este conectat la bluetooth-ul din casă. După acțiunea de verificare, dacă această componentă a identificat că bluetooth-ul este inactiv sau nu este conectat cu niciun alt dispozitiv, va lansa în execuție notificatorul ce va dezactiva toate sliderele de pe ecran și va lăsa active butoanele de mers înapoi și de ieșire din aplicație;

– componenta TinyDB (componentă comună ecranelor, discutată și în cadrul celorlalte ecrane);

– componenta BluetoothClient (componentă comună ecranelor, discutată și în cadrul celorlalte ecrane);

O proprietate importantă a elementului grafic slider de pe ecranul de setare a luminozității este plaja de valori pe care le poate lua poziția sliderului și care este cuprinsă între 0 și 255 (0 însemnând luminozitate 0% în cameră, iar 255 însemnând luminozitate 100%).

4.5 Prezentarea algoritmului implementat în App Inventor 2

Algoritmul implementat în App Inventor 2 este unul bazat pe evenimente precum apăsări de butoane, scurgerea unui timer, inițializarea unui ecran, schimbarea poziției unui slider, etc.

La apariția unor astfel de evenimente, principala acțiune pe care aplicația mobilă realizată cu App Inventor 2 o face este să trimită diferite comenzi modulului bluetooth conectat la placa cu microcontroler. Acțiuni secundare pe care aplicația mobilă le face sunt diverse memorări în baza de date TinyDB și afișarea diverselor mesaje de confirmare.

Un lucru important de menționat pentru aplicațiile dezvoltate cu App Inventor 2 este că tratează fiecare ecran ca o miniaplicație separată de restul ecranelor. Această lacună a limbajului obligă dezvoltatorul aplicației ca adresa MAC a dispozitivului bluetooth pereche să fie în permanență disponibilă într-o bază de date (TinyDB), iar atunci când se iasă dintr-un ecran dezvoltatorul trebuie să implementeze o acțiune de deconectare de la bluetooth-ul pereche și la intrarea în celălalt ecran să se reconecteze la dispozitivul bluetooth cu adresa MAC memorată în baza de date.

Când aplicația mobilă este instalată și apoi deschisă pentru prima dată, componenta TinyDB este goală, dar un atu foarte important al componentei este că atunci cand se iasă din aplicație toate datele se păstrează intacte în baza de date și sunt gata de utilizare la următoarea accesare a aplicației.

Algoritmul propriu-zis

Am decis fragmentarea algoritmului în funcție de tipurile de ecrane. Așadar vom avea trei secțiuni de algoritmi care împreună alcatuiesc întregul algoritm al aplicației mobile.

Algoritmul aferent ecranului principal

Descrierea algoritmului ecranului principal începe prin ilustrarea organigramei acțiunilor realizate la inițializarea acestuia.

Figura 11 Organigrama procedurii de inițializare a ecranului principal

După finalizarea procedurii de inițializare a ecranului, aplicația începe ”să asculte” după evenimente care se petrec în cadrul interfeței ecranului principal.

În figura ce urmează se prezintă scurta organigramă a acțiunilor ce se produc în momentul selectării unui buton de tranziționare în alt ecran, fie că este vorba de un buton de trecere în ecran de setare a culorii (vezi elementul grafic 7, 8, 9 sau 10 din Figura 6), fie că este vorba de unul de trecere în ecran de setare a luminozității (vezi elementul grafic 11 din Figura 6).

Figura 11 Organigrama procedurii de tranziționare în alt ecran

În Figura 11, ca și penultimă acțiune în organigramă se observă deconectarea de la bluetooth-ul din casă. Această acțiune este necesară datorită faptului că App Inventor 2 consideră ecranele miniaplicații independente. Pentru a reface conexiunea, după deschiderea ecranului în care aplicația s-a tranziționat, se va efectua o acțiune de reconectare cu modulul bluetooth a cărei adresă a fost reținută în TinyDB (secțiunea de memorare a adresei modului bluetooh poate fi văzută în Figura 12).

Următoarea figură ilustrează acțiunile ce se execută la apăsarea butonului de alegere a unui modul bluetooth cu care bluetooth-ul de pe dispozitivul mobil să se împerecheze (vezi elementul grafic 5 din Figura 6).

Figura 11 Organigrama procedurii de alegere a dispozitivului bluetooth pereche

Se observă în cadrul acestei figuri, că acțiunea de memorare a adresei bluetooth-ului conectat la placa de dezvoltare se execută înaintea apelului funcției de conectare, asta deoarece am observat în urma testelor efectuate că după momentul în care cele două despozitive se conectează, adresa bluetooth-ului selectat pentru conectare din lista de dispozitive (lista care se încarcă la apăsarea butonului de conectare) nu mai poate fi recuperată pentru memorarea acesteia în baza de date.

Butonul de ieșire din aplicație cât și butonul hardware de mers înapoi al dispozitivului mobil execută aceleați acțiuni în cadrul ecranului principal, așadar vor avea aceeași organigramă a acțiunilor pe care le lansează în execuție.

În figura ce urmează este prezentat firul acțiunilor provocat de apăsarea butonului de ieșire din aplicație (vezi elementul grafic 2 sin Figura 6) sau de apăsarea butonului hardware de înapoi de pe smartphone, tabletă sau notebook.

Figura 12 Organigrama procedurii de ieșire din aplicație

Se observă în organigrama de mai sus că se previne ieșirea involuntară din aplicație în cazul în care utilizatorul apasă neintenționat butonul de ieșire din aplicație sau pe cel de înapoi de pe dispozitivul mobil. În conformitate cu organigrama din Figura 12 se poate observa că acțiunea de deconectare de la bluetooth-ul din casă se poate realiza atât manual la cererea utilizatorului, cât și automat în momentul ieșirii din aplicație.

Pentru evenimentul de apăsare a butonului de activare a bluetooth-ului pe dispozitivul mobil (vezi elementul grafic 1 din Figura 6) nu este necesară ilustrarea unei organigrame deoarece acțiunea pe care acest tip de eveniment o lansează în execuție este doar cea de a trimite o cerere de activare a funcției bluetooth către sistemul Android.

Pentru evenimentul de apăsare a butonului de deconectare a bluetooth-ului de pe dispozitivul mobil (vezi elementul grafic 6 din Figura 6), în figura urmatoare se definește organigrama acțiunilor:

Figura 13 Organigrama procedurii de deconectare

Se observă în organigrama din Figura 13 că, la fel ca și în cazul acțiunii de ieșire din aplicație, aici se previne deconectarea involuntară în cazul în care utilizatorul apasă neintenționat butonul de deconectare a bluetooth-ului de pe smartphone/ tabletă/ notebook de la bluetooth-ul cu care este împerecheat.

Când utilizatorul confirmă că vrea să se deconecteze de la dispozitivul bluetooth prin apăsarea butonului “DA” din cele două variante posibile, atunci se declanșează apelul funcției de deconectare de la bluetooth-ul pereche.

Nu în ultimul rând este necesară ilustrarea organigramei acțiunilor efectuate la apăsarea butonului de stingere a luminilor din toată casa (vezi elementul grafic 13 din Figura 6).

Figura 14 Organigrama procedurii de stingere a luminilor în toată casa

De menționat este faptul că afișarea celor două tipuri de mesaje din organigrama de mai sus se face în eticheta de confirmare a stingerii luminilor din toată casa (vezi elementul grafic 12 din Figura 6).

Algoritmul aferent ecranului de setare a culorii

Descrierea algoritmului ecranului de setare a culorii începe prin ilustrarea organigramei acțiunilor realizate la inițializarea acestuia.

În figura ce urmează sunt ilustrate acțiunile care sunt lansate în execuție la inițializarea ecranului.

Figura 15 Organigrama procedurii de inițializare a ecranului de setare a culorii

De remarcat în această figură, că mesajul furnizat utilizatorului este diferit în cazul în care bluetoot-ul de pe dispozitivul mobil se dezactivează, față de cazul în care se pierde conexiunea (acoperind aici și cazul în care bluetooth-ul din casă nu mai răspunde din diverse motive).

Spre deosebire de cazul ecranului principal unde butonul fizic de mers înapoi de pe dispozitivul mobil avea aceeași funcție ca și cel de ieșire din aplicație, în cazul ecranului de setare a culorii, butonul fizic de mers înapoi are aceeași funcție cu cel software de mers înapoi (vezi elementul grafic 1 din Figura 7). Prin urmare organigramele acțiunilor declanșate de apăsarea acestor două tipuri de butoane sunt identice.

Organigrama din figura de mai jos este aplicabilă evenimentului de apăsare a butonului de mers înapoi (fie că vorbim de butonul software al ecranului fie că vorbim de cel hardware al dispozitivului).

Figura 16 Organigrama procedurii de mers înapoi la ecranul principal

Una dintre asemănările ecranului de setare a culorii cu ecranul principal este cea că ambele conțin buton de ieșire din aplicație. Acest buton are funcții identice în toate ecranele aplicației, așadar organigrama procedurii de ieșire din aplicație rămâne neschimbată (vezi Figura 12).

Fiecare buton de setare de culoare din cele 15 existente pe interfața ecranului, declanșează aceleași tipuri de acțiuni să fie executate. Diferențele constă în conținutul șirului de caractere trimis către dispozitivul bluetooth din casă (de exemplu dacă se apasă butonul de culoare albastru și suntem în camera 1 pe luminozitate 10% se va trimite “albastruSts10”, cu precizarea că “Sts” simbolizează stănga sus adică poziția camerei 1).

În figura ce urmează este ilustrată organigrama procedurii de setare a unei culori într-una din cele patru camere ale casei. Acestă procedură se pornește în momentul în care se apasă un buton din matricea de culori (en exemplu este elementul grafic 4 din Figura 7).

Figura 17 Organigrama procedurii de setare a unei culori

După cum se poate observa, acțiunile de verificare a stării dispozitivului bluetooth și a stării conexiunii stabilite între cele două dispozitive sunt necesare de fiecare dată cand un buton de setare a culorii este apăsat.

Referitor la poziția sliderelor de luminozitate, în baza de date TinyDB se păstrează întotdeauna poziția fiecărui slider din cele patru și se păstrează și o copie a lor atunci când se dă comandă de stingere lumini (fie că este comadă de stingere într-o cameră sau în toată casa) pentru ca atunci când se apasă vreunul din butoanele de setare a culorii să se aprindă lumina la intensitatea luminoasă de dinaintea stingerii acesteia.

În figura ce urmează este reprezentată organigrama procedurii de aprindere a luminii ambientale pe ultima culoare setată. Execuția aceastei proceduri este declanșată de apăsarea butonului de aprindere lumini (vezi elementul grafic 7 din Figura 7).

Figura 18 Organigrama procedurii de reaprindere a luminilor pe ultima culoare setată

Atunci când unul din butoanele de setare a culorii din matricea de culori este apăsat, se reține într-o variabilă globală culoarea aprinsă pentru ca atunci când se apasă butonul de aprindere lumini să poată fi aprinsă lumina ambientală pe ultima culoare setată înainte de stingere.

În cadrul ecranului de setare a culorii se mai resăsește un ultim tip de buton care provoacă stingerea luminilor ambientale în camera corespunzătoare ecranului deschis. Acest buton de stingere a luminilor provoacă executarea unei serii de acțiuni care sunt prezentate în organigrama ce urmează.

Figura 19 Organigrama procedurii de stingere a luminilor într-o cameră

Se observă că nu din toate acțiunile terminale se revine la așteptarea reapariției unui eveniment pe interfața grafică a ecranului de setare a culorii. Pentru cazul când bluetooth-ul nu este activ sau nu este conectat cu cel din casă se va afișa un mesaj corespunzător, dar mai mult de atât, se vor dezactiva toate butoanele de pe ecran exceptând pe cel de mers înapoi și cel de ieșire din aplicație. Așadar, datorită acțiunilor de dezactivare a butoanelor nu se poate spune că se mai așteaptă apariția vreunui eveniment de stingere a luminilor din cameră, acesta fiind motivul pentru care săgeata de la acțiunea de afișare a mesajului la cea de așteptare a evenimentului lipsește.

De menționat că, în cadrul ecranului de setare a culorii, pe lângă acțiunile de verificare a stării conexiunii și a stării bluetooth-ului de fiecare dată când se apasă un buton, mai există un mecanism de verificare a acestor stări cu periodicitate de 1.5 secunde. Prin urmare, dacă se dezactivează bluetooth-ul de pe dispozitivul mobil sau dacă se va întrerupe conexiunea bluetooth între cele două module, utilizatorul va fi notificat în acest sens chiar dacă nu apasă niciun buton de pe interfață. Acesta a fost principalul scop al utilizării componentei de clock cu periodicitate de 1.5 secunde.

Algoritmul aferent ecranului de setare a luminozității

Ecranul de setare a luminozității cuprinde cele două interfețe, cea de alegere a camerei (vezi Figura 8) și cea de setare a luminozității din slidere (vezi Figura 9 și Figura 10).

Înterfața de alegere a camerei în care se dorește setarea luminozității, este lansată în execuție de fiecare dată la inițializarea ecranului (altfel spus de fiecare dată când se intră în ecranul de setare a luminozității).

Figura 19 Organigrama procedurii de inițializare a ecranului de setare a luminozității

În Figura 19 se descrie organigrama procedurii de inițializare a ecranului de luminozitate, cuprinzând aici și acțiunea de afișare a notificatorului în care utilizatorul iși alege camera. Se observă că din momentul alegerii camerei algoritmul merge pe ramuri diferite și interfața ecranului va arăta diferit în funcție de alegerea făcută.

La fel ca și celelalte ecrane și cel de luminozitate conține buton de mers înapoi la ecranul principal (vezi elementul grafic 3 din Figura 10) și buton de ieșire din aplicație (vezi elementul grafic 4 din Figura 10). Ilustrarea acțiunilor declanșate de apăsarea acestor două butoane este redundantă deoarece a fost făcută anterior în cadrul celorlalte două ecrane (vezi Figura 16 și Figura 12).

O serie de acțiuni importante sunt lansate în execuție în momentul în care poziția unui slider de luminozitate este schimbată prin atingerea ecranului. Seria aceasta de acțiuni precum și ordinea lor de execuție este reprezentată in figura ce urmează.

Figura 20 Organigrama procedurii de schimbare a luminozității

Am decis reprezentarea algoritmilor celor trei tipuri de ecrane prin organigrame pentru a ușura înțelegerea algoritmilor și a avea o bună viziune asupra modului în care ei au fost gândiți.

Acești algoritmi se îmbină și comunică cu algoritmul implementat în cod Arduino software care va fi prezentat în capitolul 3.7.

3.6 Prezentarea generală a utilitarului Arduino software

Arduino software este un mediu de dezvoltare oferit de către producătorii plăcilor de dezvoltare Arduino și este special destinat dezvoltării programelor software pentru astfel de dispozitive programabile. Acest mediu de dezvoltare pune la dispoziție o mulțime de API-uri (Application Programming Interface) care vin în ajutorul programatorului, simplificând procesul de dezvoltare.

Structura unui program descris prin intermediul Arduino software, structură care se regăsește și în cadrul proiectului prezent, cuprinde următoarele secțiuni principale:

– secțiunea de declarații de date inclusiv declarații de noi comunicații seriale create situată înainte de metoda de “setup”. Tot în cadrul acestei secțiuni se includ si fișierele header;

-secțiunea de inițializare de date declarate mai sus;

-secțiunea de cod propriu-zis reprezentată de corpul metodei “loop”. Aici se regăsește întregul cod ce rulează în microcontroler în buclă infinită.

3.7 Prezentarea algoritmului implementat în Arduino software

Așa cum am menționat și in paginile anterioare, sistemul software al proiectului este format din cele două module: modulul software din aplicația mobilă și modulul software embedded ce rulează pe placa cu microcontroler.

Așa cum modulul sofware din aplicția mobilă are sarcina de a prescrie comenzi și a le trimite prin bluetooth către microcontroler, modulul software embedded are sarcina de a recepționa comenzile și a le procesa.

Reamintirea comenzilor pe care microcontrolerul le urmărește pentru procesare

Comenzile de la aplicația mobilă vin sub forma unui model atât cele de setare culoare cât și cele de setare de luminozitate respectă modelul:

String de comandă=“Denumire culoare” + “poziție cameră” + “valoare luminozitate”;

Comanda de stingere a luminilor în toată casa este “Stinge” , iar cea de stingere a luminilor doar într-o cameră este de forma:

String de comandă= “Stinge” + “Poziție cameră”;

Comanda de cedare prioritate comutatoarelor este de forma“Comutator” + “Poziție cameră”, iar cea de cedare prioritate sliderelor din aplicație este de forma “Slider” + “Poziție cameră”.

Mai întâi tratăm partea de achiziție de date. Din punct de vedere al plăcii de dezvoltare Arduino Mega există cinci furnizori de informație: modulul bluetooth serial și cele patru comutatoare rotative.

Detalierea părții de achiziție de date de la modulul bluetooth.

Algoritmul implementat în microcontroler pentru acest proiect folosește metoda pooling, microcontrolerul întrebând la fiecare ciclu al buclei infinite dacă a venit vreo informație în bufferul de intrare dedicat comunicației seriale. Având în vedere că informațiile de la aplicația mobilă vin sub formă de șiruri de caractere, iar utilitarul Arduino software pune la dispoziție o metodă care citește doar caracter cu caracter datele din bufferul comunicației seriale, a fost nevoie de o buclă pentru concatenarea caracter cu caracter a informației primită serial cu scopul de a achiziționa o informație corectă.

Detalierea părții de procesare a datelor venite de la aplicație prin bluetooth.

După ce microcontrolerul achiziționează o informație validă, o compară în primul rând cu stringul “Stinge” pentru a vedea dacă este o comandă de stingere totală. În cazul în care este, microcontrolerul va comanda nivel logic 0 pe cei 12 pini ai portului de ieșire analogic (12 pini deoarece sunt 4 camere, fiecare cu câte 3 canale de comandă – roșu, verde și albastru).

Dacă nu este o comandă de stingere totală se verifică dacă este comandă de stingere lumini într-o cameră anume, stingerea acționându-se similar pe pinii corespunzători camerei cerute.

Dacă nu este nici o comandă de stingere a luminii într-o cameră, atunci microcontrolerul începe să verifice dacă este o comandă de setare culoare sau de setare luminozitate. În cazul în care este, fragmentează comanda în 3 bucăți pentru a constata:

care este culoarea ce trebuie aprinsă;

care este camera în care trebuie comandată culoarea și luminozitatea;

care este intensitatea luminoasă cerută în cameră.

Pentru fiecare culoare din cele 15 disponibile pe ecranul de culori, am asociat 3 ponderi independente, câte una pentru fiecare canal de culoare fundamentală din cele trei (vezi tabelul de ponderi de la capitolul 4.1). Aceste ponderi sunt raportate la valoarea intensității cerute și reprezintă numere între 1 și 255 cu precizarea ca ponderea 1 este considerată cea mai mare și ponderea 255 este considerată cea mai mică (ponderea 0 nu este folosită). Așadar după fragmentarea comenzii și extragerea celor 3 date relevante (culoare, pozișie cameră și intensitate), în cazul în care s-a primit comandă de setare a unei culori pentru camera 1 de exemplu, microcontrolerul va pune pe fiecare pin din cei 3 pini de culoare ai camerei 1 o valoare analogică calculată simplu astfel:

“valoare = intensitate / pondere” (3-1)

unde intensitate este intensitatea obținută în urma fragmentării comenzii și pondere este valoarea brută a ponderii luată din tabelul de ponderi (vezi capitolul 4.1). Acestea au fost cazurile în care se cere setare unei culori fie compusă fie fundamentală de la aplicația mobilă. Pentru setarea în cameră a unei culori fundamentale ponderea celorlalte două culori fundamentale nefolosite este aproximativ nulă și formula “valoare = intensitate / pondere” se poate aplica în continuare cu precizarea că ponderea celor două culori fundamentale rămase neutilizate este 255 (sau în procente 0.39%). Astfel pentru setarea culorilor fundamentale, pe pinul de comandă al culorii respective se pune chiar valoarea intensității (deoarece pondere fiind 1 rezultă că valoare=intensitate), iar pe ceilalți doi pini din cei trei ce formeză culoarea se pune chiar valoarea intensității împărțită la 255 (255 fiind cea mai mică pondere posibilă).

Revenind la cazurile de interpretare a comenzii, dacă aceasta nu este nici o comandă de setare de culoare atunci se verifică daca este o comandă de cedare prioritate către slider sau către comutator. Dacă este comandă de cedare prioritate către slider (“Slider”+“Poziție cameră”), atunci se setează un flag care sare peste citirea comutatoarelor, ignorăndu-le starea. Acest flag este resetat pe 0 atunci când vine o comandă de cedare prioritate către comutator (“Comutator”+“Poziție cameră”).

Funcțiile de fade_in și fade_out specifice fiecărei camere

În momentul în care utilizatorul dorește să schimbe culoarea într-una din camere folosind unul din ecranele de setare a culorii, se apelează funcția de ”fade_out” apoi funcția de ”fade_in”.

Așadar vechea culoare începe să se stingă ajungând la 0 în doar doua secunde, iar noua culoare începe să se aprindă ajungând în doua secunde la ultima luminozitate setată.

Funcția de ”fade_out” primește ca parametri cele trei valori de intensități luminoase corespunzătoare celor trei culori fundamentale care alcătuiesc vechea culoare, adică nuanța din care se pornește tranziționarea. Plecând de la aceste trei valori, se decide care este cea mai mare, care este cea mijlocie și care este cea mai mică.După această determinare se pleacă de la cea mai mare valoare intensitate până la valoarea mijlocie scăzându-se în acest interval doar intensitatea cea mai mare cu 0.1 unități la fiecare interval de timp de 200/cea_mai mare_intensitate milisecunde. Când valoarea care era cea mai mare ajunge egală cu valoarea intensității mijlocii (care corespunde unei alte culori fundamentale ce alcătuiește vechea culoare), se scade 0,1 unități atât din valoarea cea mai mare cât și din valoarea mijlocie până se ajunge ca ambele intensități sa fie egale cu cea mai mică valoare de intensitate. Când cele doua valori ajung egale cu cea mai mică intensitate, se scad 0,1 unități din toate cele trei valori (valoare=intensitate corespunzătoare unei culori fundamentale) până se ajunge la valoarea 0.

De menționat că la fiecare pas de descreștere a intensității se acționează ledurile cu valoarea actualizată a intensității cu scopul de a creea efectul de atenuare pentru vechea culoare.

Funcția de ”fade_in” primește ca parametri cele trei valori de intensități luminoase corespunzătoare celor trei culori fundamentale care alcătuiesc noua culoare comandată de utilizator din aplicație. De data aceasta se pleacă de la zero și se merge până la cea mai mare valoare de intensitate. Algoritmul merge în sens invers față de cel de la ”fade_out”.

Ca o exemplificare a modului de tranziționare a unei culori într-o altă culoare, să considerăm că în camera numărul 1 avem culoarea turcoaz în care presupunem că ponderea de roșu egală cu 3, cea de verde egală cu 2 și cea de albastru egală cu 1 (asta înseamnă că ponderea de albastru este cea mai mare). Luminozitatea curentă o considerăm 40% (însemnând aproximativ 100 pe o scară de la 0 la 255). Utilizatorul dorește să seteze culoarea magenta care presupunem ca are ponderea de roșu egală cu 1, cea de verde egală cu 2 și cea de albastru egală cu 3. Când utilizatorul apasă butonul, se apelează funcția de ”fade_out”.

– În pasul 1 al acestei funcții se pornește de la valoarea 100/1 și se decrementează cu 0.1 intensitatea de albastru până ajunge a fi egala cu 100/2 care este valoarea intensității de verde din culoarea turcoaz. La fiecare pas de descreștere se introduce un delay de 200/100 ms;

– În pasul 2 al acestei funcții se pornește de la valoarea 100/2 și se decrementează cu 0.1 intensitatea de alastru și de verde până ambele ajung a fi egale cu 100/3 care este valoarea intensității de roșu din culoarea turcoaz. La fiecare pas de descreștere se introduce un delay de 200/100 ms;

– În pasul 3 al acestei funcții se pornește de la valoarea 100/3 și se decrementează cu 0.1 intensitatea de albastru, verde și roșu până toate trei ajung a fi egale cu 0. La fiecare pas de descreștere se introduce un delay de 200/100 ms.

În acest moment culoarea turcoaz a fost stinsă în camera numărul 1.

Se iese din apelul funcției de ”fade_out” și se intră în apelul funcției de ”fade_in”.

În interiorul funcției ”fade_in” se execută următorii pași:

– În pasul 1 se pornește de la valoarea 0 cu toate întensitățile luminoase corespunzătoare celor trei culori fundamentale. Se incrementează cu 0.1 fiecare intensitate din cele 3 până se ajunge la valoarea 100/3 care reprezintă intensitatea culorii albastru corespunzătoare culorii magenta. La fiecare pas de creștere se introduce un delay de 200/100 ms;

– În pasul 2, se pornește de la valoarea 100/3 și se incrementează cu 0.1 doar intensitătile de verde și roșu până se ajunge la valoarea 100/2 care reprezintă valoarea intensității de verde din culoarea magenta. La fiecare pas de creștere se introduce un delay de 200/100 ms;

– În pasul 3, se pornește de la valoarea 100/2 și se incrementează cu 0.1 doar intensitatea de roșu până se ajunge la valoarea 100/1 care este valoarea intensității de roșu corespunzătoare culorii magenta. La fiecare pas de creștere se introduce o întârziere de 200/100 ms.

După executarea acestor pași, în camera numărul 1 este aprinsă culoarea magenta.

Ca o verificare a faptului că acțiunea de scădere în intensitate a culorii vechi și cea de creștere în intensitate a culorii noi durează 2 ssecunde, ne raportăm la exemplul dat.

La stingere, în priml pas, la fiecare 0.1 unități scăzute se stă 2 ms, ceea ce înseamnă ca pentru a ajunge de la 100 unități la 50 unități se va sta 1 secundă. La pasul doi, pentru a ajunge de la 50 unități la 33.33 unități se va sta 166.7 milisecunde. La pasul trei, pentru a ajunge de la 33.33 unități la 0 se va sta 333.3 milisecunde. Deci acțiunea de stingere a culorii vechi va dura 1000ms+166.7ms+333.3ms = 2000ms = 2 ssecunde.

La aprindere, suma finală va fi tot de 2 ssecunde pentru aprinderea culorii noi.

Acesta a fost rezumatul achiziționării, procesării și interpretării datelor provenite de la aplicația mobilă prin bluetooth-ul conectat la placa cu microcontroler.

Partea de achiziție de date primite de la cele 4 comutatoare.

Detalierea acestei părți este relevant a fi făcută doar pentru un comutator, prin analogie principiul se extinde și la celelalte trei comutatoare.

Un lucru foarte important este faptul că valorile comutatoarelor se citesc cât timp nu au fost inhibate de aplicație.

Pentru un comutator (fiecare prezintă 6 pini de poziție și unul pentru mărimea permutată) au fost configurați pinii de poziție (prin software-ul aplicației dezvoltată în Arduino software) ca fiind pini cu pull up. Deci, pentru fiecare comutator se citesc pe cei cinci pini digitali corespunzători de intrare în placă, urmatoarele valori posibile:

011111, când comutatorul este în poziția 0 (însemnând 0% luminozitate);

101111, când comutatorul este în poziția 1 (însemnând 20% luminozitate);

110111, când comutatorul este în poziția 2 (însemnând 40% luminozitate);

111011, când comutatorul este în poziția 3 (însemnând 60% luminozitate);

111101, când comutatorul este în poziția 4 (însemnând 80% luminozitate);

111110, când comutatorul este în poziția 5 (însemnând 100% luminozitate).

Partea de procesare a datelor venite de la comutatoare.

După ce datele sunt achiziționate de la portul digital, luminozitatea este actualizată cu valoarea corespunzătoare (cea din parantezele de mai sus) respectându-se în continuare formula (1-1). Singura precizare este că acum valoarea intensității din formulă este cea definită de poziția comutatorului. După cum se observă, nu există decat șase trepte de luminozitate cu tot cu cea de oprire. Algoritmul face ca după procesare, microcontrolerul să trimită comenzi către drivere la orice schimbare de poziție observată pe comutator, așadar nu trimite comenzi încontinuu.

Algoritmul implementat în placa de dezvoltare cu microcontroler dă sens comenzilor recepționate prin bluetooth sau de la comutatoare. Practic compară aceste comenzi cu tipurile comenzilor la care el se așteaptă și când găsește o potrivire, procesează comanda și scoate pe portul analogic de ieșire o comanda corespunzătoare către driverele de leduri.

Acesta a fost nucleul algoritmului implementat în Arduino software.

4 Rezultate experimentale

Interpretarea rezultatelor experimentale a fost baza stabilirii culorilor în cadrul acestui proiect de control al luminilor ambientale. Acest pas este foarte important și a fost executat încă din stadii incipiente ale proiectului. Prin urmare, la inceputul dezvoltării proiectului, am efectuat încărcări de programe foarte simple pe placă ce conțineau doar trei comenzi (câte una de aprindere pentru fiecare culoare fundamentală), cu scopul de a stabili experimental, vizual, ponderile fiecărei culori fundamentale în cadrul unei culori complexe. Astfel am obținut tabelul de ponderi RGB (Red Green Blue) care urmează.

4.1 Tabel de ponderi RGB stabilite experimental

Tabelul de ponderi este alcătuit din valorile ponderilor fiecărei culori fundamentale în cadrul unei culori compuse (ca de exemplu mov, magenta, roz, etc). Aceste ponderi sunt raportate în permanență la valoarea intensității luminoase. Tabelul conține atât ponderea ca și valoare brută (valoare la care se împarte intensitatea comandată) cât și ponderea ca procent din luminozitate (cât la sută reprezintă ponderea din valoarea intensității comandate – valoarea aflată între paranteze este ponderea în procente).

Tabelul 1 Ponderi RGB stabilite vizual experimental

Partea de comandare a ledurilor implementată în Arduino softwarese bazează pe valorile din acest tabel și pe formula (1-1).

4.2 Comportamente greșite observate experimental

Comportamente nepotrivite observate în aplicația mobilă dezvoltată cu App Inventor 2:

Afișarea mesajului ”Invalid Bluetooth MAC address” la tranziționarea din ecranul principal în oricare alt ecran. Acest comportament se producea datorită faptului că la alegerea unui dispozitiv bluetooth din lista de dispozitive, mai întâi apelam funcția de conectare și apoi încercam să salvez în baza de date adresa bluetooth-ului selectat din listă prin apelul funcției TinyDB. StoreValue(ListPicker.Selection). Această ordine de apel (mai întâi a funcției BluetoothClient.Connect apoi a funcției ListPicker.Selection provoca returnarea stringului ”true” sau ”false” de către funcția ListPicker.Selection. Așadar apariția mesajului de eroare era justificată;

Oprirea sunetului din fundalul aplicației atunci când sunetul ajungea la final chiar dacă aplicația era în continuare deschisă;

Comportamente nepotrivite observate în aplicația embedded dezvoltată cu Arduino software:

Neacordarea de prioritate sliderelor sau comutatoarelor la intrarea, respectiv ieșirea din ecranul de setare a luminozității

Citire eronată a comutatorului când, pinul dedicat marimii ce se comută, se conectează la 5V.

4.3 Soluții de remediere

Soluții de remediere a comportamentelor greșite observate în App Inventor 2:

Pentru primul comportament greșit din lista de mai sus, în urma testelor efectuate, am interschimbat ordinea de apel a funcțiilor, apelând în cadrul evenimentului ListPicker.AfterPicking mai întâi funcția TinyDB.StoreValue(ListPicker.Selection) care memorează adresa MAC și numele dispozitivului bluetooth selectat din listă și mai apoi am apelat funcția de conectare cu dispozitivul selectat. Ceea ce am constatat în urma testelor este că ListPicker.Selection știe cine a fost elementul selectat din lista de dispozitive bluetooth atâta timp cât înainte nu s-a efectuat conectarea la respectivul bluetooth selectat (un element de tip ListPicker este elementul grafic 5 din Figura 6).

Comportamentul al doilea l-am remediat după ce m-am documentat despre proprietățile și evenimentele puse la dispoziție de mediul App Inventor 2 pentru obiectul de tip Player. Mai exact având la dispoziție evenimentul de Player.Completed (eveniment care apare atunci când durata sunetului de pe fundal s-a scurs) și metoda Player.Start (care pornește sunetul aplicației) am pus condiția ca atunci când evenimentul de Player.Completed apare să se apeleze metoda Player.Start.

Soluții de remediere a comportamentelor greșite observate aplicația ce rulează pe microcontroler:

Primul comportament greșit a fost remediat astfel: mai întâi am inceput monitorizarea a comenzilor primite de la aplicație prin intermediul utilizarului SerialMonitor oferit de mediul Arduino software. Știam că ceea ce trebuie sa recepționez este un string de forma ”Slider”+”poziție cameră” atunci când se intră într-un ecran de setare luminozitate și ”Comutator”+”poziție cameră” atunci când se iasă. Surprinzător concatenat cu aceste caractere aplicația mai trimitea automat, fără posibilitate de control, informații redundante la închiderea și respectiv deschiderea ecranului. Cum aplicația embedded se aștepta să primească strict acele stringuri fără nici o alta informație suplimentară, am constatat că niciodată codul nu va intra pe ramurile if dată citită = ”Slider”+”poziție cameră” sau if dată citită = ”Comutator”+”poziție cameră” . Ultimul pas în remediere a fost să ma folosesc de funcția “startsWith” care a făcut ca aplicația să se aștepte la un string care începe cu șirurile de caractere menționate mai sus. Astfel problema a fost îndepărtată.

Al doilea comportament greșit se petrecea datorită faptului că nu era îndeajuns conectarea pinului de 5V de la sursă la cel de pe comutator dedicat mărimii de comutat, având nevoie de diferență de potențial, deci și de masă. Problema a fost remediată în doi pași:

– conectarea pinului de masă, nu a celui de 5V la pinul de pe comutator dedicat mărimii de comutat;

– configurarea software a pinilor dedicați achiziției de date de la comutatoare ca pini cu pull up.

5 Elemente de marketing

Pentru orice produs, fie că este vorba de un produs inovator sau nu, fie că este vorba de unul simplu sau complex, trebuie luate în calcul și aspecte de marketing pentru a stabili utilitatea lui, care cumpărători sunt vizați, punctele forte și/sau slăbiciunile produsului, etc.

5.1 Costurile implicate în dezvoltarea proiectului

Costurile pentru dezvoltarea produsului sunt prezentate ca și sumă a costurilor pentru fiecare element hardware. Așadar pe baza listei elementelor hardware folosite, se însumează costul fiecăruia și se obține suma totală după cum urmează:

– Placa de dezvoltare Arduino Leonardo – cost 105 RON [5];

– Driver motoare L298 versiunea 2 –cost 79 RON [6];

– Motoreductor Plastic –cost 52 RON (2*26 RON/buc) [7];

– Senzor magnetic brick (Hall) –cost 15 RON [8];

– Servomotor rotație completă –cost 85 RON [9];

– Tastatură universală 16 butoane –cost 27 RON [10];

– Fire pentru conectare –cost 35 RON (5*7 RON) [11];

– Machetă lemn –cost 52 RON (4*13 RON) [12];

– Tijă filetată –cost 19.88 RON (4*4.97 RON) [13];

– Mufă legătură hexagonală –cost 11.28 RON (6*1.88 RON) [14];

Sumă totală: 771.32 RON.

Aceste calcule nu includ și prețul benzilor RGB deoarece lungimea benzii diferă în funcție de dimensiunea camerei în care se montează sistemul și prin urmare și costul diferă.

Având în vedere că sistemul de lumini ambientale este compus atât din elemente software cât și hardware, vom avea și costuri ale dezvoltării software, nu numai costuri materiale.

Așadar, pe lângă costurile materiale se mai adaugă si un număr de ore de lucru acordate pentru implementarea celor două module software și pentru montarea cablajului și a echipamentelor. Ca și o estimare, numărul orelor petrecute pentru dezvoltarea acestor module este de 210h (35zile*6h/zi).

5.2 Public țintă pentru vânzarea produsului

Mai întâi să menționăm scopul produsului pentru a deduce astfel publicul țintă.

Produsul pe care l-am dezvoltat este benefic pentru relaxare și recreere. Utilizatorul poate oricând să profite de opțiunea de a-și configura nuanța luminii și intensitatea în cameră, după bunul lui plac. Așadar după o zi extenuantă, o lumină slabă ca intensitate și o nuanță caldă contribuie la creșterea confortului și a relaxării.

Având aceste aspecte în vedere, consider că sistemul poate fi util pentru absolut orice tip de utilizator care dorește să aducă o notă relaxantă și recreantă casei sale. Nu există o limitare de vârstă sau de orice altă natură pentru profilul cumpărătorului unui astfel de produs. Mai mult de atât sistemul poate viza și saloanele de SPA deoarece o notă de lumină relaxantă este binevenită în mediul calm și recreant al acestor saloane (SPA-ul a devenit parte din viața omului modern care are nevoie să-și regăsească liniștea, echilibrul interior, calmul si energia fără de care cu greu poate face față provocărilor cotidiene);

O altă categorie de cumpărători o reprezintă proprietarii localurilor destinate desfășurării de diverse evenimente de orice natură.

5.3 Analiza SWOT

Scopul implementării acestei analize pe sistemul de lumini ambientale dezvoltat, este acela de a reliefa punctele tari ale produsului, a putea stabili slăbiciunile sale, a determina direcții viitoare de dezvoltare și de a identifica eventualele produse competitive de pe piață care amenință vânzarea produsului în discuție.

Figura 21 Analiza SWOT a sistemului de lumini ambientale

6 Concluzii și perspective

6.1 Concluzii și contribuții

Scopul dezvoltării acestui sistem a fost acela de a aduce o notă relaxantă, liniștită și recreantă mediului în care utilizatorul își desfășoară activitatea sau mediului în care „evadează” după o zi extenuantă. Acest sistem poate înlocui însă și luminile normale din încăpere deoarece sistemul poate reproduce lumina albă și lumina galbenă la o gamă largă de intensități.

Sistemul poate fi util așadar atât pentru orice tip de utilizator, fie că este vorba de o simplă persoană ce deține o locuință de orice dimensiune sau că este vorba de un proprietar de săli de evenimente sau de saloane de SPA.

Caracteristicile sistemului dezvoltat:

– oferă posibilitatea setării a multiple nuanțe de lumini ambientale după bunul plac al utilizatorului din aplicația mobilă;

– oferă utilizatorului posibilitatea de a seta luminozitatea preferată în oricare dintre cele patru camere ale casei atât prin intermediul aplicației mobile, cât și prin intermediul uor comutatoare rotative prezente în fiecare cameră;

– oferă utilizatorului posibilitatea de a stinge toate luminile din casă printr-o simplă apăsare de buton în aplicația mobilă, funcțiune foarte importantă pentru situațiile cănd utilizatorul vrea de exemplu să plece de acasă și să se asigure că nu uită nici o lumină aprinsă;

– oferă posibilitatea stingerii separate a luminilor din oricare cameră printr-o simplă apăsare de buton în aplicația mobilă;

– oferă funcția de memorare a ultimei culori aprinse atunci când utilizatorul stinge lumina în cameră fie de la butonul dedicat camerei fie de la butonul de stingere totală;

– oferă funcția de monitorizare în aplicație a stării dispozitivului bluetooth de pe smartphone cât și a stării conexiunii cu bluetooth-ul din casă;

– oferă funcția de pornire a bluetooth-ului prezent pe dispozitivul mobil, din interiorul aplicației, fără să fie necesară ieșirea din aplicație.

Aceste funcții sunt puse la dispoziție utilizatorului pentru a-i crește confortul și a-i menține starea de relaxare și recreere la un nivel ridicat.

6.2 Abilități dobândite în urma dezvoltării proiectului

În primul rând, în urma dezvoltării proiectului am învățat să lucrez organizat, să imi structurez schematic funcțiunile unui proiect înainte de implementarea acestora, să îmi alcătuiesc mai întâi o imagine de ansamblu bine definită proiectului ce va fi dezvoltat, cu funcțiuni bine definite, înainte de începerea fluxului de dezvoltare a acestuia.

În al doilea rând am învățat să creez aplicații mobile compatibile cu sistemul de operare Android lucru pe care nu îl mai făcusem până să realizez acest proiect și am învățat să folosesc un instrument software nou și anume App Inventor 2.

Nu în ultimul rând mi-am aprofundat cunoștiințele în programare , mi-am îmbunătățit abilitățile de programare pe microcontrolere și am învățat să asamblez și să fac montaje pentru cablaje cu funcții noi și complexe.

6.3 Funcțiuni noi pentru dezvoltări viitoare ale sistemului

Pe viitor, sistemul de lumini ambientale ar putea fi îmbunătățit prin adăugarea unui modul care să recepționeze comenzi vocale de la utilizator sau să recepționeze sunete de diverse tonalități și să comande sistemul de lumini ambientale într-un anume fel. Un exemplu ar fi ca atunci când utilizatorul bate o dată din palme luminile să se aprindă, când bate de două ori să se stingă și la altfel de bătăi să schimbe culori și intensități.

O altă funcționalitate care ar putea fi adăugată pe viitor, ar fi un modul software ce ar face ca sistemul de lumini ambientale să fie acționat pe baza a diferitelor informații achiziționate din camere de la un senzor de prezență sau senzor de mișcare, ca de exemplu informația de persoană prezentă în cameră.

O a treia funcționalitate care ar putea fi adăugată sistemului este una de memorare a culorilor ambientale preferate ale utilizatorului cu posibilitatea de autentificarea a mai multor utilizatori în aplicație, fiecare utilizator având acces la setul lui de culori preferate.

O ultimă funcționalitate ce s-ar putea atașa sistemului ar fi una care ar da posibilitatea utilizatorului să aleagă din aplicație numărul de camere al locuinței (clădirii) pentru a face posibilă configurarea luminilor ambientale într-o clădire cu orice număr de camere. Astfel, la deschiderea aplicației utilizatorul ar fi întrebat “Care este numărul de camere în care veți dori configurarea luminilor ambientale ?” și în funcție de alegerea făcută aplicația să pună la dispoziție un număr de ecrane de culoare egal cu cel de camere și un numaru de slidere în ecranul de luminozitate egal tot cu numărul camerelor.

.

Bibliografie

[1]-http://www.opiniatimisoarei.ro/wp-content/uploads/2016/02/Plan-Mobilitate-Urbana-timisoara.pdf

[1]- http://www.philapark.org/2016/03/tbt-americas-first-multi-storey-parking-garage

[1]-http://www.autoevolution.com/news/how-automated-parking-systems-work-19523.html

[2]- ir. Leon J Hamelink , The Mechanical Parking Guide 2011

[2]-http://www.arduino.cc/en/Main/ArduinoBoardMega2560

[3]-http://www.geeetech.com/wiki/index.php/Serial_Blutooth_Module_%26_Bluetooth_Bee #Specifications:

[4]- https://www.ti.com/lit/ds/symlink/uln2803a.pdf

[5]-http://www.robofun.ro/arduino_mega2560

[6]-http://www.geeetech.com/serial-ttl-bluetooth-module-p-601.html?zenid=3h7j3pjlctsvp27bc2 n0slas23

[7]-http://ro.farnell.com/stmicroelectronics/uln2803a/darlington-array-8npn-2803-dip18/dp/1094428?mckv=sVivjO9MD|pcrid|62659699157|kword|uln2803a|match|p|plid|&CMP=KNC-GRO-FRO-GEN-SKU-STM

[8]-https://www.buerklin.com/en/catalog/Multistep-rotary-switches-series-9030-type-Marquardt-9030-9032-G357200.html

[9]-http://www.cel.ro/surse/sursa-rpc-pwps_040000l_be01a-400w-l/

[10]-http://comingsoon.radioshack.com/solderless-breadboard-jumper-wire-kit/2760173.html#.VXcDi8-qqko

Anexe

A1 Imagini intermediare de pe parcursul dezvoltării

A2 Fragmente esențiale din documentația driverului L298

A3 Documentație sumară Arduino Leonardo

A4 Documentație API-uri folosite și oferite de Arduino software